Вот теперь хорошо, теперь 100к рпс

А вот добился я этого посредством распараллеливания обработки запросов. Например, на бенчмарках выше - я принимал, обрабатывал, отдавал запросы, в одном потоке. По сути, принял запрос - обработал - отдал ответ - и так далее, по кругу. Как вы понимаете, не самый эффективный способ. Решил пойти по пути торнадо: форкать процесс вебсервера во время его инициализации. По сути - благодаря флагу SO_REUSEPORT, я просто понаспавнил форков, где в каждом - свой сокет, слушающий один и тот же порт (такая штука появилась в ядре linux 3.9 версии, к слову), а вот подключения делигируются ядром уже выбранному непосредственно ядром сокету. Получается, что каждый процесс как отдельный вебсервер, и у каждого свои клиенты. Получается, что ядро у нас некого рода лоадбалансер, который прокидывает подключения на нужный вебсервер

Цель выполнена: выжать 50к РПС. На данный момент, с 4 форками (5 процессами), вебсервер выдает такие результаты: 100к рпс для статичного кешированного файла, 120к рпс для статичного перманентного редиректа (который происходит внутри вебсервера). Следующая цель: выжать 200к рпс для статичного кешированного файла. #roadtothe200kRPS #родтзе200кРПС

Теперь ещё лучше. Я перенёс форк в непосредственно класс-контроллер (главный класс веб-сервера, точка вхождения), убрал пару ненужных конструкций. Теперь стало ещё приятней: производительность ведь выросла на целых 25к рпс

Смешанные эмоции. Ебанул 12 форков (ровно столько, сколько у меня потоков в процессоре). 175к рпс конечно круто, но меня напрягает то, что процессор практически всё время тестирования был загружен на сотку. К примеру, с 6 процессами, он был загружен на 60-65% (что тоже много, как по мне). Зато результаты неплохие. Интересно, зеон же схавает?

180к рпс для статичного перманентного редиректа. Вау.

Щас бы бенчмаркать пасхалку

Решил посмотреть, что же будет, если я запущу вебсервер на малине

Как думаете, это результаты измерения с всего 1 серверным процессом? НЕТ, это 4 серверных процесса на 4 ядра

Какая же производительность у сервера на 1 процессе? А вот.

Оказывается, WSL не поддерживает флаг SO_REUSEPORT для сокетов. Держу в курсе

Пришлось для этого даже специально проверку делать, а не запускается ли вебсерв случаем под всл, и случаем не установлено ли количество серверных процессов на не-ноль

А ещё, гит почему-то перманентно игнорирует мою папочку logs. А её даже в гитигноре нет! Вручную git add logs/ ничего не дает. Магия, не иначе!

А мне ведь пришлось костылить пикрелейтед

Ну штош, столько времени спустя - могу себе позволить перекроить файловую иерархию вебсервера так, чтобы получился в итоге питоний пакет

Установить можно, просто скачав файл куда угодно, и ввести команду pip3 install path/to/package/rush-2.0.0-py3-none-any.whl


Также, в скором времени намерен залить сеё произведение исскуства на PyPI, чтобы прям по красоте

Ахуеть. У меня, оказывается, имя проекта спиздили

Это, кстати, первый мат за всё время существования канала. Ну, что поделать. По такому поводу - можно

А если серьезно, то этому репозиторию уже года 3. И вот на самом деле, мне крайне обидно, ведь и на PyPI он тоже называется rush. Неужели мне придется публиковать репозиторий под именем rush-webserver?..

Итак, я решил вести версионирование проекта. Буду делать это по старой-доброй схеме - майорный номер, минорный, и патч. Майорный будет отображать итерацию проекта, минорный - крупные изменения/привносения новых фич и возможностей в интерфейсе. Патчи же будут означать номер выпуска с багфиксами. На каждый багфикс/малейшее изменение в коде я, конечно, не буду инкрементировать патч, но это будет некого рода накопительные выпуски. Накапливается пачка багфиксов - выпускаю в релиз

Итак - цель частично выполнена. Частично - потому что это тестируется лишь эксперементальная, PoC-фича. Я просто реализовал кеширование ответов с файлами (почему нет - они ведь всегда одни и те же). И реализовал я это прямо в объекте rush.core.entities.Request. Это, конечно, круто, но для этих целей я собираюсь (в отдельной ветке, конечно же) имплементировать сессионный движок - на каждого нового пользователя будет создаваться условно свой инстанс объекта Session, с кукисами, локальным кешированием и шлюхами

А, новая цель. Выжать 250к RPS на том же статичном файле. #roadtothe250kRPS #родтзе250кРПС