15

現在、3 つの異なるストアを実行している 1 つの magento アプリがあります。

このストアのデータベースのサイズは 370MB です。店舗は 9,000 の SKU を共有し、それぞれに 1,000 から 2,000 のグループ化された製品 (SKU を関連付ける) があります。

apache AB ベンチマーク ツールを実行すると、1 秒あたり 0.29 リクエストという低い値が得られます。これは、magento ストアでも非常に低い数値だと思います。

ただし、最大の懸念はバックエンドです。現在、5 人がバックエンドを介して新しい製品を更新および挿入しており、1 つの製品を更新/挿入するのに 4 分もかかっています。それは膨大な時間の無駄であり、私の人生でそれを説明することはできません.

私のサーバーのリソースは次のとおりです。

  • プロセッサー: AMD Athlon X2 3400+ (2x 1.8Ghz)
  • メモリー: 4GB
  • ディスク: 2x 500Gb

Debian Lenny Apache 2.0、PHP バージョン 5.2.6-1+lenny16、eAccelerator および Memcahed を実行しています。（ここですべての情報を確認できます）

そして、これがApache、MySQL、およびPHPの構成ファイルです。

私はサーバー管理者ではありません (ただし、すべての Web サイトとサーバー自体を担当しています) ので、これはいわば私の「ビーチ」ではありません。私の質問は、これが現在のリソースで動作するはずの方法ですか、それとも構成に重要な何かが欠けているのでしょうか?

これは「手持ち」を探しているように見えるかもしれませんが、それは私の意図ではありません. 新しいものを何度も試すことに飽き飽きしていて、スムーズに実行できないようです。

4

7 に答える 7

6

率直な答えは次のとおりです。サーバーの能力が不足しています。これをどのように構成しても、Magento により適した環境にアップグレードする必要があります。

上位 10 個の一般的な CPU に対する CPU マーク

ソース: http://www.cpubenchmark.net/cpu.php?cpu=AMD+Athlon+64+X2+Dual+Core+3400%2B

ただし、上記の CPU は、AMD デュアルコア チップと比較して約 10 倍の処理能力を持つ非常にハイエンドな CPU です。Intel Core i7 2.2GHz クアッドコア ベンチマークである私のラップトップ CPU は約 5,000 です。ここにあるリストから 5,000 を超える CPU を選択することをお勧めします。

16GB の RAM と SSD も、最近はそれほど費用がかからないことを考えると、合理的/妥当に思えます。

于 2013-02-25T02:35:07.340 に答える
3

Magento のようなサイトにはキャッシュ サイズが小さすぎます。私は同様のサイトを運営しており、256 MB のキャッシュがあります。16MB を使用すると、常にダンプをキャッシュする必要があります。

Magento の隣で他に巨大なものが何も実行されていないと仮定すると、サーバー リソースは負荷に対して問題ありません。独り占めですが、それほど悪くはなく、4 GB の RAM で十分です。

キャッシュを一時的に無効にして、改善されるかどうかを確認します。また、最適なキャッシング構成がない可能性があるため、Magento のストア構成に目を通すことをお勧めします。Magento のキャッシング設定は複雑で不透明です。

于 2013-02-15T19:22:15.223 に答える
3

