3年4ヶ月在籍したCROOZを退職しました。 最後にオフィスを見渡したとき「ホントに大きくなったなぁ」と思いました。 「29歳で社会人&Linux歴が2年、ApacheもMySQLも触ったことありません」 という怪しい自分をあっさり受け入れて、すごくいろんなことをやらせてくれた。 あのタイミングでCROOZに出会えたことはホントに運がよかったです。 おかげでけっこうまともなエンジニアになれました（完全な主観です）。 CROOZのみんな、今までありがとう。お世話になりました！ そして10/1から、ナビプラスに入社してました。 人数は20人弱、RailsベースでECサイトの関連商品レコメンドなどをASP提供している会社です。 ここでまずやりたいことは、開発スキルを身につけることです。 デベロッパー兼オペレーションエンジニアという位置づけで、幅広く手を出していく予定です。 要するに「もう32歳に

自分はソフトウェアエンジニアとして毎日の糧を得ている。今のところはサラリーマンエンジニア以外の存在になる予定はない、が、とはいえ唯々諾々とつまんない仕事ばっかりやる毎日はできればごめんだと思っている。コードを書くのは楽しいからコードを書ける仕事をしたいし、特に面白い問題やまだ誰も手をつけてなさそうな問題を解決する仕事ができれば最高だ。 つまり、そう、尊重されたい。自分のやれること、やりたいことを尊重されるようになりたい。自分がやった仕事には価値があると思われるのは嬉しいし、そのように(勤務先以外の)他人から認められれば面白い話も聞けるようになるかもしれない。尊重されるソフトウェアエンジニアになれれば楽しそうだ。 尊重されるソフトウェアエンジニアであれば、もしかしたら自分の仕事についてある程度の自由が効くかもしれない。突然わけのわからない政治でがんじがらめの炎上プロジェクトのPMをやってこい

結論 「キャッシュしない」ことをキャッシュするのが hit for pass キャッシュオブジェクト。 同じ URL に、同時にアクセスされたとき、 キャッシュが見つからない場合 …… 先頭のリクエストだけをバックエンドに送り、残りはそのレスポンスを待つ。 hit for pass キャッシュが見つかった場合 …… 他のリクエストを気にせず、全部バックエンドに送る。 という動作になる。 発端 Varnish を3.0にバージョンアップしたら vcl_fetch のreturn (pass); がエラーになった。どうやら、単純に return (hit_for_pass); に置き換えればいいらしい。 Upgrading from Varnish 2.1 to 3.0 — Varnish version trunk documentation 2.1から3.0にアップグレードする際のVCLフ

resolv.confにオプションが書けることが判明 timeout:n 「レゾルバが他のネームサーバで問い合わせをリトライする前に、 リモートネームサーバからの応答を待つ時間」を設定する。 単位は秒で、デフォルトは RES_TIMEOUT である (現状では 5 秒、 を参照)。 attempts:n 「レゾルバが諦めて呼び出し元のアプリケーションにエラーを返すまでに、 ネームサーバに問い合わせを行う回数」を設定する。 デフォルトは RES_DFLRETRY 回である (現状では 2 回、 を参照)。 Man page of RESOLV.CONF つまり、タイムアウト時間×リトライ回数 という式になるのでデフォルトは5×2＝10秒が最大待ち時間 $ time ping uuu.com ping: unknown host uuu.com real 0m10.029s user 0m0.

はじめに アクセスが急増すると、応答時間が著しく悪化するサイトはありませんか？ 普段は200ミリ秒以内で安定してアクセスをさばいているのに、イベントやらキャンペーンやらを開始した瞬間から、普段の２倍や３倍のアクセスが殺到し、その結果、レスポンスタイムが3秒とか9秒とかかかるようになってしまうことってありますよね。 あるサイトの実状 つい先日まで、そんなサイトが私の目の前にもありました。自社で運営している某ソーシャル系のサイトなんですが、イベント開始時刻と同時にアクセス数が急増するのです。とはいえ、所詮は普段の2倍とか3倍程度の数なのだから、少なくとも1秒以内にレスポンスを返せるくらいの性能は維持したいものです。 しかし実際は困ったことに、応答に3秒以上もかかってしまう処理が大量に発生してしまう状況に陥ってしまっていました。これはきっと、どこかにボトルネックがあるに違いありません。 仮説を立