Squidのチョイ規模でかめで参考になりそうなconfとコメント (名無しさん＠おなかいっぱい)
#squidの動作させるユーザ・グループ cache_effective_user squid cache_effective_group nogroup #squidはcache_memの約3倍のメモリを使います cache_mem 64 MB #diskdはsquidと別スレッドでディスクに書込みします。複数cpuに最適値。最初の100は使用ディスク容量(MB単位) cache_dir diskd /var/cache/squid 100 16 256 #半接続で落ちたクライアントをすぐに切る half_closed_clients off #再起動/終了時の待ち時間 shutdown_lifetime 3 seconds #メモリに読み込むキャッシュオブジェクトの最大容量 maximum_object_size_in_memory 5 MB #ステータスページのパスワードを
Download Fiddler Web Debugging Tool for Free by Telerik
*Please be aware that Fiddler Classic is not in active development and offers no commitments for releases, patches ot tech support. By using this product, you assume all associated risks. We recommend upgrading to Fiddler Everywhere. Do More with Fiddler EverywhereGo beyond Fiddler Classic and try Fiddler Everywhere for free. Explore our easy-to-use and modern web debugging solution for Windows, M
「テキストプロトコルは遅くないよ」という話 - kazuhoのメモ置き場
「バイナリプロトコルは速い」「テキストプロトコルは遅い」という言説を、ときおり目にするけど、それって本当なのか。個人的には、それって昔の話だと思ってる。 SMTP みたいな、ペイロードについてもターミネータ（とエスケープ）を使うプロトコル*1は確かに遅い。で、FTPプロトコルでは、大容量のデータを「高速」に転送するために、制御用のTCPコネクションと転送用のコネクションを分けたりしてた。 だけど、HTTPプロトコルは、テキストプロトコルだけど、ペイロードについてはターミネータを使わない。keep-alive を行う際には、Content-Length ヘッダ（あるいはchunkedエンコーディング）を使うことで、ペイロードのパース／変換処理を不要にしている。別の言い方をすると、テキストプロトコルだからと言って、バイナリプトロコルよりペイロードの処理時間が長くなるとは限らない。HTTP 以降
Polipoが覗く HTTP/1.1の深淵(?)を UMLGraphで解説してみる - 聖アンドレアスの失敗
Dolipoや Polipoが 話題になっているようで。 でもその原理になっている HTTP/1.1の仕組みとかはそれほど理解されてなさそう。 この記事 でも Poor Man's Multiplexingは飛ばしちゃってるし。 ということで、自分の思い出すのと UMLGraphの練習を兼ねて 解説したいと思います。 Sequence図の UMLGraph sourceももれなく公開という大盤振る舞いです (って、だれが喜ぶんだろう)。 HTTP 0.9 まず、HTTPの基本形とは以下のようなかんじです。 Requestがあって Responseがあるという単純なもの。 そして重要なのが transactionごとに TCPを張り直すということ。 これは、HTTP/0.9時代は responseの終わりを TCP Disconnectionで 示すという荒っぽい仕様だったためしかたないっす
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
