Я пробовал около 1000 раз, но я не могу понять, почему простой веб-сайт django работает медленно с использованием apache 2.2.14 / wsgi latest / django 1.3. Я подтвердил, что проблема не в нашей базе данных, включив ведение журнала медленных запросов mysql. Я просмотрел параметры конфигурации демона wsgi еще 100 раз, но до сих пор не понимаю, почему runserver в настоящее время работает быстрее, чем apache!
Вот моя конфигурация apache, дайте мне знать, если есть другие полезные элементы!
WSGIDaemonProcess xxx display-name=xxx group=www-data user=www-data processes=25 threads=1
<VirtualHost *:80>
ServerName www.xxx.com
ServerAlias xxx.com
ServerAlias localhost
ServerAdmin jfisher@xxx.com
RewriteEngine Off
RewriteCond %{HTTP_HOST} ^xxx\.com$ [NC]
RewriteRule ^(.*)$ http://www.xxx.com$1 [R=301,L]
RewriteCond %{REQUEST_URI} ^/login/$
RewriteRule /login https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
RewriteCond %{REQUEST_URI} ^/signup/
RewriteRule /signup https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
ErrorLog /var/log/apache2/xxx-error.log
LogLevel debug
CustomLog /var/log/apache2/xxx-access.log combined
WSGIProcessGroup %{GLOBAL}
WSGIApplicationGroup %{GLOBAL}
WSGIScriptAlias / /srv/xxx.com/mod_wsgi/dispatch.wsgi
Alias /static /srv/xxx.com/src/xxx/static
<Directory "/srv/xxx.com/src/xxx/static">
Order deny,allow
Allow from all
</Directory>
</VirtualHost>
свободно:
total used free shared buffers cached
Mem: 496 489 6 0 1 17
-/+ buffers/cache: 471 25
Swap: 1023 50 973
верхняя:
top - 21:30:52 up 2:06, 1 user, load average: 0.07, 0.10, 0.12
Tasks: 101 total, 2 running, 99 sleeping, 0 stopped, 0 zombie
Cpu(s): 1.2%us, 1.2%sy, 0.0%ni, 95.4%id, 2.2%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 508272k total, 467788k used, 40484k free, 1448k buffers
Swap: 1048572k total, 59576k used, 988996k free, 22708k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5009 www-data 20 0 179m 41m 5024 R 20 8.3 0:02.59 apache2
2521 elastic 20 0 710m 70m 4052 S 1 14.2 0:54.32 java
5013 root 20 0 19272 1252 932 R 0 0.2 0:00.05 top
1 root 20 0 23628 1108 784 S 0 0.2 0:00.18 init
2 root 20 0 0 0 0 S 0 0.0 0:00.00 kthreadd
Вот настройки mpm_prefork_module:
<IfModule mpm_prefork_module>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 150
MaxRequestsPerChild 0
</IfModule>
У тебя есть:
WSGIDaemonProcess xxx display-name=xxx group=www-data user=www-data processes=25 threads=1
но тогда есть:
WSGIProcessGroup %{GLOBAL}
это означает, что вы не делегируете приложение WSGI для работы в этой группе процессов демона.
Другими словами, вместо этого вы запускаете приложение WSGI во встроенном режиме, а директива WSGIDaemonProcess является избыточной.
Если вы также используете Apache prefork MPM, вы, вероятно, столкнетесь с возможными проблемами скорости из-за того, что Apache использует до 150 однопоточных процессов в своей конфигурации по умолчанию.
Таким образом, медлительность, вероятно, связана с отложенной загрузкой вашего приложения WSGI, если оно велико, когда действительно поступает запрос.
По мере поступления новых запросов Apache вынужден запускать новые процессы, чтобы удовлетворить возросший спрос. Если запросы упадут, Apache начнет отбрасывать процессы. Если количество запросов увеличится еще раз, ему придется снова запускать новые процессы и снова загружать ваше приложение.
Это крайний сценарий, и насколько сильно он может вас ударить, зависит от того, как установлены настройки Apache MPM, которые вы не показываете, и каков ваш профиль трафика.
В худшем случае вы можете даже переопределить директиву MaxRequestsPerChild и указать Apache убить процесс после одного или небольшого количества запросов, поэтому вы можете постоянно принудительно перезагружать свое приложение.
Чтобы прочитать о проблемах, связанных с подобными проблемами, прочтите:
http://blog.dscpl.com.au/2009/03/load-spikes-and-excessive-memory-usage.html
Вот как все может пойти плохо в зависимости от конфигурации Apache.
Если игнорировать неправильную конфигурацию режима демона, возможно, это проблема приложения. Для этого я бы предложил попробовать инструмент для мониторинга производительности. Мое предвзятое предложение - это New Relic. Даже если вы не хотите платить за такой инструмент, он дает две недели пробной версии для всех функций, чего может быть достаточно, чтобы вы разобрались, где находится узкое место.
Для примера того, что New Relic может сделать для Python, посмотрите:
http://blog.newrelic.com/2011/11/08/new-relic-supports-python/