0

URL に .css、.gif などの拡張子があるかどうかを確認するために、Application Server が受信したすべての Web 要求を探す必要があります。

tomcat がすべてのリクエストをリッスンする方法を参照し、適切に構成されたサーブレットを選択してサービスを提供します。 CharChunk 、MessageBytes、 Mapper

実装する私のアイデアは次のとおりです。

  • 比較したいすべての拡張子をロードし、それらのバイト表現を取得します。
  • バイト配列内のバイトを合計して、この xtension の一意の値を取得 // 例: "css".getBytes()
  • 結果値をソート済みリストに追加します
  • リクエストを受け取るたびに、URL のバイト表現を取得します // 例: "flipkart.com/eshopping/images/theme.css".getBytes()
  • バイト配列の最後のインデックスからバイトの合計を開始し、"." に遭遇したときに中断します。ドットバイト値
  • このように並べ替えられたリストで合計された値の存在を検索します // ここで二分検索を使用します

実装や問題があればフィードバックをお寄せください。

-ありがとう、クリシュナ

4

1 に答える 1

3

これは、必要以上に複雑に聞こえます。

  • String.lastIndeXOfURL の最後のドットを見つけるために使用します
  • String.substringそれに基づいて拡張子を取得するために使用します
  • HashSet<String>サポートされている一連の拡張機能用の を用意するか、拡張機能を別のものにマップする場合は を用意HashMap<String, Whatever>します

この単純なアプローチがパフォーマンスのボトルネックであることが判明したことを発見すると、私は絶対にショックを受けます-実際、URL全体をバイトに変換する必要がないことを考えると、提案したアプローチよりも効率的であると思います配列...（値からハッシュを形成する代わりに、アプローチがとにかくバイト配列を使用する理由は明らかではありませんchar。）

基本的に、パフォーマンスに対する私の好ましいアプローチは次のとおりです。

  • アーキテクチャ上、後で変更するのが難しいものについて、事前に設計とテストを行う
  • 他のすべての場合：
    • 最初にパフォーマンス基準を決定して、いつ停止できるかを判断します
    • 動作する最も単純なコードを書く
    • 現実的なデータでテストする
    • パフォーマンスが十分でない場合は、プロファイラー (など) を使用してボトルネックがどこにあるかを調べ、それを最適化して、既存のテストを使用して利点を証明できるようにします。
于 2013-03-11T10:46:38.660 に答える