a person powered by ototoy blog

モヘンジョだろ!!

ototoyではautechreの音源について内部で一悶着。大切なことなので書けるようになったら書きます。

ところでtheatre brookのライブ音源、素晴らしいです。バンドの喜びとしか表現できない何かが会場の盛り上がりと一体になって混じりあう瞬間が聴こえてくる気がします。

https://ototoy.jp/opus/package.php/12250">https://ototoy.jp/imgs/jacket/01/22/26/0000012226.1268738078.jpg" style="border: 1px solid #ddd; margin:0 5px 5px 0;">

しかし予約→販売のスクリプトでイージーミスを含むスクリプトがあり、0時すぎからしばらく予約済みの方にもう一回決済選択ボタンを表示してしまう不具合がありました。ダブって課金はされていませんのでご安心ください。すみませんでした。精進を続けます。

PostgreSQLのエンジニアっぽい話です。俺的標準ではpg_logの下で1500ms以上かかったSQL分を時刻とかかかったduratioinとかと一緒にログに残すようにしてある。それをSQL文だけ取り出して、ページによって異なるID(数字)を全部Xに変えて(例えば654321はXXXXXXに)、その後パイプでsortしてuniq -cしてsortすると、あら不思議。時間のかかったSQL文がそのログを残した順にいい具合でグルーピングされて出力される。あとは一番数の多いやつからインデクス戦略を考え直したり、オプティマイザがアホなところをわざと分割したり、など、低コストなSQLにしていく。

しかし今日そういうことをやりかけたサービス(まあ、コソアンなのだがｗ)、は手強かった。いくらやっても次から次に重いクエリがドバーっと続く。いままでどんだけ重かったんだよ。まあ、4万の問いとその数百倍の回答と百万近いレスがあるんだもんなぁ。

今日のところは負荷耐性は上がったが、重くなる症状はユーザーから見ると改善とはほど遠いレベルにとどまった。重い時のロードアベレージは40くらいのまま。ちょっと悔しいけど、ぼちぼちやろうかと。

火曜日が終わったタイミングで書くのもなんだが、日曜日は一日中10回目のデジスタアウォードの収録だった。キュレーターの仲間うちではいつのまにか「法事ｗ」と位置づけられ(中島信也さんが言い出したっぽい)、長い拘束時間で疲れはするものの、他のキュレーターやスタッフの皆さんに会える年に一度のイベントで例年楽しみにしている。僕は今回のアウォードはゲスト扱いを加えると8回目の参加で、最初の頃に比べると、Nomineeの方々の映像作品はインターネット環境の影響をモロに受けているし、インタラクション部門もコンピュータパワーの増加とそれがネットに繋がることを当然に使っているものが多く、感慨深い。

そんな中で自分は「接続された」状態を早くから享受し、それを前提としたモノ作りができる環境に居たにも関わらず、DBとWebでウェブサービスを作る以外のことがあまり出来ていない。特に最近はiPhoneに代表されるモバイルデバイスでアプリケーション開発をすることが経済的メリットはともかく、作品としての開発を取り戻すチャンスなのに、事実上それをやる時間がない。デジスタに出品される作品、特にセレクションになるモノを見て、その背景や思想、努力を知るにつれ、その作品を鏡にして自分を省みて、うらやましかったり焦ったりする。

収録の内容は、放映を見てもらえばどんなだったかは大体分かるし事前にネタバレしてもしょうがないので割愛するけど、今回のアウォードはデジスタという番組にとって大きな変わり目になる。地デジへの変更や金融危機、日本の不況、ネットの普及、TwitterやUSTなど新しいアプリの台頭によるコミュニケーションインフラの変化などが一気に押し寄せて来て、本当に僕たちはスイッチが切り替わる瞬間を見る事ができるんだな、なんてことを、キュレーターという立場で作品を講評する機会があるおかげでシーン全体を俯瞰する努力をしながら感じることが出来る。これは普段の自分には無い視点だからとても貴重だ。

「インターネット」が誕生して15年強、ようやく条件と部品が揃ったのかもしれない。とんでもないものが産まれるかもしれない。これからデジスタがどんなふうになるかほんとに知らないけど、そういう、僕の知らないモノスゴイ現場を教えてくれるような場であってほしい。

...とちょっと感傷的な感じで書いてみました。

dolipoなどのネット高速化ユーティリティやDownThemAll!などのブラウザプラグイン形式のダウンロードユーティリティが、高速化の為に使っているのはHTTPリクエストで大きなファイルを分割するように指示し、大きなファイルを待っている間、他のメディアファイル(画像やSWFなど)が転送できない問題を解決するという手法のようだ。

このようなテクニックはRANGEヘッダやIF-RANGEヘッダで実現するのだが、ototoyの場合ダウンロードファイルは動的に生成し、用が済んだら削除するため、リクエストがRANGEごとに分かれて多重に来たとしても応えることが難しい。不可能とは言えないが、完全にユーザーにファイルが渡ったか判断するのはかなり困難だ。

そこで、今日ふとRANGE付きのリクエストに全部403 Forbiddenレスポンスを返してみたらどうなるだろうということを思いついて早速開発環境で実験してみた。つまり、403でユーティリティ側が「あ、ダメなんだね」って気がついて、改めてファイルの全レンジを普通にダウンロードし直すだろうという仮説と期待に基づいて、拒否ってみたわけだ。

サーバログを見ながらDownThemAll!で試してみたが、結果、ダウンロードは完走せずNGだった。ログを見てると、やはりRANGEヘッダでの多重リクエストが検出され、そこで意図通りスクリプトは403を返しているのだが。

403の定義を読んでみると、リクエストに対応できない場合も返していいようなことが書いてあったので、ユーティリティ側で403が返って来た場合の処理を適切に書けば問題は解決するはずなのだが。

というわけで、手抜きの割には良いKludgeだと思ったのだがあえなく挫折。手間をかけてRANGE対応するしかないような雰囲気だ。

というわけで、よし、そろそろブログもちゃんと更新するぞ。と思っている。