だから...
多くのフレームワークにはパフォーマンスの制限があります。
我慢する必要があります。 非常に大量のコードは、過度のメモリ要件、プロセッサ、非効率的な同期、古いI / Oメカニズム、またはリソース不足による貧弱なエラー処理のために、高負荷の下では機能しません。 たとえあなたのお気に入りのライブラリが非常に賢い人によって書かれ、欠陥がないとしても、それを設計するとき、利便性または使いやすさのために効率が犠牲になったという理由だけで適切ではないかもしれません。 したがって-自己記録と一緒に暮らす準備をするか、特定のアプリケーションのストレステストに合格するいくつかのソリューションを探してください。 誰もこの問題を信じることができません。
キャッシング、キャッシング、キャッシングを再度
まれに高負荷のシステムは、特にDBMSを介してキャッシュなしで実行できます。 分散システムでの適切なキャッシングは、大きく複雑なトピックですので、データについてすぐに考えるのは理にかなっています：誰がデータを更新して要求するか、どのように、どこで、どのようにデータの整合性または関連性を犠牲にすることができますか？
シンプルさ
一般に、システムが単純であるほど、動作は速くなります。 多くの場合、建築のわかりやすさ、概念、または美しさを損なうために、最大限のシンプルさを目指して努力する必要があります。
ネットワーク帯域幅には制限があります
シリアル化形式を選択するときは、事前に平均パケットサイズに1秒あたりのパケット数を掛けて、ネットワークの帯域幅と比較してください。 この点で、JsonはXMLよりも優れており、ProtobufはJSONよりも優れています。また、場合によっては、より高度なパッケージを使用して独自の形式を考案する必要があります。
オフヒープを忘れないでください
Javaの一部のオブジェクトは、動作するために追加のメモリを必要とするため、-Xmxが設定されている場合、アプリケーションがサーバーに確実に適合することを期待する必要はありません。 たとえば、Javaの各スレッドは、操作に256K〜2メガバイトのオフヒープメモリを必要とします。 1000を掛けると、すでにかなりの量が得られるので、アプリケーションで使用されるスレッドの数に注意してください。
ゴムではなくGC
厳密な遅延要件がない場合でも、ガベージコレクションに留意する必要があります。 割り当ての数、特に各リクエストに割り当てられるメモリの合計量を制限してください。 必要なすべてのメトリックは、Java Mission Controlプロファイラーにあります。
ロギングでより正確に
「まともなアプリケーションは常に入力および出力データをログに記録する必要があります」という文は正しいですが、負荷の高いアプリケーションでは、システムのボトルネックになりやすくなります。 ロガーでの競合、不十分なハードドライブ速度、1時間あたりのギガバイトのログ-これらはすべて厳しい現実です。 したがって、ロギング用のデータを非常に慎重に選択し、電力トレースを覚えておく必要があります。これらは多くのスペースを占有し、多数のエラーが発生するとアプリケーションが配置される可能性があります。 多くの場合、ログをディスクにまったく書き込む必要はありませんが、ネットワークを介して専用のシステムに送信します（ネットワークもゴムではないことに注意してください）。
リソース不足の動作
アプリケーションが噛むことができるよりも多くのリクエストを受信した場合はどうなりますか？ ベースが突然半分の速さで反応し始めたら？ ネットワークの損失が始まったら？ 優れたアプリケーションは、固執するべきではなく、「明日」と言ってください。 道徳-外部システムとのすべての対話にはタイムアウトが必要であり、アプリケーションは同時に処理されるリクエストの数を制限する必要があり、クライアントはアプリケーションがビジーまたは応答しない場合の対処方法を知っている必要があります。
通常の監視を行う
別の複雑で広範なトピックですが、簡単に言えば、アプリケーションが車を切ると、メモリ消費量、スワップ、ディスク、CPU、スレッド、システム記述子のグラフがあるはずです。
そして、常に負荷の下でアプリケーションをテストします
アプリケーションは、高負荷下で簡単に停止し、低負荷下で適切に動作します。 1秒間に1回のリクエストで数週間動作した場合、無視できるメモリまたはリソースリーク、ネットワークの輻輳、ディスクの過負荷またはオーバーフロー、およびその他の1001の理由により、1000で死ぬ可能性があります。 そのため、製品にリリースする前に、常に全負荷でビルドを実行してください。
それだけです コメント、修正、あなたの経験を共有してください。