ASKS変換のクローラーをさらに高速化してみた。

今まで1スレ当たり最大4回実行していたSQL文を見直して
1スレ当たり2回までに抑えるようにした。

この結果、50秒/35スレから35秒/35スレまで高速化できた。

SQLは、更新に掛かる時間がもの凄く多いことが解りました。
これからは、出来るだけフラグをぽこぽこ立てておいて、それを解釈するようにしよう。

今日を入れてあと3日とな！？

ASKS変換のクローラーをgzip対応にして、通信を高速化してみた。
gzencodeはココから調達、、、

gzdecode Function in PHP
http://www.tellinya.com/read/2007/08/28/83.html

ものによっては、半分から4分の3ぐらいまで速くなった。
もっと前から導入すれば良かったなぁ。

今年は、GTFPを買ってから色々とゲームやグラボを買って
PCのグラフィック面がパワーアップしたり

本格的？な過去ログ倉庫の作成をしたりと
自分の作りたいものが作れるようになってきた気がする一年でした。

来年はちと忙しくなりそう。

CPUのパフォーマンスがえらく下がった　ってのは書いたような気がするけど
CPU電圧を下げたらちょっとパフォーマンスが改善されました。

時は先週にさかのぼって、ソフマップでPentium4 3.2EGHzの詳細を見たら
電圧の部分が1.400Vだったんですね。

で、家に帰ってマザボの電圧を見てみると1.450Vになっていて、
何故か、メモリの電圧もDDR PC3200の定格ではない2.7Vになってまして、
それらをそれぞれ定格に設定したら、ちょっとパフォーマンスがあがったというか、安定しました。

アウターで60ちょい、ドライバー視点で30ちょっとぐらい

基本、ドライブ単位のデフラグにはJkDefragを使っているのだけれども、
どうやら、このソフトのGUI版があった模様。

GUI版を使うことで細かいオプションとかが簡単に設定できたり、
スケジューリング出来たりして、意外と便利かも

ちなみに、フォルダ、ファイル単位でのデフラグは、Power Defragmenter GUIが便利です。

JkDefrag GUI
http://www.emro.nl/freeware/

90631スレの圧縮作業が終了しました。
といっても、30秒の時間制限に引っかかるスクリプトをリロードして、何回も実行しただけですが。

結果から言うと、8,177,208KBまで減りました。
つまり約8GB、ほぼ半分です。

容量の少ないスレッドが多かったため、目標の4GBは無理でしたが
これで、あと半年は戦えるのではないかとおもいます。

それと、今回圧縮を掛けたことで、全ての過去ログの保存位置が統一され、
今後、作業をするときにも便利になりました。

readc.cgiで読まれたスレッドのステータス表示は以下のようになっています。

・自宅サーバーからgzで圧縮されたスレッドを読み込んだとき
　tanabota.gz
・XREAにキャッシュされているdatから読み込んだとき
　tanabota.tmp
・自宅サーバーからdatを読み込んだとき(今後はもうないはず)
　tanabota.info

#　何かおかしいと思ったら、停電でIPが変わっていた模様。
#　Google仕事してるな。

試しにex23.2ch.net以下のdatファイルを全部gz化してみました。
んで、dfした結果、以下のように。

16,980,600KB→16,602,624KB
4407ファイルを圧縮しただけでおよそ380MB減りました。

これはちょっと期待できるかも。

さらにnews23.2ch.net以下のdatファイルを全部gz化してみました。
ココだけで14555ファイルもあったりします。

dfしてみると・・・
16,603,188KB→15,581,924KB
1GBも一気に減った。すげー。

次は、wwwww.2ch.netです。
ココも10000ファイルぐらいあります。

15,581,924KB→14,641,032KB
これまた、1GB近く減りました。やべー。

現在、非圧縮で扱っている過去ログ倉庫のdatを
gzで圧縮して、転送量と使用容量を減らそう　という計画

参考値
使用前：112203byteのdatファイル
使用後：39675byteのgzファイル(w5)

対応
・現状のスクリプトに関数を組み込む

利用方法
1)readc.cgiで読まれ、XREA側にファイルがあった場合にgz化を進めていく
　自宅サーバーに転送後、自宅サーバー側で圧縮前のdatがあるか確認する必要がある。

2)readc.cgiで読まれ、自宅サーバーから転送する際に圧縮していく
　CPUに掛かる負荷が不明
　自宅サーバーから読み出すスクリプトを対応させれば良いだけなので対応は容易

3)1と2の両方を実行する
　組み込みが面倒になるかも

4)新規取得時に圧縮

現状
現在のdatファイル数は9万(11.9GB)
一日で増える容量は約150MB

参考値から計算すると、約3分の1となるため、
一日で増える容量は約50MB、総容量は約4GBとなる。

#　追記
早速、2と幻の4を適用してみた。
良い感じにgz化され始めた。

なんとか動いてるPentium4 3.2EGHzで値段が微妙に高いDDR PC3200を使ったPCも
そろそろサブ機に降格させて、Q6600を使って組めたら～なんて思ってます。

現状では、GTR2とかをやるとCPUがギリギリで
でもAGPとメモリはまだまだ行けるみたいな感じ。

というか、GTR2自体、昔はニュルニュルできたゲームなのに
CPUが怪しくなってからカクカクするようになったわけですから、、、

Q6600を付けるとなると、必然的にLGA775のM/Bが必要になり、
尚かつ、GFA76GS-Z/256D3を使うとなると、4CoreDual-SATA2とかが気になってきます。

PCI Express が4レーンだけど、しばらくGFA76（以下略）を使うとして
新しいM/B買うまでのつなぎとして考えれば…。

まぁ、まだ買うか決めてないんですけどね。
9月にHDD買うって言って、完全に忘れてたぐらいですから。

何となくawstatsのログを見てみたらこんな感じでした。

11日はサーバー復活させた日なので、少ない。
拡張子別だと、zipが4.6GBでトップ、次いでjpgが251MB

これの他にorzとか、このブログとかを回してるので、
実際は2GB/dayぐらいなのかな？

dat倉庫用に割いてるパーティションそろそろやばいな、、、

前回、リバースプロキシを使うときは、mod_rpafを使って対策すると良い
というのを書いたんだけど、.htaccessや、httpd.confでアクセス制限をしている場合
ログには元IPで記録さているけれども、アクセス制限にはリーバスプロキシのIPで
規制されていることが解りました。

んで、どうも「mod_extract_forwarded」というのを使うと
そのリバースプロキシのIPで制限されてしまう件が大丈夫らしいということで、
今から試してみる次第です。

というわけで、「mod_extract_forwarded」を試してみたところバッチリOKでした。
これで、ようやくリバースプロキシを使用できる段階になりました。

なんでまた、リバースプロキシを導入しようとしているのかというと、
Sim-Boardに置いてあるファイルってのは、海外からアクセスされる事が非常に多いため、
自然に回線速度が遅い接続が増え、接続時間も比較的長いためにApacheの受付が売り切れになってしまうのです。

そこで、リバースプロキシを入れたらどうかなぁということで、現在調整しているわけです。