UIEngine だ

[postgresql]d945gclfのpgbenchやり直し

　d945gclfのものを取り直したわけではないが、前回scaling factorが間違っていたのでやり直しを含めて再度投稿。

d945gclf:postgresql8.3

メモリ:2GB 533MHzで動作
CPU:Atom230
HDD:250G 7200rpm Hitachi（STATA II）

-bash-3.2$ ./pgbench -c 50 -t 100 pgbench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 60
number of clients: 50
number of transactions per client: 100
number of transactions actually processed: 5000/5000
tps = 170.997866 (including connections establishing)
tps = 172.326453 (excluding connections establishing)

Dell PowerEdge sc440:postgresql8.3

CPU:Intel(R) Pentium(R) Dual  CPU  E2180  @ 2.00GHz
メモリ:3,114,508 kB（つまり3Gぐらい）
HDD:SATAII(7,200回転だったかな？)

$ pgbench -c 50 -t 100 pgbench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 60
number of clients: 50
number of transactions per client: 100
number of transactions actually processed: 5000/5000
tps = 227.489773 (including connections establishing)
tps = 228.651036 (excluding connections establishing)

Dell PowerEdge sc440:postgresql8.1

$ pgbench -c 50 -t 100 pgbench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 60
number of clients: 50
number of transactions per client: 100
number of transactions actually processed: 5000/5000
tps = 165.544441 (including connections establishing)
tps = 166.139285 (excluding connections establishing)
※他のサービスtomcat等も動いているのであくまで参考データとして。

[postgresql]IntelAtom搭載マザーD945gclf は使えるのか？サーバーとして。

　省エネ。世の中は省エネ。ということで、先月？発売されたIntelAtom搭載マザーボードD945gclfはサーバーとして使えるのかどうかやってみた。というか、やってみている。細かいハードウェアの話はその他のレポートにまかせるとして、とりあえずpostgresを載せてみる。

postgresqlのインストール - ももーい鯖覚書
↑参照で

ちなみに、D945gclfにcentosを入れたのだが、ネットワークカードを認識しないので、その辺は手動で入れる必要がある。先人が解説しているので簡単である。久しぶりにmountというコマンドを使った。

　さて、とりあえず、configureからmakeなのだが、makeが遅い。うーむ非力だからか。。。あるいは気のせいか。

　ちなみにこのマザーボード、メモリスロットは1本で、最大2GBである。tomcat入れて動かすには若干不安が。ネットワークも10/100Mbpsゆえいまいち頼りない。そこがネックにならないものを動かせば良いのだが。すでに２台目を手配しているので真面目に考えないといけない。

　省エネではあるが、CPU含めたマザーからの熱よりも、HDDの熱が気になる感じ。最初にケースファンが動いておらず2時間程使っていたらケースがかなり熱くなっていた。どのケースを採用するのかにもよるのだろうが、密集して使うのには向かないかもしれないなぁ。

メモリ:2GB 533MHzで動作
CPU:Atom230
HDD:250G 7200rpm Hitachi（STATA II）

といった具合。クライアント50、スケーリングファクタを60で実験。以前「scaling factor > number of clients にしないと妥当な結果になりませんよ。」という指摘を頂いていたので感謝。

-bash-3.2$ ./pgbench -c 50 -t 100 pgbench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 60
number of clients: 50
number of transactions per client: 100
number of transactions actually processed: 5000/5000
tps = 170.997866 (including connections establishing)
tps = 172.326453 (excluding connections establishing)

以前のエントリーで使ったマシンで再度調査

CPU:Intel(R) Pentium(R) Dual  CPU  E2180  @ 2.00GHz
メモリ:3,114,508 kB（つまり3Gぐらい）
HDD:SATAII(7,200回転だったかな？)

$ pgbench -c 50 -t 100 pgbench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 60
number of clients: 50
number of transactions per client: 100
number of transactions actually processed: 5000/5000
tps = 227.489773 (including connections establishing)
tps = 228.651036 (excluding connections establishing)

といった具合。以前のデータと全然違いますな。以前のデータが全く使えないということでした。ちなみに、省エネということでノート用のCPUを搭載したものも準備中。来週ぐらいには結果をお知らせできるか。

