Низкая производительность веб-сервера gunicorn (python) на BSD (Free и Open)

Почему при увеличении workers производительность поднимается слабо?

sqlite не умеет параллельную запись, например.

Плюсую предыдущего оратора. В проде ты не будешь использовать sqlite базу в несколько воркеров. Сделай такие же тесты с другой базой.

Ты же понимаешь что этой инфы вообще недостаточно чтобы даже предположения делать. Продолжай наблюдения, пиши логи, пиши профилировочные логи, профилируй исполнение, попробуй сменить бд, посмотри какие системные вызовы и в каком количестве происходят при чтении записи в бд, вообще для начала пойми что именно замедляет работу. Раз ты это все гоняешь на виртуалках может статься так, что система виртуализации просто лучше работает с линуксом, причин может быть сколько угодно.

sqlite не умеет параллельную запись

Ок, спасибо, не знал, попробую потом.

anonymous:

причин может быть сколько угодно

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

PS.

А могут результаты сильно отличаться для виртуалки дома, и для «реальной» VPS в облаке (IaaS)?

А uwsgi пробовал? Интересно было бы взглянуть на аналогичные результаты, есле через него трафик пускать.

Какой-нибудь meinheld-gunicorn может быть быстрее на низких нагрузках. На высоких — как повезёт, но тут же тестируют ab, он же до сих пор сам является боттлнеком? Хотя это питон и даже не asgi, высокой скорости тут не будет.

Да, надо действительно протестировать. FreeBSD vs ArchLinux какой-нить Flask… а чего алхимия, а не http://docs.peewee-orm.com/

Да ежу понятно, что у него затык на sqlite, и на вводе-выводе. ТС, ты на вртуалке крутишь? Давай все вводные и код, если можно на github/gitlab

Так, я немного ошибся… Почему-то старая кука не подходит для нового сервера (там только userid и password, ну и временная метка, почему не подходит?). После ФриБСД – и Опен, и Лин возвращали редиректы (на логин), поэтому было быстро.

