2010年代には Apache の mpm_prefork とか流行らない (もしくは HTTP keep-alive のメリットとデメリット) - kazuhoのメモ置き場
HTTP の持続的接続の功罪について はじめに、HTTP の持続的接続 (keep-alive) のメリットについて。持続的接続を使うメリットは、以下の２点。 TCP 接続の確立にかかる時間の節約*1 TCP の接続と切断に必要な資源 (CPUとネットワーク) の節約 ウェブブラウザ〜データセンタ間の通信で、持続的接続を使う理由は、このうちの前者。特に太平洋を超えるようなケースだと、TCP 接続に0.2秒とかかかるので、メリットが大きい。 一方、持続的接続のデメリットは、 接続が切断されるまでの間、その接続を維持するためにコストがかかる (主としてメモリが無駄になる) という点になる。特に、１プロセス１コネクションを前提とするアーキテクチャ (例: mod_perl) だと、メモリの無駄使いが、とてもひどいことになる。 そこで、ブラウザからの接続を受ける HTTP サーバとアプリケーション
彼氏が LIKE 検索使ってた。別れたい… (もしくは Solr 入門とか Tritonn のインクリメンタルバックアップとか) - kazuhoのメモ置き場
LIKE 検索だとデータ増えてきた時なんか恥ずかしいwww 下向いちゃうしww 男にはせめて全文検索エンジン使ってほしい・・・ 検索が遅すぎてユーザー帰っちゃったら・・・・もう最悪www せめて普通 Tritonn や Solr くらいは使って欲しい。 常識的に考えて欲しいだけなんです！ 「%」検索されて全件マッチしちゃった時の恥ずかしさとか分かる？ あのね？たとえば１年間で10万件とか文書がたまるでしょ？ それを格納して検索するわけじゃない？ みんな普通に形態素解析とかn-gramとか期待してるわけでしょ？ LIKE検索でタイムアウトしてたら大恥かくでしょうがww とまあ、検索するなら全文検索エンジン使うしかないわけですが。じゃあ何を使うべきか。 自分は、ながらく Senna をベースにした MySQL の全文検索拡張 Tritonn のユーザーで、自分で機能追加のパッチも書いたりしてい
Solr って、書き込みの Disk I/O が多くて、リアルタイム検索は不可能なのかしら - kazuhoのメモ置き場
を読んでいて、pp.266-267 に、以下のような記載があった。 ・Optimize の重要性 コマンドは Solr のインデックスを物理的に最適化するコマンドです。具体的には、Solr では commit のたびに一群 11 個のファイルを作成します。 つまり、細かく commit を繰り返す形で文書の投入や更新を繰り返すと、その分だけインデックスとして多くのファイルを使うようになり、ひいてはファイルディスクリプタが枯渇する事態に陥ります。 仮に枯渇しなくても、多くのファイルを開いて検索に利用することになるため、パフォーマンスに甚大な影響を与えてしまいます。 この事態を回避するため、目安として 5 回程度 commit を行ったら最低 1 回は optimize コマンドを発行するようにしてください。 optimize を行うことで、複数回分に分かれてしまっていたインデックスファイル群
ウェブ業界の15年、これからの10年 (Re ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない) - kazuhoのメモ置き場
先のエントリ (ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない) ではボトムアップに煽った書き方をしたけど、自分がトップダウンでどういうふうに捉えているかについて。以下、あくまでも私見です。 いわゆるネット業界は1990年代後半に始まってから15年くらいたったわけだけど、当初はマスメディア（静的コンテンツの配信）が業界の中心だったのが、パーソナライゼーションを経て、コミュニケーションツールへと変化してきた*1。 それにあわせて技術的な面でも分化が進み、今ではデータベースとアプリケーションサーバと httpd っていう三層構成が一般的になっている*2。 そもそも Apache って、モジュールをC言語で a-patchy に書いて動的コンテンツを作れるのが売りだったわけだけど、今じゃコモディティ化を通り越してレガシーソフトウェアの代表格。でもみんなあんまり困ってないの
ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない - kazuhoのメモ置き場
タイトルは煽り入ってますが。 仮に動的ページを生成するのにかかる時間が1秒、そのうちデータベースやmemcached等リモートサーバへの問い合わせ時間を除くいたCPUの処理時間が0.1秒とする。また、ピークのリクエスト処理量は、平均の２倍とする。 そうすると、クアッドコアのアプリケーションサーバで処理できるリクエストは、 4 core * 10 reqs/sec * 86,400 sec/day * 30 day/mon / 2 = 51,840,000 reqs/mon と、約5,000万PV/月を１台で捌けることになる。 CPUが動いている時間は全処理時間の10倍と仮定したわけだから、アプリケーションサーバの最大同時接続数は 4 core * 10 = 40 程度あればいいことになる。実際には、安全係数を２倍かけて 80 とか。リクエストの処理に必要なメモリ量を 100MB とすると、
なぜ daemontools を使うのか - kazuhoのメモ置き場
_ djb が自作ツールの更新を放棄してからずいぶんたって、qmail やら djbdns やらはゆっくりと置き替えが進んでいるようだ。が、いまだに使い続けられているものもある。具体的には daemontools。いまだに daemontools を 使うネタが書かれているのを見て絶望した。代替物はほかにもあるのに。 (中略) _ そんなわけで、わしのことを anti djb だと思っている一部の方々が飽きて燃料投下を望んでいるような声をだいぶ前にどっか(どこだか忘れた)で見かけたので、要望に答えて若干 djb を dis り気味に runit と ipsvd を解説してみました。わしゃ別に「いいものを使う」というだけで、djb が嫌いなわけでもなんでもないんだけどね。ちなみに、自分自身では好き嫌い以前に必要性を感じてないので使っておりませぬ(これ書くために何年かぶりにインストールした)。
Apache を daemontools で管理する - kazuhoのメモ置き場
自作のサーバプログラムに、いちいち setuid とか setsid とかログローテート機能とか実装するのめんどくさいわけで。だから daemontools を使って管理してるわけですが、だったら、いっそ全部のデーモンを daemontools で一括管理したい。 ちょうど、reverse proxy をセットアップする機会があったので、apache を daemontools で管理する方法を備忘録をかねてメモ。 % cat /service/httpd/run #!/bin/sh APACHE_ROOT=/usr/local/apache-2.2.14 exec 2>&1 exec pgrphack $APACHE_ROOT/bin/httpd -DNO_DETACH -DFOREGROUND -c "ErrorLog /dev/fd/1" -c "Include /var/httpd
mysql と drizzle の負荷テストツール「skyload」が凄い！ - kazuhoのメモ置き場
tmaesakaさんがやってくれました。 ずいぶん前からSQLのベンチマークを測定するのに使いやすいプログラムないかなーと思ってました。個人的にはmysqlslapというのを使ってたのですが、幾らか気に入らない所があったりコマンドラインオプションが複雑で毎回 --help を読んだりしていました。余計な機能なんかなくて、指定したSQLを高速にくりかえしてくれる物が欲しいなぁって思ってたんです。 とあるIRCでこの前、tmaesakaさんから「いま作ってる」という話を聞いて、いろいろ要望を言ってたんですが、ついさっきチュートリアルが公開されました。速いw 名前はskyload。とても小さく、実装コードだと800行程度です。しかもオプションが少ないので使い方が単純です。試しに適当な INSERT の速度を測ってみました。 $ skyload --server=localhost --mysql
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
