彼氏が LIKE 検索使ってた。別れたい… (もしくは Solr 入門とか Tritonn のインクリメンタルバックアップとか) - kazuhoのメモ置き場
LIKE 検索だとデータ増えてきた時なんか恥ずかしいwww 下向いちゃうしww 男にはせめて全文検索エンジン使ってほしい・・・ 検索が遅すぎてユーザー帰っちゃったら・・・・もう最悪www せめて普通 Tritonn や Solr くらいは使って欲しい。 常識的に考えて欲しいだけなんです！ 「%」検索されて全件マッチしちゃった時の恥ずかしさとか分かる？ あのね？たとえば１年間で10万件とか文書がたまるでしょ？ それを格納して検索するわけじゃない？ みんな普通に形態素解析とかn-gramとか期待してるわけでしょ？ LIKE検索でタイムアウトしてたら大恥かくでしょうがww とまあ、検索するなら全文検索エンジン使うしかないわけですが。じゃあ何を使うべきか。 自分は、ながらく Senna をベースにした MySQL の全文検索拡張 Tritonn のユーザーで、自分で機能追加のパッチも書いたりしてい
はてなのサーバ運用は教科書的なスケールアウト手法? - kazuhoのメモ置き場
はてなにおける SSD の実績 - mura日記 (halfrack) の感想。木を見て森を語るような話ですが、この iostat を見ていて興味深かったのが、 ボトルネックは SSD この状態だと iostat -x の ioutil は 100% にかなり近い値40%-50% 前後だと思う*1 CPU がスカスカ メモリもそんなに積んでない*2 それでも SSD を複数台つながない、ってことは、ストレージの上限にあわせて CPU とメモリをスケールダウンする方針なんだろう。絵に描いたようなスケールアウトダウンアプローチ。 高可用性はレプリケーションで確保する、と割り切るなら、サーバ毎に RAID を組んでシステムを複雑化させる必要はないし*3、方針がはっきりしてて素晴らしいな、と思った。 酔っぱらってるようなエントリだけどまだ飲んでない 追記： うちのパストラックの新サーバの X25-
ウェブアプリケーションサーバを複数台構成とか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 とすると、
はやいTCPサーバを書く際に忘れがちなこと - kazuhoのメモ置き場
はやいTCPサーバの書き方 - nyaxtのPC作業ログ で id:nyaxt さんが書いてらっしゃるように、 epoll や kqueue を使う TCP_NODELAY, TCP_DEFER_ACCEPT *1 等を活用する TCP パケットを意識する I/O システムコールの回数を最小にする sendfile といったあたりは、確実にやるべきことだと思います。一方で、TCP 関連以外のオーバーヘッドが実は結構あって、 接続のタイムアウト処理 ログの出力 メモリの確保や解放をやらない あたりにも気を配る必要がある、と思います。 接続のタイムアウト処理については、以前 Kazuho@Cybozu Labs: 高速なCometサーバを書いてみた件 に書いたように、ビットアレイのリングバッファを使うのがベストだと思います。 ログの出力について、複数行を１回のシステムコールにまとめてもいいかど
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
