Home

日記
bookmarkletの受付口が動いていませんでしたEdit

1470.netリニューアル版のbookmarklet受付口でエラーが出て、bookmarklet経由の登録がうまく動いていませんでした。

というのは、PHP5でもそろそろ実用で使えるアクセラレータがあるかと探してみたところ、peclに入っているAPCが一応PHP 5.1系に対応していると書かれていたので試しに入れたところ、一見ちゃんと動いているように見えたので、そのまま本番環境に導入してしまいました。が、先ほど試してみたところ、上記ページでAPCなしでは発生しないエラーが発生しているのに気づいたというわけです。

ちなみにエラーが発生したコードは、instanceofで変数の内容を振り分けて処理を切り替えている部分で、APCなしでは正しく継承元クラスのオブジェクトと認識できるのに対し、APCありだとその部分で正しい判断ができていないようでした。検証コードレベルを書けるレベルまで追ってませんけど。

Published At2006-07-02 00:00Updated At2006-07-02 00:00

日記
URIデータベースの不整合障害から復旧しましたEdit

設計ミスでURIデータベースに不整合が起こり、その修復の際に各種不具合が発生していましたが、先ほど一通り復旧しました。長々トラブっていてごめんなさい。

Published At2006-07-04 00:00Updated At2006-07-04 00:00

日記
マイblogmapEdit

で、メモツール以外の新しい機能として、リニューアル版blogmapを稼働させました。ただし、従来のblogmapとはずいぶん違ったものになっています。

従来のblogmapでは、システムがpingサーバー等からblogのフィード情報を収集し、それを解析してランキング等生成していました。しかし、その方法ではspam系blog情報の混入率があまりに高すぎて、頻繁にゴミ掃除をしないとまともな情報が得られないようになっていました。

そこで、今回はユーザーが情報収集先のフィードを自由に登録し、ユーザーが登録したフィード群における被リンク情報等を解析表示できる、ユーザーカスタマイズ可能なblogmapとして作成しました。

この方法ならば、情報収集先をユーザー個々人が管理することでspamを排除できますし、また情報収集の傾向もユーザーが自由に管理することができるでしょう。実際に登録した例は以下のようになります。

表示件数やレイアウトなどは多分いろいろいじると思いますが、機能のイメージはだいたい分かると思います。自分のblogmapにフィードを登録するためのbookmarkletも用意しています。

ちなみに、情報を収集するのはあくまでもフィード内に含まれる情報のみですので、全文を掲載しているフィード以外を登録しても、あまり面白い結果は得られません。また、いわゆるフィードリーダー的な機能も一部持っていますが、フィードリーダーとしての機能はあまり充実させるつもりはありません(他に良くできたフィードリーダーがあるので)。

また、各ユーザーによって登録された特定のフィードに関しては、以下のようなページが用意されます。

従来から要望が多かった、アフィリエイト系リンクで情報収集元サイトのIDを残す機能を搭載しているので、Amazon商品系リンクについては、元サイトのアソシエイトIDが生きます(和書についてはbk1へのリンクも生成し、bk1のpartner-idが見つかった場合はそれも利用します)。

Published At2006-07-04 00:00Updated At2006-07-04 00:00

日記
URI関連のフィードを用意しましたEdit

ひとまずURIおよびメモに関するフィードをRSS 1.0形式(従来のMM/Memoと同じような形式)で用意しました。

URI以外のデータをどう扱うかはいまだに検討中です。一応Atom方向を考えてはいるんですが、調べなければならないことが盛りだくさんなので、ひとまずは慣れているRSS 1.0でお茶を濁しておきます。

Published At2006-07-05 00:00Updated At2006-07-05 00:00

日記
やっつけ1470footerEdit

RSSを配信したついでにmm_footerをやっつけで改造したけど、CSS周りとかいろいろ調整が必要なんで、自分で改造して使う根性がある人だけどうぞ。

add_body_leave_proc(Proc.new do |date|
oldest_date = Time.local(2005, 1, 11)
if date > oldest_date
if @mode == 'day' or @mode == 'latest'
userName = 'ishinao' # your 1470.net id
url = "http://1470.net/user/#{userName}/#{date.strftime('%Y/%m/%d')}"
rssurl = "http://1470.net/user/#{userName}/#{date.strftime('%Y/%m/%d')}/feed"
template_head = %Q[<div class="section mm_footer">\n<h3><a href="#{CGI.escapeHTML(url)}">今日のメモ</a> powered by <a href="http://1470.net/">1470.net</a></h3>\n<ul class="mm_footer">\n]
template_list = '<li>#{content.gsub(/href="\//, "href=\"http://1470.net\/")}</li>'
template_foot = "</ul>\n</div>\n"
cache_time = 3600;
if date.strftime('%Y-%m-%d') != Time.now.strftime('%Y-%m-%d')
cache_time = 3600 * 12;
end
rss_recent(rssurl, 50, cache_time, template_head, template_list, template_foot)
else
''
end
end
end)

Published At2006-07-05 00:00Updated At2006-07-05 00:00

日記
ようやくMM/Memoでの503頻発が改善できたっぽいEdit

