CMS「1C-Bitrix」の負荷テスト

バー、プール、レストランのある飛行機についての冗談を知っていますか。客室乗務員を離陸するときだけ「そして今、これですべて離陸しようとします」と言いますか？



Web開発は、そのような飛行機に少し似ています。 顧客は、Webスタジオにクールなデザイン、多数のインタラクティブ機能、およびオンラインストアへのすべての配信および支払いサービスを望んでいます。スタジオはこれをすべて喜んでプログラムします。しかし、サーバーがサイトの安定した運用を保証する十分なパワーを備えているかどうかは不明です

負荷を予測可能にするために、いくつかの参照値を設定するために、「1C-Bitrix：Site Management」および「1C-Bitrix：Enterprise」の負荷テストを実行しました。



クライアントが現在の機器で何が得られるかを理解し、開発者がプロ​​ジェクトの成長の見通しを理解できるように、テストを実施しようとしました。 負荷の増加に応じて拡張できますか？



この記事では、テストをどのように組織化および実施したか、そして自分自身に対してどのような結論を出したかについて説明します。



何に役立ちますか？ 参照番号により、現在のサイトと潜在的な新しいホスティングを比較し、新しい機能の導入がシステムに与える影響を明確に評価できます。 はい、システムの技術的な制限を理解してください。



テストの構成、テストプロセス中に発生した特定の問題、およびテスト結果から導き出せる結論に焦点を当てました。 最も関心のある方のために、詳細な技術レポートへのリンクがあります。

問題の声明

多くの人がストレステストの意味、目的、目的を異なって理解しています。



そもそも、自分で処方する必要があります-何が欲しいのでしょうか？



テストする製品と形式

まず、実際のオンラインストア、そのコード、およびデータベースを取得したいと考えました。 しかし、これはこの特定のソリューションをテストするものであり、他の開発者はそれを参照ポイントとして使用することはできません。 そのため、標準の「ボックス」をテストし、大規模なオンラインストアに対応する多数のポジションで満たす必要があります（私たちの経験では、これは約100,000 SKUです）。 「1C-Bitrix」は、付属の「Composite Cache」テクノロジーと連携しました。これは、保存されたページの高速キャッシュをnginxから最初にロードし、次にajaxリクエストで動的データをロードするソリューションです。 したがって、ユーザーはできるだけ早くページを受け取ります。 1秒あたりのクエリ数を推定するために、動的クエリを検討しました。



サーバーアーキテクチャはどうあるべきですか？

必ず単一サーバー構成をテストしてください。これは最も単純で最も一般的な構成です。 しかし、2台目のサーバーを追加するとパフォーマンスがどれだけ向上するかを理解することも興味深いですか？ 二重になりますか？ 4台のマシンのクラスターを使用するとどうなりますか？ 新しいサーバーと新しいサーバーをクラスターに追加して、水平方向に正常にスケーリングすることは可能ですか？



したがって、2台と4台の1台のサーバーから構成をテストすることにしました。



どの負荷シナリオを作成する必要がありますか？

多数の大規模店舗の負荷の分析によると、オンラインストアのトラフィックは3つのカテゴリに分類できます。

1. ユーザーの60％は、カタログ内の複数のページを訪れて、必要な特定の製品を把握しています。
2. 37％のユーザーが、いくつかの可能な製品から目的の製品を選択し、フィルタリング（スマートフィルター）を適用します。
3. ユーザーの3％（良好なコンバージョンの標準的な指標）は、製品をバスケットに入れて購入しました。

サーバーのロード方法

プロジェクトの負荷テストには、クローズドとオープンの2つの主なモデルがあります。 Closedは、「ユーザー」のリクエストが静的なストリームで送信される人工的な一定の静的負荷を意味します（実際のように、波ではありません）。 その目的は、最大負荷でのプロジェクトの動作を調べて、システムの最大「スループット」を理解することです。 これは指標の上部のバーであり、それを超えることはできません。



オープンモデルには、実生活に近いテストが含まれます。ユーザーは、システムが耐えることができないほどの波にさらされます。 これは、システムの限界、重要な条件での動作方法を見つけるのに役立ちます。



このテストの目標はシステムのスループットを見つけることでした。そのため、SLAが耐えられる最大負荷で閉じたモデルを選択しました。



テストに選択するSLAはどれですか？

