2025/3 | ||||||
---|---|---|---|---|---|---|
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 | 29 |
30 | 31 | |||||
2025/4 | ||||||
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
a person powered by ototoy blog
モヘンジョだろ!!コンピといえども後半の方が盛り上がるアルバムは珍しいんではないだろうか。どこか癖のある、心にひっかかるトラックが続き、Kitsuneコンピ10ではトラック1で俺の心を鷲掴みにしたCascadeurがトリを務める。完成度高し。トラック8『Behold』のブリブリ感は特にお薦め。
テストテスト(すみませんこんなエントリで)
知らないうちにblogの独自テーマが無効になっていて悲しい
twitterでのつぶやきが曲やアルバムページに反映されるようになりました。曲やアルバムページから「twitterでつぶやく」リンクをたどってつぶやいてみましょう。
ototoyではautechreの音源について内部で一悶着。大切なことなので書けるようになったら書きます。
ところでtheatre brookのライブ音源、素晴らしいです。バンドの喜びとしか表現できない何かが会場の盛り上がりと一体になって混じりあう瞬間が聴こえてくる気がします。
しかし予約→販売のスクリプトでイージーミスを含むスクリプトがあり、0時すぎからしばらく予約済みの方にもう一回決済選択ボタンを表示してしまう不具合がありました。ダブって課金はされていませんのでご安心ください。すみませんでした。精進を続けます。
PostgreSQLのエンジニアっぽい話です。俺的標準ではpg_logの下で1500ms以上かかったSQL分を時刻とかかかったduratioinとかと一緒にログに残すようにしてある。それをSQL文だけ取り出して、ページによって異なるID(数字)を全部Xに変えて(例えば654321はXXXXXXに)、その後パイプでsortしてuniq -cしてsortすると、あら不思議。時間のかかったSQL文がそのログを残した順にいい具合でグルーピングされて出力される。あとは一番数の多いやつからインデクス戦略を考え直したり、オプティマイザがアホなところをわざと分割したり、など、低コストなSQLにしていく。
しかし今日そういうことをやりかけたサービス(まあ、コソアンなのだがw)、は手強かった。いくらやっても次から次に重いクエリがドバーっと続く。いままでどんだけ重かったんだよ。まあ、4万の問いとその数百倍の回答と百万近いレスがあるんだもんなぁ。
今日のところは負荷耐性は上がったが、重くなる症状はユーザーから見ると改善とはほど遠いレベルにとどまった。重い時のロードアベレージは40くらいのまま。ちょっと悔しいけど、ぼちぼちやろうかと。