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

Magentoのパフォーマンスに関する質問を示します

2
ページネーションをネイティブに使用してMagentoコレクションを反復処理することは可能ですか?
それが私が意味することは-行う方法があります: $collection = $model->getCollection(); foreach ($collection as $item) { $item->doStuff(); } コレクションに10万行ある場合でも、MySQLから一度に1ページの行だけをロードし、裏で魔法のようにページ分割します。 Varien_Data_Collection_Db::load()それを見ることは可能だとは思えないが、ただ確認したかった。これは、一般的に必要なもののように思えます。

2
害を与えずにオフにできる未使用のコアモジュールのリスト
これにReffering Magentoの1については、このトピック彼らはほとんど使用されていないので、多分オフにするか、完全に私たちの店のための害で除去することができるコアMagentoの2モジュールのリストを準備することは有用であろう。 いくつかの命題から始めるには: Magento_UpsまたはMagento_DhlまたはMagento_Fedex(当社のクライアントは、それらの出荷を使用しない場合) Magento_Paypal - 上記のように Magento_AdminNotification (時々迷惑です) すべてのモジュールImport/Export-店舗をMagentoから移行しない場合1 Magento_BundleまたはMagento_DownloadableまたはMagento_GroupedProduct-使用しない場合 Magento_GiftMessage -(使用しない場合) Magento_Rss -使用しない場合 Magento_Sitemap そして、ここでいくつかの疑わしいもの-誰かがそれらに経験がある場合、それらが何かに役立つかどうかを知らせてください: Magento_Marketplace Magento_Msrp Magento_NewRelicReporting Magento_OfflineShipping & Magento_OfflinePayments Magento_SampleData Magento_Swagger Magento_Usps Magento_Vault

3
Magento Enterpriseフルページキャッシュの事前準備
ロックされています。この質問とその回答はロックされています。なぜなら、質問はトピックから外れていますが、歴史的に重要だからです。現在、新しい回答やインタラクションを受け入れていません。 Magento Enterpriseのフルページキャッシュのパフォーマンス上の利点は、かなりよく知られています。あまり知られていないかもしれないことは、これの完全な利益を実現するために、特に数ページしかなく、したがってオーガニックなトラフィックを利用している大規模な製品セットで、完全に実装され、ホットでなければならないことです十分な速さでプライムします。 Magentoには、サイトをクロールし、早朝にFPCを暖めるための組み込みのcronジョブが含まれています。 早朝のジョブの実行に時間がかかりすぎて、他のジョブの実行をブロックすることによって引き起こされる問題を見て、聞いたことがあります。私が持っているいくつかのアイデアは次のとおりです。 生成されたサイトマップファイルのすべてのページをクロールするシェルスクリプトを作成します。 別個のcrontabエントリと短いPHPスクリプトを使用して、Magentoをブートストラップし、クローラープロセスを直接実行します。 これについての考えや経験は大歓迎です!


6
カートのチェックアウトおよびチェックアウト保存アクションの高速化
私はいくつかのMagento CEショップを運営しており、キャッシングでスピードアップしていますが、カートとチェックアウトはまだ遅いままです。これらのページを高速化するための経験やヒントはありますか? おそらくデータベースを最適化することを通して? チェックアウトから注文を保存するときに一部のクエリが実行され、サーバーのスロークエリログに表示され、データベースがボトルネックになっているようです。

5
速度:APCとMemcachedの両方を使用したMagento
私たちは多くのフォーラムを研究してきましたが、次の答えを知りません。両方がAPCありMemcache、サーバーにインストールされています。正しい最適な構成が何であるかはわかりません。 私の質問 MemcacheとAPCの両方を同時に使用してMagentoを実行するのに最適な設定は何ですか?(またはこれはまったく賢くない) 背景調査 ここでは、MemcacheとAPCは高速キャッシュと低速キャッシュとして推奨されています(ただし、ディスクはありません)。このような音は、十分なRAMがある場合にのみ機能します(そして、それについて確実に) http://www.coeusblue.com/blog/48-magento/65-magento-caching この記事は、Memcache または APCについてのものです。 http://magebase.com/magento-tutorials/speeding-up-magento-with-apc-or-memcached/ また、ここでは、Memcacheが本当​​に機能するのは、遅いバックエンドも定義されている場合のみであると述べています。 http://www.magentocommerce.com/boards/viewthread/283908/#t393090 この記事は同じことを言っていると思います http://www.byte.nl/blog/speeding-up-magento-the-burden-of-two-level-cache/ これは、local.xmlに対するISPのソリューションです <cache> <backend>apc</backend> <prefix>sitenamehere__</prefix> </cache> <cache> <backend>memcached</backend> <memcached> <servers> <server> <host><![CDATA[127.0.0.1]]></host> <port><![CDATA[11211]]></port> <persistent><![CDATA[1]]></persistent> </server> </servers> <compression><![CDATA[0]]></compression> <cache_dir><![CDATA[]]></cache_dir> <hashed_directory_level><![CDATA[]]></hashed_directory_level> <hashed_directory_umask><![CDATA[]]></hashed_directory_umask> <file_name_prefix><![CDATA[]]></file_name_prefix> </memcached> </cache> 状況 共有ホスティングBrim FPCがインストールされている:http : //ecommerce.brimllc.com/full-page-cache-magento.html (このFPCには、より複雑にするためにスケーラブルなファイルキャッシュもあります)

