5

私はパフォーマンスとスケーラビリティを理解するために頭を悩ませようとしており、開発者/システム管理者がシステムを強化するために何をしているのか知りたい. 回答を標準化するために、次のいずれかに最善を尽くして回答していただけると助かります。

  1. プロフィール- Joomla での雑誌掲載。CodeIgniter + OpenId + AJAX の求人掲示板
    • パフォーマンス-サーバーごとの 1 秒あたりの最大要求数は?
    • ハードウェア- サーバー、ルーター、ディスク、LAN?
    • ソフトウェア- Lighttpd、Memcache、Varnish、Nginx、Squid、Pound、LVS、eAccelerator など。
    • サービス- Amazon S3、Akamai、Google コンピューティングなど。
    • 構成- 静的ハッシュ、アップストリーム モジュール、n リクエスト後の x 分間の Memcache、ログ イメージ リクエストの無効化など。
    • その他- 他に何かありますか? (たとえば、正規化されたテーブルは、読み取りが多いサイトには適していません)

編集: Web 開発者がこのようなものを探すことが重要であるため、この質問を 閉じる前に再検討してください。プログラマーは自分のコードからセミコロンを微調整することができますが、memcached 用に記述したり、 Google App Engine を介してCDNをまとめたりする悪いコーダーに負けてしまいます。

4

3 に答える 3

3

私たちのシステム: 多くを語ることはできませんが、多くの有料顧客にサービスを提供する大規模な SaaS アプリケーションです。

私たちが行うすべてのパフォーマンス/キャパシティの作業は、非常に慎重に行われます。機能するかどうかを試すだけではありません。

とにかく作業を続けることができるかどうか、最初に現在のパフォーマンスとキャパシティの分析が行われます。

可能であれば、コードをプロファイリングして実験的な変更を加えることができる非運用システムでパフォーマンスの問題を再現します。常に本番環境とまったく同じハードウェアを使用できるとは限りません (本番環境には非常にハイスペックなサーバーが多数ありますが、開発環境には本番仕様の専用パフォーマンス テスト ボックスが数台しかありません)。

問題を非実稼働環境で意味のある分析ができない場合は、実稼働環境のコードにいくつかのインストルメンテーションを出荷します (インストルメンテーションがシステム自体に影響を与えないことを確認するための慎重なテストの後)。この計測器は「オフ」で出荷され、十分なデータを収集するために選択的にオンにされます。

問題の正確な分析が得られたら、可能な解決策を検討し、場合によってはプロトタイプを開発します。これらは機能の正確性をテストできます。

複数のオプションがある場合、通常は最もリスクの低いオプションを選択します。

その後、通常のリリース プロセスに従います - 多くのテスト、コード レビューなど。

関連する場合、変更には、問題が発生した場合に本番環境ですぐにオフにできる「元に戻すスイッチ」が付属している可能性があります。

私たちが特定した潜在的なパフォーマンスの改善点は多数ありますが、そのほとんどは、問題が発生するまでそれ以上開発することはありません (いずれにせよ、そのソフトウェアの関連のないリファクタリングを行っている場合を除きます)。

于 2009-01-11T13:18:18.370 に答える
3

パフォーマンスを最適化するための具体的なマスタープランはありません (最初にソフトウェア「xyz」から開始するなど)。

一般的方法：

  1. 改善/投資した時間によって、最も改善可能なエンティティを特定 (測定!)
  2. 最適化する
  3. 繰り返す
于 2009-01-12T14:14:01.080 に答える
2

あなたの質問に箇条書きで答える時間はありません。=) しかし、差し迫った必要がない場合は、懸念事項を分離し、サーバー リソースを結合しないという一般的な戦略をお勧めします。mod_proxy (および同等のもの) はあなたの友達です。これにより、パフォーマンスの問題が発生したときにハードウェアを簡単に投げることができます。もちろん、システムを最初から完全に因数分解する必要はありません (実際のボトルネックがどこに現れるかを予測するのは非常に難しいため)。しかし、問題が発生した場合。あなたの友人を思い出してください。

于 2009-01-11T11:05:34.813 に答える