恥ずかしいけど。 require 'rinda/tuplespace' require 'erb' require 'webrick/cgi' require 'rbtree' require 'nkf' require 'digest/md5' require 'enumerator' たくさんrequireする。enumeratorはeach_sliceを使いたかったから。 class Page include ERB::Util def initialize @color = create_color end def create_color Hash.new do |h, k| md5 = Digest::MD5.new md5 << k.to_s r = 0b01111111 & md5.digest[0] g = 0b01111111 & md5.digest[1] b = 0
アプリケーションA:keyXをgetする アプリケーションA:getが待たされる アプリケーションB:keyXにvalueXをセットする アプリケーションA:getが帰り、valueXを取得できる このように非同期に通知する機構をmemcachedプロトコルを使って汎用的に利用することができます。 インストール ソースコードはCodeReposにあります:lang/ruby/lkserver $ svn co http://svn.coderepos.org/share/lang/ruby/lkserver $ cd lkserver # memcachedテキストプロトコルのパーサーをコンパイル $ ruby extconf.rb $ make # Rev(イベント駆動IOライブラリ)をインストール $ gem install rev # 11511/tcpで起動 $ ruby lkse
特にサーバー用途では、CPUがシングルコアに戻ってくることは考えにくい。 マルチコアCPUの性能を活かすにはマルチスレッドに対応したサーバーの実装が必要になるわけですが、マルチスレッドなプログラミングは往々にして「高負荷になると固まる」とか「たまに落ちる」といった悩ましいバグと戦わなければならず、イヤです。 かといってシングルスレッドでは、近い将来 32コアCPU! などが出てきたとき、たぶん性能を発揮できません。 そこで、そこそこデバッグしやすく、それでいて多コアCPUでもスケールするという落としどころを模索しているのですが、ボトルネックはネットワークIO周りにあるだろう*1という前提の元で、ネットワークIO部分だけをマルチスレッドで動かし、それ以外の部分をシングルスレッドで動かすというアーキテクチャを考えています。 ロジックの部分はマルチスレッドで書いても共有リソースにアクセスする度に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く