2011年10月13日木曜日

スマートフォンなどのタッチUIで気を付ける点

 最近スマートフォンのブラウザサイトを作ってて思うことを書いてみる。

1) マウスのように「点」ではなく、「面」でのクリックなので、「面」でクリックしても誤クリックにならないようにする。
具体的にはリンクやボタンは大きめに。大きくできないなら余白を広く。

2) マウスとタッチで「リンクをクリックして遷移していくストレス・コスト」が違う。マウスのほうが直接画面をタッチするわけではないので、カーソルの軌道修正などのコストがあり、一回のクリックのコスト・ストレスはタッチより高い。
なので、スマホ版は画面が小さいというデメリットを、「通信が発生しない高速の画面切り替え」で補うと良い。
具体的には、メニューなどはタッチさせて、JavaScriptで表示要素を動的に出す感じとか。

3) 片手(左手など)で操作で操作する場合、親指での操作になるとおもうが、リンク・ボタンの位置によっては押しにくいことを認識すること。左側の方が押しやすい。最近のfacebookのスマホ版で左上のロゴがきえて、メニューになったのもそのあたりかと。

2011年9月20日火曜日

OpenPNEの開発用メーリングリスト

そういえばOpenPNEのMLって入ってますかね?
わりと色々流れてるので、入っておくといいかも。
■入会
http://ml.pne.jp/mailman/listinfo/openpne-dev

■過去ログ
https://groups.google.com/group/openpne-dev?hl=ja&pli=1

OpenPNE3.7以降の方向性の案

OpenPNE3.7以降の方向性について書いてみます。

まず簡単にオープンソースなSNSエンジンの意味の確認から入ります。
ストールマンも言ってるようにFacebookやGoogleなどのプロプライエタリなソフトウェアにソーシャルグラフなどのデータを置くコンピューティングは、
最終的にエンドユーザに不自由を強いるはめになると思っています。(FacebookやGoogleがある日サービスをやめたら?ある日良くわからない理由で強制退会させられたら?)
なので、FLOSSなSNSのソフトウェアを用意し、個人もしくはコミュニティの意志でソーシャルグラフなどのデータを扱える状態にするのは価値があることだと思っています。

# ストールマンが言っているのは↓な感じのこと
# Richard M. Stallman曰く、「Gmailを使うのは愚かなことだ」 | スラッシュドット・ジャパン オープンソース
# http://opensource.slashdot.jp/story/08/10/02/037222/Richard-M.-Stallman%E6%9B%B0%E3%81%8F%E3%80%81%E3%80%8CGmail%E3%82%92%E4%BD%BF%E3%81%86%E3%81%AE%E3%81%AF%E6%84%9A%E3%81%8B%E3%81%AA%E3%81%93%E3%81%A8%E3%81%A0%E3%80%8D

全然たたき台なんで、フィードバックなど是非〜

■ユーザ体験の方向性
(1) 負荷性能の向上
  「昨今の経済状況」や「コンピュータリソースの増減でシビアに課金するクラウドサーバの台頭」を受け、
  より少ないコンピュータリソースで高いパフォーマンスを出すWebアプリが求められていると思います。
 
  具体的には、最低でもOpenPNE2.14より良い性能を出す事を基準とし、
  http://openpne-dev.blogspot.com/2011/09/mediawiki117wordpress321openpne23.html の条件で、
  * メモリ使用量は、現状の20MB -> 8MB程度まで減らす
  * 秒間PVは、現状の約21PV -> 50PV程度まで増やす
  事を実現するというのはどうでしょうか?

(2) スマホ対応
  「2010末頃からの急激なスマートフォンユーザの増加」を受け(東京都でスマホ率が40%ぐらいになったんでしたっけ?この辺のマーケティング資料出せる人いたら是非ください)、
   OpenPNE3がスマートフォンでも快適に操作できることが求められていると思います。

(3) 他SNSとのシームレスな連携
  「既存の巨大SNSでのソーシャルグラフを使ったSNSの増加」を受け、
  今までの独立したSNSで「新規登録・招待・認証・フレンドリンク」を行うSNSの他にも、
  FacebookやTwitterなどのソーシャルグラフをオープンにしているSNSのアカウントやソーシャルグラフAPIを使い、
  「新規登録・招待・認証・フレンドリンク」ができるSNSが求められていると思います。
 
  具体的には、
  http://mangafuldays.jp/
  http://liblar.com/
  http://shopal.jp/
  http://booklog.jp/
  のような感じです。
 
  ガチで新規にソーシャルグラフを構築していく感じじゃなくて、こういうのが最近多いですよね。