システムが安定してリクエストを処理していると判断するしきい値を明確に識別する必要がありました。 これを行うために、 大規模オンラインストアのTOP-100統計（2014年のKommersantのバージョンによる）を使用し、2つの主要なメトリックを選択しました：要求の99％への応答は1秒未満で与えられるべきであり、コードでの応答の数、 HTTP 200とは異なり、0.5％以下にする必要があります。 テストは24時間継続して実施する必要があります。



どのホスティングを選択しますか？

テスト用のサイトとして、サンクトペテルブルクのTsvetochnnaya-1データセンターでホストするSelectelを選択しました。 Selectelは、最も一般的な構成のサーバーを提供しました-Intel Xeon E3-1270v3 3.5 GHz、32 GBのRAM、RAID 1の2×240 GB SSDドライブ。1台のサーバーは、異なる構成でロードセンターとして使用されました。 1C-Bitrix」、テストに使用しました。



システム構成

テストの一環として、サーバーはLinux CentOS 6.6で動作し、1C-Bitrix：Web Environmentパッケージがインストールされています 。詳細については、 こちらをご覧ください 。



システム上のPHPはバージョン5.6.9に更新され、キャッシュディレクトリはtmpfsにマウントされました。 テスト用に3つの構成が準備されました。



1）1台のサーバー。 「1C-Bitrix：Site Management」、WebおよびMySQLは同じサーバーで動作します







2）2台のサーバー。 「1C-Bitrix：Enterprise」、最初のサーバーのnginxバランサー、両方のサーバーのWebアプリケーション、MySQLマスターとその書き込み/読み取り-最初のサーバー、MySQLスレーブと読み取り-2番目のサーバー







3）4台のサーバー。 2番目の構成がスレーブマシンによって水平方向にスケーリングされるバリアント。



テスト方法

テストツールとしてYandex.Tankが選択されました。 Yandex.Tankでは、PhantomとJMeterの2つの負荷生成システムを使用できます。 Phantomは、パフォーマンスの点ではJMeterより優れていますが、POSTロジックの生成、Cookieの保存およびその後の使用は許可しません。 このため、JMeterを使用して負荷を生成しました。



誰がテストしていますか？

私たちは、独立した企業がテストを実施することを望んでいました。その意見は、私たちとサードパーティ企業、および業界の専門家の両方から信頼されています。 このタスクをITSummaに委ねました。ITSummaは、2008年からRunetの有名なプロジェクトの24時間体制の管理と技術サポートを行い、市場で定着しています。 その従業員は、専門会議（Highload、RIT ++など）の定期的な講演者です。

テスト中

振り返ってみると、テストは3つの段階に分けることができます。



最初の段階はフィッティングシューティングで、SLAが保存されるスレッドの最大数を選択します。

• 単一サーバー構成：34スレッド
• 2サーバー構成：74スレッド
• 4サーバー構成：136スレッド

2番目の段階 -最初の段階では、完全なテストを実行しようとします。 ストレステストを計画するときは、テストを実行するシステムの最終決定とテスト手順自体の改良の両方に時間がかかることを理解する必要があります。



この段階で、多くの困難に直面しました。 それらを克服した経験から、多くの教訓を学びました。

1. ストレステストを実施する場合、最初の大規模なテストは理想的な結果からはほど遠いことを忘れないでください。 おそらく、OSとサーバーソフトウェアの構成にある何かを忘れるでしょう。 テストシステム自体に問題がある可能性があります（JMeterはJavaアプリケーションであり、 ガベージコレクションに固有の問題があります ）。 まあ、そして最も重要なこと-あなたはあなたのシステムにあなたが以前に気付かなかった、そして修正することができる薄いスポットを見るでしょう。 たとえば、テストの一環として、9つの重大なバグが発見されました。これらの修正は、製品の次のバージョンでリリースされる予定です。 したがって、最適化ガイドとして最初のテストを検討してください。
2. やや明らかなことですが、これは言う価値があります：最適化中に、サーバー上のすべての構成変更をコミットする必要があります。 理想的には、一度に数個以上の変更を適用しないでください。 そうしないと、どのアクションがパフォーマンスの向上につながったかを正確に把握することが困難になります。
3. すぐに検出されないエラーが存在する場合の毎日のテストは、仕事の損失です。 繰り返しの1つの後、構成に多くの変更を加えたとき、良い結果が得られ、満足していました。 しかし、その後、彼らは3番目のシナリオがオフになっていることを発見しました。これは、私たちの場合で最も難しいユーザーの注文です。 私は再びテストを始めなければなりませんでした。 1日後、適用された変更がシステムを高速化しないことがわかりました。
4. ストレステストの対象となるシステムは実稼働システムであり、実稼働サイトで発生する一般的な問題はすべて同じことが起こり得ます。 テストの1つでは、起動から12時間後に、いずれかのサーバーのスペースが不足しました。 したがって、問題が電話に届くように、使い慣れた監視システムのサイトで問題に関する標準のアラートを出すことが重要です。 そして、受け取り次第、すぐに実行して、すでに収集された貴重なデータを失わないように状況を修正する必要があります。
5. 良い結果は、多くの場合、テストエラーを意味します。 反復の1つでは、前のテストと比較して2倍の増加がありました。 MySQLは最大接続を超えると「クラッシュ」し、そのような状況のサイトはテストシステムに有効なHTTP 200コードで応答することが判明しました。
6. どのテストでも、「官僚主義」は非常に重要です。スクリプト、システム構成、テストログなど、テストのできるだけ詳細な説明を作成してください。 これらはすべて、その後の分析に役立ちます。

