Назад | Перейти на главную страницу

Apache2 mod_wsgi python 2.6 Django очень медленно

Я пробовал около 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/