H2o: Délai manquant (sommeil, Thread.sleep) dans mruby ?

Créé le 2 mai 2017  ·  6Commentaires  ·  Source: h2o/h2o

J'ai écrit un gestionnaire mruby qui utilise http_request pour garder mon cache à jour dans wordpress, mais comme je ne connais aucun moyen de mettre le gestionnaire en veille et qu'il fait trop de demandes, la demande échoue car php ne peut pas suivre.

Existe-t-il un moyen de dormir quelques secondes dans l'eau à l'aide de mruby (j'ai essayé d'installer l'extension Thread mruby personnalisée, mais je n'arrive pas à obtenir la date de réponse du thread) ?

L'erreur:
[lib/handler/fastcgi.c] in request:/index.php/tag/science:connection failed:failed to connect to host

Le code:

if request_is_from_self and links_file_exist and req_is_get
    links = `php #{links_filepath}`

    for link in links.split(' ') do
        req = http_request(link)
        _, _, _ = req.join
    end
end
enhancement mruby

Tous les 6 commentaires

salut @taosx
Je doute un peu que c'est vraiment php qui ne peut pas suivre.
envoyez-vous des requêtes http à la propre instance de h2o qui exécute ensuite fastcgi ?

Je ne sais pas si vous l'avez fait intentionnellement pour émuler des pauses, mais d'après ce que j'ai lu, vous vous joignez à chaque demande de manière séquentielle. L'idée serait que les demandes soient envoyées en parallèle, de sorte que vous ne commencez à rejoindre qu'une fois toutes les demandes lancées.

pouvez-vous essayer quelque chose comme

links.split(' ').map{|l| http_request }.to_a.map{|r| r.join}

et poster une description plus détaillée de l'erreur ?

aussi si ce sont toujours les mêmes quelques liens et qu'ils sont plus ou moins statiques, vous pouvez rapidement implémenter un cache mémoire bon marché.

Je pense que votre code ne fournit pas d'argument à http_request, j'ai modifié comme ceci :
links.split(' ').map{|l| http_request(l) }.map{|r| r.join}
mais il semble toujours moins performant que le code que j'ai posté ci-dessus.
J'ai résolu la solution en installant et en activant opcache en php et maintenant le temps qu'il faut pour faire toutes les requêtes est passé de 27 secondes à 3,1 secondes sans erreur. En utilisant votre code va à 4 secondes.

Après avoir fait quelques tests supplémentaires, j'aimerais ouvrir l'intégralité du code de mon site wordpress avec h2o qui met en cache les pages toutes les 2 minutes, précompresse à la fois avec gzip et brottli aux paramètres maximum et sert à partir du cache. J'adore h2o jusqu'à présent, merci à tous les contributeurs de h2o !!

À l'avenir, j'aimerais voir plus de fonctionnalités de script pour h2o, comme openresty mais basé sur h2o :D

@taosx ah désolé. j'ai oublié la partie cruciale : .to_a

links.split(' ').map{|l| http_request }.to_a.map{|r| r.join}

juste par curiosité, pouvez-vous réessayer. et combien de demandes faites-vous / quelle est la taille du tableau de liens ?

@yannick J'ai réessayé, j'ai dû modifier http_request pour lui donner son argument (l).
La vitesse est tombée à 3,06 secondes :D et parfois à 2,9+ lors du réchauffement du cache.
Le tableau de liens a 41 éléments (aws ec2 t2.micro).

Chaque fois que j'ajoute un autre message, j'obtiens 1 lien du message lui-même + ~ 5 liens des balises ajoutées...
Je pense avoir un petit problème dans un futur proche. Je pense que je vais laisser tomber mruby pour le moment et adopter une approche différente à l'avenir.

Pensez-vous que je pourrais utiliser h2o avec mruby comme cache de proxy inverse pour wp, je pense que c'est possible.

il semble que vous déboursiez vers php via des liens = php #{links_filepath} . c'est probablement très lent, avez-vous supprimé cette heure ?
pour l'eau uniquement, le t2.micro devrait être ok, mais si vous exécutez également les éléments php sur cette machine, ils se disputent le processeur unique et les performances diminuent davantage. donc au moins pour les tests, je prendrais quelque chose comme un c4.large ou un c4.xlarge.

oui la mise en cache via mruby devrait être possible, soit vous le faites en mémoire, soit vous utilisez redis (qui a actuellement encore besoin d'un patch mais devrait être fusionné bientôt, voir https://github.com/h2o/h2o/pull/1152 )

C'est une discussion intéressante !

Mis à part la manière dont le problème doit être résolu (par exemple, en implémentant un cache à l'aide de mruby), je pense qu'il n'y a aucune raison pour laquelle nous ne devrions pas fournir une fonction de veille dans notre gestionnaire mruby.

Cette page vous a été utile?
0 / 5 - 0 notes