Zopfli - naoyaのはてなダイアリー
Googleが今日（米国時間2/28）、オープンソースの新しい圧縮アルゴリズムZopfliをローンチした。今の標準圧縮技術であるzlibライブラリに比べて5〜8%圧縮率が高いといわれ、また解凍アルゴリズムは今のWebブラウザが現用しているもので間に合うため、Webサーバがこれを採用すれば、データの伝送速度が上がり、Webをやや速くすることができるだろう。 Google が出力が deflate 互換の圧縮アルゴリズムをオープンソースにしたというので、ちょっとタイムラインで話題になっていた。圧縮アルゴリズム周りにはまってた頃から結構時間が経ってしまって色々忘れてしまったけど、少しニュースを捕捉してみようと思う。 Zopfli は deflate 互換なので、deflate アルゴリズムを解釈できる実装なら伸張できる。当然ブラウザが持ってる deflate 実装で伸張できるので、エンドユーザー
RHELでもコネクション単位にTCPの再送タイムアウトを制御したい
前に書いた「TCPの再送タイムアウトを制御したい」の続き。 要は、コネクション単位で再送タイムアウトを調整したい件である。 国内で仕事でLinuxを使っていると、どうしても Redhat にバイアスがかかる事情があって、これはこれでなんとかしたいのだが、それはまた別の話。 それで、2/21(現地時間)にGAがアナウンスされた RedHat 6.4 では、 http://www.redhat.com/about/news/press-archive/2013/2/red-hat-announces-general-availability-of-next-minor-release-of-red-hat-enterprise-linux-6 kernel version は 2.6.32-358 まであがっている。もちろん、以下からソース(SRPM)も入手できる。 http://ftp.re
「逃げる」のススメ - 脱社畜ブログ
ドラクエみたいなRPGをやっていると、戦闘中に「たたかう」とか「じゅもん」とかのコマンドが並んでいる一番下に、「にげる」という選択肢が出てくる。このコマンドは、残念ながら常にうまくいくということはなくて、例えばたまに回りこまれてしまったり、ボス戦だったりすると100%成功しないようになっていたりする。 これはあくまでゲームの話なのだが、僕が今日書きたいと思っているのは現実世界における「にげる」コマンドのことだ。実は、現実の世界にも「にげる」コマンドは存在している。しかし、多くの人がこのコマンドの存在を知らない。そして、現実世界の「にげる」コマンドは、犯罪に手を染めたとか、借金を踏み倒したといった一部の場合を除けば、基本的に回りこまれることなく成功する。 例えば、仕事が辛くて辛くて仕方が無くなったとする。責任の重圧に潰されそうになったり、終わりのない残業・休日出勤のスパイラルに入ってしまい、
TCPの再送タイムアウトを制御したい
TCPの再送タイムアウトで最近まで知らなかったことがあったのでメモ。 たとえば、APサーバとDBサーバがあるとする。 AP-DB間のDBCPで使うTCPコネクションは、DBサーバがノードダウンしたのであればさっさと再送リトライをあきらめて切れてほしいと思うのが普通だろう。 このTCPの再送リトライ処理は、何もいじらないと15分以上続くので、 できればTCPコネクション単位で細かく調整させてほしいと思うのは人情だと思う。 Linux の場合、昔はこの調整をしようと思うと、sysctl を使って /proc/sys/net/ipv4/tcp_retries2 の値を書き換えるしかなかった。 これは、リトライ回数でしか指定できず、そのリトライ間隔が回数ごとに変わっていく（長くなる）のでわかりにくい上に、そのOS上の全TCPコネクションで有効になってしまうという問題があった。つまり、このオプション
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
pgBadger: redirect to pgbadger.darold.net