8
サイトの速度の最適化に関するアドバイス、どこから始めますか?
Magentoサイトの読み込み時間が遅い場合の解決策を見つけてみてください。Yslowテストを実行しましたが、最大の犯罪者は HTTPリクエストの数を減らす CDNを使用する Expiresヘッダーを追加 JavaScriptを最後に配置する jSとCSSを縮小する ETタグを構成する DNSルックアップを削減する AlphaImageLoaderフィルターを避ける Eコマースマネージャーとして、Magento管理者、ウェブマスターツールなどでの自分の役割から何ができるか、開発者にサイトをコンプライアンスに準拠させ、著しく高速化するよう指示することができるかについて、いくつかのアドバイスを探しています。 私はまた、管理者内であなたのためにこれの多くを行うように見えるGTMetrixと呼ばれるプラグインを見てきました(CSSシートの結合、画像の最適化など)、誰もこれで経験がありますか?私は通常、非常に多くの拡張機能を避けようとしますが、これは本質的な機能に深く入り込んでいますが、解決策のように思えます。http://gtmetrix.com/magento-optimization-guide.html あなたのアドバイスは大歓迎です。私はどこから始めて最高の影響を与えるのかを知るのに苦労しています。 前もって感謝します。

2
Magento Automatic Caching Insight
memcacheを使用してMagento EE 1.11を実行しています。memcahceサーバーあたり2GB、合計4GB。約240kの製品があります。 使用可能なRAM:6GB コア:16 スレッド:32 これが取引です。新しい製品が追加され、製品の変更が毎日行われます。もちろん、新しい製品がバックエンドで追加/変更されるたびに、キャッシュ、特に「フルページキャッシュ」が無効になります。 Magentos Auto Cache Generationを有効にすると、クローラーに8つのスレッドが割り当てられ、キャッシュの構築に約2日かかります。2日後、memcacheは2つのRAMディスク間で約2GB浮きます。 問題は、製品が毎日変更されると、キャッシュが無効になり、「フルページキャッシュ」が更新されるとすぐに、それらの2GBのキャッシュが1に戻り、Magentos Autoキャッシュの粘性サイクルが再び開始されることです。キャッシュが0に戻るだけでなく、CPU使用率が90%に急上昇し、ウェブサイトが5〜10秒以上待機するゲームに変わります。100種類以上のバリエーションがある製品をリクエストしようとするのを忘れることができます。キャッシュされていないので、初めてロードするのに数分かかります、それはばかげています。 だから、コミュニティへの私の質問。 Magentoが無効になった場合、キャッシュ全体を再構築せずに0から開始せずにキャッシュを自動的に「更新」する方法はありますか?キャッシュが無効になると、Magentoは何かが変更されたことを認識しますが、キャッシュ内の正確な場所はわかりません(間違っている場合は修正してください)。キャッシュ全体の再構築をバイパスするモジュール/構成はありますか? 補足として、Tiny Bricks LightSpeedモジュールを使用しています。 Magentos自動キャッシュ生成は、cronジョブで時間制御できますか?午後10時から午前6時にクロールを開始するとします。 この状況に対処する最善の方法は何でしょうか?、あなたが理解しているように、毎日ギガバイト単位のキャッシュを再構築することは受け入れられません。

1
Mage_Core_Model_Session_Abstract_Varien :: startの応答時間が長い
だから私は多くのサイトでNew Relicに気付いていました。Mage_Core_Model_Session_Abstract_Varien:: startが原因で、長いページ読み込みの多くが発生しています。私はいくつかの研究を行ったが、これについて他の誰も話していない。 キャッシュにはNginx、PHP FPM、Redis、セッションにはMemcacheを使用します。私の考えのいくつかは、多分それは永遠に取っている何かであり、セッションをロードすることが問題であるように見えるということです。または、どういうわけか、セッションに大量のデータを追加するカスタムコードがあり、巨大なセッションが発生します。 私はセッションとその管理方法に関してそれほど知識がありませんが、セッションのロックに関する記事をいくつか見つけました。しかし、私は人々が同時に多くのページを開いているとは思わない。 これらの負荷の一部は20〜30秒です。セッションに起因するこれらのタイプの長いリクエストを分析する方法について他の誰かがこれに気づいている、またはより多くの知識を持っている場合、私はちょうど興味があります。

