Записи с тегом «test»

Хостинг python приложений имеет некоторые нюансы, не всегда удобные и приятные для хостера. Мы уже больше года предоставляем python-хостинг и столкнулись с рядом особенностей. Да, не все в нашем мире идеально :-)

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

Поэтому серверные веб-технологии пошли двумя основными направлениями в плане сопряжения программной части с веб-сервером:

1. разработка всяких mod_* — встроенных интерпретаторов в веб-сервер;
2. переботка стандарта cgi с целью увеличения производительности (FastCGI);

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

В тредовой (thread) модели python есть такое понятие как Interpreter Lock. Это когда тред блокирует интерпретатор на определенное время (пока не выполнит операцию, выполнит определенное кол-во инструкций или не пройдет таймаут). В принципе этот метод разделения ресурсов вполне хорошо работает на практике. Но в случаем с хостингом есть свои нюансы...

Представте вполне реальную картину. Веб сервер (Apache) с встроенным mod_python обслуживает 50 python-приложений. Если апач работает в тредовом режиме, тогда и mod_python тоже (апач настраивается на тредовый режим через опции компиляции, а модуль уже при сборке сам определяет в каком режиме работает апач и собирается в этом же режиме). Теперь сама ситуация: 50 веб-сайтов смогут вполне создать нагрузку 1-5 запросов в секунду, а на каждый процесс апача у нас приходится, например, по 25 тредов и одному интерпретатору python. Теперь вспомним про Interpreter Lock и прикинем какие могут быть ситуации. В общем говоря в тредовом режиме mod_python работает достаточно нестабильно. Выглядеть это будет как таймауты (код будет долго ждать разблокировки интерпретатора).

При работе в fork() режиме веб-сервера, проблема блокировок снимается (т.к. на каждое соединения клиента выделяется отдельный процесс веб-сервера и следовательно отдельный интерпретатор), но возникает проблема с экономией оперативной памяти. Т.к. каждый процесс потребляет значительное кол-во памяти (от 20 до 50 Мб ориентировочно).

Теперь вспомним про второй способ сопряжения приложенияс веб-сервером и подумаем о связке не встроенным способом — т.е. через популярный FastCGI. Веб-сервер в этом случае разгружается и никак практически не зависит от стабильности приложения. Т.е. конечный пользователь в любом случае получит или запрашиваемый результат или страницу с ошибкой, что намного лучше таймаута без каких либо объяснений. В этом случае сам веб-сервер может работать в тредовом режиме и экономить память. Но есть другая проблема. Каждое отдельное python-приложение будет запущено отдельным процессом и будет также потреблять память, что в итоге может дать не экономию, а большие затраты.

Интересно что приложение запущенное в режиме FastCGI может также работать в тредовом и fork() режимах, что соответственно влияет на потребление ресурсов. В тредовом режиме проблемы остаются те-же что и с mod_python. Только кол-во запросов к отдельному FastCGI-процессу в принципе сокращается, что дает меньшую вероятность таймаута в связи с блокировкой интерпретатора.

Подводя итог. Хочу отметить что идеального решения нет. Для каждых отдельных случаев нужно разрабатывать решения (чем мы в принципе и занимаемся). Просто имея эту информацию, Вы сможете сами представить при написании Вашего проекта в каком окружении его лучше запускать. Следовательно Вы сможете его правильно спроектировать и оптимизировать.

Желаем успехов в разработке!

Недавно прошел анонс сабжа. Руки чешутся пощупать сие творение, но пока есть задачи и поважнее. Очень надеюсь что проект не загнётся! Перспективы очень интересные. Если кто-то пробывал этого зверя, напишите в комменты - очень интересно Ваше впечатление. Если сам выкрою время его пощупать обязательно напишу репорт. Feb 22, 2006 Alpha 3 released! NexentaOS (elatte) Alpha 3 is now available for Download.