いつきコンテンツ

ヘルプ

カウンター


2011-07-02 よっしゃ、3連休~

月曜火曜休みにシフトしたのです~

[日記] angelbeatsのタグ検索で18,706件@pixiv

件数表示あり&1日で28件増え。どんだけ増えた!? つか、元の値に戻った……。

実際には35件位増え。直井の日らしく、直井絵が超増殖した。

[ネタ][メモ] 【速報】『エヴァンゲリオン新劇場版:破』金曜ロードショーで放送決定!【8月26日】

マジか!

……しかし、8/26は普通に水曜日扱いなので(笑)見れなさげ。

まぁBD持ってるからいいか……。

いや、破の前に序を地上波放送してくれよ

そういえば、すっ飛ばしたね……。

[ネタ] 夏の新アニメ『ロウきゅーぶ!』安心安定のポル産ロリアニメだったね!

まだスコポン部分は出てきてないのか。

流れるラインがロリなのは原作通りなのでw

てか、どんな話し方するのか気になるぅぅぅーーーーー ← 原作は1巻発売当時から買い続けてる

[ネタ] 7月2日は『けいおん!』「琴吹 紬ちゃん」の誕生日!!

おめでとうございます。

相変わらず購買部は誕生日仕様か。

[日記] サーバーのBIOS上げたら毎日特定時間にbootする設定が出てきた

教えてくれたさくらの人、サンクス!

で、ついでなのでいつも「温度が高い」と文句を言われるCPU温度を測定してみた。CoreTemp使用。

負荷かけるツールはPRIME95を利用。

ちなみに、CPUはXeon 3060です。

……負荷かける前から77度とかあるんですがw

負荷かけたら、86度まで上昇。てか、CPUが熱すぎて2.4GHz標準のはずなのに1.5GHzまでクロックが下がっている……

ファンは回ってるので、原因はグリスっぽいなぁ。そういえばグリス塗った記憶がない(笑)


ついでなので、メインPCの温度も測定。

負荷無し状態で60度ぐらい。負荷かけると100度ぐらいまで上がる……が、定格クロック(2.8GHz/x21)より高い、2.93GHz(x22)で動作中……。100度に上がってしばらくすると、2.87GHz(x21.5)にクロックが落ちて、100度よりは温度が上がらなくなる。

負荷を止めた瞬間に75度まで温度が下がり、10分もすると60度程度に落ち着く。

純正ファンなのでちょっと放熱不足気味ではあるけど、こっちはそこまで問題になるレベルではないかな。てか、4CPU8スレッド、全部100%になったのって初めてだw

x264vfwで8スレッド利用にしても50%超えたこと無いのよ……。

[日記] Firefox/SeaMonkeyでの同時アクセス数について最適化してみた。テスト中~。

最近どうも同時アクセス数が多いとコネクションを拒否ってくるサーバーが増えてきた(まぁある意味当然の対応)ようなので、色々見直してみた。あと、1サイトからのみデータを読むのではなく、色んなサイトからJavaScriptやらcssやら画像やらをロードしてくるページが多いのも見直しポイント。

about:configと入力して、フィルタにnetwork.httpと設定。

network.http.max-connectionsは、ブラウザが使える最大のコネクション数なので、かなり大きくしてもOK。1つのwebページに対して色んなサーバーからデータを読み込むとかよくあるパターンなので、増やしまくると良い。でもまぁ常識的な範囲で。SeaMonkeyの場合、デフォルトは30だが、多分少ない。思い切って200を設定。

network.http.max-connections-per-serverは、サーバーに対して張るコネクション数の最大値。上記の通り、同時に同じIPからアクセス来るとコネクションを切ってしまうサーバーが増えてきたので、減らす方向で。SeaMonkeyのデフォルトは15だが、こんなにコネクション張るとイジメなので、かなり小さく。とりあえず6に設定。ただし、network.http.keep-aliveはtrueにしておくこと。これで1サーバに対しては6コネクションしか張らないが、同じコネクションを使い回して色んなファイルを要求できるようになる。keep-aliveをfalseにすると、多分爆オソになる。

network.http.max-persistent-connections-per-proxyは、1proxyに対して張るコネクション数の最大値。proxy使ってないなら放置でOK。

