最近スマートフォンのブラウザサイトを作ってて思うことを書いてみる。
1) マウスのように「点」ではなく、「面」でのクリックなので、「面」でクリックしても誤クリックにならないようにする。
具体的にはリンクやボタンは大きめに。大きくできないなら余白を広く。
2) マウスとタッチで「リンクをクリックして遷移していくストレス・コスト」が違う。マウスのほうが直接画面をタッチするわけではないので、カーソルの軌道修正などのコストがあり、一回のクリックのコスト・ストレスはタッチより高い。
なので、スマホ版は画面が小さいというデメリットを、「通信が発生しない高速の画面切り替え」で補うと良い。
具体的には、メニューなどはタッチさせて、JavaScriptで表示要素を動的に出す感じとか。
3) 片手(左手など)で操作で操作する場合、親指での操作になるとおもうが、リンク・ボタンの位置によっては押しにくいことを認識すること。左側の方が押しやすい。最近のfacebookのスマホ版で左上のロゴがきえて、メニューになったのもそのあたりかと。
2011年10月13日木曜日
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
わりと色々流れてるので、入っておくといいかも。
■入会
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とかでやる
というのはどうでしょうか？
まず簡単にオープンソースな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の脆弱性・バグ修正・バージョンアップに追従するコストが発生する
* 標準機能から外れる表現をするのが面倒そう
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のようなサイトには向いてないような気がしています。
なんか詳しい人の見解を聞きたいっす。
メリット
* 手軽にリッチな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)
■次回
データとか入れてやっていきたいな。
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とかの負荷性能との対比もやりたいな。
あたしよ！
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
登録:
投稿 (Atom)