Я обновил данные в ОП. Линукс немного быстрее Фри (но не «рвёт»). Опен в 2 раза сливает Линуксу (ожидаемо пожалуй :( )

Другую базу попозже попробую. Да, я пишу там в базу, забыл об этом когда писал ОП. Ну видимо да, узкое место sqlite, не догадался. Так что это стало понятно, и соответственно совсем не спешно.

Я многое сделал для бэка, но впереди ещё много работы (и другой тоже очень много). Можно и переписать. Что посоветуете типа Фласка (маленькое, не фул-стэк), но асинхронное? x3al

menangen

если можно на github/gitlab

Ох, я бы не хотел раскрывать. Да и не нужно пожалуй уже теперь.

а чего алхимия, а не peewee-orm

Исторически вышло (да, у меня фласк). Искал какой-нибудь kick-start-проект, нашёл flask-user, а там используется алхимия.

ты на вртуалке крутишь?

Ну да, qemu.

KernelPanic

А uwsgi пробовал?

Не, я его боюсь. Говорят он очень (слишком) гибкий, надо понимать что ты делаешь.

ab – не инструмент тестирования производительности бэкенда, о чем английским по белому у него на странице написано. что твой факап с 302 наглядно показал, кстати

Что используют умные разработчики вместо аб?

умные разработчики используют умных тестировщиков. а в твоем случае могу посоветовать либо loadrunner чтобы просто прикинуть масштаб проблемы, либо сразу самописный скрипт с профайлером (из которого тебе нужен в основном профайлер), либо забить – производительность тестируют не с потолка, а на основе реальных требований к производительности реальных сценариев.

либо сразу самописный скрипт с профайлером

Профайлер - это питоновский? Будет прямо мой код запускать, без вэб-сервера? Типа как юнит-тесты?

запускать твой код будет скрипт, селениумовский в браузере или ещё какой, а профайлер тебе покажет тайминги и бутылочные горлышки. я тебе пытаюсь донести что тебе в первую очередь нужно понять, что и как у тебя тормозит внутри твоего кода, а уже потом, когда ты будешь уверен в бэкенде – строить профили нагрузки и под них подбирать запускалку.

Что посоветуете типа Фласка (маленькое, не фул-стэк), но асинхронное?

https://fastapi.tiangolo.com/

Оно почти как flask в использовании.

Если очень хочется делать бенчмарки на тему «оверхэд фреймворка» или «минимальное время ответа», есть wrk.

Спасибо!

скрипт, селениумовский

Только что про них узнал, сходил на их сайт. Не, до деплоя мне это не нужно. И после думаю тоже.

строить профили нагрузки и под них подбирать запускалку.

Тоже не нужно. Пока не начнутся тормоза. Только потом заинтересуюсь.

У меня сейчас другая цель была. Проверить что нигде не накосячено в целом. В смысле – не сделаны грубые ошибки. Типа как при вычислениях в октаве нужно поставить бинарный пакет atlas-а (будет в 3 раза быстрее), а лучше самому откомпилить (ещё в 3 раза). Не использовать атлас (ну либо проприетарные аналоги типа мкл) с октавой – это глупость. Не знаю правда что аналогично глупого может быть здесь, в вэб.

А можешь ещё на мой вопрос анону ответить:

А могут результаты сильно отличаться для виртуалки дома, и для «реальной» VPS в облаке (IaaS)?

(это именно в этом, интересном мне контексте, проверять что не накосячено «в целом»)

А могут результаты сильно отличаться для виртуалки дома, и для «реальной» VPS в облаке (IaaS)?

Зависит от того, насколько твой IaaS-провайдер оверселлит.

А ну тогда ок, дома можно тестировать-профилировать в виртуалках, и это будет надёжно. Супер, спасибо.

Я бы на твоём месте не заморачивался со всей этой производительностью, и не городил велосипеды, а взял бы django + django rest framework. На них ты быстро напишешь что тебе нужно, если будешь внимательно читать документацию, а так тебе приходится самому все батарейки собирать руками, это точно не для новичков.

Если уж ты так хочешь супер быстрый бекенд - то это тебе к golang / node.js (jit), ещё просто попробуй pypy с jit для flask + pewee, и fastapi как тебе выше рекомендовали, для асинхронных движков нужны асинхронные драйвера к бд, либо обертки к ним 😀 django 3 тоже асинхронная и многопоточная, кстати

Есть ещё вариант «к чёрту фласк, асинхронность, sqlite, postgres, vps и вообще всё это». AWS с питоновыми лямбдами легко скейлится до любого числа запросов в секунду и ограничивается только кредитной картой.

Не, ну тестировать высоконагруженный хост с ORM и sqlite в качестве субд - это несколько «тупо»

как ты умело прикрываешь лень фразами «в целом, грубые ошибки, другая цель»

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

асинхронная и многопоточная джанга, святые угодники LMAO

Ну, она запускается в несколько процессов по количеству ядер, вроде как, этакая «много поточность по питоновски», плюс в каждом процессе асинхронный обработчик, да

fastapi.tiangolo.com

Почитал, и понял что я неправильно спросил :) Можно я спрошу иначе: для моего паттерна пользования сервером – насколько актуальна (быстрее) асинхронщина?

У меня классический случай: вопрос-ответ. Динамических данных мало, в основном только заказы юзеров (потом сделаю referrals и рейтинги продуктов). Это не будет форум или сайт объявлений. Главная цель сервера – быстро отвечать аппу (к каким продуктам у юзера есть доступ, и пр.). Пользователи будут работать именно с аппом, а не с сайтом.

Подбрасывание файликов клиенту, которые он по-любому запросит (стили, жс), пуши, long-poll http, SPA, вот это всё – мне не нужно. Статику думаю раздавать (каким-нибудь) клаудфлэром.

Насколько будет быстрее асинхронщина?

menangen

Если уж ты так хочешь супер быстрый бекенд…

Почему не предлагаешь C++? :) Цели сделать супер быстрый бэкенд нет (и не будет). Просто чтобы не был откровенно тормозным из-за какой-то глупости, которую я сейчас возможно сделаю.

