В эксперименте Lupyd PostgreSQL обработал 9 718 запросов в секунду по протоколу QUIC, сетевому протоколу передачи данных, при средней задержке 246 мс. Для сравнения, TCP показал 4 749 запросов в секунду и задержку 7 088 мс.

Авторы связывают разницу с очередью на стороне клиента: при сетевой задержке 30 мс запросы по TCP ждали свободных соединений, а QUIC распределял их по потокам уже открытых соединений. Это был синтетический тест с лёгким запросом, занимавшим около 0,5 мс внутри базы данных.

QUIC уменьшил очередь, но потреблял больше процессорного времени на стороне клиента и не ускорял выполнение запросов в самой базе данных.

Проверка утверждений:

  • В эксперименте Lupyd PostgreSQL по потокам QUIC обработал 9 718 запросов в секунду при средней задержке 246 мс, тогда как TCP показал 4 749 запросов в секунду и 7 088 мс. (подтверждено самой публикацией: доказательство; «Peak Avg Latency 7,088 ms 246 ms TCP experienced queue delay as requests waited for available sockets. Completed QPS 4,749 9,718 QUIC drained incoming queries without client-side queuing.»)
  • В тесте TCP-запросы ждали свободных соединений в очереди на стороне клиента, а QUIC распределял запросы по потокам существующих соединений. (подтверждено самой публикацией: доказательство; «In the QUIC run, queries were assigned to open streams across the 50 connections up to the 40-stream limit. In-flight queued queries remained low (between 0 and 41) throughout the ramp, with latency remaining consistent between 170ms and 246ms.»)
  • Тест проводили на искусственном канале с задержкой 30 мс и лёгким запросом, который занимал около 0,5 мс внутри базы данных. (подтверждено самой публикацией: доказательство; «Simulated Latency: 30ms round-trip latency injected into the client link via netem / tc . Test Query: SELECT trunc(random() * 100) FROM generate_series(1, 10) (~0.5ms database time).»)
  • В тесте QUIC уменьшил очередь, но использовал больше процессорного времени на стороне клиента, а мультиплексирование транспорта не ускоряет выполнение запросов в самой базе данных. (подтверждено самой публикацией: доказательство; «QUIC’s client-side CPU consumption was higher (~970ms CPU vs ~370ms for TCP). User-space packet framing and crypto parsing in s2n-quic require more CPU cycles than kernel-offloaded TCP. Multiplexing network transport does not speed up slow queries or make the database engine faster.»)

Первоисточники:

оценка 54,7 из 100 · тип: исследование