H2o: ¿Falta retraso (sueño, Thread.sleep) en mruby?

hola @taosx
Dudo un poco que sea realmente php el que no pueda seguir el ritmo.
¿Está enviando solicitudes http a la propia instancia de h2o que luego ejecuta fastcgi?

No estoy seguro de si hizo esto intencionalmente para emular pausas, pero por lo que leí, se une a cada solicitud de forma secuencial. La idea sería que las solicitudes se envíen en paralelo, por lo que solo comenzará a unirse después de que se activen todas las solicitudes.

puedes probar algo como

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

y publicar una descripción de error más detallada?

Además, si son siempre los mismos pocos enlaces y son más o menos estáticos, podría implementar rápidamente una memoria caché barata.

Creo que su código no proporciona un argumento para http_request, lo modifiqué así:
links.split(' ').map{|l| http_request(l) }.map{|r| r.join}
pero todavía parece funcionar peor que el código que publiqué arriba.
Resolví la solución instalando y activando opcache en php y ahora el tiempo que lleva hacer todas las solicitudes se redujo de 27 segundos a 3,1 segundos sin errores. Usando su código va a 4 segundos.

Después de hacer algunas pruebas más, me gustaría abrir el código fuente completo para mi sitio de wordpress con h2o, que almacena en caché las páginas cada 2 minutos, se precomprime con gzip y brottli en la configuración máxima y sirve desde el caché. Me encanta h2o hasta ahora, gracias a todos los colaboradores de h2o !!

En el futuro, me encantaría ver más funciones de secuencias de comandos para h2o, como openresty pero basadas en h2o: D

@taosx ah lo siento. Olvidé la parte crucial: .to_a

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

solo por curiosidad, ¿puedes intentarlo de nuevo? y ¿cuántas solicitudes haces / qué tan grande es la matriz de enlaces?

@yannick Intenté de nuevo, tuve que modificar http_request para dar su argumento (l).
La velocidad se redujo a 3,06 segundos: D y, a veces, 2,9+ cuando se calentó la caché.
La matriz de enlaces tiene 41 elementos (aws ec2 t2.micro).

Cada vez que agrego otra publicación, obtengo 1 enlace de la publicación en sí + ~ 5 enlaces de etiquetas agregadas ...
Creo que tengo un pequeño problema en un futuro próximo. Creo que dejaré mruby por ahora e iré por un enfoque diferente en el futuro.

¿Crees que podría usar h2o con mruby como caché de proxy inverso para wp? Creo que es posible.

parece que se paga a php a través de enlaces = php #{links_filepath} . que probablemente sea muy lento, ¿eliminó ese tiempo?
por solo h2o, t2.micro debería estar bien, pero si también ejecuta php en esa máquina, compiten por la CPU única y el rendimiento cae aún más. así que al menos para las pruebas tomaría algo como c4.large o c4.xlarge.

sí, el almacenamiento en caché a través de mruby debería ser posible, ya sea que lo haga en la memoria o use redis (que actualmente todavía necesita un parche, pero debería fusionarse pronto, consulte https://github.com/h2o/h2o/pull/1152)

¡Esta es una discusión interesante!

Aparte de cómo se debe resolver el problema (por ejemplo, implementando un caché usando mruby), creo que no hay ninguna razón por la que no debamos proporcionar una función de suspensión en nuestro controlador mruby.