Comments 17
Я стал страшно далек от таких низкоуровневых деталей, но разве nginx не использует для раздачи статики sendfile? Тогда тоже не должно быть накладных расходов на копирование в userspace и обратно.
А так может получиться, что когда реализуешь полноценные TCP и HTTP, поддержку прочих плюшек типа HTTPS, rate-limiting, error pages, и т.д. и т.п., окажется, что все выигрыши где-то потерялись, а стоимость поддержки такого решения чрезвычайно высока.
Для TCP есть библиотеки под dpdk. А http не так уж и сложно/заумно реализовывать, если надо.
Понятно, что для раздачи статики лучше взять nginx- его все админы умеют настраивать.
Ну и использовать http для высокой нагрузки — это глупо. Канал загружает плохо (да, я знаю про http Pipelining), накладных расходов на заголовки много. Бинарные протоколы рулят.
А http не так уж и сложно/заумно реализовывать, если надо.
С этих слов начиналось очень много epic fail'ов. Практически все не так уж сложно реализовать. До тех пор пока не надо укладываться в дедлайны, пока не нужно думать о поддержке всего этого в течении многих лет (особенно будет «приятно», если автор подобного велосипеда на атомном реакторе уйдет в другое место, а поддерживать его придется менее продвинутым коллегам), исправлении уязвимостей безопасности, и так далее и так далее.
Эх… В жизни все направлено на оптимизацию прибыли, а оптимизация быстродействия часто противоположна оптимизации прибыли.
Как качественно перевести книгу издательству, если качественный перевод требует большего времени и больших затрат на переводчиков (кого попало не возьмешь, а грамотный опытный переводчик будет стоить дороже)? Пока будет готовиться качественный перевод, скажем, книги по Rust, другие издательства напечатают книги по Rust плохого качества, и убьют рынок для качественной книги — затраты на качественный перевод никогда не отобьются.
Как сделать качественный быстродействующий сайт, если ресурсы надо тратить на захват рынка, исправление неотложных багов, добавление свистелок, которые нравятся тем пользователям, от которых зависит прибыль?
К сожалению, как-то приходится с этим жить.
Если любая компания вместо того, чтобы сосредоточиться на своем продукте, будет писать собственные реализации TCP и HTTP, прогресс совсем замрет.
(да, я знаю про http Pipelining)
Зато создаётся ощущение, что про HTTP/2 не знаете
sendfile будет работать только когда на диске файл лежит сразу как надо. Если используется gzip или ssl, то всё будет копироваться в userspace и обратно.
А ещё файл на диск можно положить сразу разбитым на tcp пакеты, и тогда нужно будет только поправить адреса и checksum, ну если приспичило ну совсем быстро что-то отдать.
Когда-то был еще HTTP сервер в ядре...
У всех разный опыт, конечно. Рядом со мной всегда происходят такие истории:
1) Можно реализовать это самостоятельно, у нас простой вырожденный случай, мы получим свое быстрое решение
2) Через месяц: «Ой, а вот надо бы этот и это случай поддержать»
3) Еще через месяц: «Оказывается, существующее ПО рассчитывает на то и это, придется наш велосипед расширить для совместимости с существующими клиентами»
4) Еще через месяц: «На production страшный баг, срочно требуется до 6 утра найти и накатить патч, иначе бизнес потеряет кучу денег»
И т.д. Свое решение всегда будет расти. Его надо будет расширять, портировать на новые платформы, тестировать, поддерживать. И в большинстве случаев на это потребуется намного больше денег, чем купить более дорогой или еще один сервер.
То есть теоретически я красоту и крутость понимаю. Но на практике, скорее всего, выгоду из этого может извлечь только Google, Яндекс и Cloudflare. Остальные, если сунутся, увязнут по шею.
Да и у всех разные задачи, конечно. В моей практике есть гораздо более доступные цели для оптимизации. Если я в текущем проекте начну оптимизировать раздачу статики, то даже самый дотошный пользователь не заметит никаких изменений. Зато есть десяток мест, где я могу не только произвести вполне заметное измеримое улучшение, но и при этом получить еще более поддерживаемый читаемый код.
Но это, конечно, мой случай. Допускаю, что есть места, где другая ситуация, и единственным узким местом может стать копирование данных из ядра в процесс и обратно. Просто уверен, что таких проектов, единицы проектов в мире.
DPDK (https://www.dpdk.org/) — это фреймворк для работы с сетью в обход ядра.
Ядро ОС выполняет функцию (де)/мультиплексирования при работе приложений с сетевым оборудованием. Тут получается, что данный фреймворк фактически монопольно, предоставляет сеть только одному приложению, из-за этого становится быстрее, но теряется универсальность.
Реальное применение подобного подхода очень ограниченно, хотя и не нулевое.
1M HTTP rps на 1 cpu core. DPDK вместо nginx+linux kernel TCP/IP