Erlang, HTTP, highload
lionet рассказывал о том, как делал свой HTTP сервер, потому что имеющихся возможностей эрланга стало не хватать.
Я столкнулся с похожими проблемами, когда возник вопрос про раздачу более гигабита. Реализация HTTP в эрланге на многих десятках тысяч запросов в минуту не оптимальна. Основная проблема мне видится в том, что ошметки запроса (заголовки) по одному гоняются из драйвера в код и там аккумуллируются.
Итог простой: раздача гигабита (сырая ретрансляция) требует больше одного ядра, что выглядит плохо на фоне varnish, которому требуется на это не более 30%.
Когда Лев рассказывал про свой косер, я ему сказал, что мне видится его архитектура неудачной с той точки зрения, что внутри эрланга уже есть свой libevent со всем чем только нужно и хороший API к нему в виде драйверов. Если бы он свой косер написал в виде драйвера, то всё работало бы ничуть не хуже, но при этом в одном адресном пространстве с бизнес-логикой.
Я решил провести эксперимент и спустить обработку HTTP вниз в драйвер. Взял http_parser.c, который был выпилен из nginx и используется в Node.js и воткнул его в эрланговый драйвер.
Получилось неплохо.
Итог такой: этот сырой прототип раздает гигабит (./test.erl + ab) примерно в 20-30% ядра. Ровно такой же бенчмарк на обычном эрланговом HTTP-сервере показывает около 100%. На основании этого можно сделать вывод о том, что действительно обработка самого протокола силами эрланга приводит к ужасной потере скорости и развивать данный кусок кода стоит.
Я столкнулся с похожими проблемами, когда возник вопрос про раздачу более гигабита. Реализация HTTP в эрланге на многих десятках тысяч запросов в минуту не оптимальна. Основная проблема мне видится в том, что ошметки запроса (заголовки) по одному гоняются из драйвера в код и там аккумуллируются.
Итог простой: раздача гигабита (сырая ретрансляция) требует больше одного ядра, что выглядит плохо на фоне varnish, которому требуется на это не более 30%.
Когда Лев рассказывал про свой косер, я ему сказал, что мне видится его архитектура неудачной с той точки зрения, что внутри эрланга уже есть свой libevent со всем чем только нужно и хороший API к нему в виде драйверов. Если бы он свой косер написал в виде драйвера, то всё работало бы ничуть не хуже, но при этом в одном адресном пространстве с бизнес-логикой.
Я решил провести эксперимент и спустить обработку HTTP вниз в драйвер. Взял http_parser.c, который был выпилен из nginx и используется в Node.js и воткнул его в эрланговый драйвер.
Получилось неплохо.
Итог такой: этот сырой прототип раздает гигабит (./test.erl + ab) примерно в 20-30% ядра. Ровно такой же бенчмарк на обычном эрланговом HTTP-сервере показывает около 100%. На основании этого можно сделать вывод о том, что действительно обработка самого протокола силами эрланга приводит к ужасной потере скорости и развивать данный кусок кода стоит.