Partager l'interpréteur Python dans Apache Prefork/WSGI

Question

Je tente d'exécuter une application Python dans Apache (prefork) avec WSGI de telle sorte qu'un seul interpréteur Python sera utilisé. Cela est nécessaire car l'application utilise la synchronisation des threads pour empêcher les conditions de course. Puisque Apache prefork engendre plusieurs processus, le code finit par ne pas être partagé entre les interprètes et donc la synchronisation des threads est non pertinente (à savoir que chaque thread ne voit que ses propres verrous qui n'ont aucune incidence sur les autres processus).

Voici la configuration:

• Apache 2.0 (prefork)
• WSGI
• python 2,5

Voici la configuration Apache pertinente:

WSGIApplicationGroup %{GLOBAL} 
<VirtualHost _default_:80> 

WSGIScriptAlias//var/convergedsecurity/apache/osvm.wsgi 

Alias /admin_media/ /var/www/html/admin_media/ 

<Directory /var/www/html/admin_media> 
Order deny,allow 
Allow from all 
</Directory> 

Alias /media/ /var/www/html/media/ 

<Directory /var/www/html/media> 
Order deny,allow 
Allow from all 
</Directory> 

</VirtualHost> 

Ici est ce que j'ai essayé jusqu'ici (aucun de ch travaillée):

1. Ajout WSGIApplicationGroup %{GLOBAL}

2. Spécification WSGIDaemonProcess et WSGIProcessGroup au sein de l'hôte virtuel:

   fils WSGIDaemonProcess de OSVM = 50
   WSGIProcessGroup OSVM

Est il n'y a aucun moyen de forcer Apache prefork à utiliser un seul interpréteur Python avec WSGI? Les documents semblent impliquer que vous pouvez avec les options WSGIDaemonProcess et WSGIApplicationGroup mais Apache crée toujours un interpréteur Python distinct pour chaque processus.

Answer 1

L'application WSGI ne peut pas être exécutée en mode intégré sur les systèmes UNIX, qu'il s'agisse de préfork ou de MPM, car il y aura effectivement plusieurs processus. Voir:

http://code.google.com/p/modwsgi/wiki/ProcessesAndThreading

Création d'un groupe de processus démon constitué de processus unique et de déléguer l'application WSGI à qui devrait obtenir ce que vous voulez. Vous ne devriez même pas avoir besoin d'utiliser WSGIApplicationGroup s'il s'agit d'une seule application WSGI montée dont vous parlez. Si vous voulez être absolument sûr, vous pouvez également le définir.

Ainsi la configuration au sein VirtualHost serait:

WSGIDaemonProcess osvm 
WSGIProcessGroup osvm 
WSGIApplicationGroup %{GLOBAL} 

WSGIScriptAlias//var/convergedsecurity/apache/osvm.wsgi 

Bien que « processus = 1 » pour WSGIDaemonProcess rend explicite qu'un processus est créé, ne fournit pas l'option si et juste laisser défaut à un processus . Toute utilisation de l'option 'processes', même si pour un processus verra 'wsgi.multiprocess' mis à True. Plutôt que d'utiliser votre application WSGI réelle, je vous suggère de tester avec le programme de test simple ci-dessous.

import cStringIO 
import os 

def application(environ, start_response): 
    headers = [] 
    headers.append(('Content-Type', 'text/plain')) 
    write = start_response('200 OK', headers) 

    input = environ['wsgi.input'] 
    output = cStringIO.StringIO() 

    print >> output, "PID: %s" % os.getpid() 
    print >> output 

    keys = environ.keys() 
    keys.sort() 
    for key in keys: 
     print >> output, '%s: %s' % (key, repr(environ[key])) 
    print >> output 

    output.write(input.read(int(environ.get('CONTENT_LENGTH', '0')))) 

    return [output.getvalue()] 

En sortie de cela, la valeur PID doit toujours être la même. L'indicateur wsgi.multiprocess doit être False. Le mod_wsgi.La valeur de process_group doit être ce que vous avez appelé le groupe de processus daemon. Et le groupe mod_wsgi.application_group devrait être une chaîne vide.

Si ce n'est pas ce que vous voyez, assurez-vous de redémarrer Apache après avoir apporté des modifications à la configuration. Ajoutez également:

LogLevel debug 

configuration Apache pour VirtualHost. Cela amènera mod_wsgi à consigner beaucoup plus de messages dans le journal des erreurs Apache sur la création du processus et le chargement du script, y compris les détails du groupe de processus et du groupe d'applications pour lesquels les choses se passent.

Pour d'autres informations sur le débogage, voir:

http://code.google.com/p/modwsgi/wiki/DebuggingTechniques

Si les problèmes persistent, vous suggère d'aller à la liste de diffusion mod_wsgi sur Google Groupes.