Apache2 mod_wsgi python 2.6 Django molto lento

Ho provato circa 1000 cose, ma non riesco a capire perché un sito semplice django è lento utilizzando apache 2.2.14 / wsgi latest / django 1.3. Ho confermato che il problema non è il nostro database triggersndo mysql lenta query di logging. Ho esaminato le impostazioni di configuration del wsgi da un'altra 100 volte, ma ancora non capisco perché runerver è attualmente più veloce di apache!

Ecco il mio config apache, fai sapere se ci sono altri elementi che potrebbero essere utili!

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> 

gratuito:

  total used free shared buffers cached Mem: 496 489 6 0 1 17 -/+ buffers/cache: 471 25 Swap: 1023 50 973 

superiore:

 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 

Ecco le impostazioni di mpm_prefork_module:

 <IfModule mpm_prefork_module> StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxClients 150 MaxRequestsPerChild 0 </IfModule> 

  • Posso "registrare" script python per eseguire su Windows?
  • IO Attendere che causa un rallentamento così elevato (EXT4 JDB2 a 99% IO) Durante il commit di Mysql
  • Imansible installare python2.7-dev su Ubuntu 12.04.2 LTS
  • Django, nginx, FastCGI - in esecuzione tramite socket unix, problemi di authorization
  • syslog-ng non lavare il pipe al programma esterno
  • Sisthemes di monitoraggio della networking in Python
  • Come posso aggiornare Python a 2.7.9 su Ubuntu 14.4?
  • PIP che non si installa nella directory virtuale
  • One Solution collect form web for “Apache2 mod_wsgi python 2.6 Django molto lento”

    Hai:

     WSGIDaemonProcess xxx display-name=xxx group=www-data user=www-data processes=25 threads=1 

    ma poi hanno:

     WSGIProcessGroup %{GLOBAL} 

    il che significa che non si sta delegando l'applicazione WSGI per eseguire in quel gruppo di processi daemon.

    In altre parole, si esegue l'applicazione WSGI in modalità incorporata e la direttiva WSGIDaemonProcess è ridondante.

    Se stai usando anche MPM prefork Apache, probabilmente stai perdendo eventuali problemi di velocità dovuti a Apache utilizzando fino a 150 processi singoli filettati nella configuration predefinita.

    La lentezza è quindi probabilmente dovuta al caricamento pigra dell'applicazione WSGI, se è grande quando una richiesta viene effettivamente inserita.

    Con l'introduzione di ulteriori richieste, Apache deve continuare a creare nuovi processi per soddisfare una crescente domanda. Se le richieste scadono, Apache avrà inizio i processi di abbandono. Se arriva un ulteriore aumento delle richieste, è necessario avviare nuovamente nuovi processi e caricare nuovamente l'applicazione.

    Ora, questo è un scenario estremo, e quanto male possa essere colpito da esso dipende da come vengono impostate le impostazioni MPM di Apache, che non vengono mostrate e quali sono il tuo profilo di traffico.

    Nel peggiore dei casi potresti addirittura superare la direttiva MaxRequestsPerChild e dire ad Apache di uccidere il process dopo un singolo o un piccolo numero di richieste e pertanto potresti costringere le ricariche dell'applicazione per tutto il tempo.

    Per alcune letture su problemi correlati per questo tipo di problema leggi:

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

    Così è come le cose potrebbero andare male a seconda della configuration Apache basata.

    Ignorando la configuration sbagliata per la modalità daemon, hai la possibilità di essere un problema di applicazione. Per questo suggerisco di provare uno strumento di monitoraggio delle performance. Il mio suggerimento parziale c'è la Nuova Reliquia. Anche se non si vuole pagare per un tale strumento, fornisce due settimane di prova per tutte le funzionalità che potrebbero essere sufficienti per risolvere il punto in cui è il collo di bottiglia.

    Per un esempio di ciò che la nuova rilievo può fare per Python, guarda:

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

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.