Hacker News Digest

После публикации результатов тестов, показывающих, что Cloudflare Workers значительно уступают по производительности Vercel, команда Cloudflare проанализировала тест и обнаружила ряд факторов, повлиявших на результат.

Во-первых, выяснилось, что в тесте использовалась более старая версия Cloudflare Workers, которая не была оптимизирована для этого конкретного типа нагрузки. Cloudflare немедленно выпустила обновление, улучшающее производительность.

Во-вторых, в тесте использовалась библиотека, которая вносила дополнительные накладные расходы на стороне Cloudflare, но не на стороне Vercel. После замены библиотеки на более оптимизированную, разница в производительности значительно сократилась.

Кроме того, команда обнаружила, что тест не полностью изолировал переменные — часть замедления была вызвана сетевыми задержками, а не производительностью самого Workers. После настройки теста для измерения только времени выполнения кода, разница стала минимальной.

В конечном счете, Cloudflare удалось не только догнать, но и превзойти Vercel по некоторым показателям, просто устранив узкие места в своем стеке.

Ключевой вывод: всегда полезно проверять свои тесты и окружение, прежде чем делать выводы о производительности. Иногда проблема не там, где кажется.

• Cloudflare и Vercel продолжают обмениваться тестами и оптимизациями, но вместо обвинений они фактически сотрудничают, чтобы улучшить свои продукты.
• Стороны соревнуются в прозрачности: Cloudflare публикует исходные данные теста, а Vercel делает тот же тест открытым исходным кодом.
• Сообщество отмечает, что обе платформы теперь демонстрируют лучшую производительность, чем раньше, и что конкуренция в конечном счете выгодна для пользователей.

PostgreSQL 18 представил новую опцию конфигурации io_method, дающую пользователям больше контроля над обработкой дискового ввода-вывода. В отличие от версии 17, где использовались только синхронные запросы, в 18 доступны три режима: sync (старое поведение), worker (новый стандарт по умолчанию с фоновыми процессами) и io_uring (асинхронный интерфейс Linux для чтения с диска).

В ходе тестирования с использованием sysbench на базе данных размером ~300 GB на различных конфигурациях EC2 были получены неожиданные результаты. При одиночном подключении и сетевых хранилищах (gp3, io2) версии 18 в режимах sync и worker показали производительность выше, чем 17 и 18 с io_uring. Полные результаты для высококонкурентных сценариев и быстрых NVMe-накопителей еще ожидаются.

• Обсуждение подтвердило, что при использовании локального NVMe диска разница между 17 и 18 версиями PostgreSQL незначительна, но при этом сетевое хранилище всё ещё сильно уступает по производительности.
• Участники отметили, что важно понимать, что при использовании облачного хранилища вы платите не за IOPS, а за то, чтобы кто-то другой имел дело с резервным копированием, репликацией и обслуживанием оборудования.
• Также было отмечено, что в настоящее время PostgreSQL не поддерживает прямой ввод/вывод, но над этим ведётся работа.
• Были высказаны опасения, что использование VPS с локальным диском может повлечь за собой вопросы надёжности, так как такие диски, как правило, не имеют избыточности.
• В контексте обсуждения также поднялся вопрос о том, что влияние на производительность может оказать использование или отсутствие расширения, такого как TimescaleDB.