　来年にかけて電気代も値上げされるだろうし、今から省エネに取り組まないと電気代もしゃれにならないぞと。データセンターの電源容量の制約の話もあるのだが。

[追記] 8.1.11でもテスト。こちらはtomcat等、他のプロセスが動いているので低めに出るのだが、予想通り。

$ pgbench -c 50 -t 100 pgbench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 50
number of clients: 50
number of transactions per client: 100
number of transactions actually processed: 5000/5000
tps = 158.763570 (including connections establishing)
tps = 159.305423 (excluding connections establishing)

あれ？scaling factor: 50になってる。60にしなければ、、、やり直そう。

社長曰く「何でもオープンにすればいいってもんじゃぁない。」、、、「いえ、公開します。」、、、「・・・」

　「技術者じゃなけりゃひとじゃない、、、」なんて刺激的な言葉が聞かれる今日この頃。社長も大変である。

　この言葉は「技術者こそが社の命運を握る」と信じて疑わない、とある社長の言葉だが、最近困ったことも起きるとのこと。技術者にまかせすぎて、何でもオープンにしちゃうらしい。Googleのまねをしているのかどうか知らないが、会社のビジネスを発展させる領域のみオープンにすべきで、大切な部分は隠しておかなければならないのに、全部公開するそうな。まかせているだけに、止めずに放置しているらしいが。

　さて、こんな作り話のような本当の話は置いておいて、Googleにしろ、Microsoftにしろ、オープンにしている部分はかなり戦略的であって、「ちょっと、そこを見せてほしいのだけど」というところは見せてくれない。

　うーん、何を書こうとしていたのか、わからなくなったので、とりあえず書くのを止める。続きはいつかくか不明。

[postgresql][pgbench]ベンチマークpostgresql8.3

　postgresql8.3.3をベンチマーク。この手の作業は好きでは無いので、「まぁ、結構速くなったじゃん・・・」と思えばそれでOKにしておく。サーバーを次々調達できるわけでもないので、そのあたりは臨機応変に。3月ぐらいに購入したDELLのPowerEdge SC440（？）を使用する。サーバーのハードウェアはこんな感じ。

CPU:Intel(R) Pentium(R) Dual  CPU  E2180  @ 2.00GHz
メモリ:3,114,508 kB（つまり3Gぐらい）
HDD:SATAII(7,200回転だったかな？)

で、結果は以下の感じ。比較対照として8.1.11をやろうとしたが、いろいろ面倒になったのでやめる。一応、稼働中（笑）のサーバーで走らせてみる。稼働中のサーバーはapache+tomcatが走っているので全く同じ環境というわけではない。参考にならないのだが、一応やったのでメモとして。これだけ差が出てしまうと、ますますこのデータだけでは参考にならない。とほほ。

[追記]コメント欄の指摘で↓のデータはあてにならないことが判明。使う前にちゃんと調べなさいということか。再度ベンチマークした結果は↓で。8.1.11は調査していないのだが、、、

UIEngine だ: [postgresql]D945gclf は使えるのか？サーバーとして。

★8.3.3の1回目

$ pgbench -c 50 -t 100 pgbench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
number of clients: 50
number of transactions per client: 100
number of transactions actually processed: 5000/5000
tps = 873.567219 (including connections establishing)
tps = 890.649287 (excluding connections establishing)

★8.3.3の2回目
$ pgbench -c 50 -t 100 pgbench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
number of clients: 50
number of transactions per client: 100
number of transactions actually processed: 5000/5000
tps = 858.366446 (including connections establishing)
tps = 874.924013 (excluding connections establishing)

▼8.1.11の1回目
$ pgbench -c 50 -t 100 pgbench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
number of clients: 50
number of transactions per client: 100
number of transactions actually processed: 5000/5000
tps = 360.870573 (including connections establishing)
tps = 363.802999 (excluding connections establishing)

▼8.1.11の2回目
$ pgbench -c 50 -t 100 pgbench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
number of clients: 50
number of transactions per client: 100
number of transactions actually processed: 5000/5000
tps = 441.239788 (including connections establishing)
tps = 445.593124 (excluding connections establishing)

---おまけ

