web-dev-qa-db-ja.com

パフォーマンスとスケーラビリティを向上させるためにサーバーを調整するためのアドバイス

私は主に認証されたユーザーが使用するWebアプリケーションに取り組んでいます。 WebアプリケーションはFeedsモジュールを使用してCSVファイルからレコードをインポートします。このデータを保存するために選択されたのは、MySQLではなく書き込みの方がはるかに高速であるためです。アプリケーションは、毎日何千ものレコードを非常に高速にインポートしています。レコードはユーザーに参照され、ユーザーがログインすると、情報を参照できます。アプリケーションは、モバイルアプリのAPIとしても使用されます。

サーバーとして17GBのAWS EC2インスタンスがあります。

Varnishは、匿名ユーザー向けのコンテンツを完全に提供する機能をインストールします。 1秒あたり約3000〜4000リクエストを取得していますが、これで十分です。

私の問題は、認証されたユーザーのベンチマークを行うときに、jsonコンテンツのみのAPIページで、1秒あたり24のリクエストしか取得しないことです。また、他のページでは、1秒あたり9〜11リクエストのようになります。以下は、Apacheベンチマークの出力です。

Concurrency Level:      100
Time taken for tests:   9.154 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      1790900 bytes
HTML transferred:       1731600 bytes
Requests per second:    10.92 [#/sec] (mean)
Time per request:       9154.469 [ms] (mean)
Time per request:       91.545 [ms] (mean, across all concurrent requests)
Transfer rate:          191.05 [Kbytes/sec] received

memcache_storage モジュールを使用してMemcacheがインストールされています。何らかの理由で、 memcache ではなく、このモジュールを使用すると1秒あたりの要求がわずかに高くなります。 4GbはMemcacheキャッシュとして設定されます。 Memcacheの統計出力の一部を次に示します。

Cache Information
Current Items(total)    10730 (95109)
Hits    644064
Misses  74324
Request Rate (hits, misses) 1.44 cache requests/second
Hit Rate    1.29 cache requests/second
Miss Rate   0.15 cache requests/second
Set Rate    0.19 cache requests/second

APCもインストールされ、完全に機能します。

多くのモジュールをインストールしていません：

芯

ブロック、フィールド、フィールドsqlストレージ、フィールドUI、ファイル、フィルター、画像、リスト、ロケール、メニュー、ノード、数、オプション、パス、システム、分類法、テキスト、ユーザー、

貢献する

コンテンツアクセス、ワニス、ctools、eck、フィード、フィードui、改ざんフィード、改ざんui、メール、フィールド権限、hsmフィールド、ノード参照、参照、ユーザー参照、jquery update、mongodb、mongodbストレージ、mongodbウォッチドッグ、エンティティapi 、メッセージを無効にする、画像URLフォーマッタ、ジョブスケジューラ、ライブラリ、クイックタブ、クイックタブスタイル、apc、eckエンティティキャッシュ、エンティティキャッシュ、memcacheストレージ、サービス、レストサーバー、エンティティフィールドクエリビュー、ビュー、json、ビューui。

Develの出力については、通常、次のような結果が得られます。 （この出力は、ページを更新した後のものです）

Executed 57 queries in 10.79 ms. Queries exceeding 5 ms are highlighted. Page execution time was 167.27 ms. Memory used at: devel_boot()=1.36 MB, devel_shutdown()=13.96 MB, PHP peak=14.25 MB.

_drupal_session_writeクエリは常に最も長く、8ミリ秒未満で実行されることはなく、下の出力のように500ミリ秒に達することもあります。

Executed 57 queries in 607.49 ms. Queries exceeding 5 ms are highlighted. Page execution time was 2395.87 ms. Memory used at: devel_boot()=1.36 MB, devel_shutdown()=13.96 MB, PHP peak=14.25 MB.

これらは私のPHP settings.phpの設定です

/**
 *MongDB configuration
 */
 $conf['mongodb_connections'] = array(
   // Connection name/alias
   'default' => array(
     // Omit USER:PASS@ if Mongo isn't configured to use authentication.
    'Host' => 'mongodb://localhost',
     // Database name
     'db' => 'mydb',
   ),
 );
 $conf['mongodb_watchdog'] = 'mydb_logs';
 $conf['field_storage_default'] = 'mongodb_field_storage';

/**
 *Memcached
 */
$conf['cache_backends'][] = 'sites/all/modules/memcache_storage/memcache_storage.inc';
$conf['cache_default_class'] = 'MemcacheStorage';
$conf['cache_class_cache_form'] = 'DrupalDatabaseCache';
$conf['session_inc'] = 'sites/all/modules/memcache_storage/includes/session.inc';
$conf['lock_inc'] = 'sites/all/modules/memcache_storage/includes/lock.inc';

/**
 *Varnish
 */
$conf['cache_backends'][] = 'sites/all/modules/varnish/varnish.cache.inc';
$conf['cache_class_cache_page'] = 'VarnishCache';

/**
 * Add APC Caching.
 */
$conf['cache_backends'][] = 'sites/all/modules/apc/drupal_apc_cache.inc';
$conf['cache_class_cache'] = 'DrupalAPCCache';
$conf['cache_class_cache_bootstrap'] = 'DrupalAPCCache';

My.cnfファイルの構成。

key_buffer_size = 12M

query_cache_size = 32M

query_cache_limit = 2M

query_cache_type = 1

# InnoDB caches.
innodb_buffer_pool_size = 500M
innodb_flush_method = O_DIRECT

max_connections = 75

table_cache = 96

sort_buffer_size = 12M

tmp_table_size = 12M

この時点で本当に迷っています。パフォーマンスとスケーラビリティに関する記事をたくさん読んだので、言及されていることのほとんどを実行したようですが、まったく機能していないようです。サーバーがこの数値で本当に速くクラッシュするように感じるので、私はストレスを感じています。誰かがアドバイスをくれるといいのですが。

敬具。

7cachingperformance
3
Arturo

質問が具体的すぎるため、まだ回答はありませんでした。それをいくつかの正確な質問に分けて、正確な答えが得られるようにすることをお勧めします。誰かが完璧な答えをここで提供できる方法はありません。

しかし、少し手助けしてみましょう。

  • アプリケーションは主に認証されたユーザーによって使用され、ここでパフォーマンスの問題に気づいたので、当面はVarnishに焦点を絞らないことをお勧めします。
  • Apache ABでのベンチマークは、私の経験では最も信頼できる負荷テストツールではありませんでした。代わりに Apache jMeter をお勧めします。余裕がある場合は、 Soasta などの世界クラスのクラウド負荷テストプロバイダーを入手してください。オプション、試してみてください Blitz.io 。
  • MongoDB： StackOverflow で直接回答を検索して、そこで経験豊富なMongoDBの人々を把握し、新しい質問をする必要があります必要に応じて質問。
    • DrupalコミュニティではMongoDBの経験があまりないことに注意してください。フィールドストレージにそれを使用している主要なサイトが少なくとも1つあることを知っています（ examiner.com ）しかし、これにはかなり深い専門知識が必要であり、長期的にそれを維持するのに問題が発生する傾向があります。したがって、この全体の決定に疑問を投げかけ、代わりにMySQLを使用することが本当にボトルネックになるかどうかを判断する単純に遅いが、許容できる場合でも、バッチインポートを小さくすることで、ほとんどのフィードのパフォーマンスの問題を解決できます。
    • また、@ chxはDrupalのMongoDB開発にかなり深く関与していることにも注意してください。彼のサイトには、20以上の「 私の/ MongoDBの観点からのDrupal 8の進捗状況 」というブログ投稿があります。
    • https://drupal.org/project/mongodb モジュールについて知っていることは確かですが、念のため、ここに行きます:-)
  • Memcache Storageは必ずしも最良のオプションではありません。 https://drupal.org/node/206075 でかなり白熱した議論がありましたが、ここでは、メインのMemcacheプロジェクトを修正する方が適切である可能性があることがわかります。 memcacheと同じレベルのコミュニティー作業が得られる可能性が非常に低い競合モジュール。また、使用されるベンチマーク方法論は議論の余地があるため、パフォーマンスの利点は広く議論されてきました。

あなたへの私の主なアドバイスは、物事をシンプルに保ち、できるだけ多くの複雑さの層を取り除き、そこから始めることです。 https://drupal.org/project/memory_profiler モジュールを使用して、どのページが非常に遅いかを確認するか、XHprofプロファイリングを使用して次のレベルに進みます（ そのためのモジュールがあります！ ）

1
anavarre