タグ付けされた質問 「performance」

TL; DRの要件は、Magentoのフレームワークに準拠したパフォーマンスを念頭に置いて、追加のクエリ/メモリを最小限に抑えて、在庫の在庫レベルをカテゴリ製品リストページに表示することです。 スケーラビリティのためのプリロードに関するVinai Koppの記事を読んだ後。 パフォーマンスのために追加のクエリ/ロードをできるだけ少なくして、カテゴリ製品リストページ（list.phtml）に在庫在庫レベルを含める最良の方法は何ですか？ 私はいくつかのアプローチを知っています： afterLoad（）は、media_gallery追加のクエリなしでインクルードしてもうまく機能するように見えますが、インベントリで同じアプローチを実装することに成功していません。 $attributes = $_product->getTypeInstance(true)->getSetAttributes($_product); $media_gallery = $attributes['media_gallery']; $backend = $media_gallery->getBackend(); $backend->afterLoad($_product); product_idたとえば、キーを使用してコレクションと並行して必要なデータを収集するようにSQLに指示します。しかし、フレームワークを通じてより多くの手段を探しています。 現在、私は単に次のstock_item方法でオブジェクトをロードしています： $_product->load('stock_item')->getTotalQty(); これは機能しますが、コレクション内のすべての製品の在庫在庫合計を取得するためのクエリが追加されていることに気付きました。 ... __EAV_LOAD_MODEL__ (Mage_Catalog_Model_Product, id: stock_item, attributes: NULL) __EAV_LOAD_MODEL__ (Mage_Catalog_Model_Product, id: stock_item, attributes: NULL) __EAV_LOAD_MODEL__ (Mage_Catalog_Model_Product, id: stock_item, attributes: NULL) ... 奇妙なことに、これは動作します。魔法はMage_Eav_Model_Entity_Abstract-> load（$ object、$ entityId、$ attributes）で発生します。$ attributesが空の場合、loadAllAttribute（$ object）を呼び出します。したがって、$ product-> load（ …

12 category  performance  inventory  list.phtml 

_getProductCollection() クラスのメソッドにMage_Catalog_Block_Product_List 次のようにフィルターを1つ追加しました。 protected function _getProductCollection() { ... $this->_productCollection = $layer->getProductCollection(); $this->_productCollection->getSelect()->joinInner( array('cpe' => 'catalog_product_entity'), 'e.entity_id = cpe.entity_id' ) ->where("cpe.type_id = 'simple'"); ... } 上記のコードはMagentoバージョン1.7で正常に動作しています。しかし、次のコードを書くたびに、 列が見つかりません：1054 'where句'の列 'e.type_id'が不明です エラー。 コード（機能していません）。 protected function _getProductCollection() { ... $this->_productCollection = $layer->getProductCollection(); $this->_productCollection ->addAttributeToSelect('type_id') ->addAttributeToFilter('type_id','simple'); ... } さて、質問です。 最初の作業コードを使用すると、パフォーマンスに影響がありますか？ 適切な製品フィルターを使用するために回避する他の方法はありますか？ 更新： 次のコードを適用してrwdテーマを使用しても、エラーは発生しません。しかしdefault、テーマを使用するたびに、以下のエラーが発生します。 コード protected …

12 magento-1.9  product-attribute  performance 

切り捨ててもよいテーブルのリスト（/programming/12205714/list-of-tables-to-safely-truncate-in-magento）を読んでいましたが、表示されませんでした report_viewed_product_index テーブルは巨大で、データベースの復元には非常に長い時間がかかります。このデータを切り捨てるか、少なくとも最も古いデータを削除しても安全ですか？

12 mysql  performance  enterprise-1.13 

