Rust против параллельного веб-сервера Go, почему Rust здесь медленный?

ProgramBox

Rust против параллельного веб-сервера Go, почему Rust здесь медленный?

Post author:admin
Запись опубликована:22 августа, 2022
Post category:Вопросы по программированию

#concurrency #rust #webserver

#параллелизм #Ржавчина #веб-сервер

Вопрос:

Я пробовал провести сравнительный анализ примера многопоточного веб-сервера в книге Rust, и для сравнения я создал нечто подобное в Go и запустил тест с использованием ApacheBench. Хотя это простой пример, разница была слишком большой. Веб-сервер Go, выполняющий то же самое, был в 10 раз быстрее. Поскольку я ожидал, что Rust будет быстрее или на том же уровне, я попробовал несколько ревизий с использованием futures и smol (хотя моей целью было сравнить реализации, используя только стандартную библиотеку), но результат был почти таким же. Может ли кто-нибудь здесь предложить изменения в реализации Rust, чтобы сделать ее быстрее, не используя огромное количество потоков?

Вот код, который я использовал: https://github.com/deepu105/concurrency-benchmarks

Версия tokio-http самая медленная, остальные 3 версии rust дают почти такой же результат

Вот тесты:

Rust (с 8 потоками, с 100 потоками цифры ближе к Go):

❯ ab -c 100 -n 1000 http://localhost:8080/ This is ApacheBench, Version 2.3 <$Revision: 1879490 gt; Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking localhost (be patient) Completed 100 requests Completed 200 requests Completed 300 requests Completed 400 requests Completed 500 requests Completed 600 requests Completed 700 requests Completed 800 requests Completed 900 requests Completed 1000 requests Finished 1000 requests Server Software: Server Hostname: localhost Server Port: 8080 Document Path: / Document Length: 176 bytes Concurrency Level: 100 Time taken for tests: 26.027 seconds Complete requests: 1000 Failed requests: 0 Total transferred: 195000 bytes HTML transferred: 176000 bytes Requests per second: 38.42 [#/sec] (mean) Time per request: 2602.703 [ms] (mean) Time per request: 26.027 [ms] (mean, across all concurrent requests) Transfer rate: 7.32 [Kbytes/sec] received Connection Times (ms) min mean[ /-sd] median max Connect: 0 2 2.9 1 16 Processing: 4 2304 1082.5 2001 5996 Waiting: 0 2303 1082.7 2001 5996 Total: 4 2307 1082.1 2002 5997

Percentage of the requests served within a certain time (ms) 50% 2002 66% 2008 75% 2018 80% 3984 90% 3997 95% 4002 98% 4005 99% 5983 100% 5997 (longest request)
Вперед:

ab -c 100 -n 1000 http://localhost:8080/ This is ApacheBench, Version 2.3 <$Revision: 1879490 gt; Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking localhost (be patient) Completed 100 requests Completed 200 requests Completed 300 requests Completed 400 requests Completed 500 requests Completed 600 requests Completed 700 requests Completed 800 requests Completed 900 requests Completed 1000 requests Finished 1000 requests Server Software: Server Hostname: localhost Server Port: 8080 Document Path: / Document Length: 174 bytes Concurrency Level: 100 Time taken for tests: 2.102 seconds Complete requests: 1000 Failed requests: 0 Total transferred: 291000 bytes HTML transferred: 174000 bytes Requests per second: 475.84 [#/sec] (mean) Time per request: 210.156 [ms] (mean) Time per request: 2.102 [ms] (mean, across all concurrent requests) Transfer rate: 135.22 [Kbytes/sec] received Connection Times (ms) min mean[ /-sd] median max Connect: 0 2 1.4 2 5 Processing: 0 203 599.8 3 2008 Waiting: 0 202 600.0 2 2008 Total: 0 205 599.8 5 2013

Percentage of the requests served within a certain time (ms) 50% 5 66% 7 75% 8 80% 8 90% 2000 95% 2003 98% 2005 99% 2010 100% 2013 (longest request)

1. tokio_minihttp — это просто доказательство концепции, и оно не поддерживается. Глава о многопоточном веб-сервере в книге — всего лишь пример. Стандартная библиотека Go имеет хорошо переработанную и оптимизированную реализацию http. Чтобы получить равное сравнение, я бы попробовал использовать Hyper или Actix-Web.

2. сообщение хорошее, но тест плохой. стоит обновить или закрыть / удалить.

3. @mh-cbon что вы имеете в виду, не могли бы вы уточнить, плз

4. потому что, хотя некоторые люди будут утверждать, что ab не является подходящим инструментом для тестирования, по крайней мере, сообщение содержит понятное и воспроизводимое содержимое. Хотя из-за того, что версия rust не так хороша, как должна быть, это ошибка. сравнение яблок и груш. Я видел ваш ответ ниже. это улучшает ситуацию.

5. Да ладно, разве это не суть SO, это вопрос, а не утверждение. Если бы версия Rust была настолько хороша, насколько это возможно, мне не пришлось бы правильно задавать вопрос.

