LINUX.ORG.RU
решено ФорумAdmin

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

 , , ,


0

1

Привет всем!

Обработка заказа: обращение к базе за предыдущими заказами (там нужна история), нетривиальная обработка, и формирование странички с новым. База sqlite (через алхимию), 20КБ. Питон ничем (сифоном) не ускорял. Апачевский бенч: ab -c 2 -n 300 -C <кука> <адрес> Внизу – результаты, 3 числа, requests/sec, для werkzeug (отладочный), gunicorn workers=1, и gunicorn workers=2. Всё под одинаковыми виртуалками, 2 процессора, на хосте CPU governor=performance.

FreeBSD, 12.1, python 3.7.9
57, 57, 79
56, 58, 84

OpenBSD, 6.7, python 3.7.9
33, 38, 47
114, 157, 254

Linux, Debian 9, python 3.5.3
65, 78, 83
90, 321, 397

Все системы довольно дефолтные. Что скажете, это нормальные результаты? (я нуб)

Линукс рвёт БСД. Почему так плохо с FreeBSD? Почему не очень хорошо с OpenBSD?

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


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

Aswed ★★★★★ ()

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

anonymous ()
Ответ на: комментарий от x3al

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

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

anonymous:

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

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

PS.

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

the1 ()
Последнее исправление: the1 (всего исправлений: 1)
Ответ на: комментарий от KernelPanic

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

x3al ★★★★★ ()

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

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

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

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

@menangen

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

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

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

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

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

Ну да, qemu.

@KernelPanic

А uwsgi пробовал?

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

the1 ()
Последнее исправление: the1 (всего исправлений: 1)
Ответ на: комментарий от the1

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

vedowi6419 ()
Ответ на: комментарий от the1

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

vedowi6419 ()
Ответ на: комментарий от the1

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

https://fastapi.tiangolo.com/

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

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

x3al ★★★★★ ()
Ответ на: комментарий от vedowi6419

Спасибо!

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

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

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

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

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

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

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

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

the1 ()
Ответ на: комментарий от the1

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

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

menangen ★★★★★ ()
Последнее исправление: menangen (всего исправлений: 1)
Ответ на: комментарий от menangen

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

x3al ★★★★★ ()
Ответ на: комментарий от the1

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

menangen ★★★★★ ()
Ответ на: комментарий от x3al

fastapi.tiangolo.com

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

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

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

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

@menangen

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

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

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

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

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

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

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

x3al:

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

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

anonymous:

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

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

the1 ()
Ответ на: комментарий от the1

Ты зря так на джангу. Вот тебе пример: я похожую аппу писал для тревел бизнесмена из Мексики. Писал на 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/

menangen ★★★★★ ()
Ответ на: комментарий от the1

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

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

menangen ★★★★★ ()
Последнее исправление: menangen (всего исправлений: 1)
Ответ на: комментарий от menangen

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

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

patricksoftwareblog.com

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

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

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

PS, забыл.

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

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

PS2.

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

the1 ()
Последнее исправление: the1 (всего исправлений: 2)
Ответ на: комментарий от the1

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

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

the1 ()
Ответ на: комментарий от the1

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

the1 ()
Последнее исправление: the1 (всего исправлений: 1)
Ответ на: комментарий от x3al

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

ei-grad ★★★★★ ()
Ответ на: комментарий от the1

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

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

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

the1 ()