Я бы на твоём месте не заморачивался со всей этой производительностью, и не городил велосипеды … самому все батарейки собирать руками

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

У меня всё очень специфично. Например, должна быть интеграция с аппом. Ещё хочу объединение истории заказов оплаченных разными системами оплаты (пэйпэл на сайте и гугл пэй на андроиде). Это значит объединение 2-3 пользовательских профиля в 1. Админка тоже специфичная.

Я скоммуниздил (MIT) регистрационный код (подтверждение емэйла, забыл пароль, и пр.) из flask-user, и сессионную работу (куки там всякие) оттуда же. Я ничего этого сам не писал. Из более-менее стандартных фич – мне нужно будет сделать логин через пэйпэл и гугл (oauth? не пробовал пока), и приём оплаты через гугл (пп сделал). Всё остальное – собственно бизнес-логика, моя специфика. Никакой фул-стэк фрэймворк её за меня не реализует и не упростит. Например, посмотрел чужие реализации классической корзины заказов – не то, и сделал себе свою специфику сам.

Не нужна мне Джанга, кмк. Что она мне упростит?

x3al:

к чёрту фласк…

:) Да, видел слово serverless, но не вчитывался в это дело. Не знаю, возможно. Потом буду думать, ближе к деплою. А до деплоя мне далеко если честно. Может года через 2, если оптимистично.

anonymous:

как ты умело прикрываешь лень фразами…

Это не лень, это оптимизация :)

Ты зря так на джангу. Вот тебе пример: я похожую аппу писал для тревел бизнесмена из Мексики. Писал на flask + sql alchemy, потом понял, что изобретаю джангу с этими всеми авторизациями… короче, джанга быстрая, ты не заслуженно её считаешь какой-то не такой, все твои запросы по поводу oauth - уже есть готовые и хорошо работающие модули для джанги, flask по сравнению с джангой почти не популярен, и всё надо прибивать гвоздями, это не так удобно и уж тем более, не так быстро для разработки как Джанга:

https://tutorial.djangogirls.org/ru/django_start_project/

https://djangopackages.org/grids/g/authorization/

https://github.com/st4lk/django-rest-social-auth

https://www.patricksoftwareblog.com/

Насколько будет быстрее асинхронщина?

Асинхронщина нужна там, где много мелких запросов, либо куча запросов висит в фоне (long polling, web sockets), в твоей задаче асинхронщина никаким боком, можешь не заморачиваться

изобретаю джангу с этими всеми авторизациями…

регистрацией пользователей в смысле?

patricksoftwareblog.com

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

в твоей задаче асинхронщина никаким боком

О, спасибо! А то я начал читать и думаю, зачем мне это… :)

PS, забыл.

github.com/st4lk/django-rest-social-auth

По твоей ссылке нет ПП. Ну не важно, сам добавлю – наверняка будет проще чем самому с нуля. Зато там же есть ссылка на аналог для фласка :)

PS2.

Кстати, именно social логин – меня абсолютно не интересует. Я буду логинить только для целей оплаты. Если там гугл – только которая соц. сеть, то нужный-мне-гугл придётся тоже самому делать.

Почему-то старая кука не подходит для нового сервера

О, я похоже понял. Там оказалось что кроме меня ещё и фласк-логин вставляет свои данные в куку (юзер-агент + айпи, и ещё кое-что), и сам фласк тоже – флэш-мессаги и счётчик. Вот думаю именно из-за счётчика. Для нового сервера счётчик будет из будущего.

А 320 requests/sec/core у линукса, которые с неправильной кукой, и которые отметаются на уровне фрэймворка – это нормально? Или должно быть существенно выше? AMD FX 4350 @ 2.8 GHz (ограничиваю, чтоб не грелся сильно)

Хуже - пока руками WAL не включишь там и чтение блокируется при записи. А если включить WAL то «не уметь в параллельную запись» оказывается вполне норм.

Не знаю правда что аналогично глупого может быть здесь, в вэб.

Теперь знаю. vde_switch между сервером и бенчем :) Если бенч тоже на виртуалке, то ок.

(ну и sqlite в многокоре – спасибо)