kumama go言語とかgolangとかGAEとかネットサービスとかその他色々・・・

28Feb/100

GAE::GoogleAppEngineLauncherのpythonパス

OSX SnowLeopardでGoogleAppEngineLauncher使うときはPythonを2.5系に設定し直すのは前に書いたけど、今日サブマシンの方で設定変えようとして何度入力しても設定反映のために再起動すると消えて居て反映されないという・・・。

ちょっと調べてみると
Issue 1 - google-appengine-mac-launcher - Python path has no apparent effect - Project Hosting on Google Code
に書いて有るとおり、Python2.5のパス入れた後にEnterキー押さないと忘れるらしい・・・。

しかもissue #1ってorz

Filed under: app engine No Comments
18Feb/102

HTML5とflashとIE6

正直、chromeでHTML5がサポートされつつ有るし、
websocketsすげーって思ってる自分としては、
何となくFlashが嫌いでHTML5頑張れー、
Adobe製品に負けないようなオーサリングソフト出てこいー、
って思ってたけど。

15Feb/100

GAEのdev_app_serverでURLFetchでのタイムアウト回避

GAEのproxy対応でOKなんだけど、
Proxyが遅くてタイムアウトする場合・・・

urlfetch_stub.py の _API_CALL_DEADLINE = 30.0 とかにする。

# Android2.1も試したいものの・・・

Filed under: app engine No Comments
4Feb/100

websocketsのpipeline

またもEmerge Technologyからのネタ。
この、websocket pipelineのサンプルが意味するところら辺の話。

# ちなみにHTML5のドラフト上、「websocket」ではなく「websockets」が正解・・・だったと思うw

websocketsの利用シーンとしては現状httpでは出来ないサーバ側からの通知とか、
非同期通信ばかりを思い浮かべていたけど、ajaxで出来る事もwebsockets化する!って
言うのはなんと言うか着眼点が面白いというかちょっと思いつかなかったなぁと言う感じ。

ただ、なんと言うか記事読んでいて思ったのは、
「websockets+pipelineが凄い!」っていう結論に成るような論旨展開に成っているんじゃない?!という事。

pipelineにするとシーケンシャルにしか処理できません。
例えば、1件処理するのに3秒かかるリクエストを3件行うとします。
3並列で実行すれば3秒、シーケンシャルに処理すれば3秒x3=9秒かかるのは当たり前です。
ただ、この話は3並列で処理を実行した場合のオーバーヘッドが0という前提が必要です。

それをふまえ、何故、「websocket+pipeline」のサンプルがajaxでの処理が遅いのか考えてみると、
サーバ側でリクエスト1件に対するオーバーヘッドが大きいからに他成りません。
mod_python使っていても、handlerがpublisherの場合のTPSはそんなに良くないはずです。
またサーバ側のCPUのスレッド数も分かりませんし、
apacheのpreforkがいくつに成っているのかも分かりません。

websockets版はスレッドとしてpython上でread/writeをループしているだけで、
pythonの初期化とかしてないので早くて当たり前ですね。

上記のような事を考察せずNWの遅延とかターンアラウンドの話ばかりを引き合いに出しているあたり、
微妙に突っ込まれる事も有るかも知れません。

その上WebSocketsの方はページを開いたときにコネクションを張ってしまっています。
なんと言うか、インフラとかapacheとかajaxに詳しくない人って印象を受けてしまうのは気のせいでしょうか。

穿って考えると、websocket+pipelineが早い、という事ではなく、
「自分のサーバとかJSだとwebsockets+pipelineの方が早いみたい。」
と、言う話で一般的にAjaxよりもwebsockets+pipelineが早いという話では無いような気がしてきます。

と、色々書きましたがやっぱりWebSocketsは現状httpでは出来ない事を実装するためのものと、
思った方が良いのかも。

http(s)なら今までの資産として、javascriptのライブラリも使えるし、
cookieとか認証とか文字コード変換とかjsonとかproxyでのキャッシュとか
今まで蓄積してきたモノが使えます。

websockets上で独自プロトコル作るのがデファクトとは思えず。

まー、apache + mod_pythonなんてケチな環境じゃなく、
golangで専用プロセス上げてればもうちょっと違う結果になったのかもw

Filed under: etc, golang No Comments