電脳ではたらくOpenPNE開発者の日記@ネット: 9月 2011

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以降の方向性について書いてみます。

まず簡単にオープンソースな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)

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