lockedLoadData /キャッシュされていないページのビルドの目的はusleepに費やされ、約1分かかります

Magento 2.3.1へのアップデート以降、キャッシュされていないページの読み込みに問題があると思います（開発中）。

私はblackfire.ioトレースを行いましたが、ここでusleepに 42秒が費やされていることがわかりました。

今、これの目的は何なのかと思っています。なんらかの競合状態で走っていると思いますか？

誰かが以前にこのようなことを経験しましたか？

編集：コールスタックはcommercebugを含むようです。

まあそれは選択です？-Magentoのエンジニアが作った。

これは答えではありませんが、その関数は、キャッシュされたデータをロードするためのコールバックを受け入れるようです。コールバックは、現在ロックが設定されているかどうかを確認します。そうでない場合は、ロックを設定し、データをロードしてから、ロックを解放します。所定の場所にブロックがある場合は、マイクロ秒（0.1秒）の間スリープし100,000、ローダーを再度呼び出します。

だから、大声で考えて、私の推測は

1. この関数へのリクエストの数が通常より多いかもしれません
2. キャッシュからの通常の読み取り時間より長い。

lockedLoadDataメカニズムは、サーバーの負荷を減らす必要があります。

以前は、高負荷のサイトで構成キャッシュが消去されると、すべてのクライアントが同じ情報を生成して、CPU / IOの負荷を大幅に増加させていました。

lockedLoadDataでは、1つのクライアントのみがキャッシュを生成し、他のクライアントはそれを待ちます。

仕組みの詳細。

最初の関数は「データを取得する」コールバックを呼び出し、それがデータを返すだけではない場合（データがキャッシュにある場合、コードは以前のように機能し、ロックを使用しません）。

データが利用できず、ロックがロックされている場合、ループで、データが取得されるか、ロックが削除されるまで、データをロードしようとします。

ロックがない場合は、ロックを作成してデータを生成し、それをキャッシュに保存して、ロックを削除してデータを返します。

PS：これらの変更は、最大20kRPMの負荷を持つクライアントの1つにパッチのように送信され、問題なく少なくとも3か月間機能しました。おそらくあなたのカスタマイズ/モジュールの問題（たとえば、それらがキャッシュメカニズムを壊した場合）