postgresql8.3.3のインストールは以下を参考に。

postgresqlのインストール - ももーい鯖覚書

PostgreSQL導入から接続まで（1/3） － ＠IT

スティーブ・ジョブズ化する中島氏（Life is beautiful）。かくしてエンジニアはビジョナリストとなるのか、、なぁ？

Life is beautiful: 「iPhone開発者支援プログラム」に興味がある人、この指とまれ
http://satoshi.blogs.com/life/2008/06/iphone-2.html

↑のエントリーを見て『「UIEngine開発者支援プログラム」に興味がある人、この指とまれ』ではないことに「あれ、どうしてだろう？」と考えてみる。UIEngine>>>iPhoneを否定するということ？って、そもそもビジネスとしてもセグメントが違いすぎるか。比べちゃいけない、比べちゃいけない。

　最終的には「UIEngineではアプリの市場を作り出せないこと」なのかなぁと思いつつ、ただのコンテストじゃなくて、あくまで支援であって、決着は市場で決まるというところが楽しそう。

　あるいは、中島氏が今回のアップル主催（？）のコンテストでよっぽどはまり、「俺がこれだけ楽しいのだから、他のみんなも楽しくなれるはずだぁ」と考えてのことかもしれないが。そう、つまりは趣味。

　このタイミングでこのような支援プログラムに参加してくるのは、

・世間のことは何も知らないけど優秀な若者

か

・山師みたいな結構優秀な熟練者

の気がする。どちらが集まっても結構面白そうだ。集まった人で会社を起こして「えいえいおー」というのもありかも。支援してもらえるのはお金だったりマーケティングだったりするみたいだが、マーケティングの面倒を見てもらえるのは結構ありがたいかもしれないね。スティーブに嫌われた携帯Flashに舵をきってる私はちょっと参加できないかなぁ？と思いつつ、でもやっぱり、Macを買っておこうか？と思ってしまうところに不思議な魅力があるのだ。iPhone恐るべし。

　先日のFlashを買った勢いでMacも買おうか？と思ったが、何を買ったら良いかわからない。MacAIRだっけ？AIRMacだっけ？出たころは結構批判があったけど、それにしようかなぁ。とりあえず、しばらく悩む。AmazonではMacのノートは買えないのかなぁ。。。

Flash Liteは避けては通れない。技術的なことは無視してユーザー数にこそ注目。

　docomoの906が出るとか何とかで携帯ショップも騒がしい。もうD906iが出ないので次の携帯を何にするのか迷っております。良いタイミングなのでsoftbankにしてiPhoneにしようかな。あと数週間で出るとは、意外に早いものである。日本語入力がどれだけ洗練されているのか？それだけ知りたい。

　今の携帯、それもほとんど（適当だな。確か90%を超えていたと思うのだが。）でFlashが動く。正確にはFlash Liteなのだが。UIEngineから鞍替えを宣言するわけではないが、UIEngineでサービス側として素敵なインタフェースを実装しても、どうしてもキャリアの壁を突破できないのが悔しいところである。そこで、Flash Liteで作ることにした。幸いUIEngineと違い、Flash Liteはファイルフォーマットの仕様が公開されている。楽である。仕様書には嘘も多いらしいが、とりあえずあるのとないのとでは大きな違い。

　コンパイルして、バイナリエディタで開いて、diffして云々とかやらなくて良いし。とはいっても、そもそもバイトコードの仕様なんてVMが読みやすいように最適化されているはず（あくまで、「はず」ね）なので、想像で何とかなることも多い。けど、仕様書があるのは電車の中で読めたり、散歩中に読めたりするという点で大きな違いがある。

　携帯も通信速度は速くなるし、パケット通信料も相対的に下がっていくしかない。そうなるとリッチコンテンツの出番が増す。その辺はPCと同じなのだろう。今やPCはデスクトップが死んだみたいに言われていて、サーバー側の実装と「おもてなし」の組み合わせによる競争になっていると見ると、携帯がどうなっていくのかは興味深い。