network.http.max-persistent-connections-per-serverは1サーバー毎の持続的接続数の上限。多分keep-aliveの数だと思われる。デフォルトは6だったが、そんなに使わないので2に設定。根拠は特にない。

network.http.keep-alive.timeoutはkeep-aliveのタイムアウト時間だが、デフォルトの300(5分)は、長すぎる。まぁmax-connectionsを猛烈に引き上げたのであんまり影響は無いのだが、色んなサイトを開くとmax-connectionsに到達してしまう可能性が上がる。ぶっちゃけ60(1分)程度で十分なので、60を設定。そのサイト内を見る時に、1分以内なら再コネクションが必要なくなるが、普通はさくっと移動するか、じっくり読むかで、5分は中途半端すぎると思う。あんまり短くしすぎると、今度はkeep-aliveでデータを連続取得するのにも問題がでるので、小さくしすぎないこと。


こんな感じに設定を変更してみた。

書いてて気づいたのだが、デフォルト値だと、network.http.max-connections=30でnetwork.http.max-connections-per-server=15なので、最悪ケースでは2サーバーにしか同時にアクセスできない状態になるのね。で、network.http.max-persistent-connections-per-server=6、network.http.keep-alive.timeout=300なので、6コネクションは5分間無駄に残る、と。単純計算で、5サーバーに6コネクション張りっぱなしになる状態が続くと……。さすがに足りなくなったらcloseしてるんでしょうが、超無駄っぽい。


ちなみに。この設定をしたら、体感的に早くなった。

iGoogleとか、あちこちからデータを拾ってくるようなページだとかなり早い。あとアマゾンの画像があったり広告がいっぱいあったりするページとかが早くなった。

あと、同時アクセス数制限かけてるページもまぁそれなりには見れるようになった。

本当はnetwork.http.max-connections-per-serverを2とか4とかにしたいんだけど、そこまで減らすとpixiv見るのに影響が出てしまったので、6で。


あと、これはウチの環境が悪いのかSeaMonkeyが悪いのかは分からないけど、DNSプリフェッチがかかってると、大量にリンクあるページを開いた後、別ページを開いたあと、DNSの反応が極端に悪くなりまする……(○○のホスト名を解決しています、的なメッセージで固まる)

そういう現象に悩まされてる人は、network.dns.disablePrefetchを作ってtrueに設定すると良いよ。


てか、DNSプリフェッチはともかくとして、それ以外の設定かましてみたが、ニコ動とか半端無く早くなるな。

そしてサーバー側にも優しい仕様。

昔の高速化手法である、サーバーへの同時アクセス数をむやみに増やす方式より、色々な値を適切にする方がよさげ。

[ネタ] 花咲くいろは 第13話 四十万の女 ~傷心MIX~ ‐ ニコニコ動画(原宿)来ました

最近、MXの電波悪すぎなので、ニコ動に切り替えるかもしれん。

[情報] 姫路第2火力5号機の運転停止=磁界発生装置に故障、供給綱渡りに-関電

関西電力、ピンチ。

つか、東電範囲内でも余力が数%しか無い時に火力発電所落ちたら、大停電起きる可能性あるな……。

[ネタ] 報酬3割カット条例で月額65万円になった大阪府議会幹部らが「生活が苦しい」「普通の暮らしをさせろ」と訴える

選挙費用がかかるのはわかるけど

「事務所が駅前の一等地にあり、賃料がしんどい」

これは、まったく理由になってないからね!?

[日記] 今日もアニメは無理……。

どう考えても無理

[日記] 今日の作業曲は、「マミさんの戦闘テーマ」を歌ってみた【小松菜】 ‐ ニコニコ動画(原宿)でした

公式歌詞バージョンが出たけど……

そのバージョンはまだかなぁ(笑)

Last Update: 2011-07-03 10:33:18

カレンダー

2003|04|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|07|08|11|
2013|03|05|08|
2014|01|
2015|04|05|06|07|09|10|12|
2016|01|03|05|06|10|11|
2017|06|
2018|05|08|09|10|11|
2019|04|08|12|
2020|03|08|09|11|
2021|05|
2022|04|
2023|12|
Generated by tDiary version 4.1.2 + amazon(DB Patch 0.2.1) + counter(DB Patch 0.2) + IKPatch version beta 4.0.1.
Powered by Ruby version 2.1.5-p273 with ruby-fcgi