Все больше наших клиентов используют в своих проектах замечательный web-фреймворк Django и неудивительно. Ведь данный фреймворк позволяет очень быстро создавать динамические сайты и обладает при этом огромной гибкостью. Он имеет в своем арсенале множество готовых решений почти на все случаи жизни, и по-сути, является низкоуровневым конструктором сайтов. А главное его достоинство – это гибкость, благодаря которой, можно в короткие сроки создавать абсолютно любые по сложности веб-приложения.Данный фреймворк имеет удобный встроенный веб-сервер, на котором можно без проблем отлаживать ваше приложение, но для реального боевого использования он естественно не годится.
В последнее время мы получаем множество запросов от клиентов, касающихся его деплоймента на рабочий сервер. В связи с этим мы решили провести небольшое тестирование нескольких наиболее популярных связок на предмет производительности и простоты их использования, для рекомендации нашим клиентам оптимального варианта.
Для тестов мы взяли типичный Dedicated Server.
Некоторая информация о сервере:
— Linux alex.tests 2.6.33.2 #1 SMP Wed Apr 7 10:36:28 MSD 2010 i686 GNU/Linux
Debian GNU/Linux 5.0 \n \l
Intel® Core(TM)2 Duo CPU E8400 @ 3.00GHz
cpu cores: 2
alex:~# free -m
total used free shared buffers cached
Mem: 3291 224 3067 0 10 187
-/+ buffers/cache: 26 3264
Swap: 2055 0 2055
— В данном тесте участвовали три связки:
1) apache2+mod_wsgi
Это самое распространенное и рекомендуемое решение на сегодняшний день. Данный модуль может использовать два режима работы: embedded-режим (где Apache работает аналогично mod_python) и так называемый daemon-режим, аналогичный по принципу работы FastCGI/SCGI.
2) nginx+flup
Flup представляет по своей сути набор различных WSGI-модулей. Он является рекомендуемым методом запуска django-приложений в FastCGI режиме.
3) nginx+superfcgi
Как утверждает автор проекта это “The only one true way to run WSGI apps through fastcgi”. Его автор barbuza. Это решение не так распространено как остальные.
Дабы исключить искусственные лимиты операционной системы на файловые дескрипторы, мы установили следующие параметры на сервере:
ulimit -n 10240 (максимальный размер записываемых файлов данным шеллом)
sysctl -w net.core.somaxconn=150000 (максимальное кол-во соединений )
sysctl -w fs.file-max=100000 (кол-во открытых файлов)
В качестве клиента использовался обычный VDS на XEN, находящийся на сервере в этой же стойке. Нагрузка создавалась с помощью httperf. Эта утилита специально предназначена для подобного рода исследований, она искусственно создает нагрузку на удаленный сервер и имеет множество настроек.
В качестве испытуемого выступало простое Django-приложение, которое по определенному url вызывало определенный view и загружало небольшой html-шаблон. Таким образом, в тесте участвовали основные компоненты фреймворка. На данный URL осуществлялось по 20000 запросов с возрастающей скоростью.
Дабы исключить всю магию, после каждой связки операционная система на сервере переустанавливалась заново, а клиент перезагружался.
Нас больше всего интересовали значения reply rate (скорость ответов) и response time (среднее время ответа). Также был интересен расход памяти.
В итоге результаты были следующими:
Абсолютным лидером является связка nginx+superfcgi, что наряду с легкостью установки делает ее оптимальным production-вариантом. И именно ее мы можем порекомендовать нашим клиентам. Интересно отметить, что даже при 6000 запросов в случае данной связки (в отличие от других) не наблюдалась тенденция к уменьшению времени и числу ответов. Что касается максимального расхода памяти, то он составил 318Mb для Apache и около 290Mb в случае с nginx.
А теперь интересное предложение: всем читателям хабра, купившим у нас выделенный сервер мы не только можем установить и настроить эту связку бесплатно (для этого напишите тикет и попросите направить его в отдел Scripting Guru), но и предоставим 30% скидку на первый месяц аренды сервера. Для того чтобы активировать скидку, нужно при заказе указать промокод: habradedic.