このスレッドが古代のインターネット時間であることは知っています。ほとんどの所有者/開発者にとって最も関連性が高いと思われるいくつかのポイントを追加すると思いました. Magento のパフォーマンスは、考慮すべきことがたくさんある深いトピックになる可能性がありますが、うまくいけば、いくつかの主要なポイントを理解することが大いに役立ちます。

  1. キャッシング(オペコード キャッシュ、MySQL キャッシュ、フル ページ キャッシュなど)を活用すればするほど、ハードウェアの重要性は低くなります。申し訳ありませんが、現在使用しているハードウェアは非常にひどいものです (既に指摘したように)。これを回避し、キャッシュをより適切に活用することでパフォーマンスの問題を隠すことができます。最も重要なのは、フル ページ キャッシュ (Google) と opcode キャッシュをセットアップすることです。
  2. キャッシングはスピードアップに役立ちますが、深くフィルタリングされたカテゴリページ、検索ページ、カート、チェックアウトなど、キャッシュされていないページにアクセスすると、ハードウェアの貧弱さが目立ちます。訪問者がこれらのページのいずれかにアクセスすると、ほとんどのキャッシュがバイパスされ、適切なハードウェア/適切に構成されたセットアップに行き着きます. この時点で、パフォーマンスの問題があることが明らかになります。
  3. 一般的に言えば、より高速な CPU (より高い GHz) は、Magento を構成する多数の PHP ファイル (約 14,000 以上) をより高速に処理できることを意味します。PHP はほとんどの場合、最大のボトルネックです。
  4. SSD は待ち時間が短いため少しは役に立ちますが、より大きなカタログ(システム内のより多くの製品または注文) では実際に役立ちます。このシナリオでは、データがドライブのより大きなセクションに分散され、さまざまな MySQL テーブルにアクセスしてデータにアクセスするために、ハードディスク上のさまざまな物理的な場所にバウンスする必要があるため、SSD は通常 HDD (15k rpm でさえ) よりも優れています。 . SSD は、この種の「ランダム シーク」作業をより適切に処理します。DB全体をメモリにロードするのに十分なメモリがある場合、チェックアウト中にデータベースに注文を書き込む場合や、保存されたカートの製品データなどを除いて、これは大した問題ではありません.
  5. よくある誤解は、CPU コアが多いほどウェブサイトが高速になるというものです。これは非常に誤解を招きます。CPU は主要な高速道路のようなものだと考えてください。コアは高速道路の車線のようなもので、CPU GHz は速度制限のようなものです。時速 50 マイルで 20 レーン、または時速 100 マイルで 1 レーンのどちらを使用しますか? 交通量にもよりますよね！サイトへの同時訪問者が増えるということは、通常、より多くのコアが役立つことを意味します。トラフィックが比較的少ない場合は、コアが少なくてもクロック速度が高い方がはるかに優れています。Magento cron、インデクサー、および管理領域で作業する管理者などのすべてが負荷に加わることを考慮してください。redis、memcache、varnish などのキャッシング プログラムも追加した場合、これらも高速道路のスペースを消費します。
  6. CPU や HDD が過負荷になっているかどうかを確認する簡単な方法は、サーバーの統計情報を確認することです。確認できるように、10 分ごとに CPU / ディスクの統計をログに記録するsarなどを設定してみてください(カスタマイズ可能)。CPU の % アイドル時間を表示する必要があります。アイドル時間が増える = 頑張りすぎない。おそらくそれ以上のコアは必要ありません。ディスクの場合は、iowait列を確認します (またはiostatリアルタイムで使用します)。iowait が高い場合は、より優れたディスクまたは SSD が役立つ可能性があります。
  7. 持っている RAM が多いほど、キャッシュできる (および処理できる接続) が多くなります。ユーザー (apache / nginx / mysql) からの接続ごとに、および一般的なシステム オーバーヘッドのために、一定量の RAM が使用されます。RAMが多いほど、RAMにキャッシュできるものが多くなり、高速になります。たとえば、MySQL を調整し、ほとんどのデータをメモリに保存して、検索を高速化できます。これは、RAM のレイテンシが低いだけでなく、データの取得に必要な CPU サイクルも少ないためです。その結果、読み込みが高速になり (場合によってはわずかに)、CPU 負荷が大幅に低くなります。セッション、Magento キャッシュ、フル ページ キャッシュ、MySQL データ、およびその他のアイテムをメモリに保存できます。したがって、必要な量はさまざまですが、一般的な経験則は次のとおりです。データベースのサイズは、メモリの約 25 ～ 50% に抑える必要があります。1 GB の magento データベースがある場合、約 4 GB のメモリが必要です。
  8. 多くの場合、CDN はユーザー ページの読み込みに劇的な影響を与えることはありませんが、サーバーの負荷を軽減することはより重要です。CDN の主な利点は、そのサーバーがコンテンツをダウンロードする訪問者に物理的に近いことです。より近いサーバーがロード時間から 50 ミリ秒しか短縮しない可能性があることを考えると、それほど大きな影響はありません. さらに重要なことは、CDN が静的ファイルのすべての要求を処理するようにすると、サーバーが主に動的要求で動作するようになる可能性があることです。場合によっては、CDN がページに読み込まれたアセット (画像、css、js など) の 90 ～ 99% の読み込みを処理していることを意味します。トラフィックの急増 / かなりの高負荷が発生している場合。