新1470.netと同程度にバランスされるはずなのに、なぜかMM/Memoばかり503エラーになっていたのを改善しようといろいろいじっていたんだけど、ようやく改善できたっぽい。

結局問題は、旧1470.netで受け付けていたpingサーバーへの、世界中からの(ほとんどがspamの)アクセスで、PoundからMM/Memoへのコネクションがあふれてしまっていたらしい。pingサーバーへのアクセスをMM/Memo側のサーバーに振らないように変えたところ、503の頻発はようやく解消された模様。

というわけで、今週頭あたりからご迷惑をおかけしてきましたが、ようやく従来通りアクセスできるように戻ったと思います。

Published At2006-07-06 00:00Updated At2006-07-06 00:00

日記
URLのパーツごとの統計Edit

旧1470.netではURLをvarchar(255)で格納していたんだけど、新1470.netではprotocol、hostname、port、path、querystring、fragmentというパーツに分割し、URL自体はそれらへのIDへのリンクとして持つようにした。

URL情報をハンドリングするには、必ず6つのテーブルへの参照が必要と、処理的には冗長なんだけど、従来のやり方だと無限に増え続けるURL情報がDBサイズを圧迫するんで、とにかくDB上のURL関連データのサイズを圧縮する方が、スケールを考えたときには圧倒的に有利だったので。

で、しばらく走らせてみて、いろいろなURL関連の情報がたまってきたところで、URL数に対しての各パーツの数ってのは、結構面白い情報だなーと思ったので、現在の値を晒してみる。こういうのって研究している人いるのかなー。

URL112,679
プロトコル*12
ホスト名*221,378
パス78,979
QUERY_STRING8,214
フラグメント23,510

ちなみに、URL情報は形式的にvalidであれば、実体がなくても(404とか返ってきても)登録はされるようになっているんで、すべてが有効なURLであるとは限らない。

あと、うちのDBに登録されるURLってのは、基本的に

  • 誰かが興味を持ったURL
  • RSSなどで配信されているURL

なので、そういう偏りがあることにも注意が必要だろう。

*1 現在のところhttpとhttpsしか扱っていないので

*2 小文字に統一して扱っている

Published At2006-07-07 00:00Updated At2006-07-07 00:00

日記
メモのパーマリンク情報の不整合を修正中ですEdit

メモのパーマリンク生成処理にバグがあったため、メモに関連するURIデータベースに重複(同じメモに関するURI表現が複数存在する)等が発生しています。現在修正スクリプトを走らせているので、しばらくしたら正しいパーマリンク表現一つに収束すると思います。

Published At2006-07-07 00:00Updated At2006-07-07 00:00

日記
1台外れのサーバーがありましたEdit

1台deployに失敗してエラーを返すサーバーがあり、先ほどまで1/3の確率でエラーを返す状態になっていました。

ちなみに現在の構成では、フロントのpoundでバックエンドのWebサーバー×3に分散させていて、

   Session
Type IP
TTL 300
End

といった感じでIPアドレスベースで接続サーバーを固定しているんで、IPアドレスが変わらない限りは、基本的に同じサーバーに接続するようになっています。

ので、外れのサーバーをひいた場合はずっとエラーが出っぱなし、あたりのサーバーをひいた場合は特に問題がない、みたいな感じの挙動になっていました。

Published At2006-07-07 00:00Updated At2006-07-07 00:00

日記
スケーラビリティとミニマムの負荷Edit

旧バージョンはDBのselectクエリーは分散できるものの、それ以外は分散がほとんど効かないような設計だった。今回はアプリケーションサーバーもDBサーバーも単純に追加できるような設計にしてみたんだけど、そういう設計だとミニマムでの負荷はどうやってもある程度ベタに書いた設計よりも高くなってしまうなー。

すでに現段階で結構な手数を高速化(大量に呼び出されるurlForをベタに書き直したり、エスケープ処理の呼び出しにかかるコストを下げたりとか、とか)に費やしているんだけど、それでも1台増やしたサーバーがぱんぱんだ。DB負荷対策のためにメモリを増やしておいたんだけど、ロジックに費やすCPUパワーの方が先に頭打ちになってしまった。

商売でやってるんだったら、素直にサーバーを増やせばいいんだろうけど、個人でやっていると金だけじゃなく運用にかかる人的コストもばかにならない(俺は開発にかけるコストは趣味だから気にならないけど、運用は趣味じゃないから、その分のコストが増えるとうんざりしてくる)から、サーバーを増やす敷居が高い。

というわけで、単純にサーバーを追加するだけでスケールするような設計は、商売でやるにはいいんだろうけど、個人では実はあまり使えず、それよりも小技で高速化しやすいような設計(キャッシュをメソッド単位できめ細かくかましたり、フレームワーク依存のロジックを高速バージョンに差し替えやすかったり)の方がメリットが大きいかもなー。ひとまずメモリはまだ余っているんで、CPUパワーをメモリ使用量とトレードするような高速化を補助する仕組みをいろいろ追加していこう。っつーのはまあ、一般的には大して需要が大きくはないだろうけど。

Published At2006-07-10 00:00Updated At2006-07-10 00:00