Post #50
68
Как думаете, это результаты измерения с всего 1 серверным процессом? НЕТ, это 4 серверных процесса на 4 ядра
- 👎 1
Channel Public Channel
ЧА - Subscribers
- 122
- Photos
- 216
- Videos
- 3
- Links
- 144
Showing posts older than #51 · Back to latest
Older Posts 20 shown
Post #49
66
Решил посмотреть, что же будет, если я запущу вебсервер на малине
- 👎 1
Post #48
68
Щас бы бенчмаркать пасхалку
- 👎 1
Post #47
68
180к рпс для статичного перманентного редиректа. Вау.
- 👎 1
Post #46
69
Смешанные эмоции. Ебанул 12 форков (ровно столько, сколько у меня потоков в процессоре). 175к рпс конечно круто, но меня напрягает то, что процессор практически всё время тестирования был загружен на сотку. К примеру, с 6 процессами, он был загружен на 60-65% (что тоже много, как по мне). Зато результаты неплохие. Интересно, зеон же схавает?
- 👎 1
Post #45
71
Теперь ещё лучше. Я перенёс форк в непосредственно класс-контроллер (главный класс веб-сервера, точка вхождения), убрал пару ненужных конструкций. Теперь стало ещё приятней: производительность ведь выросла на целых 25к рпс
- 👎 1
Post #44
73
Чайник из Юты Пожалуй, буду разбавлять подобные посты в официальном стиле ещё и неким подобием дневника разработки вебсервера. Конечно, без всги/авсги/ювсги/придумайте-сами, а просто standalone. Однако, так даже интереснее: всегда хотел поработать напрямую с http. Сразу…
Цель выполнена: выжать 50к РПС. На данный момент, с 4 форками (5 процессами), вебсервер выдает такие результаты: 100к рпс для статичного кешированного файла, 120к рпс для статичного перманентного редиректа (который происходит внутри вебсервера). Следующая цель: выжать 200к рпс для статичного кешированного файла. #roadtothe200kRPS #родтзе200кРПС
- 👎 1
Post #43
71
А вот добился я этого посредством распараллеливания обработки запросов. Например, на бенчмарках выше - я принимал, обрабатывал, отдавал запросы, в одном потоке. По сути, принял запрос - обработал - отдал ответ - и так далее, по кругу. Как вы понимаете, не самый эффективный способ. Решил пойти по пути торнадо: форкать процесс вебсервера во время его инициализации. По сути - благодаря флагу SO_REUSEPORT, я просто понаспавнил форков, где в каждом - свой сокет, слушающий один и тот же порт (такая штука появилась в ядре linux 3.9 версии, к слову), а вот подключения делигируются ядром уже выбранному непосредственно ядром сокету. Получается, что каждый процесс как отдельный вебсервер, и у каждого свои клиенты. Получается, что ядро у нас некого рода лоадбалансер, который прокидывает подключения на нужный вебсервер
- 👎 1
Post #42
109
Вот теперь хорошо, теперь 100к рпс
- 👎 1
Post #40
72
Прогресс. Сверху - Rush-v2. Снизу - Rush-v1. Не смотря на то, что РПС выросло практически в 2 раза, я крайне недоволен тем, что задержка на 14 мс возросла :(
- 👎 1
Post #39
71
А фокус был в пикрелейтед. А именно - в заголовке Connection: close. По сути, каждый раз, когда клиент хочет подключиться к серверу - сервер его отшивает, аки лесбиянка парней. Убрав заголовок, под всл сервер начал выдавать уже 1.5к рпс (мало). Под мятой - уже 21к. Неплохо, но хотелось бы 30к как минимум
- 👎 1
Post #38
77
Post #37
64
Это пиздец, товарищи
Post #36
66
По крайней мере, оно пыталось отдать страничку с текстом "500 Internal Server Error". Уже хоть что-то
Post #35
67
"А, так оно вообще не работает"
Post #34
67
"Но почему оно так медленно работает?.."
Post #33
68
"Оно запускается без ошибок!"
Post #32
72
Тру стори
Post #31
80
Вот вроде и неплохая либа. Шустрая, на С, круто-классно. Но курва документация - просто нищебродская. К тому же, даже непонятно, как парсить файлы из post-запросов. Наглядный пример того, что хорошая документация - 50% библиотеки.
PyPI http-parser http request/response parser Post #30
81
А, и да, я наконец-то вспомнил пароль от аккаунта.