私は現在インスタンスで実行Magento 2.2, php7, Apache2していAmazon AWS EC2 c4.largeますが、開発サーバーとして使用している場合、t2.microインスタンスでさえ通常は問題ありません。 何らかの理由で、たまにsetup：upgradeを実行すると、カスタムモジュールの1つでセットアップファイルを更新した後、またはサードパーティのモジュールをインストールした後、サーバーが非常に遅くなり、試行するたびにCPU使用率が100％のままになりますページをロードするには、ページのロードに1分以上かかり、ページをロードしない場合はCPU使用率が25％のままになります。これは、私がsetup：upgradeを呼び出したmagento Webサイトにのみ影響します。同じサーバー上の他のmagentoインストールのページは、通常の速度でロードされます。 アップグレードしたばかりのモジュールを削除してサーバーを再起動し、コードを変更せずにモジュールを再インストールすることで問題が解決する場合があります。2番目のセットアップ：アップグレードで問題が修正され、場合によっては修正できる唯一の方法と思われます。Magento 2モジュールを完全に再インストールすることにより。 私はこれが上で発生持っていたMagento 2.1.6, 2.1.8, 2.1.9し、2.2どれも他には、デフォルトで、開発者や生産モードの問題を持っているようだしないことを、テーマやモジュールの異なる組み合わせのすべての種類を。 編集：重要な注意 この問題が発生していて、私と同じようにキャッシュを無効にしていないことが確かである場合、現時点で確認済みの問題（Magento 2.3）があり、実行composer updateするとすべてのキャッシュが無効になることがあります。したがって、キャッシュが有効になっていると思われる場合でも、再確認することをお勧めします。

12 magento2  performance 

Magentoの速度の改善について調査中です。現在表示されているのは、次の設定でページが飛ぶことです。画像のみが後から来ます。メインファイルは数ミリ秒で配信されますが、画像のため、読み込み時間は2秒のままです。 メイジキャッシング css / jsをマージ apc + memcacheを縮小 htaccessの微調整 tmpfsのセッション/キャッシュ 私の質問：（自分のサーバーで）CDNをセットアップする手順は何ですか？ （そしてそれは実際に役立ちますか） 私はそれがこのようなものであることを理解しています（しかしこれはまったく機能していません）： cdnサブドメインを作成する ドキュメントルートを変更する（および/またはcnameを設定する理由） 設定を変更

11 performance 

私は大規模なmagentoプロジェクトを完了するのに非常に近く、magentoの速度を向上させることに焦点を当てています。序文のように、私はこの大規模なプロジェクトを社内で行い、状況を把握しながら、フロントエンドの開発者を務めています。 2GBのRAMを備えたMedia Temple専用仮想サーバーに開発マジェントがあります。私は最近、600もの製品と、各製品に約25の異なる属性（合計で約300の固有の属性）と、おそらく50のカテゴリを持っていました。15秒前後の読み込み速度のトラブルシューティングを行うために、すべて削除しました。 しかし、私の読み込み時間はまだ長く、一貫性がありません。Firebugが応答について500ミリ秒を報告するようにホームページをリロードしました。すぐにリロードすると、9秒以上報告されます。これはサーバーの問題ですか、それともMagento自体の問題ですか？そのようなものをテストするにはどうすればよいですか？

11 magento-1.7  performance 