　リッチクライアント用のプラットフォームで覇権を取ろうと、AIRとかSilverlightとか頑張っているが、とりあえずMicrosoftが覇権をとることは無いので無視して（OSやらオフィスやらが売れないと会社として儲からないが、Silverlightが普及してMSが儲かるスキームを組めるとは思えない。）いこう。「Javascriptがブラウザで動くもの」という制約がなくなってくると面白いのだけど、なんか最近は、ブラウザがブラウザとして意識する必要が無いぐらい、サービスがブラウザに乗っていてあたりまえになっているし、ブラウザOSでいいじゃんみたいな話になったとしてもユーザーが困らないぐらい、みんなブラウザに接している時間がとても長いと思う。

レンタルサーバーと自宅サーバー、電気代は結構高い

　部屋の中にあるサーバーが憎らしくなるぐらい暑くなってきた今日この頃。サーバーなんて古いノートパソコンでいいでしょ（Joel on softwareにも書いてあったし）と思っていたこともあったのだが、最近真面目にサーバーを起動し続けていて、まぁ、数台なんだが、電気代の明細を見てびっくり。5,000円/台といった感じ。

　こりゃぁ、レンタルサーバーを借りようか？と少々迷ったりそんなもやもやが続く。

　ウェブ上から情報をかき集めてきて、構文解析してDBに保存してなんてことを延々やっていたら、CPUもフル稼働であら素敵。ホームページを公開しているだけならそんなことにはならないのだろうが、そういうわけにもいかないようだし。結局レンタルサーバーに移行するのは見送っている。

　それにしても、最近レンタルサーバーが国内でもずいぶん安くなった。

チカッパ！レンタルサーバー：月額525円
http://chicappa.jp/

とか、

ロリポップ！レンタルサーバー - ナウでヤングなレンタルサーバー：月額263円
http://lolipop.jp/

まぁ、Googleもまだない頃から考えるとびっくりなわけです。はい。30MBでも大容量とか、そんなころだったのに。

とりあえず、消費税廃止に一票、、、

　[ぼやき]最近、わけあってEコマースのシステムをいじっているのだが（どんなわけ？）、もう、消費税は絶対に廃止して欲しい。商品毎の集計とか、領収書毎とか、内税・外税とか、切り上げ、切り捨て、四捨五入とか。さらに、そこから、割引だとか、返品業務とかからんでくると、どっと疲れる。どれだけテストに時間をかけろ？ということかい。後、税率の変更も考慮しないと。また上がるのかい？いつ？

　どんなにスマートに画面のデザインが決まっても、内部のロジックこそが重要。使えないUIでも仕方ないが、計算間違っていたらそれ以上に意味が無い。業務を考えない、システム設計をしたソースコードがあったりする点も手に負えないな。

　会計系のソフトが法外とも思える値段で売られている理由が、最近少し理解できた。

　そんなわけで、消費税を廃止して欲しい。それだけだ。世の中の販売管理ソフトウェアにかかる開発及びテスト工数が減る。無くなった消費税分をどこで吸収するのか？企業に売り上げに応じた○○税を徴収してくれ。税金の計算ロジックが単に会計系のソフトに移るだけなのだが、私の手元から離れるので、今はハッピーだ。

　そのうち、会計系のソフトをいじり始めたら、「もう、面倒な税金は全部やめて、国民の所得税だけとか、売上にかかる○○税だけにして欲しい。」と言い出すのだが。

　悲しいかな、このエントリーは何の解決策も示せない、ただのぼやきにすぎない。

　とはいっても、実はこの消費税関連の計算は、「オブジェクト指向でモジュール化、さらにDIで疎結合で素敵なコードができるよ！」と言うオブジェクト指向フェチにはたまらなく面白い課題に見えるのかもしれないが。心を切り替えて励む。

そろそろFlashを始めないと、という気もする。

TechCrunch Japanese アーカイブ » Adobeの「Open Screen」プロジェクト―FlashをPC、携帯、TVの事実上の標準に強力プッシュ

　最近私のまわりで、妙にFlashに関する話題が増えてきた。何だろうか？とはいっても、「私のまわり」も狭い世界なので一般的にそうなのかどうか。とりあえず、昨日あった会話。すれ違っている気もするが。

私「携帯Flashつくるのにソフトいるの？」

K氏「とりあえず、公開されているFlashのバイトコード仕様書を読んだら。」

私「なるほど」