Blogの最近のブログ記事

結構高速化されたと思うので、ときどき遅かった原因を推察。

実は、カウンタ生成用にSQL Server(Express)にログ吐いてるんだけど、そのmdbへのアクセスが問題だった(らしい)ことが分かった。

ファイルアクセスが原因であれば、ときどき遅くなるのも納得できる。
＃ウィルスチェックとか、他のファイルアクセスとか。

mdf, ldfをRAMディスクに移してから極端に遅い現象は解消された。
高速化と別ドライブ化の2つが効いていると考えられる。

コンテンツも含め、ディスクアクセスの高速化はWEBサイトにも必要ってことが分かったのは収穫。
一般にWEBサーバ自体それほど大容量ディスクを必要とするものは無いので、SSDを利用するのも一つの手段として十分にアリだと思う。
DBファイルも数GB程度であれば、SSDを利用するのが処理の最適化よりもパフォーマンス向上が望めるのではないかと、今回の件で思う次第。
＃今回はRAMディスクだったんだけど。

ぬか喜びってわけじゃないけど、どうにも遅い場合ってのはあるらしい。

キャッシュにヒットしなかったり、他の処理でディスクアクセスがあった場合などがそれに該当すると考えている、というか感じがする。

で、結論から言うと、ブログコンテンツすべてRAMディスクに移動しました。

またぬか喜びかも知れないけれど。

IISの出力キャッシュを構成してみた。

• 出力コンテンツの最大サイズを2MBに拡大
• ブログサイトに対して、.htmlをカーネルモードキャッシュのみに限定

手元の感覚では、若干軽くなった気がするんだけど・・・

PageButeなる有名なプラグインがあることを知る。

で、導入してみた。

若干高速化できているっぽい。

最悪条件7秒だった場合においても、約半分程度になったと思う。

なるほど、インデックスはこういうときに効果を発揮するものだったわけだ。

IISが遅くてたまらん人は、とりあえず、inetpub下のインデックス化をしてみると良いってことだな。

さて、遅さも何とかなったようなので、もう一つ処理を入れるとしますか。

遅いのには理由があるはず。
CPUスピードが関連しているのならば、CPU負荷の高い状態ってのが発生するはずだと、思うに至る。

遅いときと、そうでないときがあるらしい。

昨日の覚書きの。

FROM句一発で複数集計やろうと弄ってみたものの面倒くさすぎるので、2つのSELECT文による集計結果をそれぞれ文字列化して区切り文字を挟んで1つのSELECT文のできあがり。

効率悪いかも知れんけど、接続とSELECTを複数回発行するよりはマシだろう。
インデックス(に限らず)ページのレスポンス向上したかな？

思いついたのでメモ。

DBアクセス回数を減らせば高速化できるはず。

インデックスページの表示を少しだけ高速化するよう、IISフィルタ処理を一部省略してみたので、多分、少しだけ高速化できてると思う。

インデックスページは内部折り返し(リダイレクトを内部で処理してるっぽい)のため、フィルタを2回通過してた。

これを1回に抑えることで、理論的には50%、処理時間を削減できたはず。
＃実際には50%にはならないと思うけど。

CPU負荷とかDBアクセスも減るので、他のページアクセスにも良い影響があるはずだと思いたいが、いかがなものか。