web-dev-qa-db-ja.com

Apache2 mod_wsgi python 2.6 Django非常に遅い

私は約1000倍のことを試しましたが、Apache 2.2.14/wsgi latest/Django 1.3を使用して単純なDjango Webサイトが遅い理由を理解できないようです。 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 [email protected]

    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>
apache-2.2performancepythondjangomod-wsgi
3
Jonathan S. Fisher

あなたが持っている：

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アプリケーションが大きい場合は、リクエストが実際に受信されたときに、WSGIアプリケーションの読み込みが遅れる可能性があります。

より多くの要求が来ると、Apacheは増加する需要を満たすために新しいプロセスをスピンアップし続ける必要があります。リクエストがドロップオフすると、Apacheはプロセスのドロップを開始します。リクエストがさらに増加し​​た場合は、新しいプロセスを再度起動し、アプリケーションを再度ロードする必要があります。

これは極端なシナリオであり、Apache MPM設定がどのように設定されているか、表示されていないか、トラフィックプロファイルがどのようなものかによって異なります。

最悪の場合、MaxRequestsPerChildディレクティブをオーバーライドし、単一または少数のリクエストの後にプロセスを強制終了するようにApacheに指示している可能性があるため、アプリケーションのリロードを常に強制している可能性があります。

この種の問題に関連する問題についてのいくつかの読み物については、以下を読んでください。

http://blog.dscpl.com.au/2009/03/load-spikes-and-excessive-memory-usage.html

これが、ベースのApache構成に基づいて状況が悪化する可能性がある方法です。

デーモンモードの間違った構成を無視すると、アプリケーションの問題である可能性があります。そのためには、パフォーマンス監視ツールを試すことをお勧めします。私の偏った提案にはNewRelicがあります。このようなツールにお金をかけたくない場合でも、すべての機能について2週間の試用期間があり、ボトルネックがどこにあるかを整理するのに十分な場合があります。

New RelicがPythonでできることの例については、以下をご覧ください。

http://blog.newrelic.com/2011/11/08/new-relic-supports-python/

4
Graham Dumpleton