2

私は現在、やや大規模な通信プロトコルを扱いやすいものに作り直しています。これは一種の意見のある質問ですが、あなたの経験に基づいて、コードが大きくなるにつれて、これら2つのアイデアのどちらが維持しやすくなります。

クライアントとサーバーがあります。サーバーには、クライアントが必要とする可能性のあるA、B、C、Dなどの情報があります。情報は、名前のような単一のデータセットではなく、名前のリストです。通常、列の内容全体。クライアントは通常、ABC、DEF、ABDなどのグループでこのようなものを必要とします。重複はあまりありません（つまり、通常、Aの要求の80％はBとCの要求でもあります）。

システムが大きくなるにつれて、通信プロトコルが次のように機能するシステムを維持するのが容易になります。

Request 1: Server returns ABC
Request 2: Server returns ABD

また

Request 1: A
Request 2: B
Request 3: C

等

最初のコードを使用する傾向があります。コードが少し読みやすく、操作しやすくなり、ABCなどのグループに特別なリクエストを送信すると、サーバーがデータベースで実行するクエリが少なくなり、必要な情報。しかし、コードベースは現在よりも大幅に大きくなります。クライアントとサーバーの通信方法をすでに見直しているので、ここの人々がどちらかまたは両方の方法で経験したことを聞きたかったのです。 。

編集：私はネットワークトラフィックだけでなく、サーバーがこれらの要求をどのように処理するかなどについても話していることに注意してください。クライアントが3つの個別のリクエストを行う場合、サーバーは3つのDBクエリを作成する必要がありますが、グループ化されたリクエストは1つのクエリとして実行される可能性があります。

4

3 に答える 3

2

これは「時期尚早の最適化」のケースだと思います。

  1. 実際にパフォーマンスの問題が発生するかどうかはわかりません。
  2. あなたが述べているのは、認識されたパフォーマンスの問題に対するより複雑なコードです。
  3. 実際には、2 番目のオプションはパフォーマンスが低下する可能性があります(接続を受け入れて要求を処理するか、少し長い応答を送信するか、どちらが重いかを検討してください)。

これで、ボトルネックやパフォーマンスの問題が、この情報を検索する場所 (データベースなど) に関連している可能性が高くなります。その場合、プロトコルに影響を与えることなく、その側でパフォーマンスを調整できます (たとえば、DB から返された値をキャッシュできます)。

于 2012-04-26T20:35:22.467 に答える
1

(2) の方が簡単ですが、(1) の方がはるかに効率的で、それほど複雑ではありません。私は（1）で行きます。最適な長期戦略を提供します。

考えてみると、リクエスト入力は (2) の T か (1) の T[] のどちらかです。配列を使用するのはそれほど複雑ではありません。

于 2012-04-26T20:33:52.170 に答える
0

パフォーマンスが問題にならない場合は、必要なものをすべて提供し、コードをより小さく、より簡潔に保つ、より単純なプロトコルを維持する必要があります。

パフォーマンスが問題である場合、それはどの程度の問題ですか? 追加された複雑さを正当化するのに十分ですか?

于 2012-04-26T20:33:26.217 に答える