H2o: mrubyに遅延（sleep、Thread.sleep）がありませんか？

こんにちは@taosx
私は、その本当にphpが追いつけないのではないかと少し疑っています。
fastcgiを実行するh2oの独自のインスタンスにhttpリクエストを送信していますか？

一時停止をエミュレートするために意図的にこれを行ったかどうかはわかりませんが、私が読んだことから、あなたはその後すべてのリクエストに参加しています。 リクエストは並行して送信されるため、すべてのリクエストが実行された後にのみ参加を開始するという考え方になります。

あなたは次のようなことを試すことができますか

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

より詳細なエラーの説明を投稿しますか？

また、常に同じいくつかのリンクがあり、それらが多かれ少なかれ静的である場合は、安価なメモリキャッシュをすばやく実装できます。

あなたのコードはhttp_requestへの引数を提供していないと思います、私は次のように変更しました：
links.split(' ').map{|l| http_request(l) }.map{|r| r.join}
しかし、それでも私が上に投稿したコードよりもパフォーマンスが悪いようです。
opcacheをphpにインストールしてアクティブ化することで解決策を解決しましたが、すべてのリクエストを実行するのにかかる時間が27秒から3.1秒にエラーなしで短縮されました。 コードを使用すると、4秒になります。

さらにいくつかのテストを行った後、2分ごとにページをキャッシュし、最大設定でgzipとbrottliの両方で事前圧縮し、キャッシュから提供するh2oを使用して、WordPressサイトのコード全体をオープンソースにしたいと思います。 これまでのところh2oが大好きです、h2oへのすべての貢献者に感謝します!!

将来的には、openrestyのように、h2oに基づいたh2oのスクリプト機能をもっと見たいと思っています：D

@taosxああごめんなさい。 重要な部分を忘れました： .to_a

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

好奇心から、もう一度試してみてください。 リクエストはいくつありますか/リンク配列の大きさはどれくらいですか？

@yannickもう一度試してみましたが、http_requestを変更して引数（l）を指定する必要がありました。
キャッシュをウォームアップすると、速度は3.06秒：Dに低下し、場合によっては2.9+に低下しました。
リンク配列には41個の要素があります（aws ec2 t2.micro）。

別の投稿を追加するたびに、投稿自体から1つのリンクを取得し、追加されたタグから最大5つのリンクを取得します...
近い将来、小さな問題があると思います。 今はmrubyを削除し、将来は別のアプローチをとると思います。

mrubyでh2oをwpのリバースプロキシキャッシュとして使用できると思いますか。それは可能だと思います。

リンク= php #{links_filepath}介してphpにシェルアウトしているようです。 それはおそらく非常に遅いです、あなたはその時間を削除しましたか？
ちょうどh2oの場合、t2.microは問題ないはずですが、そのマシンでphpのものも実行すると、単一のCPUをめぐって競合し、パフォーマンスがさらに低下します。 したがって、少なくともテストには、c4.largeやc4.xlargeのようなものを使用します。

はい、mrubyを介したキャッシュが可能であるはずです。メモリ内で行うか、redisを使用します（現在もパッチが必要ですが、すぐにマージする必要があります。https：//github.com/h2o/h2o/pull/1152を参照してください）。

これは興味深い議論です！

問題を解決する方法（mrubyを使用してキャッシュを実装するなど）を除けば、mrubyハンドラーでスリープ機能を提供しない理由はないと思います。