(4) タイムライン型への移行
  「Facebook、Twitter、Google+などのタイムライン型SNSの台頭」を受け、
   今までの「機能毎のタイムライン->リンク遷移してコメント」以外に、
  「トップページに全活動の一元的なタイムライン->その場でコメント&Good or Bad」というユーザ体験ができるSNSが求められていると思います。
 
■技術の方向性
(A) フレームワーク・O/Rマッパーのオーバーヘッドの最小化
  「ユーザ体験の方向性 (1)負荷性能の向上」の解決の為の施策です。

  負荷性能測定方法の策定と負荷性能基準値の策定をした上で、
  「Silex&PDO」とか「Symfony2&Propel2」とか模索し、負荷性能基準値を満たすようにするというのはどうでしょうか?

(B) 標準バンドルプラグインを減らす
  「ユーザ体験の方向性(1)(2)(3)(4)」全ての解決の為の施策です。

  現状のコア&標準バンドルプラグインを全てカバーしつつ開発を続けるのは非常にコストがかかるので、
  まずコア&数プラグインに絞った状態からはじめて、低コストでハイパフォーマンスな開発をするというのはどうでしょうか?

(C) 「テスト済み」な状態を維持する
  「ユーザ体験の方向性(1)(2)(3)(4)」全ての解決の為の施策です。
 
  SNSは機能と機能の連携が非常に多いソフトウェアだと思います。
  適切な自動テストが無い状態で機能追加・バグ修正を行うと、その影響で思いもしないバグが起きたりします。
  その修正に時間をとられたりすると、非常にコストがかかり開発資源を浪費します。
 
  具体的には、
  * 自動テストの基準を定めた上で自動テストを用意し、常に自動テストが通る状態を維持する
  * CI(継続的インテグレーション)をjenkinsとかでやる
  というのはどうでしょうか?

(D) 「脆弱性が無い事を確認済み」な状態を維持する
  「ユーザ体験の方向性(1)(2)(3)(4)」全ての解決の為の施策です。
 
  (C)とほぼ一緒なのですが、
  SNSはユーザのロールによって「閲覧できて良い情報」と「閲覧できては駄目な情報」が複雑に設定されており、
  適切な自動テストが無い状態で機能追加・バグ修正を行うと、その影響で思いもしない脆弱性が起きたりします。
  その修正に時間をとられたりすると、非常にコストがかかり開発資源を浪費します。
  
  具体的には、
  * 自動テストの基準を定めた上で自動テストを用意し、常に自動テストが通る状態を維持する
  * CI(継続的インテグレーション)をjenkinsとかでやる
  というのはどうでしょうか?
 

2011年9月15日木曜日

OpenPNEのスマートフォン対応にjQuery Mobileを使うべきか否か

はい!ギュンばんわ!

OpenPNEのスマートフォン対応にjQuery Mobileを使うべきか否かの検証中です。