于 2015-03-31T23:32:22.477 に答える
2

私は、7 つのサイトで 30,000 以上の製品を扱う会社で Web 開発を行っていますが、通常、製品のアップロードや編集に管理者を使用しないようにしています。アップロードと編集にはmagmiを使用しています。この製品にとても満足しています。lightspeed サーバーを使用していますか?

于 2013-02-19T18:35:06.007 に答える
1

仮想サーバーを実行している場合は、Nginx を Apache の代替として使用することを検討してください。これにより、パフォーマンスがいくらか向上することがわかりました。また、ある種のキャッシングの実装も検討してください。Memcached または Redis を使用することをお勧めします (実行できる場合)。これにより、パフォーマンスが大幅に向上することは間違いありません。

Magento は非常にデータベース集約型のシステムです。ウェブサイトの混雑度によっては、さらに RAM を追加できる可能性があるため、実行中のプロセスの量に十分なメモリがあることを確認してください。

于 2013-02-22T17:26:47.530 に答える
0

開発が完了したら、mysqlでの遅いクエリロギングを無効にします（my.cnfからコピーされた行）：

log_slow_queries        = /var/log/mysql/mysql-slow.log
long_query_time = 2

一部のphpおよびapache設定を上書きできる.htaccessファイルを投稿していません。

/app/etc/local.xmlにキャッシュ設定を追加しましたか？そうでない場合は、/ app / etc / local.xml.additionalを確認して、自分に最適なものを適用してください。

于 2013-02-21T19:18:25.543 に答える
0

Magentoには多くのリソースが必要です。バックエンド構造は、最適化が遅くて難しいものです。ただし、すべての製品をcsv / xmlからインポートし、手動でインポートしないことをお勧めします。これに関するチュートリアルがたくさんあります。

フロントエンドを最適化するためのヒントを次に示します。

  • パフォーマンスの指標については、GTMetrixを参照してください：http：//gtmetrix.com/reports/www.belexpress.eu/k2bPETVrホームページが大きすぎます。ページは、最初のロード時に1MBを超えてはなりません。これを高速化するには、遅延読み込みや画像の最適化などを使用する必要があります。

  • いくつかのヒントは非常に優れたパフォーマンスを可能にしますが、Webサイトがトラフィックを生成し、ホスティングに月額500ドルを得ることができる場合は、より大きなサーバーが必要になります。6クアッドコア、48GBRAMなどの非常に強力なサーバー構成を見つけることができます。 、SSDディスク、無制限の帯域幅を備えた10GB/sネットワーク。

  • （より強力なサーバーを備えた）より優れたホスティングソリューションを選択した場合、コンパイルを使用する場合は/varや/include / srcなど、最も使用されるディレクトリをRAMとしてマウントすることでパフォーマンスを向上させることができます。コードを毎日変更しない場合にのみコンパイルを使用します。変更しない場合は、RAMとして/ include/srcをコンパイル+マウントすると非常に優れたパフォーマンスが得られます。

  • eAcceleratorとmemcachedについてはよくわかりません。個人的には、APCを使用しており、ポート80をVarnishに置き換えました。それは私のウェブサイトに余分な速度を与えます。

Magentoを高速で実行することは、あらゆる側面を最適化するための日常的な作業であり、魔法のトリックはありません。

よろしく、

于 2013-02-15T18:27:11.957 に答える