Ronacherがまた新しいプロダクトを公開した。スタティックファイルを使ったCMSみたい。WritingsWordPressとかDjangoといったデータベースから動的にコンテンツを生成するシステムの複雑さが嫌になったって。他にもいろいろスタティックファイルを使ったCMSからはあるけど結局気に入らなくて自分で作ってしまったということらしい。実は常々スタティックファイルの方がいいなあと思っているサイトがある。この人の作ったものは品質が高いしスタイルも好きだから、年が明けたら使ってみたい。使ってみたらまた感想を書いとこう。年が明けてちょっと暇な時間にドキュメントを読んでみた。いやあ、簡単に使ってみようって具合にはなかなかいかないぞ。Jinja2は使ってるし、Flaskっぽい考え方がそこここにあって馴染みある感じなんだけど学ぶことのボリュームがかなりある。やればいい感じでライフサイクルを管理できそうなのはよくわかった。Techstrftimeの%aで曜日を出力するのはやめたlocaleを使ってみたりいろいろと試してみたけれど、無理にstrftimeの%aで曜日を漢字で出力するのは今ひとつだった。ディストリビューションによって挙動が変わったり、OSのメジャーアップデートで文字化けしてみたり。それぞれに事情はいろいろあって、単にバグだったり、必要なパッケージが変わってたりと、まあ仕方ないかなあと思うことも少なくない。ああでもないこうでもないと、忘れてしまっても問題ない方法を考えてみた。TipsさくらのVPSのローカルネットワーク接続まとめさくらのVPSを5台借りてあれこれ負荷をかけてテストしてみている。実際にテストできるようになるまではいろいろあったけれど。ローカルネットワークは1Gbのベストエフォートがなかなかよい感じに速いと思います。チェックしてないので数字は出しませんが。VPNだとかトンネリングだとかいろいろ工夫して複数台構成をさくらのVPSのグローバルネットワーク上に構築しているならば移る価値ありだと思います。3台あればいろいろ試すこともできるし6千円弱/月の価値はあるかと。うちは某VPSを2台解約することにさっき決めました。本登録したし今後も使いますけれど、お試し期間中はローカルネットワーク接続が使えないというのはなんだかなあとは思いました。複数同時に申し込むとしたらそれが一番お試ししたいことのはずなのに。そうそう、複数台の申し込みが面倒くさいのもなんとかならないもんでしょうか。いえばらしいのですが。注意するべき点がひとつ。ある質問:さくらのVPSで回線速度が遅くアクセスに時間がかかります。さくらのVPSにおいて、不特定のVPS収容ホストとクライアント環境(プロバイダ等)の組み合わせにより、さくらのVPSからのダウンロード方向の通信に遅延が発生する場合があります。・http,ftp,scp等でのファイルのダウンロード速度が極端に遅い。・ファイルをダウンロード中に通信が切断される。・ホームページの静的なコンテンツ表示に異常に時間がかかる。上記のような現象が確認された場合、設定変更を行うことで回避できる場合があります。このQAとは現象は違うけれど、ローカルネットワーク経由の通信で1406bytes以上のデータをやりとりできない問題が起きる場合がある。tsoをoffにする設定が入っているからこの問題は起きない。tsoを切らないと問題が起きる場合がある=切る必要がある。いう場合にこの設定が必要かは明らかにされないので、さくらのVPSを借りてローカルネットワーク接続を使う場合は必須の設定ということになるでしょう。問題起きたら設定でもいいんだろうけど僕はもう自動的に全部設定すると思う。ちなみにUbuntu12.04ではこんな感じで設定しました。関係あるかもしれない注意点。デフォルトでインストールされるCentOS6であれこれ試行錯誤していたときに、eth1とeth2のインターフェース設定の中でMACアドレスを指定しないと、OS起動時にインターフェースが見えなくて使用できない仮想マシンがありました。tsoを明示的に切る必要のある仮想マシンだったのかどうかはもう覚えていないのです。メモも見当たらないのです。UbuntuにしてからはOSがNICを見つけられない状況は起きていないし、今後CentOSを使うつもりはないので確かめることもないのです。さくらインターネットこのニュースにのって、今月1日にさくらのVPSのローカルネット対応等を期待して2Gを5台追加。試しに使ってみて、負荷をかけてみて今の本番環境と比較してみるのだ。張り切ってみたのだけど、二日間ぐらいはカスタムOSのインストールがスムーズにいかない。こんなにカスタムOSのインストールに手間と時間がかかるのでは本末転倒なので、デフォルトのCentOS6で使ってみるかと試してみるも、こっちはこっちで慣れていなくて基本的な環境整備にひどく時間を取られる。はあ、もういやだ、とUbuntuのカスタムOSインストールをもう一度ためしてみると、数日前とはエライ違い。混み合っていたせいなのか、何か不具合が治ったのかはわからない。Ubuntuなら慣れてるし助かる。5台分のOSを設定して、データベース・サーバとして2台、アプリケーションサーバを2台、リバースプロキシサーバを1台の構成を試す。MySQLがおかしい。1台だけどうしてもおかしい。mysqlクライアントでローカルネットワーク経由でデータベースサーバに接続して、SELECTするとハングアップしてしまう。試すと、だいたいパターンが見えてきた。以下、ハングアップは、ローカルネットワーク接続の時にだけ起きる。グローバルネットワーク経由だと起きない。データ量として1kbぐらい(勘です)に閾値がある感じ。LIMITで件数を制限するとあるデータ量まではSELECTできるから。接続先データベースサーバではなく、接続するクライアントマシン側の問題。接続先データベースサーバを変えても発生する場合も発生しない場合も状況は変化しない。同じ構成のマシンで起きるマシンと起きないマシンがある(どうも収容ホストが違う気がする)。ローカルネットワークの割り当てを削除して再割当てしたりしてみたけど状況に変化ない。CentOS6で試したときにも起きていた。Ubuntuにしてからも起きている。条件は(たぶん)同じ。(CentOSのときはちゃんと調べなかった)この件については、いろいろと検索してみたけれど、似たような状況は見当たらないし、サポートに問い合わせてみることにした。アプリケーションの話でしょ、と言われると弱いんだけどMySQLなんだからなんとか聞いてもらえないかなあ。ホントは他のアプリケーションでも現象を確認できるといいんだけど。追記どうもその後の調査で特定の1台(a1とする)からのみハングアップするらしいことがわかった。a1,a2,b1,b2の4台の仮想マシンがある。b1とb2にMySQLサーバがインストールされている。a1,a2にはMySQLクライアントがインストール済み。この時、a1からb1、a1からb2のデータベースへローカル接続した時のみハングアップの問題が起きる。b1からb2、b2からb1、a2からb1、a2からb2では問題は発生しない。a1の生成時に何かあったんじゃないかと考えてしまう。追記その2mysqlだけじゃなあ、と思い立ってscpで何かコピーしてみよう。おおっ、stalled。ファイルサイズを変えながらコピーしてみると、1405bytesまではコピーできる。Exchangeピタリ。