とりあえずスマートフォン版でのマイホームをjQuery Mobileで作ろうとしてみたけど、
標準機能( http://jquerymobile.com/designs/#smartphone あたりね)だと、↓あたりの表現までが限界な気がした。

■デモ
http://smaho-hello.myzw2.pne.jp/jquery-mobile/

■ソース
https://github.com/rysk92/smaho_hello

これ以上はCSSやJavaScript変えたりしないとできないっぽいけど、僕の感覚的にはjQuery Mobile使わない方が効率いいんじゃないかなと思ってきました。。。
わりとjQuery Mobileの標準機能から外れようとするとコストかかりそうな予感。。。


それでjQuery Mobileでどの程度の表現までできるかを知りたくて調べてたのですが、
http://www.jqmgallery.com/
っていうjQuery Mobileを使ったサイトのリストを見つけました。

大体見てみましたが、ちょっとした静的なホームページにはいいけど、UIに凝るSNSのようなサイトには向いてないような気がしています。

なんか詳しい人の見解を聞きたいっす。

■jQuery Mobileを使うことのメリット・デメリット

メリット
* 手軽にリッチなUIが作れる(jQuery Mobileの標準UIなら)

デメリット
* jQueryMobileの脆弱性・バグ修正・バージョンアップに追従するコストが発生する
* 標準機能から外れる表現をするのが面倒そう

2011年9月7日水曜日

WordPress3.2.1とBuddyPress1.2.9とMediaWiki1.17とOpenPNE2.14.9とOpenPNE3beta13の負荷性能限界値を見てみる!の巻!

はい!ギュンばんわ!

OpenPNEと他のOSSプロダクトの負荷性能限界値の差を見てみようかなぁと。

検証するのは、

* OpenPNE 2.14.9
* OpenPNE 3.6beta13(coreのみ)
* OpenPNE 3.6beta13(標準バンドルプラグイン全部入)
* WordPress 3.2.1
* MediaWiki 1.17
* WordPress 3.2.1 & BuddyPress 1.2.9
* societo ( https://github.com/societo/societo Symfony2を使ったSNSエンジン)

の7つ。

今回のコンセプトは「ほぼインストールしたままのデータ量が最小の状態で測定する」です。
つまり基本的にこの状態より良い負荷性能は、同じソフトウェア・ハードウェアを使う限り期待できないわけです。

負荷検証の環境と手法は、


■環境
* サーバ(自作のコモデティなもの。Webx1/DBx1/負荷かける側x1。芭蕉1,2,3と命名。)
* OpenPNE 2.14.9( グラフなどでの識別名は、2.14.9_core_one )
  メンバーはデフォルトの1人 / LOG_C_ACCESS_LOGはfalse

* OpenPNE 3.6beta13( 3.6beta13_core_one )
  coreのみ / メンバーはデフォルトの1人

* OpenPNE 3.6beta13( 3.6beta13_default_one )
  標準バンドルプラグイン全部入 / メンバーはデフォルトの1人

* WordPress 3.2.1( WordPress_3.2.1 )
  普通にインストールしたまま

* MediaWiki 1.17( MediaWiki_1.17 )
  普通にインストールしたまま

* WordPress 3.21 & BuddyPress 1.2.9( WordPress_3.2.1_and_BuddyPress_1.2.9 )
  普通にインストールしたまま

* societo( societo )
  普通にインストールして、secure_defaultのAnonymous access を True

詳細(でもないけど)のセットアップ方法は、
https://github.com/rysk92/doc/tree/master/20110907_webapp_monitor_openpne/enviroment/software_install
に置いた。

■手法
15秒に5接続ずつアクセスを増やしていく。
sar -rでWebサーバ(芭蕉1)を監視し、スワップしはじめたら終了する。
ツールは拙作の↓を使った。config.pyを設定して、python reqsan_manager.py とかで実行な感じ。
https://github.com/rysk92/webapp_monitor/blob/master/reqsan_manager.py


reqsan_manager.pyの設定は、
https://github.com/rysk92/doc/blob/master/20110907_webapp_monitor_openpne/enviroment/webapp_monitor_reqsan_manager_config.py
な感じ。

日本語で書くと、

* OpenPNE 2.14.9( グラフなどでの識別名は、2.14.9_core_one )
  ログイン->マイホームアクセス(20回)を繰り返す

* OpenPNE 3.6beta13( 3.6beta13_core_one )
  ログイン->マイホームアクセス(20回)を繰り返す

* OpenPNE 3.6beta13( 3.6beta13_default_one )
  ログイン->マイホームアクセス(20回)を繰り返す
* WordPress 3.2.1( WordPress_3.2.1 )
  / にひたすらアクセス

* MediaWiki 1.17( MediaWiki_1.17 )
  /index.php/メインページ にひたすらアクセス

* WordPress 3.21 & BuddyPress 1.2.9( WordPress_3.2.1_and_BuddyPress_1.2.9 )
  / にひたすらアクセス

* societo( societo )
  / にひたすらアクセス
な感じ。


■結果

生pngは↓
https://github.com/rysk92/doc/blob/master/20110907_webapp_monitor_openpne/report.png

ピアレビュー用のもろもろの生データは、
https://github.com/rysk92/doc/tree/master/20110907_webapp_monitor_openpne
ツールは、
https://github.com/rysk92/webapp_monitor


■平均レスポンスタイム約5秒の時点
- OpenPNE 2.14.9( グラフなどでの識別名は、2.14.9_core_one )
-- PV:約3000PV/分
-- httpdの平均メモリ使用量:約8MB
  
- OpenPNE 3.6beta13( グラフなどでの識別名は、3.6beta13_core_one )
-- PV:約1300PV/分
-- httpdの平均メモリ使用量:約20MB

- OpenPNE 3.6beta13( グラフなどでの識別名は、3.6beta13_default_one )
-- PV:約550PV/分
-- httpdの平均メモリ使用量:約30MB

- WordPress 3.2.1( グラフなどでの識別名は、WordPress_3.2.1 )
-- PV:約6500PV/分
-- httpdの平均メモリ使用量:約9.5MB

- MediaWiki 1.17( グラフなどでの識別名は、MediaWiki_1.17 )
-- PV:約2000PV/分
-- httpdの平均メモリ使用量:約10MB

- WordPress 3.21 & BuddyPress 1.2.9( グラフなどでの識別名は、WordPress_3.2.1_and_BuddyPress_1.2.9 )
-- PV:約5000PV/分
-- httpdの平均メモリ使用量:約11MB

- societo( グラフなどでの識別名は、societo )
-- PV:約6000PV/分
-- httpdの平均メモリ使用量:約11MB

な感じ。

■まとめ
平均レスポンスタイム約5秒周辺での各ソフトウェアのザックリした対比は、下記のようになる。

【2.14.9_core_one vs 3.6beta13_core_one】
PV: 約3000PV/分 : 約1300PV/分 (2.14.9が約2倍こなせる)
httpdの平均メモリ使用量: 約8MB : 約20MB (2.14.9が約1/3)

【2.14.9_core_one vs 3.6beta13_default_one】
PV: 約3000PV/分 : 約550PV/分 (2.14.9が約5倍こなせる)
httpdの平均メモリ使用量: 約8MB : 約30MB (2.14.9が約1/4)

【WordPress 3.2.1 vs 3.6beta13_default_one】
PV: 約6500PV/分 : 約550PV/分 (WordPress 3.2.1が約11倍こなせる)
httpdの平均メモリ使用量: 約9.5MB : 約30MB (WordPress 3.2.1が約1/3)

【WordPress_3.2.1_and_BuddyPress_1.2.9 vs 3.6beta13_default_one】
PV: 約5000PV/分 : 約550PV/分 (WordPress_3.2.1_and_BuddyPress_1.2.9が約9倍こなせる)
httpdの平均メモリ使用量: 約11MB : 約30MB (WordPress_3.2.1_and_BuddyPress_1.2.9が約1/3)

【MediaWiki_1.17 vs 3.6beta13_default_one】
PV: 約2000PV/分 : 約550PV/分 (MediaWiki_1.17が約3.5倍こなせる)
httpdの平均メモリ使用量: 約10MB : 約30MB (MediaWiki_1.17が約1/3)

【societo vs 3.6beta13_default_one】
PV: 約6000PV/分 : 約550PV/分 (societoが約10倍こなせる)
httpdの平均メモリ使用量: 約11MB : 約30MB (societoが約1/3)

■次回
データとか入れてやっていきたいな。

2011年8月31日水曜日

OpenPNE2と3の負荷性能限界値を見てみる!の巻!

はい!ギュンばんわ!
あたしよ!

OpenPNE2と3の負荷性能限界値を見てみようかなぁと。

負荷検証の手法と環境的には、

■手法
15秒に5接続ずつアクセスを増やしていく。1接続は「ログイン->20回マイホームを呼ぶ」を繰り返す。
sar -rでWebサーバ(芭蕉1)を監視し、スワップしはじめたら終了する。
ツールは拙作の↓を使った。config.pyを設定して、python reqsan_manager.py とかで実行な感じ。
https://github.com/rysk92/webapp_monitor/blob/master/reqsan_manager.py

■環境
* サーバ(自作のコモデティなもの。Webx1/DBx1/負荷かける側x1。芭蕉1,2,3と命名。)
* OpenPNE3.6beta13(Doctrine版・コアだけ・メンバー数38万人)
* OpenPNE3.4.15(Doctrine版・コアだけ・メンバー数38万人)
* OpenPNE3.2.7.5(Doctrine版・コアだけ・メンバー数38万人)
* OpenPNE2.14.9(メンバー数38万人)

今までAPCが抜けてた(!!)ので、今回から入れてます。

で、結果は、

■結果

おっとBloggerって大解像度の画像はるとこうなるのか。。。
生pngは↓
https://github.com/rysk92/doc/raw/master/20110831_webapp_monitor_openpne/report.png

ピアレビュー用のもろもろの生データは、
https://github.com/rysk92/doc/tree/master/20110831_webapp_monitor_openpne
ツールは、
https://github.com/rysk92/webapp_monitor

使ったコモデティなハードも示してあるし、負荷性能検証のツールと結果の生データも示してあり、Webアプリのソフトウェア自体もFLOSSなので、ピアレビューできていいよね。

■考察
スワップが開始すると平均レスポンスタイムが跳ね上がり、ユーザ的にも使えないレベルになりますね。
仮に今回は平均レスポンス5秒以内がユーザが耐えられるサービス限界レベルとして考える(ホントは1秒以内位だと思うけど)。

■スワップ開始時点
- 2.14.9
-- PV:約3500PV/分(約58PV/秒)
-- 平均レスポンスタイム:約5秒
-- httpdのプロセス数:約4000
-- httpdの平均メモリ使用量:約7MB

- 3.2.7.5
-- PVは:約1100PV/分(約18PV/秒)
-- 平均レスポンスタイム:約15秒
-- httpdのプロセス数:約430
-- httpdの平均メモリ使用量:約18MB

- 3.4.15
割愛

- 3.6beta13
-- PV:約1400PV/分(約23PV/秒)
-- 平均レスポンスタイム:約13秒
-- httpdのプロセス数:約400
-- httpdの平均メモリ使用量:約22MB

■平均レスポンスタイム約5秒の時点
- 2.14.9
-- PV:約3500PV/分(約58PV/秒)
-- 全体のメモリ使用量:約90%(約7GB)
-- httpdのプロセス数:約1400
-- httpdの平均メモリ使用量:約7MB

- 3.2.7.5
-- PVは:約1100PV/分(約18PV/秒)
-- 全体のメモリ使用量:約40%(約3GB)
-- httpdのプロセス数:約180
-- httpdの平均メモリ使用量:約18MB

- 3.4.15
-- PV:約1100PV/分(約18PV/秒)
-- 全体のメモリ使用量:約40%(約3GB)
-- httpdのプロセス数:約200
-- httpdの平均メモリ使用量:約20MB

- 3.6beta13
-- PV:約1400PV/分(約23PV/秒)
-- 全体のメモリ使用量:約50%(約4GB)
-- httpdのプロセス数:約200
-- httpdの平均メモリ使用量:約22MB

な感じ。

■まとめ
芭蕉1のスペックだと3.6beta13の場合メモリよりCPUが先に限界がきている。
CPU(Intel Core 2 Quad Q8400S 2.66GHz)を据え置くならメモリは8GBじゃなくて4GBぐらいで良さそう。

また限界値テストからは若干外れるが、
平均レスポンスタイム約5秒周辺での各バージョンのザックリした対比は、

【2.14.9 vs 3.6beta13】
PV: 約3500PV/分 : 約1400PV/分 (2.14.9が約2倍こなせる)
httpdの平均メモリ使用量: 約7MB : 約22MB (2.14.9が約1/3)

【3.4.15 vs 3.6beta13】
PV: 約1100PV/分 : 約1400PV/分 (3.6beta13が約1.2倍こなせる)
httpdの平均メモリ使用量: 約20MB : 約22MB (3.6beta13が約1.1倍増えちゃってる)

■次回
サービスレベルを平均レスポンスタイム1秒以内ぐらいに注目して、もっとゆっくり負荷をかけて、検証してみようかな。
あと今回はコアだけにしてたので、バンドルプラグインをいれてやってみようかな。
あ、あとMediaWikiとかWordpressとかの負荷性能との対比もやりたいな。

2011年8月28日日曜日

段階的に負荷をあげて、OpenPNE3.6beta13とOpenPNE2.14.9の負荷性能を比較してみた!の巻!


はい!ギュンばんわ!

昨日に引き続き負荷性能の比較ですよと。
段階的に負荷を増やしての限界テストをやってみましたよと。

平均レスポンスタイムが5秒以内なところでいうと、

- OpenPNE3.6beta13(Doctrine版・コアだけ・マイホームにアクセス)
-- PVは、約700PV/分(約11PV/秒)
-- httpdの平均メモリ使用量は、約35MB
-- 平均レスポンスタイムは、約5秒

- OpenPNE2.14.9(マイホームにアクセス)
-- PVは、約1500PV/分(約25PV/秒)
-- httpdの平均メモリ使用量は、約13MB
-- 平均レスポンスタイムは、約2.5秒

な感じですかねー

段階的な負荷の上げ方は、15秒に1接続ずつ増やしていく感じでやりました。

なんかOpenPNE2.14.9が尻すぼみなのが気になる(ネットワークの調子がおかしくなった可能性あり)なので、再試験してみるかなぁ〜www

負荷をかけるのに使ったのは、今回あらたに作った↓であります。
https://github.com/rysk92/webapp_monitor/blob/master/reqsan_manager.py