タグ

2010年10月3日のブックマーク (4件)

  • selectよりkqueue,epoll(apache2のススメ) - 最速配信研究会(@yamaz)

    最近3人ほどのエンジニアと話したのだがapache2に対して割とネガティブな意見を持っていた. 曰く「既存モジュールが使えないから」 曰く「スレッドベースってちょっと。。」 曰く「WEBでいい話聞かないから」 3人しか話してないんだけど,3人とも「apache2はスレッドでしか動かない」と思いこんでたようでちょっとおどろいた.apache2でも StartServers 5 MinSpareServers 5 MaxSpareServers 64 MaxClients 100 MaxRequestsPerChild 10000 という設定をすることで今までどおりpreforkモデルで動かすことはできる.preforkモデルだと各種ハンドラもスレッドセーフに無理にすることはないので,わかってて使う分には問題ない. 私がapache2を勧める1番の理由はapache2ではリクエストの多重化処理

    selectよりkqueue,epoll(apache2のススメ) - 最速配信研究会(@yamaz)
    masa_matya
    masa_matya 2010/10/03
    selectをwhileで回してsocketを調べる方法だと遅い実装。kqueueを使うと速い。
  • 「コネクションプーリング都市伝説」はほんとに都市伝説?(その3) - 最速配信研究会(@yamaz)

    前回のシリアル/パラレル処理の視点に立ってコネクションプールについて考えてみたい. コネクションプールが遅いとは はてなおやさんが考察しているように 普通にmod_perl でコネクションプールを素直に張るとコネクション数が爆発する. 図にすると図1のような感じで個々のapacheがコネクションを複数持つので,サーバ台数が増えるとコネクション数が飛躍的に増えることがわかると思う. 図1 コネクションが爆発してる様子(正直書くのも大変) コネクション数が増えると単純にコネクションを維持するコストも増えていくので, このあたりが「コネクションプーリング都市伝説」の根拠になっていると思われる. これはこれで全くその通りで間違いない. さて,ここでもうちょっと大きな視点に立って,クライアント<->サーバ間の通信路が 1個の伝送路をパケットによって多重化しているととらえてみたい.そうするとここで シ

    「コネクションプーリング都市伝説」はほんとに都市伝説?(その3) - 最速配信研究会(@yamaz)
    masa_matya
    masa_matya 2010/10/03
    「コネクションプーリング都市伝説」は、リクエストをシリアライズできる実装があれば解決できるかもというお話
  • Google 日本語入力コミック

    作:Google 日本語入力チーム 画:白根ゆたんぽ この 作品 は クリエイティブ・コモンズ 表示 - 非営利 - 改変禁止 2.1 ライセンスの下に提供されています。 ©2011 Google - ホーム - Google について

  • アジャイルチームのアーキテクトのための10の助言

    原文(投稿日:2010/09/14)へのリンク Microsoft AustraliaのソリューションアーキテクトであるTom Hollander氏は、TechEd Australiaでアジャイルチームにおけるアーキテクトの役割と題したプレゼンを行った。 氏はこの場でアジャイルチームを率いるアーキテクトとして氏が行っていることについて議論した。 アーキテクトの役割について話すとき、氏が指すのは“ソリューションアーキテクト’、つまりアプリケーションのアーキテクトだ。エンタープライズアーキテクトやある種の専門家(例えばメッセージングやインフラなどの専門家)を指してはいない。 氏のチームは、最後に2、3日のコード凍結を行う、安定した4週間のイテレーションプロセスで、毎日のスタンドアップミーティングや毎日のビルドと自動テストが伴う継続的統合を実践している。氏のチームでは次のような役割を採用している

    アジャイルチームのアーキテクトのための10の助言