この例では、Tomcatサーバーに基づいて実行されるWebアプリケーションの動作がシミュレートされます。 測定はさまざまな負荷で行われました。 接続されているクライアントの数を増やすことにより、負荷が変化しました。 適応症の測定は、アプリケーション所有者の管理パネルを介して実行されました。
サーバー実装
セッションの各新規ユーザーには、サイズが10 MBのバイトの配列が配置されます。
<html> <body> <h1>Hello!</h1> <% byte[] data = (byte[]) session.getAttribute("test-data"); if (data == null) data = new byte[1024 * 1024 * 10]; request.getSession().setAttribute("test-data", data); %> Your session ID <%=session.getId()%><br/> Your session data size <%=data.length%> bytes<br/> </body> </html>
お客様到着
グラフは、それぞれ100、300、1000の3つの顧客の波を示しています。
- 100クライアントの最初の波（一度に1つのストリームで）は約1.3Gbを消費します。 その後、セッションのタイムアウトがあります（10分）==ユーザーセッションからのすべてのデータがアンロードされ、メモリがプラットフォームに返されます。
- 300クライアントの第2波（10ストリーム）〜3.5Gb。 繰り返しますが、セッションのタイムアウト後、メモリはプラットフォームに戻ります。
- 1000クライアントの第3波（100ストリーム）〜11Gb。 セッションがタイムアウトすると、メモリはプラットフォームに戻ります。
ズーム設定
最初の行の右側の列には、数字3/64（現在/制限）が示されています- クラウドレットのメモリ消費量（最小分割不可分は256Mb）。
アプリケーションは、1〜64個のクラウドレット（256Mb〜16Gb）に拡張できます。 このアプリケーションのスケール係数設定= x64回。
結論
Webアプリケーションが各ユーザーに10Mbのデータをロードすることはまずありませんが、それでもテストはJelasticの可能性を完全に実証します。 私たちの場合、この量のデータをセッションにロードすることは、メモリの増加プロセスを高速化し、適切なメモリポンピングに必要なクライアント数を減らすために行われました。
より現実的な指標については、この投稿のタイトルを読んだ全員が実際の条件でのテストに参加します。 上の画像は、200Kbを各ユーザーのセッションにロードします。 トピックが興味深い場合、実際のテストの結果は後で投稿されます。 16Gbで確立された制限がHabrユーザーにとって十分であることを願っています。
- 更新
実験結果
- 最初のピーク-この記事の負荷テスト-は11Gbのメモリを消費しました。
- 2番目のピーク-この記事の主要なリリース-は2Gbのメモリを消費しました。
- テール-残留現象、アクティビティの低下-は0.6Gbのメモリを消費しました。
ユニーク訪問者ごとに200 kbのメモリがメモリに格納されたという事実に基づいて、同時に10分以内に、ピーク時に5,000人以下のサーバーがサーバーに存在しました。
結果は、まだサーバーをロードできる必要があることを示しています:)、ロードのエミュレーションは実際よりもメモリを揺さぶりました。
どちらの場合も、彼はメモリから動的スケーリングを行い、実際に消費されたクラウドレット