Ответ №1:

Я только сравнил ваши «rustws» и версию Go. В Go у вас есть неограниченные программы (даже если вы ограничиваете их все только одним ядром процессора), в то время как в rustws вы создаете пул потоков с 8 потоками.

Поскольку ваши обработчики запросов спят 2 секунды на каждый 10-й запрос, вы ограничиваете версию rustws до 80/2 = 40 запросов в секунду, что вы и видите в результатах ab. Go не страдает от этого произвольного узкого места, поэтому он показывает вам максимальную обработку ит-свечи на одном ядре процессора.

1. Вот способы, которые я могу придумать, которые могут помочь с данным узким местом: 1. Асинхронный код 2. Потоки 3. Процессы. Вы могли бы увеличить лимит потока до чего-то огромного, например 1000, и посмотреть, как это происходит. Однако потоки не будут такими эффективными, как программы или асинхронный код.

2. Правда, на самом деле, основываясь на комментарии к Reddit, я смог получить ту же производительность из rustws_async образца github.com/deepu105/concurrency-benchmarks/blob/main /…

Ответ №2:

Я, наконец, смог получить аналогичные результаты в Rust, используя библиотеку async_std

 ❯ ab -c 100 -n 1000 http://localhost:8080/
This is ApacheBench, Version 2.3 <$Revision: 1879490

gt;

Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/

Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking localhost (be patient)

Completed 100 requests

Completed 200 requests

Completed 300 requests

Completed 400 requests

Completed 500 requests

Completed 600 requests

Completed 700 requests

Completed 800 requests

Completed 900 requests

Completed 1000 requests

Finished 1000 requests
Server Software:

Server Hostname:        localhost

Server Port:            8080
Document Path:          /

Document Length:        176 bytes
Concurrency Level:      100

Time taken for tests:   2.094 seconds

Complete requests:      1000

Failed requests:        0

Total transferred:      195000 bytes

HTML transferred:       176000 bytes

Requests per second:    477.47 [#/sec] (mean)

Time per request:       209.439 [ms] (mean)

Time per request:       2.094 [ms] (mean, across all concurrent requests)

Transfer rate:          90.92 [Kbytes/sec] received
Connection Times (ms)

              min  mean[ /-sd] median   max

Connect:        0    2   1.7      2       7

Processing:     0  202 599.7      2    2002

Waiting:        0  201 600.1      1    2002

Total:          0  205 599.7      5    2007
Percentage of the requests served within a certain time (ms)

  50%      5

  66%      6

  75%      9

  80%      9

  90%   2000

  95%   2003

  98%   2004

  99%   2006

 100%   2007 (longest request)

 

Вот реализация
 use async_std::net::TcpListener;
use async_std::net::TcpStream;
use async_std::prelude::*;
use async_std::task;
use std::fs;
use std::time::Duration;

#[async_std::main]
async fn main() {
    let mut count = 0;

    let listener = TcpListener::bind("127.0.0.1:8080").await.unwrap(); // set listen port

    loop {
        count = count   1;
        let count_n = Box::new(count);
        let (stream, _) = listener.accept().await.unwrap();
        task::spawn(handle_connection(stream, count_n)); // spawn a new task to handle the connection
    }
}

async fn handle_connection(mut stream: TcpStream, count: Box<i64>) {
    // Read the first 1024 bytes of data from the stream
    let mut buffer = [0; 1024];
    stream.read(amp;mut buffer).await.unwrap();

    // add 2 second delay to every 10th request
    if (*count % 10) == 0 {
        println!("Adding delay. Count: {}", count);
        task::sleep(Duration::from_secs(2)).await;
    }

    let contents = fs::read_to_string("hello.html").unwrap(); // read html file

    let response = format!("{}{}", "HTTP/1.1 200 OKrnrn", contents);
    stream.write(response.as_bytes()).await.unwrap(); // write response
    stream.flush().await.unwrap();
}

1. и при выполнении 10 Тыс. запросов асинхронная реализация rust в целом ускоряется на несколько секунд.

2. Эта версия rust должна быть быстрее, чем версия Go, потому что на самом деле она не делает то же самое. Он просто принимает TCP-соединения и записывает файл обратно, он не представляет реальный веб-сервер, как у вас в версии Go. Сравнение не совсем справедливо.

3. Итак, если я использую HTTP-библиотеку, такую как hyper в Rust, это будет более справедливо? или вы можете предложить что-то лучшее для Go?

4. Я написал версию TCP в Go, чтобы сделать ее более справедливой. Может быть небольшое улучшение. Мне придется несколько раз запускать тест ab для подтверждения github.com/deepu105/concurrency-benchmarks/blob/main/gows_tcp /…

5. HTTP-версия быстрее, чем чистая TCP-версия на 0,1 секунды, и все еще на 0,1 с медленнее, чем Rust для 10000 запросов при 100 одновременных запросах

Метки: Rust против параллельного веб-сервера Go, почему Rust здесь медленный?