http-python-thread
1) mod_python - зло, используй fastcgi (через flup, к примеру).
2) архитектурно нормально запускать отдельным процессом, нет? Ну в смысле необязательно каждый раз запускать, можно поднять "два" процесса - "один" на обработку запросов, "другой" на обработку чего-то там "тяжелого" и типа межпроцессное взаимодействие (сокеты, к примеру)...
ЗЫ Мне, честно говоря, решение "отдать ответ и задуматься" как-то не нравится архитектурно.
2) архитектурно нормально запускать отдельным процессом, нет? Ну в смысле необязательно каждый раз запускать, можно поднять "два" процесса - "один" на обработку запросов, "другой" на обработку чего-то там "тяжелого" и типа межпроцессное взаимодействие (сокеты, к примеру)...
ЗЫ Мне, честно говоря, решение "отдать ответ и задуматься" как-то не нравится архитектурно.
А в твоем случае же все "взаимодействие" - отдать один раз данные второму процессу и забыть.
В принципе, с fastcgi ты можешь и треды сделать, конечно. Но, по-моему, процессы+сокеты = лучше масштабируемое решение здесь. А оверхед на "взаимодействие" невелик.
В принципе, с fastcgi ты можешь и треды сделать, конечно. Но, по-моему, процессы+сокеты = лучше масштабируемое решение здесь. А оверхед на "взаимодействие" невелик.
Мне, честно говоря, решение "отдать ответ и задуматься" как-то не нравится архитектурноТут недавно был такой же вопрос
ЗЫ Мне, честно говоря, решение "отдать ответ и задуматься" как-то не нравится архитектурно."отдать ответ и задуматься в текущем процессе/треде". Возможно, я неправильно понял, что именно ищет автор, но mod_python и прочие http server приблуды почти наверняка не предусматривают запуск задачи после в отдельном треде/процессе.
1) mod_python - зло, используй fastcgi (через flup, к примеру).Я слышал ровно обратное мнение, и так же без аргументов, что, мол падает часто.
2) архитектурно нормально запускать отдельным процессом, нет? Ну в смысле необязательно каждый раз запускать, можно поднять "два" процесса - "один" на обработку запросов, "другой" на обработку чего-то там "тяжелого" и типа межпроцессное взаимодействие (сокеты, к примеру)...
Сейчас устроено так: есть CGI (запустить его как FastCGI, SCGI или mod_python --- дело настройки апача).
Есть за апачем сервер на питоне — BaseHTTPServer.
И все запросы CGI перенаправляет туда. Там из сервера уже возвращают ответ (xml-rpc и в сервере запускается тред с обработкой запроса. Форматированием, качанием из инета и т.д. Результаты складываются там же на сервере, и возвращаются на запрос с другими параметрами.
Что будет под нагрузкой --- непонятно. Непонятно насколько питонский сервер хороший.
Но, по-моему, процессы+сокеты = лучше масштабируемое решение здесь.Отваливаются сокеты-то
Отваливаются сокеты-тоот чего отваливаются? крепче приклеивать надо.
Сейчас устроено такизврат какой.
если обработка долгая я бы не гонял каждый запрос в свой сервер, а информацию о текущем состоянии запросов хранил в базе из которой брал бы прямо из cgi, либо какой-нить извратик с memcached сварганил.
если обработка долгая я бы не гонял каждый запрос в свой сервер, а информацию о текущем состоянии запросов хранил в базе из которой брал бы прямо из cgi, либо какой-нить извратик с memcached сварганил.
Спасибо.
Читал про memcached, и про интерфейсы питонские к нему читал. Интересно бы попробовать, только вот судя по статистике получится как из пушки по воробьям
В сервере самое тяжелое — обработка в треде после ответа на запрос.
Насчет изврата: эта штука растет. Там как раз надо заменить слабые места. Вот их и ищу. База изначально и предполагалась.
ну вот самое тяжёлое и вынести в сторону, а остальное сделать стандартно fastcgi и бд.
если уж бд не будет справляться тогда приделать memcached.
если уж бд не будет справляться тогда приделать memcached.
есть CGI (запустить его как FastCGI, SCGI или mod_python --- дело настройки апача)прям так уж и дело настройки?
помню, у меня в случае с перлом переход от CGI к mod_perl был просто революцией (производительность, возможности, но и переписать немало кода пришлось)
или на питоне всё так аккуратно пишется что переход к многопоточности проходит незамеченным?
У mod_python разные способы есть:
есть CGI handler — как раз CGI запускать, без изменений. В документации сказано что "оно скорее всего будет работать". Сам CGI-то маленький, там переписывать много не придется.
А есть уже publisher. Там по-другому пишется. Но тож переписать не сложно.
про PSP говорить не буду. PHP для Питона со всеми вытекающими.
Устроено так: есть статические странички. Они отдаются Апачем. На страничках AJAX. AJAX-запросы (и iframe'ы, и всё проч) ходят к CGI, точнее, через CGI к питонскому серверу. CGI разбирается какой именно метод дернуть и с какими параметрами.
есть CGI handler — как раз CGI запускать, без изменений. В документации сказано что "оно скорее всего будет работать". Сам CGI-то маленький, там переписывать много не придется.
А есть уже publisher. Там по-другому пишется. Но тож переписать не сложно.
про PSP говорить не буду. PHP для Питона со всеми вытекающими.
Устроено так: есть статические странички. Они отдаются Апачем. На страничках AJAX. AJAX-запросы (и iframe'ы, и всё проч) ходят к CGI, точнее, через CGI к питонскому серверу. CGI разбирается какой именно метод дернуть и с какими параметрами.
Я слышал ровно обратное мнение, и так же без аргументов, что, мол падает часто.Здесь и далее имхо. Баги-глюки есть и там и там. Но fcgi архитектурно более "правильное" решение. В плане контроля памяти или секьюрности, к примеру. Или опять же удобства рестарта.
есть CGI (запустить его как FastCGI, SCGI или mod_python --- дело настройки апача)
Ну, не знаю, как у вас, а у меня переход на мод питон в свое время был изрядным геморроем.
Есть за апачем сервер на питоне — BaseHTTPServer.
И все запросы CGI перенаправляет туда. Там из сервера уже возвращают ответ (xml-rpc и в сервере запускается тред с обработкой запроса. Форматированием, качанием из инета и т.д. Результаты складываются там же на сервере, и возвращаются на запрос с другими параметрами.
Что будет под нагрузкой --- непонятно. Непонятно насколько питонский сервер хороший.
Меня в дрожь бросает от слов "нагрузка" и "веб-сервер на питоне"
Я не знаю, зачем вам второй веб-сервер. И зачем ждать ответа. Особенно если под нагрузкой. Имхо, как раз тут все было бы замечательно как я описал. Веб-запросы - это одно. "Долгие" процессы - это другое. Можно и правда все через бд синхронизовать или только часть. Если удастся разделить по процессам одного только на чтение - другого только на запись, то можно неплохо в будущем разнести доступ к базе и соответственно ускориться. Репликации и проч.В документации сказано что "оно скорее всего будет работать".Опять же у меня не заработало. И, кстати, не в этом ли случае кто-то где-то жаловался то ли на утечки памяти, то ли на какую-то хрень с мультитредовостью? Я к тому, что даже разрабы, насколько я помню, не гарантировали корректную работу в этом случае, вроде бы.
Меня в дрожь бросает от слов "нагрузка" и "веб-сервер на питоне"А почему?
(Меня тоже бросает, но как следует объяснить не могу — погуглил и не нашел как делать правильно и от какой нагрузки ломается питонский сервер).
Почитал про Suzanne в Success Stories на python.org — там BaseHttpServer их вполне удовлетворил.
Знаешь, меня бросает в дрожь не в силу каких-то тестов именно этого сервера. А просто в силу неоднократно проверенных на практике фактов о медлительности интерпретатора питона. Когда оптимизируя просто количество строк можно обнаружить интересную разницу в скорости. Ну то есть если _все_ написано "правильно", "грамотно" и хорошо знающим питон и тонкости его оптимизации человеком, то он даст нормальный результат по скорости, насколько этого можно требовать от настолько удобного языка.
Но вряд ли кто-то сильно этим заморачивается. Стандартный подход - модуль на сях, если что не так. А потому, если нету такого модуля, то стоит подумать и очень хорошо погонять сервер на тестах.
Но вряд ли кто-то сильно этим заморачивается. Стандартный подход - модуль на сях, если что не так. А потому, если нету такого модуля, то стоит подумать и очень хорошо погонять сервер на тестах.
все равно же в основном база будет тормозить, а не генерация страницы...
Тормозить может много чего. А может не будет. Нужно тупо протестировать как следует. Но я бы сразу от этой идеи отказался, честно говоря. Мы сейчас, кстати, о веб сервере, а не о cgi/mod_* скриптах.
При схеме веб сервер -> "голый" сокет -> "голый" процесс для "длительных" -> бд <- веб сервер, к примеру, не факт, что тормоза будут только на бд, если веб сервер на питоне. Впрочем, один фиг это гадание на кофейной гуще.
При схеме веб сервер -> "голый" сокет -> "голый" процесс для "длительных" -> бд <- веб сервер, к примеру, не факт, что тормоза будут только на бд, если веб сервер на питоне. Впрочем, один фиг это гадание на кофейной гуще.
+1.
Ну да, согласен. Это как раз те самые "общие соображения", из-за которых и хочется посмотреть по сторонам.
> Когда оптимизируя просто количество строк можно обнаружить интересную разницу в скорости.
Такого не видел, в существенную разницу не верится
> Ну то есть если _все_ написано "правильно", "грамотно" и хорошо знающим питон и тонкости его оптимизации человеком, то он даст нормальный результат по скорости, насколько этого можно требовать от настолько удобного языка.
Мне понравилась статья про оптимизации WideFinder.
Ну да, согласен. Это как раз те самые "общие соображения", из-за которых и хочется посмотреть по сторонам.
> Когда оптимизируя просто количество строк можно обнаружить интересную разницу в скорости.
Такого не видел, в существенную разницу не верится
> Ну то есть если _все_ написано "правильно", "грамотно" и хорошо знающим питон и тонкости его оптимизации человеком, то он даст нормальный результат по скорости, насколько этого можно требовать от настолько удобного языка.
Мне понравилась статья про оптимизации WideFinder.
Такого не видел, в существенную разницу не веритсяЧто есть "существенная"?
В общем, я иногда в сложных местах лишний иф даже ставить не хочу. Как раз после того, как одно время много времени провел за экспериментами с профайлером и собственным кодом. Правда, дело касалось 2.5 и у меня была специфика - много мелких по коду объектов, но очень часто создаваемых и используемых.Мне понравилась статья про оптимизации WideFinderЧет не помню, ссылку кинешь?
В общем, я иногда в сложных местах лишний иф даже ставить не хочу.Так тут же не в строчке дело.
Согласен. Пример неудачный, так как общий. Хорошо. Лишнюю временную переменную не заведу.
О, спасибо. Полезного для меня не очень много, но есть. А вообще достаточно интересно, конечно. Я, к примеру, как-то до сих пор не предполагал, что "list.append is an atomic operation in CPython".
Оставить комментарий
pilot
Хочется такую штуку: приходит HTTP-клиент, спрашивает запрос, ему отвечают HTTP-ответ и запускают долгоиграющую обработку запроса. Когда обработают, куда-нибудь складывают.Чем (пакет?) правильно такое делать, если хотим еще и приличной скорости и надежности?
Почитал про mod_python --- он вроде не умеет "задумываться" после отправки ответа. Разве что CleanupHandler'ом, но что-то не верится что он работает после отправки ответа.
Встроенный BaseHTTPServer доверия не вызывает (напрасно? хотя в нем и понятно как делать, и Suzanne его хвалит.
Или я чего-то архитектурно неправильное хочу...