3
コアモジュールを無効にした場合の副作用は何ですか?(例:Mage_Rss / Mage_Log)
たとえば、Mage_Rssは広く使用されておらず、チェックアウトリクエストごとに複数回キャッシュクリーニングを強制するため、Mage_Rssを無効にしてチェックアウトプロセスを高速化することをお勧めします。 私は同様の理由でMage_Logを無効にすることを評価しています-PapertrailApp.comを介してApacheログを集約するだけでなく、すでにGoogle Analyticsを導入していますが、結果をチェックするプロセスを正式化していないことに気づきましたので、お気軽にお答えください特にMage_Log用、または一般的にコアモジュールを無効にします。 / sqlのインストーラースクリプトと、\ etc \ config.xmlを参照して登録するイベントを調べることで、モジュールが使用するテーブルを判別できることはわかっていますが、他に関連するものは何ですか?このモジュールは、接頭辞log_を持つテーブルにのみ影響を与えるように合理的にカプセル化されていますか?このコアモジュールによって定義されたいくつかのイベントがありますが、それらのオブザーバーは正常/サイレントに失敗するか、ダウンストリームの問題を引き起こしますか?影響を受けるレポートがある場合、どのように通知するのですか?

2
magento 2はmagento 1よりも優れていますか?
magento 2のパフォーマンスとmagento 1.xバージョンよりも優れている点について知りたいのですが。最近、magento 2の学習を開始しましたが、これは純粋なzendアーキテクチャに基づいたまったく新しい理論セットであることがわかりました。したがって、Magento 1.xバージョンよりも優れているかどうかを知りたいだけです。

4
phtmlテンプレートでgetModelクラスをインスタンス化するのは良いですか?
これは、Magentoの優れたプログラミング慣行に関する質問です。 製品を関連製品とともにサムネイルで(カテゴリ製品リストに)表示する必要があります。だから私はmypackage/mytheme/template/catalog/product/list.phtmlこのようなもので編集しました <?php $related=$_product->getRelatedProductIds(); if(count($related)>0){ echo '<div class="a'.$ap.'"></div>'; echo '<div class="li_p"><ul>'; foreach($related as $rela){ $rela_nom=Mage::getModel('catalog/product')->load($rela); echo '<li><a href="'.$rela_nom->getProductUrl().'"> <img src="'.$this->helper('catalog/image')->init($rela_nom, 'small_image')->resize(20).'" width="20" height="20"> </a><li>'; } echo '</ul></div>'; } ?> そして、それは非常にうまく機能します。 しかし、私の質問は次のとおりです。phtmlファイルでモデルクラスをインスタンス化するのは正しいですか? そうでない場合、この機能を実現する最良の方法は何でしょうか?つまり、どのファイルを編集するのが良いのか、どのクラスを追加するのが良いのか、どこですか?ヘルパー? 少し例を挙げてください。または、どのファイルを編集するほうが良いかを教えてください。

2
Magento CEでニスを使用するために必要な変更
VarnishがMagentoサイトをキャッシュできるようにするには、どのような修正が必要であるかの良い実例を見つけるのに苦労しています。 理想的には、無効/有効にするものやそれらを探す場所などのタスクのリストが欲しいです。また、これらの変更が機能するように設計されたVarnish構成を用意しておくとよいでしょう。 Magentoのパフォーマンスガイドはワニスについて多くのことを話しているので、以前に行われたことは知っていますが、実際に機能させる方法については説明していません。

3
SOAP呼び出しのパフォーマンスを改善する
Magento 2.1のパフォーマンスに問題があります 私の店には、90.000の製品があります。これらの製品を石鹸に加えました。これを行ったとき、各記事(製品?)(要求>応答)で約7秒かかりました。要約すると、すべての製品を初期化するのに数日かかりました。 現在、すべての製品がショップにあります。数週間のうちに、記事(製品)に関するいくつかのことを更新する必要があります。石鹸でこれを再度行うと、同じ時間がかかります。更新を行うと、ショップは使用できなくなります。リクエストとレスポンスの例はこちら:https : //pastebin.com/aqnMJk98 https://pastebin.com/UAh0h8Zz サーバーには、12コアのCPU、24 GBのRAM、およびSSDが搭載されています。Apache2 PHP7-fpmおよびMYSQLを使用したUbuntu 16.04の実行。 更新プロセスを見ると、MySQLの5つのコアが100%PHPで少し動作しており、残りはアイドル状態です。使用するRAMはごくわずかiotopであり、SSDが退屈していると言います。 データベースのパフォーマンスを見て、Magentoがデータベースへの追加プロセスで数千のコマンドを実行したことを確認しました。これでいい? Magento CSVインポートで更新すると、はるかに高速になります。 このMagento2を高速化するにはどうすればよいですか?この状況では、このショップでうまく機能することは不可能です。

1
Magento 2のVCLを作成する
公式ドキュメントでは、Varnishは標準でサポートされていると書かれており、Varnish 3およびVarnish 4と互換性のあるVCLファイルを生成するオプションがあるはずです。管理パネルまたはCLIを使用してこれを見つけることができません。誰かがこの機能を使用しようとしましたか?

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.