Question

Pour le moment, j'ai un script mod_wsgi structuré comme ceci.

def application(environ, start_response):
    status = '200 OK'
    output = 'Hello World!'

    response_headers = [('Content-type', 'text/plain'),
                    ('Content-Length', str(len(output)))]
    start_response(status, response_headers)

    return [output]

Je me demandais si quelqu'un connaissait un moyen de changer cela pour qu'il fonctionne sur une base rendement au lieu de return , afin de pouvoir envoyer la page telle qu'elle est générée et pas seulement une fois terminé, le chargement de la page peut ainsi être plus rapide pour l'utilisateur.

Cependant, chaque fois que j'échange la sortie contre une liste et la renvoie dans application (), une erreur est générée:

TypeError: sequence of string values expected, value of type list found
Était-ce utile?

La solution

def application(environ, start_response):
    status = '200 OK'
    output = 'Hello World!'

    response_headers = [('Content-type', 'text/plain'),
                    ('Content-Length', str(len(output)))]
    start_response(status, response_headers)

    yield output
  

"Cependant, chaque fois que j'échange la sortie contre une liste et la renvoie dans l'application (), une erreur est générée:"

Eh bien, ne cédez pas la liste. Produisez chaque élément à la place:

for part in mylist:
    yield part

ou si la liste contient tout le contenu, il suffit de:

return mylist

Parce que la liste est déjà un itérateur et peut céder elle-même.

Autres conseils

Notez que le "rendement" doit être évité sauf en cas de nécessité absolue. En particulier, le «rendement» sera inefficace s'il produit beaucoup de petites chaînes. Cela est dû au fait que la spécification WSGI exige qu'après chaque chaîne, la réponse soit vidée. Pour Apache / mod_wsgi, le vidage signifie que chaque chaîne est forcée de sortir par la brigade de baquets de sortie Apache et le système de filtre et sur le socket. Ignorer la surcharge du système de filtre de sortie Apache, écrire de nombreuses petites chaînes sur un socket est tout simplement mauvais pour commencer.

Ce problème existe également lorsqu'un tableau de chaînes est renvoyé par une application car un vidage doit également être effectué entre chaque chaîne du tableau. Cela est dû au fait que la chaîne est traitée comme une liste, mais pas une liste. Ainsi, pour une liste de chaînes préformée, il est préférable de joindre les chaînes individuelles en une seule chaîne de grande taille et de renvoyer une liste contenant uniquement cette chaîne. Cela permet également à une implémentation WSGI de générer automatiquement une longueur de contenu pour la réponse si elle n’a pas été explicitement fournie.

Assurez-vous que lorsque vous joignez toutes les chaînes d’une liste, le résultat est renvoyé dans une liste. Si cela n'est pas fait et si la chaîne est renvoyée, cette chaîne est traitée comme une variable, où chaque élément de la chaîne est une chaîne de caractères unique. Il en résulte une couleur après chaque caractère, ce qui sera encore pire que si les chaînes n'avaient pas été jointes.

N'envoyez pas la longueur du contenu et envoyez le résultat tel que vous le dérivez. Vous n'avez pas besoin de connaître la taille de la sortie si vous ne le faites pas envoyer l'en-tête Content-Length. De cette façon peut envoyer une partie de la réponse avant que vous ayez calculé le reste.

def application(environ, start_response):
    status = '200 OK'
    output = 'Hello World!'

    response_headers = [('Content-type', 'text/html')]
    start_response(status, response_headers)

    yield head()
    yield part1()
    yield part2()
    yield part3()
    yield "<!-- bye now! -->"

Sinon, vous ne tirerez aucun avantage de l'envoi de morceaux, puisque le calcul de la sortie est probablement la partie lente et le protocole Internet enverra quand même la sortie en morceaux.

Malheureusement, cela ne fonctionne pas dans le cas où, par exemple, le calcul de part2 () décide que vous devez vraiment changer un en-tête (comme un cookie) ou besoin de construire d'autres structures de données globales - si cela se produit, vous devez calculer la totalité de la sortie avant envoi des en-têtes, et pourrait aussi bien utiliser un return [sortie]

Par exemple, http://aaron.oirt.rutgers.edu/myapp/ docs / W1200_1200.config_template Nécessité de créer une structure de données globale de page pour les liens vers les sous-sections ce spectacle en haut de la page - donc la dernière sous-section doit être restituée avant que le premier bloc de sortie ne soit remis au client.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top