ARecX6のファームアップするたびに再起動失敗するのはマジやめてほしい。
今日もアップデート(2.14)したらhttp無応答に。
仕方なく背面スイッチでOff/On。
せっかく外部からのアクセスを可能にしてるのに・・・
ARecX6のファームアップするたびに再起動失敗するのはマジやめてほしい。
今日もアップデート(2.14)したらhttp無応答に。
仕方なく背面スイッチでOff/On。
せっかく外部からのアクセスを可能にしてるのに・・・
よくあるパターン。
Excelアドインのセキュリティ問題は大体解決(残すはxll本体をどうするか<でかい!)したんで、まぁいい。
で、通知アイコンを実装しようと思ったら、C/C++(非MFC)の場合、今まで適当に済ませてきたことが一気に襲ってくるわけ。
バックアップ後に起動したら、RAMディスクの内容消えてる・・・
焦った焦りまくった。
どういうことかは分からないけど、定期的にバックアップとった方がいいってことらしい。
コンテンツのほとんどは生成可能物だったので再構築すればいいんだけど、写真などのファイル類は再構築できないものらしいから、気をつけなきゃならん。
T61以外でも使えると思うけど。
あとは指示に従い再起動すれば、ServerCoreでも解像度向上。
超素晴らしい。
面倒というか、なんというか。
でも逆に、どこかに書いておかないと忘れる。
"誰か"が自動的に書いてくれると、「あぁ、バックアップしなきゃ」と思うので、便利。
というわけで、今回もコンテンツ書き換えで実装。
ある程度メンテ日近くになると、毎月第一日曜日の22:00~をページ上部に埋め込む。
忘れにくくするとともに、自動通知なので助かる。
・・・バックアップはHDD丸ごとコピーなので、相変わらず手動ですが・・・
結構高速化されたと思うので、ときどき遅かった原因を推察。
実は、カウンタ生成用にSQL Server(Express)にログ吐いてるんだけど、そのmdbへのアクセスが問題だった(らしい)ことが分かった。
ファイルアクセスが原因であれば、ときどき遅くなるのも納得できる。
#ウィルスチェックとか、他のファイルアクセスとか。
mdf, ldfをRAMディスクに移してから極端に遅い現象は解消された。
高速化と別ドライブ化の2つが効いていると考えられる。
コンテンツも含め、ディスクアクセスの高速化はWEBサイトにも必要ってことが分かったのは収穫。
一般にWEBサーバ自体それほど大容量ディスクを必要とするものは無いので、SSDを利用するのも一つの手段として十分にアリだと思う。
DBファイルも数GB程度であれば、SSDを利用するのが処理の最適化よりもパフォーマンス向上が望めるのではないかと、今回の件で思う次第。
#今回はRAMディスクだったんだけど。
parallel_forなんてものを知る。
すげぇじゃん、これ!
って思って、Addin for Excelの利用者定義定数関数の登録に使ってるfor文をparallel_forに変えてみた。
8192関数の登録時間を短縮してやろうという腹積もりですよ。
ぬか喜びってわけじゃないけど、どうにも遅い場合ってのはあるらしい。
キャッシュにヒットしなかったり、他の処理でディスクアクセスがあった場合などがそれに該当すると考えている、というか感じがする。
で、結論から言うと、ブログコンテンツすべてRAMディスクに移動しました。
またぬか喜びかも知れないけれど。
IISの出力キャッシュを構成してみた。
手元の感覚では、若干軽くなった気がするんだけど・・・
最近のコメント