PCIカードでGzip圧縮 52
ストーリー by Oliver
次のハード化はなんだ 部門より
次のハード化はなんだ 部門より
dseg 曰く、 "本家より。先日終了した電子関連見本市、CeBITで、
ドイツのWuppertal 大学とVigos社の共同開発による、大変興味深いPCIカードの試作機が展示されたという。
"Webサイト アクセラレータ"と銘打たれたこのカードは、Gzip圧縮をハードウェア上でリアルタイムに行うというもので、
現行の速度は 32Mbytes/sec と 100MbitのLAN上のデータを扱うには十分なスペック。Webサイト関連のみならず、ネットワーク越しのバックアップ等にも威力を発揮しそうだ。将来的には倍の 64Mbytes/sec を目指しているとの事だ。
尚、Vigos社のプレスリリースも読むことができる。発売時期等の詳細は不明だが・・・せっかくハードでこなしてくれるのなら、Bzip2圧縮版(板)も欲しいなあ。"
ハードが速いとは限らぬ (スコア:2, すばらしい洞察)
このハードでもソフトウエアで結局は制御するわけだから、そのソフトウエアの実行速度だって気になる。
デコードされたデータが多いとき、結局PCIバス経由でデータ転送せにゃあかんでしょう。もちろん、エンコードされたデータがカードに入るときも同様。で、データ量があまりに多くなった場合は、この転送速度だってネックになる。デコード結果がメモリに入りきらないくらいの大きさになった場合、結局ディスクのI/O速度にデコード速度はよるのではないか?
過去にも同種のハードウエアアクセラレータがあったけれども、結局量産に入る前にソフトウエアの実行速度が上がって量産時の初期コストもあわせるとコスト的にあわないものになっていた。
さて、今回はどうか?
GHzなCPUが普及してきた今では特に… (スコア:2, 参考になる)
で、FPGAか何かで拡張ボードを作って、ハードで圧縮したファイルをソフトで解凍させたり、その逆をしたりして、ちゃんと互換性があるよ!
…はいいんだけど、いかんせんそのボード、Cバス(お!)なもんだから、データ転送が遅くて、結局ソフトのほうが速いという結果に…
PCIにしたところで、今だったらCPUはGオーダーだしなぁ~
PCIにすれば速いかっていうと、単純にそうとは言えないし…
PCIはバスマスタ/バースト転送でないと性能が出ないのに、「PCI=速い」というイメージだけでPCIバスを採用したけど、中身はCPU転送/シングル転送で動いてて、ぜんぜん性能が上がらなかった…という失敗作が、私の足元に(汗)
挿す位置の問題? (スコア:1)
Gzip板がLAN板のドーター板として実装されたら良かったのにね、
とかいう風に考えると良いのでしょうか?
#音源板にドーターが色々有って楽しいと思うのでG7。PCじゃないがMU100に歌うドーターとかも。
Re:挿す位置の問題? (スコア:0)
直接、lan板がgzip板の機能をインターコネクト経由して使えればいいんですね。
Hypertransportとかって、p2p通信なんだから
そういう使い方すれば、便利なのになぁ。
PCに使う部品をサービスとしてそれを管理するディレクトリ機能を
インターコネクト上に持てばいいじゃないですか。
Re:ハードが速いとは限らぬ (スコア:0)
Re:ハードが速いとは限らぬ (スコア:0)
プレスリリース (スコア:1)
指したかったのはこれ [vigos.com]かな?
#自力ではえーごは読めないので確認できず^^;;;
以前、 (スコア:1)
#INSの64Kで最大512K送れると書いてあった。
Re:以前、 (スコア:0)
>#INSの64Kで最大512K送れると書いてあった。
それ、パケット受け取り先ではどうするんですか~
今回のPCIカードって単にgzip圧縮する機能だけもってるんじゃないんですか?
それをどう使うかは、アプリケーション依存なんだと思いますが。
Re:以前、 (スコア:1)
Re:以前、 (スコア:2, 参考になる)
> GZIP Accelerator can process more than 32 Megabytes of
> data per second and this will enable Web content compression
> in truly real-time!
> The PCI-Board offloads the cycle-intensive encoding
> operations from the webservers main CPU
つまり、これによると
「本来WebサーバのCPUが行っていたWebコンテンツの
エンコーディングにかかる負荷を減らすことができるんだ。(超意訳)」
とあります。
Webサービスが、相手の端末を選ぶようではだめですから
これは、コンテンツのリアルタイムgzip圧縮に使われると
考えたほうがいいと思います。
受け取る側は、コンテンツを圧縮したままで受け取ることを想定したアプリケーションなんでしょうね。
簡単なところでは、ftpの取得時圧縮のように
コンテンツの一括取得がgzip圧縮形式で受け取れるように
なっていたりするのかもしれません。
他、適切なアプリケーションが浮かびませんが
ブラウザ以外の専用アプリケーションを使えば、
もっと幸せな使い方が見つかりそうですね。
# 巨大掲示板。
# バックのデータは、プレーンテキストで扱って
# ブラウザ経由でアクセスするときはプレーンテキストを
# 整形して表示させる。
# 専用のビューアに対しては、gzip圧縮されたデータを
# 送りつけて整形をビューアに任せられる・・・・・とかね。
Re:以前、 (スコア:1)
ごめん。HTTP/1.1を考えてなかった。
ブラウザでも十分、圧縮の恩恵を受けられますね。
Webサービス (スコア:1, すばらしい洞察)
# しかし、なんだな、ほんとはXMLベースのやつをわざわざ「Web Service」という名前にしたヤツのほうが悪いと思うんだが。
Re:以前、 (スコア:0)
何か昔のJPEGカードとかみたいだぞ (スコア:1, すばらしい洞察)
無茶苦茶似てるような気がします。
ネットワークで使うとなると、ローカル側とサーバ側両方に実装してないと駄目なんですよね?あんまり流行りそうにないなあ.....。
パケット圧縮して、細い帯域で大量のデータを流そうってシステムは流行ったものが無いと思うんですけど、どうなんでしょ?個人的にはWAPなんて典型的な例だと思ったけど。
Re:何か昔のJPEGカードとかみたいだぞ (スコア:1)
>システムは流行ったものが無いと思うんですけど、どうな
>んでしょ?
パケットではないが,NMPモデムのクラス4だとデータ
圧縮してましたが.
Re:何か昔のJPEGカードとかみたいだぞ (スコア:1)
V.42bis なんかは、圧縮率それなりにいい割にレスポンスも悪くならなかったのが嬉しかったですね。確か MNP5 はデータ待ちのタイムアウトが遅かったのかレスポンス悪かったし。
Re:何か昔のJPEGカードとかみたいだぞ (スコア:0)
iモードやEZ-Webでも「パケ割」等の有料でデータ圧縮を利用
できるようにするサービスが成立している様なので、それなりに
ニーズはあるのでは。
# MPEGだって、局側はハードウェアだとおもいますが・・・・
Re:何か昔のJPEGカードとかみたいだぞ (スコア:0)
# 衛星系は流行ってないと言えるかな?
# 地上波は・・・
# 流行りそうに無いから強制的に導入するのかも :-D
どうせなら3DESとAESも載せてほしい (スコア:1)
tarのzオプションがこれカードを使うようにフックしてくれたりすると、日常業務にも役立つ。
だけど、Pentium3で十分速いと言えば速いからなぁ……。
Masafumi Otsune [otsune.com]
Re:どうせなら3DESとAESも載せてほしい (スコア:1)
CPUに拡張命令セットとして統合させる方式が流行ってたりしますね。
Re:どうせなら3DESとAESも載せてほしい (スコア:0)
tarのzオプションはgzipを呼んでいるだけなので、gzipコマンドがこのカードを使うようになってくれると...という話になりますね。
Re:どうせなら3DESとAESも載せてほしい (スコア:1)
Re:どうせなら3DESとAESも載せてほしい (スコア:0)
?少なくともGNU gzip-1.3.3ではzlibなんて使ってないですよ。それとも最近のLinuxとかだとzlibで作ったminigzip的なものをgzipとして同梱してたりするんでしょうか?ちなみに先に書いた「tarはgzipを呼んでるだけ」についてはtar-1.13.25/READMEに
GNU tar uses the gzip and bzip2 programs to read and write
Re:どうせなら3DESとAESも載せてほしい (スコア:0)
あんまり突っ込んじゃ可哀想です。
次のハード化 (スコア:1)
# 要はFlashだけど。
Re:次のハード化 (スコア:0)
Re:次のハード化 (スコア:0)
Re:次のハード化 (スコア:0)
無駄! 無駄!! (スコア:1)
本当に2chみたいな文字主体の巨大サイトやWebディスク兼用のメールサイト以外は使い道が無さそうなんですが. だって普通Webサービスで通信量が問題になるとしたら, 画像や音声みたいなバイナリデータが中心で, しかもそういった奴って一部の例外を除けば既に圧縮済みでしょう. それに再度圧縮をかけたからって, 処理時間の無駄にしかなりません.
バックアップ用途に使うとしても, この機器が有効に使えるような高速なバックアップストレージを持っている環境なら, 専用のネットワークを使うはずですし, さらに高速な用途となったら, 今度はSANか何かで集中管理した方がTCOは下がるはずです.
となると, やはりニッチな領域で目的にうまくはまれば良いと思いますが, 汎用的に使われる物かと言われれば疑問符がかなり付くと思います.
スループットは上がるでしょう (スコア:1)
転送量だけで効果を測るのは早計じゃありませんか?
1トランザクションの時間が短くなるってのは、
ある程度ヒット数の大きいサイトでは同時処理トランザクション数が減って
結構スループット改善に効果あると思います。
大体から、Webの情報の大半は文字データなんで圧縮率もいいでしょうし、
JPG etcの圧縮済みのコンテンツを再圧縮するような愚さえおかさなければ(タイプで識別できますよね)、
ニュースサイトのように頻繁に内容の変わるサイトにおいて
都度圧縮によるトランザクション時間の短縮は効果大きいと思いませんか?
処理トランザクション数を増やすために通信帯域を広げるよりも
お安く改善に役立つと思うんですがね。
Re:無駄! 無駄!! (スコア:0)
こういった製品を導入するときには、きちんと自分のサービスの特性を分析して
カードを買うのがいいのか、箱を増やすのがいいのか、速い箱にいれかえるのがいいのか
と検証をしてから行うものでしょう。
効果が*必ず*あるだなんて盲目的に信じて導入する方がどうかしてますよね。
即効でうれしい人は・・・ (スコア:0)
参考 (スコア:1, 参考になる)
ただし、最近購入されたサーバ?ではスレッド自身も圧縮取得可能な様です。
ただし、いわゆる専用ブラウザでは、スレッドの更新された部分のみを取得しており、その際には「あぼ~ん」(発言削除)があると整合性が取れないのでGZipデータは取得しないのが現状です。
Re:即効でうれしい人は・・・ (スコア:0)
Re:即効でうれしい人は・・・ (スコア:0)
ハウジングサーバとかなら別か。
Re:即効でうれしい人は・・・ (スコア:2, すばらしい洞察)
「我が社のサーバーは、(本来の帯域/圧縮率)もの帯域がございます。」
と言うのですよ。w
Re:即効でうれしい人は・・・ (スコア:0)
ユーザのメリットとしては、データの転送が速くなります。
あの~ (スコア:0)
しかも、たいていのWebサーバとWebブラウザには、これらのエンティティエンコーディングに対応した機能が実装されているのですが。
ハードウェアでやるってことに対する意味は認めなくもないんだけど、いつぞやのblog騒動と同じ位間が抜けてると思う。
Re:あの~ (スコア:1)
とかいいつつそれが役に立つかどうかはサーバーの運営をしたことが無いので分からない。
とりあえず、 本家の書き込み [slashdot.org]をリンクしてみる。
Re:あの~ (スコア:1)
ちなみに/.JはGzip転送しています。古いOmniWebで保存すると、Gzipのまま保存する事がままあって、ちょっと面倒くさかったな。
# しかし何度見ても本家Apacheセクションの配色には驚く
Re:あの~ (スコア:1)
上の私の書き込みの本家のリンクでもある様に当然のことながら対応したものはまだ無い。
けれども、其処の書き込みでは、ある程度のヒット数があるサイトの運営者はmod_gzipを外したときの負荷のグラフを見るとショックを受ける、と書いてあるぐらいだから結構な負荷になっているのかな?
200$以下だったらうちのサーバーファームに速導入するよ、っていってるし。
Re:あの~ (スコア:0)
リバースプロクシーと組み合わせて使うように書いてあるんだから、 まさにそれを使ってるんじゃないのかなと予想してるんですがねえ。
>ハードウェアでやるってことに対する意味は認め
Re:あの~ (スコア:0)
箱 (スコア:1)
商用サーバ向けだとSSLアクセラレータ付きであることも多々必要となることもあるようですね。
他力本願。
Re: あの~ (スコア:0)
RFC [w3.org]
Lynx等のクライアントは未だにHTTP 1.0でリクエストするし、携帯端末も然り。
ですが。(オフトピ) (スコア:0)
ってなに?
日本語の扱いは大丈夫ですか?あなたは何を言いたいのですか?
「ですが、メーカーはそのことを知っているのでしょうか。」を省略しているのですか?
「ですが、その決まりきった工程の一部をハードウェア化するのは汎用CPU
Re:ですが。(オフトピ) (スコア:0)
「皆は知らないかもしれないけど、俺はこんなこと知ってるんだぜ」という薀蓄を自慢したくて、でも、その薀蓄を元の文章と結びつけるような論理的な展開ができない場合に、とりあえず「ですが。」と文末に付けているだけだと思っていました。あれって本当は何か意図があるんでしょうか?
Re:ですが。(オフトピ) (スコア:0)
Hifn(旧 Stac)との絡み (スコア:0)
http://www.matsusaka-u.ac.jp/~okumura/compression/patents.html