a person powered by ototoy blog

モヘンジョだろ!!

2010年02月24日

良い音楽をきちんと届けること 

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時すぎからしばらく予約済みの方にもう一回決済選択ボタンを表示してしまう不具合がありました。ダブって課金はされていませんのでご安心ください。すみませんでした。精進を続けます。

| Posted By nt 投稿日: 2010年2月24日 5時52分 更新日: 2010年2月24日 5時52分

コメント

name:
comment:
【コメントに関する注意事項】
記事と全く関連性のないコメント(例：宣伝目的のコメントスパムなど)は、オーナーの判断により削除される場合があります。 - レコミュニ会員としてコメントする

トラックバック

SQLチューニングのノウハウ 

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

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

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

| Posted By nt 投稿日: 2010年2月24日 5時43分 更新日: 2010年2月24日 5時43分

コメント

name:
comment:
【コメントに関する注意事項】
記事と全く関連性のないコメント(例：宣伝目的のコメントスパムなど)は、オーナーの判断により削除される場合があります。 - レコミュニ会員としてコメントする

トラックバック