3番目の段階はテスト自体です。 すべての手順が完了し、システムが最適化されたら、テストを数回実行することをお勧めします。 私たちの経験では、これにより真に正確な結果を得ることができ、24時間のテストでも同じテストとほとんど同じになります。 テストを繰り返して、1秒あたりのクエリに対して正確な結果を得ました。

試験結果

構成1（1サーバー、「1C-Bitrix：Site Management」、「Business」エディション）



テスト実行時間：86 892秒

• 1秒あたりのPHP要求の数：167、34の同時スレッド
• 99パーセンタイル：0.366ミリ秒。
• 閲覧したページ数：14 421 563
• 失敗したリクエストの割合：0.31％

パーセンタイルヤンデックスタンク





RPS「シェルフ」（上限-毎秒350リクエスト、「合成」リクエストを含む-毎秒167動的リクエスト）。



これは、複雑なシステムにとっては良い結果ですが、バスケットとそのデザインに商品を追加するための複雑な手順によって主な負担が生じることに注意することが重要です。



構成2（2台のサーバー、「1C-Bitrix：Enterprise」）

• テストリードタイム：86,850秒
• 1秒あたりのPHP要求の数：265、74の同時スレッド
• 99パーセンタイル：0.95
• 閲覧したページ数23 082 301
• 失敗したリクエストの割合：0.47％
• 1と比較したスケール係数：1.60構成

パーセンタイルヤンデックスタンク





「シェルフ」RPS（「複合」リクエストを含む-上限-毎秒550リクエスト）。



1秒あたりのリクエスト数は、期待したほど増加しませんでした-1.6倍。 マルチサーバー構成では、サーバー間相互作用とデータ交換のオーバーヘッドが追加されることに注意してください。



構成3（4台のサーバー、「1C-Bitrix：Enterprise」）

• テストリードタイム：86,402秒
• 1秒あたりのPHP要求の数：535、136の同時スレッド
• 99パーセンタイル：0.9
• 閲覧したページ数：46,256,141
• 失敗したリクエストの割合：0.47％
• 構成2と比較したスケールファクター-2.00

パーセンタイルヤンデックスタンク





RPS「シェルフ」（「複合」リクエストを含む-上限-1秒あたり1100リクエスト）。



そして、ここで-スケーリングで優れた結果。 2サーバー構成にさらに2つのサーバーを追加すると、生産性が2倍に向上しました。 この結果は、「鉄」の垂直制限に達しないことを示唆し、追加のサーバーがマシン間で負荷を適切に分散します。

結果と今後の計画

このテストでは、開発者がシステムのパフォーマンスを評価するときに集中できる標準を設定しようとしました。 私たちにとって非常に重要な結果は、水平スケーリング「1C-Bitrix」の高効率の確認でした。2台ではなく4台のサーバーを使用し、2倍の増加をもたらしました。 そしてもちろん、1つのサーバー上の複雑なシステムでのダイナミクスに対する167クエリが優れたメトリックです。



次のポイントを自分で確認するために、オープンシステムでテストを実施する予定です。

1. 単一のサーバー内で制限に達した後、システムはどうなりますか？
2. システムは超高負荷からどのくらいの速さで回復しますか？
3. 開発者が現在の機器で作成したプロジェクトを提供できる実際のユーザー数を推定できるように、このようなツールキットを入手する方法は？

このテストの結果と私たちが学んだ経験についてお話しします。



便利なリンク：

1. 1C-Bitrixの負荷テストに関する詳細レポート
2. Yandex.TankのAlexey LavrenyukによるFailOver Conference 2015のレポート
3. JMeterのチューニング