＊「ふっかつのじゅもんがちがいます。」 – ブログ引越しを計画中ブログエンジンは「管理ページと表示ページのドメインを分ける」設計が正しかったのだということがよく分かった。
Widget（ブログパーツ）は素晴らしいと思うので、今後サービス作る時にはこれは是非考慮したい。
shag の日記 – inetd 経由で起動されても peeraddr は取得可能の意味がよくわからない。HTTP/1.1 のバーチャルホストって、
GET /index.html HTTP/1.1 Host: example.com
の Host: example.com をみて挙動を切り換えるだけなので TCP/IP 関係ないですよね。というか inetd 経由で起動されたプログラムも peeraddr わかりますよね。
なんだっ（略。 バーチャルホストへの親しみUP。
masatobito 『ご指摘ありがとうございます 単に僕が知らなかっただけです inetd経由だとIPアドレスが取得できないと勝手に思い込んでましたが、よく考えれば標準入出力のファイルディスクリプタになってれば取得できますね』masatobito 『意味不明 ”標準入出力のファイルディスクリプタがソケットになってれば”』
なるほど、inetd経由だとSOCKETなんですな。 こんな簡単にかけるなら役に立つとこがありそうだなー。
最近パフォーマンス対策とかバグ修正とかして大分エラーメールが減ってきたんですが、全然なくならないのがこれ。
Lost connection to MySQL server during querymax_allowed_packetが足りないと出る場合があるとあったので倍に増やしてみても効果無し。なんだろなー。
 |
|
Webサービスの開発プロセス全体についてまんべんなく書いてありました。それぞれのトピックスに関してはもっと濃い本を参照する必要があるけどプログラマでも別ジャンルだった人がWebを始めるときに読んだらかなり助かるんじゃないかなーと思いました。
特に、「早過ぎる最適化は悪」っていうのはホントに同意。パフォーマンスに問題が出たからつって、真っ先に、カーネルチューニングとかテーブル分割とかRAMディスクとか言い出すのは暇人か金持ち。（言い過ぎ）
 |
|
MySQLモデリングについてマルチカラムインデックスをちゃんと勉強しないといけないなあとおもったので（前に持ってたにもかかわらず）実践ハイパフォーマンスMySQLを注文しました。
1人（MAX３人）でWebサービスを作ることに焦点を合わせて考えると、パフォーマンスに関してもかなり効率的に（手っ取り早く）対処しないといけない。小～中規模Webアプリのボトルネックは圧倒的にDB、それもSQLとインデックスにかかってる気がする！（91%ぐらいの割合で）
それなのに、MySQLだとあんまり勘が利かないんですよね。ポスグレだと、EXPLAINの結果もインデックスの作用も大体予想通りだし、遅い部分があっても、「そうなるわな」って感じなのにMySQLだと「え？そこが？」みたいな。
別にポスグレで独自の難しい機能を使ってるとかじゃなくて、MySQLでは単に「１テーブル１インデックス問題」のせいじゃないんかと。もし勉強してみてマ（略）スをうまく使えば対応可能だったら安心だけど、そうじゃなかったら（非正規化が必要ということだったら）ポスグレ移行も考えたい。
Debian—Debian “etch” Release InformationDebian GNU/Linux 4.0 (a.k.a. etch) was released April 8th, 2007. The release included many major changes, described in our press release and the Release Notes.
To obtain and install Debian GNU/Linux 4.0, see the installation information page and the Installation Guide. To upgrade from an older Debian release, see the instructions in the Release Notes.
Debin etchが昨日リリースされたみたいです。
FirefoxがIceWeaselになったりThundrbirdがIceDoveになったりしてますが、この間デスクトップ環境を入れてみた感じはUbuntuじゃなくてもいいかもと思えるぐらい良さそうでした。
サーバー環境に関しては慣れの問題だとは思いますが、もう体が溶けるほど使い易しぃ・・・。ノンストレスです。依存症です。
それとDebian JP Projectのページが何か綺麗になっとる。Software Designに寄稿された武藤さんのインストールドキュメントなんかもあって非常に分かり易い。素晴らしい仕事！
最近衝撃を受けた小さいこと。
Photoshopとかのこういうシリアル入れる欄。
1034-2321-4323-6518-6985-8733これはこういうテキストをペーストすると一気に全部入る！！！
eringi blog: Pear/Net_Url_Mapper今はたいていのフレームワークにURLをルーティングする機能が備わってるけど、その機能だけを抜き出したようなパッケージ。 やっつけで作ったオレオレフレームワークに組み込んだり、いまいち使い方が分からないEthnaのステキURLを代替できそう。
おお、Railsみたいに書けちゃうのかよ。
おれのもはや見たくもない大量のrewrite ruleゴッソリ減りそう。
p0t: １テーブル１インデックスオライリーの「実践ハイパフォーマンスMySQL」には
「MySQLでは、1つのクエリを実行する時、１つのテーブルにつき１つのインデックスしか使用できない」
と書いてあります。同じような内容を公式リファレンスマニュアルからは見つけられなかったんですが、実際に試して見る限りそのようです。他のRDBの感覚で言うと１テーブル１インデックスしか使われないのでは現実的な速度が出ない気がします。
この問題について。
何人かの人に聞いて回ったりしてるんですが、はっきりしたことはわかってません。
現状の俺の結論としてはこんな感じです。
- MySQLモデリングは実在する！（他のDBより非正規化を早い段階で行う）
- データモデリング手法の中には（この問題のせいで）MySQLでは機能しないものもある。
- MySQLでは非正規化でパフォーマンスを上げる。
眠たいことを言ってもしょうがないので断言気味です。
元々、通常のプログラミングとDBでは（インデックスのせいで）パフォーマンスの良い設計っていうのが感覚的に結構違う気がします。MySQLの非正規化は（DBAに対して）プログラマ側の考え方で、自分の慣れた理論にもってけるので特に文句が出てないんじゃないのかと思いました。
オンメモリのテーブルとか、レプリケーションとかレベル２のテーブル分割とか、それって、「1テーブル１インデックス問題」のせいでいろいろやらなきゃいけなくなってんじゃないの？とか怪しんでます。
関連エントリー：
