5

私は米国の主要大学のウェブマスターです。私が作成し、過去7年ほど担当してきたウェブサイトには、たくさんのリクエストがあります。私はこれまで以上に複雑な機能をWebサイトに組み込んでいますが、ストアドプロシージャ、ビューなどを使用して、マルチプロセッサMicrosoftSQLサーバーにプログラミングの負担をできるだけ多くかけることが常に私の習慣です。 IIS WebサーバーのPHP、ASP、またはPerlでは実行できないこと。どちらのサーバーも非常に強力で有能なマシンです。私はこれを長い間一人で行っており、誰もブレインストーミングを行うことはありません。私のアプローチが、将来のさらに高い負荷の状況に理想的であるかどうかを知りたいと思います。

私の質問は次のとおりです。ネストされたSELECTステートメント、ビュー、ストアドプロシージャ、および集計関数を使用してSQLサーバーに負荷をかける方がよいのでしょうか、それともサーバー側のコンパイルを使用して複数の単純なクエリを取得して処理する必要があるのでしょうか。 PHPのようなタイムスクリプト？続けますか、それともより良い方法を考え出しますか？

最近、いくつかの負荷トレースを実行し、SQLサーバーの肩にどれだけの負担をかけているかを学んだ後、パフォーマンスに関心を持つようになりました。WebサーバーとSQLサーバーはどちらも、1日を通して高速で応答性が高く、どれだけの量を使用するかはほとんど関係ありませんが、準備を整えて自分自身をトレーニングし、既存のコードに最適化されたベストプラクティスをアップグレードしたいと考えています。それが重要になる時。

あなたのアドバイスと入力をありがとう。

4

4 に答える 4

9

各レイヤーをスタックに配置して、最適なドメインで使用します。

WHERE句またはGROUP句で十分な場合は、データベースサーバーに1000行を送信させ、PHPを使用してそれらをフィルタリングしても意味がありません。データベースを呼び出して2つの整数を追加することは最適ではありません（SELECT 5+9正常に機能しますが、phpがそれ自体を実行できるため、ラウンドトリップを保存できます）。

おそらくスケーラビリティを調べたいと思うでしょう。アプリケーションのどの部分を複数のプロセスに分割できるのでしょうか。まだ2つのレイヤー（スクリプトとデータベース）を使用している場合は、そこにスケーリングする余地がたくさんあります。ただし、常に最初にボトルネックから始めてください。

いくつかの例：CDNで静的コンテンツをホストし、ページにキャッシュを使用し、nginxとmemcachedについて読み、nosql（mongoDB）を使用し、シャーディングを検討し、レプリケーションを検討します。

于 2011-03-05T13:58:54.403 に答える
4

私の意見では、一般的に（ほとんど）Webサーバーに処理を任せるのが最善だと思います。2つのポイント：

1つはスケーラビリティです。アプリケーションが十分に使用されるようになったら、負荷分散について心配し始める必要があります。また、分散データベースクラスターをセットアップするよりも、共通データベースを指す2つの追加のWebサーバーをドロップする方がはるかに簡単です。したがって、データベースからできるだけ多くの負担を取り除き、データベースを1台のマシンにできるだけ長く保持するのが最善です。

2つ目のポイントは、クエリの最適化です。これは、使用しているクエリとデータベースバックエンドに大きく依存します。私が最初にデータベースを使い始めたとき、4つまたは5つの異なるテーブルからのものであっても、必要なデータを正確にフェッチする複数のJOINを使用して複雑なSQLクエリを作成するという罠に陥りました。私は、「それがデータベースの目的です。データベースに大変な作業をさせましょう」と考えました。

私はすぐに、これらのクエリの実行に時間がかかりすぎて、他のリクエストからデータベースをブロックしてしまうことがよくあることに気付きました。クエリを複数のリクエストに分割するのは非効率的かもしれませんが（たとえば、forループで）、高速インデックスを使用して複数の小さなクエリを実行すると、すべてのハードワークを渡そうとするよりもはるかにスムーズにアプリケーションを実行できることがよくあります。データベースへ

于 2011-03-05T14:13:00.063 に答える
0

まず、クライアント側のキャッシュ（.js、.css、静的HTML、画像）、および画面の部分的な更新を行うためのAJAXなどのテクノロジーの使用によって完全に取り除くことができる負荷があるかどうかを確認する必要があります-これはWebサーバーとSQLサーバーの両方の負荷を取り除きます。

次に、Webサーバーのキャッシュによって削減できるSQLの負荷があるかどうかを確認します（静的データや低更新データなど）。システムに「コンテンツ」ページが多数ある場合は、次のように拡張できる一般的なCMSキャッシュ手法を確認してください。ページを再構築したりデータベースにアクセスしたりせずに、より多くのユーザーが同じデータを表示できるようにします。

于 2011-03-05T14:28:36.290 に答える
0

私はdbの外で可能な限り多くのことをする傾向があり、dbの呼び出しを高価で時間のかかるものと見なしています。

たとえば、フィールドname_givenとname_familyを持つユーザーテーブルでselectを実行すると、クエリを拡張して、連結によって作成されたfull_nameという列を返すことができます。しかし、そのようなことは、サーバー側のスクリプト言語（PHP、Rubyなど）のモデルで簡単に実行できます。

もちろん、dbが操作を実行するためのより「自然な」場所である場合があります。しかし、一般的に、私はWebサーバーに負荷をかけ、他の回答に記載されている多くの手法を使用してそこで最適化することに傾倒しています。

于 2011-03-05T14:35:48.797 に答える