URL アドレスをよりわかりやすくするために (もちろん他の理由がある可能性があります)、多くのサイトではhttp://www.cnblogs.com/lifeなどの URL 書き換えを使用します。このような URL 書き換えは通常、asp.net で処理されます。 *.* を IIS の aspnet_isapi.dll (C:WINDOWSMicrosoft.NETFrameworkv1.1.432aspnet_isapi.dll) にマッピングし、web.config で対応する構成を作成し、最後に対応する処理プログラムを記述する必要があります。 , ほとんどの場合そのようにしていますが、ボケパークでも同じようにしており、問題はないようです。
しかし、Boke Park には長い間パフォーマンスの問題があり、ガーデンの多くの友人もパフォーマンスを向上させるためのさまざまな方法を考え、素晴らしい結果を達成しましたが、私もまだ理想的なものではないため、貢献したいと考えています。私はBoKe Parkがとても好きで、基本的に朝、昼、晩に上記の記事を読んでいます。昨夜、技術グループの友人からURLについて質問されました。 BoKe Park ということに突然気づいた書き換え パフォーマンスの問題は、URL の書き換えが原因である可能性が高いです。
私の友人の質問は次のとおりです。
http://www.wodecity.com/foodとhttp://www.wodecity.com/food.html (このリンクは現在無効です) はどちらも、 URL の書き換えによって同じページ http://www.wodecity を見つけます。 /page/food.aspx 、どちらも同じ処理プログラムを使用します。唯一の違いは、 http://www.wodecity.com/foodなどの拡張子のないアドレスを処理するには、 *.* を aspnet_isapi dll にマップする必要があることです。 http://www.wodecity.com/food.htmlは *.html を aspnet_isapi.dll にマップします。 http://www.wodecity.com/food.htmlのパフォーマンスはhttp:/よりも優れていることがわかりました。 / www.wodecity.com/food の方が 10 倍から 20 倍も優れています。彼はその結果について非常に落ち込んでいました。私も最初は驚きました。*.* と *.html の違いは何ですか? *.* は、CSS ファイルやすべての画像ファイルを含む、ページに対するすべてのリクエストが、彼が作成した URL 書き換えハンドラーによって処理されることを意味します。 、*.html は存在しません。ここで問題が発生します。ページhttp://www.wodecity.com/foodには、URL を使用する必要があります。ハンドラーを同時に書き換えると、大量の画像を処理すると遅くなりませんか?何をするか？彼らはhttp://www.wodecity.com/foodのような、より親しみやすい URL を使用したいので、やはり *.* を使用する必要があるため、しばらく考えた後、URL 書き換えプログラムに任せるように言いました。それらの画像ファイルを処理しないでください。方法は 2 つあります。 方法 1: 画像が保存されているフォルダーを仮想ディレクトリに変換し、仮想ディレクトリ *.* のマッピングを移動して、URL 書き換えプログラムが画像ファイルを処理しないようにします。 URL 書き換えプログラムを必要としない他のファイルの保存は、画像フォルダーと同様に扱う必要があります。方法 2 は、 http://img.wodecity.com/ を使用して画像ファイルを保存することです。はい、これはすべて、URL 書き換えハンドラーがそれらの画像ファイルを処理しないことを意味します。
すべて問題ありませんでした。彼は今朝テストするために会社に行くと言いました。
私の考えを検証するために、今日プログラムを書いてテストしました。結果も 20 倍近く違っていました。私の考えは正しいです。
私の考えやテスト結果が間違っているかもしれませんが、ここでは PK を歓迎します。 msn:cxbsky#hotmail.com。
また、Blog Park の問題は私の友人のサイトの問題とよく似ている可能性があるため、この記事が Blog Park のパフォーマンスの問題に役立つことを願っています。
ps：この記事を書き終えて友人にテスト結果を聞いてみたところ、「元々は50人までしか対応できなかったのに、今は700人以上でも問題ない」とのこと。
http://www.cnblogs.com/csky/archive/2006/08/09/urlrewrite.html