Partager Python interprète dans Apache Prefork / WSGI

Question

Partager Python interprète dans Apache Prefork / WSGI

voix

6

Je tente d'exécuter une application de Python dans Apache (prefork) avec WSGI de telle sorte qu'un seul interpréteur Python sera utilisé. Ceci est nécessaire car l'application utilise la synchronisation des threads pour éviter les conditions de course de se produire. Depuis Apache prefork engendre de multiples processus, le code serpente pas être partagé entre les interprètes et ainsi la synchronisation du fil est hors de propos (chaque fil ne voit que sa propre serrures qui sont sans incidence sur les autres processus).

Voici la configuration:

Apache 2.0 (prefork)
WSGI
2,5 python

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>

Voici ce que j'ai essayé jusqu'à présent (dont aucun travaillé):

Ajout WSGIApplicationGroup% {GLOBAL}
Spécification WSGIDaemonProcess et WSGIProcessGroup au sein de l'hôte virtuel:

WSGIDaemonProcess OSVM threads = 50
WSGIProcessGroup OSVM

Y at-il aucun moyen de forcer Apache prefork à utiliser un interpréteur Python unique avec WSGI? Les documents semblent indiquer que vous pouvez avec les options de WSGIDaemonProcess et WSGIApplicationGroup mais Apache crée encore un interpréteur Python pour chaque processus.

apache apache2 mod-wsgi wsgi django-wsgi

Créé 27/08/2009 à 06:37
source utilisateur Luke Murphey

Dans d'autres langues...

1 réponses

Graham Dumpleton · Accepted Answer · 2009-08-27 07:07

Vous ne pouvez pas avoir l'application WSGI exécution en mode embarqué sur les systèmes UNIX, que ce soit Prefork ou travailleur BRIKLIS, car il y aura en effet 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 devriez même pas besoin d'utiliser WSGIApplicationGroup si elle est une seule application WSGI montée vous parlez. Si vous voulez être absolument sûr que, vous pouvez également définir.

Ainsi, la configuration au sein VirtualHost serait la suivante:

WSGIDaemonProcess osvm
WSGIProcessGroup osvm
WSGIApplicationGroup %{GLOBAL}

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

Bien que « les processus = 1 » pour WSGIDaemonProcess rend explicite qu'un processus est créé, ne fournit pas l'option et si juste le laisser par défaut à un processus. Toute utilisation de l'option « processus », même si pour un processus verra « wsgi.multiprocess » est définie sur True.

Plutôt que d'utiliser votre application WSGI réelle, je vous suggère de tester le programme de test simple suivant.

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()]

Dans la sortie de cela, la valeur PID doit toujours être le même. Le drapeau wsgi.multiprocess doit être faux. La valeur mod_wsgi.process_group doit être ce que vous avez appelé le groupe de processus démon. Et le mod_wsgi.application_group doit être une chaîne vide.

Si ce n'est pas ce que vous voyez, assurez-vous réellement redémarré Apache après avoir effectué des modifications de configuration. ajouter aussi:

LogLevel debug

à la configuration Apache pour VirtualHost. En faisant cela entraînera mod_wsgi de journal beaucoup plus de messages par erreur Apache journal sur la création de processus et le chargement du script, y compris les détails des choses groupe de groupe et de l'application de processus se passe pour.

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

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

Si des problèmes encore, proposez-vous aller à la liste de diffusion mod_wsgi sur Google Groupes.