1

長時間実行される Magento プロセスを使用してオーバーヘッドを軽減した経験がある人なら誰でも。たとえば、注文または顧客リソースへの典型的な Magento API 呼び出しは 1 秒以上かかる可能性があり、その時間の半分は Magento オーバーヘッドに費やされ、問題の API リソースに固有のものではない可能性があります。

では、Magento PHP プロセスがスピンアップされてメモリ内に保持され、API リクエストを待機しているとしたら、毎回 Magento をロードしなくても処理できるようになります。

実行時間の長い php スクリプトに関する私の検索のほとんどは、PHP スクリプトのトラブルシューティングに関連する質問/問題を引き起こしています。これは、処理しているデータ量の b/c を実行するのに予想よりも時間がかかるなどです。たとえ可能であったとしても、この種の優れたリソースを見つけるのは困難です。

更新:私のニーズをもう少し具体的にするには:

  • サーバー側で安全にキャッシュできる単純な GET 用に memcached を既に用意しています。
  • 今最適化したいのは書き込み操作です。
  • REST API を使用しているため、関心のある WSDL の読み込みはありません。
4

1 に答える 1

1

を調べるproc-openと、通常は OS 自体で発生する多くの管理を行う必要があります。

ただし、問題が速度であり、利用可能なハードウェアを利用するためにパイプ/フォークする手段が必要なだけではない場合は、システム全体のボトルネックを見つけて、そのようなことに飛び込む前にキャッシュすることを検討します。WSDL キャッシング、DB 正規化、OP コード キャッシング、さらには memcache やリバース プロキシ キャッシングなど。Alan は彼の Mercury API 製品 ( http://store.pulsestorm.net/products/mercury-api )に WSDL キャッシングを持っています。

proc-openこの同じアプローチを使用して、8時間以内に32コアシステム上のMagentoにアドレスを含む50万件を超える顧客レコードを（Magentoのモデル（スタック）を介して）インポートするときに以前に使用しました。1 つの PHP ファイルがメインのエントリ ポイントとして機能し、データのチャンクに基づく新しいプロセスが、実際のインポートを行うセカンダリ PHP ファイルに分岐されました。

私が言及したインポートのマルチスレッド用にこの小さなスクリプトを活用しましたが、これはあなたの質問に対する正確な答えではありません。技術的に具体的な指向ではないようですが、可能性についての洞察を提供してくれることを願っています:

于 2012-08-27T20:16:53.150 に答える