M1に戻ると、次の変数を変更することで、遅いクエリをログに記録できますlib/Varien/Db/Adapter/Pdo/Mysql.php。 /** * Write SQL debug data to file * * @var bool */ protected $_debug = false; /** * Minimum query duration time to be logged * * @var unknown_type */ protected $_logQueryTime = 0.05; /** * Log all queries (ignored minimum query duration time) * * @var bool …

10 magento2  database  magento-2.1  performance  log 

バックグラウンドでリモートサーバーにHTTPリクエストを送信するコードを特定する方法はありますか？ 開発マシンでレセプションがむらがあると、localhostで実行している場合でも、多くのショップで読み込みに時間がかかることに気付きました。 一部のリモートサーバーが接続が不安定なために応答に時間がかかるためだと感じています。これらのリクエストを特定して削除したいと思います。たとえば、外部サーバーがダウンしているか遅い場合など、ライブインストールが遅くなるのではないかと心配です。

10 performance  extensions 

マジェントのウェブサイトを持っています。ユーザーはいません（一度に最大2〜3人）。 サーバー：CPU：2000MHz RAM：2048Mb HDD：50000Mb。 ZendServerCE（apc + memcached + Zend Optimizer + Zend Data Cache）をインストールしました。ウェブサイトの読み込みが最悪だったため、memcachedをオフにしました。管理コンソールでフラットタイプの構造、インデックスの再作成、データのキャッシュを設定しました。 だから私はapc + Zend Optimizer + Zend Data Cacheを持っています。 最初の問題は、ディスパッチがどのように機能するかをランタイムで確認したことです。start_session（）の呼び出しには約500〜700ミリ秒かかります。その良い結果ではないようです。なぜそんなに長いのかわかりません。 私はこれを読みました：http : //dev.mysql.com/doc/refman/5.0/en/server-system-variables.html#sysvar_key_buffer_sizeそして私のサーバーに最適なオプションを見つけました。 1時間当たり： Key_read_requests = 8887 Key_reads = 252 Key_write_request = 187 Key_writes = 146 252/8887> 0.01ですが、多すぎません。それは私が今までに得た最適な値です。その他の結果は> 6から始まりました。 ここにmy.cnfがあります： key_buffer = 48M myisam_sort_buffer = 2M sort_buffer …

10 performance 

現在、パフォーマンスに関していくつかのモジュールを改善しようとしています。 コレクションでのメソッドの使用法を知っている方もいるかもしれません。これは、製品を直接ループするのを回避するのに非常に役立ちます。walk() さらに、@ Vinaiのおかげで、コレクションdelete()メソッドを使用することもできます。 しかし、Magento 1のネイティブファイルは、これらの方法のいずれかを使用して削除するとは限らないことに気づきました。 私が見てきた最悪のコードの一つがあるmassDelete()からメソッドapp/code/core/Mage/Adminhtml/controllers/Catalog/ProductController.phpどこの製品は、削除前のループでロードされます。 foreach ($productIds as $productId) { $product = Mage::getSingleton('catalog/product')->load($productId); Mage::dispatchEvent('catalog_controller_product_delete', array('product' => $product)); $product->delete(); } そこで、パフォーマンステストをいくつか行い、ロギングの呼び出しをいくつか追加して、100製品の削除にかかった時間とメモリ使用量を確認しました。 テスト1：walkメソッド 上記に貼り付けた元のコードを次のコードに置き換えました。 $collection = Mage::getResourceModel('catalog/product_collection') ->addAttributeToSelect('entity_id') ->addIdFilter($productIds) ->walk('delete'); そして私の結果は私のくだらない開発サーバーで次のとおりです（10回のテストに基づく平均）： 元のコード：19.97秒、15.84MB使用 カスタムコード：17.12秒、15.45MB使用 したがって、100個の製品を削除すると、私のカスタムコードは3秒速くなり、使用するメモリは0.4MB少なくなります。 テスト2：コレクションdelete()メソッドの使用 元のコードを次のコードに置き換えました： $collection = Mage::getResourceModel('catalog/product_collection') ->addAttributeToSelect('entity_id') ->addIdFilter($productIds) ->delete(); そしてここで吹き飛ばされた心は結果です： 元のコード：19.97秒、15.84MB使用 カスタムコード：1.24秒、6.34MB使用 したがって、100個の製品を削除すると、私のカスタムコードは18秒速くなり、使用するメモリは9MB少なくなります。 コメントで述べたように、このメソッドはMagentoイベント（ロード後、削除後）も、インデックス/キャッシュフラッシュもトリガーしないようです。 質問 だから私の質問は：Magentoコアチームがループで製品をロードするのではなくwalk('delete')、コレクションdelete()メソッドを使用しない理由がありますか？ 主な目標は、モジュール開発の場合は、そのようなキーポイントに注意することがある：1を使用することはできませんいずれかの特定の例があるwalk/収集delete()方法は？ …

10 collection  magento-1  performance  best-practice  memory-leak 

経験豊富なmagento開発者に複数の質問があります。 magento v1 soap apiの速度を向上させることは可能ですか？データを要求すると、magentoが顧客の住所などの単純な情報を編集するのに1.5秒かかります。 複数の関連するデータノードをリクエストするには、約5〜7秒のコストがかかります。 今、私はすでにAJAXリクエストを介してこれらのリクエストを行っているので、ページインターフェースはすばやく読み込まれますが、速度の向上は素晴らしいことです。 または、magento dbから直接関連情報を提供する独自のアプリケーションを作成する方が良いでしょうか？それはdbほど複雑ではなく、直接クエリを実行すると、100秒以内にロードされ、結果が表示されます... そのオプションに関して私が持っている唯一の考慮事項は： magentoがデータベーススキームを更新および変更した場合はどうなりますか？ または、magentoのデータベース設定は比較的安全/下位互換性のあるアップグレードですか？ 誰もがこれとその成功または失敗の物語について何か経験がありますか？どうすればよいかを知るためには、情報に基づいた決断が必要です。

10 performance  api 

Magento 2スタックを使用しています。Magento1 OpCache構成の一部を再利用しています。コメントを有効にする必要があることはすでに学習しましたが、他の値を改善できると確信しているので、現在の構成は次のとおりです。 [opcache] opcache.enable=1 opcache.enable_cli=0 opcache.memory_consumption=256 opcache.interned_strings_buffer=12 opcache.max_accelerated_files=65406 // thanks Mage2.Pro! ;opcache.max_wasted_percentage=5 ;opcache.use_cwd=1 opcache.validate_timestamps=0 ;opcache.revalidate_freq=2 ;opcache.revalidate_path=0 ;opcache.save_comments=0 ;opcache.load_comments=0 opcache.fast_shutdown=1 opcache.enable_file_override=1 ;opcache.optimization_level=0xffffffff ;opcache.inherited_hack=1 ;opcache.dups_fix=0 ;opcache.blacklist_filename= ;opcache.max_file_size=0 ;opcache.consistency_checks=0 ;opcache.force_restart_timeout=180 opcache.error_log=/var/log/php5/php5-opcache.error.log opcache.log_verbosity_level=3 ;opcache.preferred_memory_model= ;opcache.protect_memory=0 注： 質問の（開かれた状態で）構成ブロックをすべての回答で編集し、すべてのユーザーにとって役立つようにします。また、問題が発生したり、サイトのルールに違反したりする場合は、繰り返しの提案も避けます。私に知らせて。

10 magento2  performance  opcache 

現在、ページの読み込みが遅く、チェックアウトがすべての中で最も遅いです： 28リクエスト 18.5 KB転送（残りはディスクまたはメモリからキャッシュ） 終了：15.24秒（ローダーが消え、ユーザーは何かを実行できます） DOMContentLoaded：6.45s ロード：10.28s チェックアウト/カートのロードは次で終了します： 29リクエスト 28.5 KB転送（残りはディスクまたはメモリからキャッシュ） 終了：6.35秒 DOMContentLoaded：1.9秒 負荷：3.79秒 空のカートにはこれがあります： 22件のリクエスト 8.2 KB転送（残りはディスクまたはメモリからキャッシュ） 終了：2.78秒 DOMContentLoaded：1.22s 負荷：2.65秒 キャッシュにredisを使用しており、すべてのキャッシュがアクティブです。JavaScriptは、cssとhtmlだけでなく、縮小、マージ、バンドルされています。サーバーは、8つのCPU、16GBのRAM、およびSSDを備えたかなり良い場所にあります。負荷などは、言及されるほど高くはありません。基本的にサーバーはスリープしています... 約80の商品と1つの店舗しかありません。Magentoのコンテンツ部分は使用しません。製品の詳細ページ、チェックアウト、顧客領域（およびバックエンド）だけがMagentoによって提供されます。Magentoの「前」にあるCMSシステムは、メディアを含めて2秒未満でページを提供します。 チェックアウトドキュメントのTTFBがすでに5.66秒であることがわかります。Magentoプロファイラーを有効にするとmagento->routers_match->CONTROLLER_ACTION:checkout_index_index->action_body、ほとんどの場合それが原因であることがわかります。正確に何が原因かははっきりしていませんが。ここではプロファイラーはあまり役に立ちません（少なくとも私は）。 magento->routers_match 5.347600 5.347600 1 42,063,304 10,485,760 magento->routers_match->CONTROLLER_ACTION:checkout_index_index 5.143997 5.143997 1 15,976,176 10,485,760 magento->routers_match->CONTROLLER_ACTION:checkout_index_index->action_body 5.143980 5.143980 1 15,975,304 10,485,760 magento->routers_match->CONTROLLER_ACTION:checkout_index_index->action_body->EVENT:checkout_allow_guest 0.000609 0.000609 1 82.464 0 magento->routers_match->CONTROLLER_ACTION:checkout_index_index->action_body->EVENT:checkout_allow_guest->OBSERVER:checkout_allow_guest 0.000592 …

8 magento2  magento-2.1  checkout  onepage-checkout  performance 

私は現在Magento 2に取り組んでおり、すべてのページの読み込み時間が非常に長いことに気付きました。 私は現在Xamppで実行しており、プロダクションモードが有効、HTML / js / CSSがマージされて縮小されています。ワニスは無効になっており、Webホスティングがサーバーにインストールできないので使用しません。いくつかのスクリプト。親がMagento 2の空白のテーマであるカスタムテーマを使用しています。設定を変更した後、静的ファイルを再デプロイしてキャッシュを空にしました。 私の主な懸念は、ネットワークパネルを見ると、毎回大量のjsファイルがロードされていることがわかります。たとえば、私のカテゴリページでは、122のjsファイルが読み込まれ、合計サイズは955キロです。 私はマージとミニファイなしでサーバーでそれをテストしましたが、上で述べたように、問題はロードされたファイルの量にあると思います。 バンドルオプションを試しましたが、8MBのjsファイルが生成されますが、これはさらに悪いことです。 私は何かを見逃しましたか、それともjsファイルの量がこれだけであるのはいくぶん正常ですか？ワニスは良いパフォーマンスのために必須ですか、そしてそれに代わるものはありますか？ 私はMagento 2を初めて使用するので、詳しい情報が必要な場合は、喜んで提供します。

8 magento2  javascript  performance 

適切なサイズの管理対象サーバー上で、Magento 1.9.2.1とLesti_Fpcを実行しています。最初は、デフォルトのファイルキャッシュを使用していましたが、問題ありませんでした。しかし、カタログが大きくなり（約8000製品は悪くないと思いますが）、クローラーがより積極的になると、キャッシュが少し大きくなるとすぐにサイトが遅くなりました。キャッシュがクリアされたとき、すべてが再び迅速に実行されていました。 local.xmlの次のエントリを使用して、キャッシュバックエンドとしてAPCに切り替えようとしました。 <global> <cache> <backend>apc</backend> <prefix>MYSHOP_</prefix> </cache> </global> しかし、これは問題をさらに悪化させました。次に、Cm_Cache_Backend_Fileがこの問題のために作成され、次のように統合したことを読みます。 <global> <cache> <backend>Cm_Cache_Backend_File</backend> </cache> </global> これは少し良い感じですが、問題は同じです。キャッシュを小さく整理するために、Aoe_CacheCleanerも統合しましたが、これも役に立ちません。それでも、キャッシュがクリアされるとすぐに、すべてが再び迅速に実行されます。 編集： infaboの回答に基づいCm_Cache_Backend_Fileて、ファイルapp/etc/fpc.xmlと次のコンテンツでFPCをアクティブ化しました： <?xml version="1.0"?> <config> <global> <fpc> <lifetime>86400</lifetime> <backend>Cm_Cache_Backend_File</backend> </fpc> </global> </config> これは理にかなっていると確信していますが、問題を解決することもできません。 この問題の一般的な解決策は、キャッシュバックエンドとしてのRedis（または多分Memcached）であるようですが、残念ながら、管理対象サーバーでは使用できません。別のホスティング会社に切り替えることは（まだ）オプションではありません。 今は色々調べましたが、もうわかりません。多分誰かが助けることができますか？

8 magento-1.9  cache  performance