技術ネタ の最近の記事

はじめに

チームラボの高須さんがメインとなって開催されている深圳観察会、これの第7回ニコ技深圳観察会(2017年04月)へ参加してきました。

ニコ技深圳観察会の各種情報については以下を参照してください。情報は過去の参加者の方々が沢山アップしてくれています。

自分のことについて少し書くと、現在はフリーランスでWEBアプリケーションのフロントエンドとバックエンドの設計や開発をしていたり、少しだけiOSとAndroidも開発していたりします。Maker的な面で言えば昔からそういったことが好きでして、Maker Faireの前身のMake Tokyo Meetingから観に行ったり、ArduinoやらRaspberry Piとか趣味でチョロチョロ触ったりしています。でもMakerよりもHackerというもののほうがどちらかというと好きな人種かもしれません。たぶんモノを作るよりも壊すことの方が好きな人種です(スミマセン)。

そんな人から見た現在の「深圳」を書きます。書きますとは言っても精緻なレポートではありません。ただの私見です。感想です。そして「現在」と言っているのは、おそらくこの街は成長のスピードがものすごく早いようなので、数ヶ月でバンバンとシステムが変わるであろうからです。
深圳ガイドやら渡航法なものは、高須さんのブログ(http://ch.nicovideo.jp/tks/ )から辿ると結構見つかりますのでそちらを参照ください。

動機

さて「深圳(Shenzhen)」というとみんなどうゆうイメージを持つんでしょうか。「モノづくり」、「工場」、「怪しい家電が大量にある」、「町中でドローンをビュンビュン飛ばしてる」、などなどそういったワードが出て来るのではないでしょうか。実際自分もそういったワードを聞いていてそこから興味を持ちました。そして参加する至った強い理由としては、茂田さんのブログ記事(深圳クエスト2017 / http://shigeta.com/?eid=231)を見て深圳という街をハックしているような雰囲気が伝わってきて(もちろん観察会のレポートも面白い)、「これは行かねばなるまい」と思ったからです。「なんだかよくわからない先端を行っているらしい怪しげな街を乗り切ってハックする」とかもう熱くならないわけがありません。

深圳という街

深圳という街についてですが、歴史的な側面についてはほとんどが高須さんや伊藤さんから口頭で聴いただけなので、自分で調査したものではありません。理解不足や誤認識もあるかもしれません。この点を了承した上で読んでください。

つい30年ほど前までは寂れた漁村であった深圳ですが、中国最初のが経済特区に指定され、香港への輸出のバックヤードとなるべくして工場などが出来てゆき成長してきたようです。そしてだんだんと成長してゆく過程で深圳の工場などの強みを活かして産業を作ろうということになり、深圳の産業グループ・賽格電子集団(Shenzhen Electric Group:SEG, http://www.seg.com.cn/)が東京の秋葉原あたりをモデルとして開発を始めたのが、電子部品などが小さな店舗で所狭しと詰め込まれた電気ビル「賽格広場(SEG Plaza)」のようです。このビルが発端となり、次々と同様のビルが開発され、現在の華強北(ファーチャンペー)の電気街になったようです。

20170402_120521.jpg20170402_112120.jpg

Photo by Yosuke Tanaka

IMG_20170403_133214.jpg20170403_144556278.jpg

Photo by Yosuke Yamada

「なったようです」と書きましたが、これもここ数年でもどんどんと開発が進んでいるようで、何度か来ている人達でも数ヶ月の間で変化が大きく驚きがあるようです。確かに事前にネットで「このあたりに◯◯の店がありました」というような、数ヶ月にアップされた記事などを読んでからその場に行ってみても既に違う施設が開発されているようなケースもありました。おそらく日本でネットで調べておいてから華強北に向かっても、この情報は街の変化のスピードに耐えられないのではないでしょうか。深圳・華強北の最新情報をネット越しに得るには、アーカイブとしてのインターネットはあまり機能しないかもしれません。そして日本語の情報だけでは現状足りないでしょう。そしてインターネット越しに情報を得るよりも実際に目の当たりにする方が圧倒的に刺激的です。

そして、日本では見ることができないであろうディープな部分としてはスマートフォンを中心としたデバイスのパーツ取りと販売です。華強北の少し南のゾーン、華強路駅付近には怪しげなスマートフォン解体マーケットがあります。パーツ売り場も様々なのですが、発売されたばかりのiPhone7レッドの筐体などが既に販売されているのも驚きでした。そして外装パーツ以外のものでも下記の写真のように、まるでデパートの化粧品売場のように綺羅びやかに飾ってショーケースの中に展示されて若い女性が売り子として販売してる景色など、完全にサイバーパンクです。おそらくここに義体のパーツがショーケースに並んでても違和感はないでしょう。

2017-04-03 18.18.33.jpg2017-04-03 18.26.20.jpg

少し危ないゾーンでもあるため撮影は出来ませんでしたが、路上で豪快にスマートフォンを叩きつけて分解をしてパーツ取りをしている方々も居ました(撮影してるとバレると怒られるようです)

電子決済とシェアリングエコノミー

直接「深圳が」というテーマではありませんが、この街のエコシステムを知るにあたり外せないものが「wechat payment」です。wechatというと「テンセントがやってるよくわからないデカいチャットサービス」とか「ちょっと意識の高い人が使ってるチャット」などのイメージがあるかもしれませんが、それはwechatのごく一側面でしかありません。「チャットと決済サービスをベースとした巨大プラットフォーム」というのが今回観察会で思った自分の印象です。細かな部分は他の方のレポートを読んでいただくのがより正確な情報となり、また少し大げさかもしれませんが、とにかくこの街では現金が1元もなくてもwechat paymentのwalletの中にお金が入っていれば生活に困らないように出来ています。飲食店にも、パーツ屋にも、至る所にQRコードがあり、これで決済が完了します。

20170407_150617.jpgIMG_20170403_183048.jpg

Photo by Yosuke Yamada, Yosuke Tanaka

写真左、レンタル自転車を借りるのもwechatでQRコードを読み取って支払い、ロック解除。どこで乗ってどこで乗り捨ててもOKというサービスが複数社から提供されています。町で自転車乗っている人のほとんどがこの手のレンタル自転車でした。この街ではたぶん「自転車を所有する」という概念は無くなってきているのではないでしょうか。また、当然クラックする人は現れますが、とにかく始めてしまって問題はあとから解決する、というスピード感のようです。
写真右、路上で謎のUSBケーブルを手売りしている。ここでもwechatのQRコードを交換するだけで決済が完了します。そして少し人が集まっているだけで関係ない人が「なんだなんだ」と寄ってきます。たぶん街の人達が常に新しいものを欲しているのではないでしょうか。

Industryとしての深圳

「モノづくり」という側面を見せる深圳ですが、やはり歴史的な経緯なのか「ホビーとしてのモノづくり」よりも「世界の工場」という面が強いように思えます。ですので、数多くの工場があるようですが、そんななかでも今回の観察会の中で一番キレている工場(組み立て工場)がAsh Cloudでした。


http://cdn2.ashcloudsolution.com/wp-content/uploads/2016/12/ashcloud_540p.mp4

この工場では社内の勤怠・コミュニケーション・経理処理などから工場のラインの管理に至るまで全てをiOSをベースとしたシステムで統合的に管理され、工場のラインでの製品組み立て・箱詰めのような部分のみ人間が行なうという狂気に満ち溢れたシステマティックな世界に包まれていました。

20170406_094135.jpg 20170406_101538.jpg

Photo by Yosuke Tanaka

AIやロボットの技術進展により人間の職、特に単純労働が奪われるという話は昨今よく耳にしますが、現状においてはフレキシブルに対応が可能な人間が単純作業をいくつもこなし、システムがそれらの人間を管理するという形が合理的であるという理念の元こういったシステマティックな組み立て工場が出来たのでしょうか。もちろんラインにロボットを組み入れることも現在検証中のようで、これが実現すると完全なオートメーションが完成するのかもしれません。そしてこのシステムですが、財務的な部分以外は顧客がリアルタイムに状況を把握できるようにアプリケーションが顧客にも提供されているようです。構内も洗練されたデザインで統一されており、「狂気」以外の言葉が見つかりませんでした。深圳がハードウェアの側面から注目されているのは周知されていることかと思いますが、こういった統合的なシステムの面でも抜きに出た企業があるというのが凄いことだと思いました。当然のことながら相当にテンションが上がりました。

Maker Space

「世界の工場」としての深圳がフィーチャーされますが、やはりいわゆる「モノづくり」が好きなMakerが多いからこういった進化を遂げたのでしょうか(鶏と卵論にはなるかもしれませんが)、どうなのでしょうか。どちらが先かはわかりませんが、やはり深圳にもMaker Spaceがいくつか稼働しています。そんな中でも一番印象的だったのが、seeed studioが運営しているChaiHuo Maker Space(柴火创客空间)

2017-04-05 17.06.24.jpg

他のMaker Spaceがスタートアップ・起業という文脈と不可分なものとして語られる中でも、このChaihuoはホビー・DIYの精神を保ったままの存在のようでした。実際各企業やMaker Spaceや工場を回ってからここへたどり着いた際になんだかホームグラウンドに帰ってきたような落ち着きを感じました。これは深圳のOCTと呼ばれているクリエイティブを発信する大きな公園のような施設内に存在しているという理由もあったからかもしれません。

そんな中で説明をしてくれたのはseeedの社員のViolet Suさん。

17757463_10212178299594657_168316571653738542_n.jpeg

Photo by tks

深圳のメイカーとイギリスのメイカーをつなぐためにイギリスに1ヶ月滞在していた際の事をプレゼンしてくれました。とてもパワフルでさらにとても聴きやすい英語、そして常に笑顔が絶えず、本当にこの会社・仕事、そしてMakerが好きなんだろうな、という事がひしひしと伝わってきました。彼女自身はエンジニアなどではないようですが、ロールモデルにしたいような人だと思いました。

日本はどうなのか

観察会のメンバーで晩御飯を食べた後などに、「深圳は凄すぎる」「日本は終わった」「日本が勝てるのはもうトイレしか残っていない」などなどお酒が入った勢いもあり喋り散らしていました。自分もツイッターでそんな発言をしたりもしました。確かにワールドワイドに展開する企業や経産省の役人の方々などはそういった競争の中に居る方もいるかと思います。ですが、そういった枠の視点を少し大きく、もしくは小さく見直してみるとどうなのでしょうか。国がどうこうとかよりもアジア全域が活性化すれば、とか地球全域が楽しくなれば、とか。もしくは自分自身さえ楽しければ国とかどうでも良いのでは、とか。

ソフトウェアの世界ではオープンソースというものが広がったお陰で様々な技術が加速度的に進歩し、今のインターネットがここまで進歩したのも技術がオープンになったからであることはみなさんよく知っているところかと思います。それが深圳ではハードウェアにも大きく関係しており、公板(ゴンバン)/公模(ゴンモウ)というパブリックなマザーボード/外装をシェア/コピーしてゆくことにより様々な新しい製品が生まれているようです。

様々な規制を掛けて顔色を伺ったり保身をするよりも、とにかくオープンにしてシェアして混ぜ合わせてカオスな状態になるくらいまで進めてゆくほうがクールでクレイジーで楽しいものが生まれるのではないでしょうか。そんな事を思い知らされた観察会でした。

まとめ

1人で情報を集めて深圳を観に行っても華強北を見て終わりになってしまうかもしれません。深圳のエコシステムを色々な角度から見られるという点においても、このニコ技深圳観察会は大変有意義なものですので、おすすめです。ソフトウェア、ハードウェア、WEBやらITと名のつく各種業界にいらっしゃる方々は是非一度深圳を体験すると良いと思います。特にcivic tech界隈の方々はどうでしょうか。

10月予定のMaker Faire Shenzhenには是非行こうと思っています。

追記

2017-04-07 11.06.35.jpg

本題からは外れるのですが、華強北の割りとど真ん中にvivienne westwoodの店がありました。
オフィシャルサイトにはLuohuのしか載ってないですが、ここには載っています。
http://www.modamiahk.com/en/vivienne-westwood-china/

電気街のど真ん中にvivienne westwoodって凄いですよね。華強北はcoolだと思わせるものがあったのでしょうか。いつまで存在するのかはわかりませんが。

参考

人類史上最速で成長する都市「深セン」で何が起きているの / DIAMOND online

深圳のバイオレット・スーが教えてくれた、Makerムーブメントの本質(前編) / エンジニアtype

深圳のバイオレット・スーが教えてくれた、Makerムーブメントの本質(後編) / エンジニアtype

ハードウェア開発の「伽藍とバザール」 / Wireless Wire News

深センの公板/公模 700円の粗悪アクションカメラに見るイノベーション / fabcross

対象の製品はこちら。

超小型USBシリアル変換モジュール

これを、

このArduino Pro Mini互換機(AE-ATMEGA328-MINI)で使うおうという算段。

本当はこちら

(FT-232RQ)を買おうと思っていたのだが品切れでまぁ隣にあった安いやつでもいけるかなと思って。

結論から言うと

そのままではうまくいかない。

詳しくはこのあたりを。

超小型USBシリアル変換モジュールをArduinoとして使う方法 (https://b.eax.jp/eh/arduino/13744/)

DTRリセットをモジュールに返さないといけないようなのだがこのモジュールではDTRを受け取れない。RTSを引き抜いてくるという裏技が書かれてあるがそれもちょっと...と思い他を探すとこれ。

Arduino Pro Mini 互換 起動メモ (http://www.greysound.com/2014/05/07/arduino-pro-mini-%E4%BA%92%E6%8F%9B-%E8%B5%B7%E5%8B%95%E3%83%A1%E3%83%A2/)

書き込み中にArduino側のリセットボタンを押せばいける、と。

結論としては

うまくいった。

リセットのタイミングが難しいとあるが、Arduino IDEの設定で書込の詳細ログを表示するようにして

のあたりのタイミングでArduinoをリセットすればすんなり書き込めます。

検証環境

Arduino IDE 1.6.7AE-ATMEGA328-MINI
AE-FT234X

どうも。

保存用RITZを開封するか悩んでいます。 ハシモトです。

また、こちらなんですが、Elixirの特集があったんで読みたくて買ったわけなんですね。で、まぁElixirの特集もそれなりに面白く、またMQTTとかの特集も結構良かったんですが、他の特集で「モバイル開発最前線」というのがあって、これはAndroidの開発環境回りのお話だったので、チラッとやってみるかと思ったんですが、色々手こずったのでこちらにログを。 (ちなみにAndroidは出たばかりの頃にチラッとやっただけでほぼ初心者です)

サンプルアプリケーション

https://github.com/yanayanalte/SampleAndroid まず記事で紹介されているサンプルアプリケーションはこちらです。

おもむろに git clone してコンパイルを試みますが

git clone git@github.com:yanayanalte/SampleAndroid.git
cd SampleAndroid
./gradlew assembleDebug

:app:preBuild UP-TO-DATE
:app:preDebugBuild UP-TO-DATE
:app:compileDebugNdk UP-TO-DATE
:app:checkDebugManifest
:app:preReleaseBuild UP-TO-DATE
:app:prepareComAndroidSupportAppcompatV72211Library
:app:prepareComAndroidSupportSupportV42211Library
:app:prepareComCrashlyticsSdkAndroidAnswers122Library
:app:prepareComCrashlyticsSdkAndroidBeta112Library
:app:prepareComCrashlyticsSdkAndroidCrashlytics232Library
:app:prepareComCrashlyticsSdkAndroidCrashlyticsCore232Library
:app:prepareIoFabricSdkAndroidFabric133Library
:app:prepareDebugDependencies
:app:compileDebugAidl
:app:compileDebugRenderscript
:app:generateDebugBuildConfig
[Fatal Error] :22:27: 要素タイプ"android:value"に関連付けられている属性"{1}"には、開始引用符が必要です。

FAILURE: Build failed with an exception.

* What went wrong:
Cannot read packageName from path/to/SampleAndroid/app/src/main/AndroidManifest.xml

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

Total time: 16.873 secs

あえなく失敗します。 どうやらAndroidManifest.xmlのandroid:valueがイカンとのことなので調べますと、fabricのAPI KEYの設定のようです。

Fabric

で、Fabric。Twitterが開発しているモバイルの開発プラットフォームというかクラッシュレポートとかをよろしくやってくれるようですが、こいつのAPI KEYがイカンと。

https://github.com/yanayanalte/SampleAndroid/blob/master/app/src/main/AndroidManifest.xml#L22

「XXXXXXXXXXX」という設定になっています。 fabric自体がよくわからないので、色々ググって、まずどうにかしてAPI KEYを手に入れる事に専念するわけですが、fabricにサインアップしても設定画面などは一向に出てこない。 設定画面から取れるという情報もあるが、そもそも以下の画面しか出てこない。

Gyazo

ので、取り敢えずAndroid Studioにプラグインを突っ込む事にする。 ここでsafariとかでやってるとプラグインのzipを勝手に解凍してしまうので注意。 基本的にはfabricのページの手順に沿ってインストール。 するとAndroidのアイコンの横にfabricのアイコンが現れる。

Gyazo

ので、これをクリックしてサインインして進める。

そして、サンプルアプリケーションをAndroid Studioで開いた状態からこのプラグインを起動させて進めていくと、以下のようにインストールするkitを選べとなる。

Gyazo

CrashlyticのUpdateをクリックすると、

Gyazo

こんな感じでAPI KEYを変更するぜ、と言われるのでApplyボタン(キャプチャでは見切れてますが)を押すとAndroidManifest.xmlが書き換わり、API KEYが取得できる。

$ vi ./app/src/main/AndroidManifest.xml
$ ./gradlew assembleDebug
:app:preBuild UP-TO-DATE
:app:preDebugBuild UP-TO-DATE
:app:compileDebugNdk UP-TO-DATE
:app:checkDebugManifest
:app:preReleaseBuild UP-TO-DATE
:app:prepareComAndroidSupportAppcompatV72211Library UP-TO-DATE
:app:prepareComAndroidSupportSupportV42211Library UP-TO-DATE
:app:prepareComCrashlyticsSdkAndroidAnswers122Library UP-TO-DATE
:app:prepareComCrashlyticsSdkAndroidBeta112Library UP-TO-DATE
:app:prepareComCrashlyticsSdkAndroidCrashlytics232Library UP-TO-DATE
:app:prepareComCrashlyticsSdkAndroidCrashlyticsCore232Library UP-TO-DATE
:app:prepareIoFabricSdkAndroidFabric133Library UP-TO-DATE
:app:prepareDebugDependencies
:app:compileDebugAidl UP-TO-DATE
:app:compileDebugRenderscript UP-TO-DATE
:app:generateDebugBuildConfig UP-TO-DATE
:app:generateDebugAssets UP-TO-DATE
:app:mergeDebugAssets UP-TO-DATE
:app:generateDebugResValues UP-TO-DATE
:app:generateDebugResources UP-TO-DATE
:app:mergeDebugResources UP-TO-DATE
:app:processDebugManifest
Warning: /path/to/SampleAndroid/app/src/main/AndroidManifest.xml:25:1 Warning:
  Element uses-permission#android.permission.INTERNET at AndroidManifest.xml:25:1 duplicated with element declared at     AndroidManifest.xml:5:5
/path/to/SampleAndroid/app/src/main/AndroidManifest.xml:25:1 Warning:
  Element uses-permission#android.permission.INTERNET at AndroidManifest.xml:25:1 duplicated with element declared at     AndroidManifest.xml:5:5
:app:fabricGenerateResourcesDebug
:app:processDebugResources
:app:generateDebugSources
:app:compileDebugJava
注意:一部の入力ファイルは非推奨のAPIを使用またはオーバーライドしています。
注意:詳細は、-Xlint:deprecationオプションを指定して再コンパイルしてください。
:app:preDexDebug
:app:dexDebug
:app:processDebugJavaRes UP-TO-DATE
:app:validateDebugSigning
:app:packageDebug
:app:zipalignDebug
:app:assembleDebug

BUILD SUCCESSFUL

Total time: 38.731 secs

めでたくビルド成功。

だがしかし

この企画はgithubにpushした上でのcircleCIでのビルドを前提としているはず。 API KEYをハードコーディングした状態でpushして良いはずがなかろう....。

ということで環境変数からうまく読み込む方法を調べる。

http://stackoverflow.com/questions/25700680/crashlytics-found-an-invalid-api-key#answer-25704532

安定のStack Overflow。 build.gradleに

manifestPlaceholders = [name: value]

とすれば

${name}

でAndroidManifest.xmlから変数で読み込める模様。 今々ではFlavorは無視するので、/app/build.gradleのdefaultConfigにこのmanifestPlaceholdersを突っ込みます。

あとはbuild.gradleはそもそもgradleなので、こいつに環境変数から値が渡ればOK。

build.gradleからの環境変数の参照 - horie1024の日記

こちらによれば、

ORG_GRADLE_PROJECT_

がプレフィックスにつく環境変数はbuild.gradleからそのまま読み込める模様。 なので、

$ export ORG_GRADLE_PROJECT_FABRIC_API_KEY="YOUR KEY"
$ vi ./app/build.gradle

defaultConfig {
    ....略....
    manifestPlaceholders = [fabricApiKey: FABRIC_API_KEY]
}

$ vi ./app/src/main/AndroidManifest.xml
<meta-data
    android:name="io.fabric.ApiKey"
    android:value="${fabricApiKey}" />

というような感じにすればOK。 circleCIでも上記のようなORGGRADLEPROJECTFABRICAPI_KEYのような環境変数を充ててやればOK。

それにしてもデベロッパーフレンドリーじゃないサンプルだったな...。

久しぶりに技術ネタでも。

大学院の授業でオレオレプロトコルを作る授業がありまして、作ったは良いけどどこかにサクッとデプロイできないかなー、herokuとか良いんじゃないかなー、いや、でもherokuって基本はHTTPのサービスじゃなかったかな、いや、どうだろう?探してみるか?


という事で、ありました。

Ruppell's Sockets | Heroku Dev Center

好きなsocketプログラミングをherokuにデプロイできるぜ!みたいなaddonのようです。 後述しますが、内部的にはsshポートフォワードで実現してるっぽいです。

heroku addons:create ruppells-sockets

こちらのaddonを乗せて

git submodule add https://bitbucket.org/ruppells/sockets-connect.git lib/sockets-connect

gitのsubmoduke突っ込んで

echo 'socket: ./lib/sockets-connect/rs-conn ./any_start_command' > ./Procfile

Procfileに socket コマンドで ./lib/sockets-connect/rs-conn から起動コマンドをキックさせるように記述します。 コマンドが複雑な場合は1つのシェルスクリプトなんかにまとめておけば問題ありませんね。

git add .; git commit -m "Add awesome configuration"; git push heroku master

あとは適宜git commitして、push

heroku config:get RUPPELLS_SOCKETS_FRONTEND_URI #-> tcp://4950.381b424d-12fa-4fad-b464-9013a482ca7f.sockets.ruppells.io:4950

内部的にはsshのポートフォワードで実現しているようなので、上記のようにしてendpointを取得します。

バックエンドのポートはデフォルトだと1337番が勝手に振られて、通信出来ないとステータスコードでエラーと言われます(heroku logs -tのログで確認できます)。 ですので、バックエンドのポートが決まってる場合は

echo 'socket: ./lib/sockets-connect/rs-conn -b 8080 ./any_start_command' > ./Procfile

みたいにして、ポートを指定します。 ですが、ここは結局バックエンドのポートなので、フロントのsshポートフォワードされた方はなんだかうまく指定出来ません...。調べれば分かるかも。

ではでは。

どうも。

秋風に身を切られる思いです。

去年くらいにちらほら出てきたnodejsでのrails系フレームワークの「sails」。
今後使えるのかどうか、またどのくらいベンチが出るんだろうかと思い、ベンチを取ってみました。

使ったのは下記のrailsとsailsのサンプルアプリケーションをherokuに上げました。

rails_sample / github
rails-sample / heroku

sails-sample / github
sails-sample / heroku

これを、apコマンドにてvps(gmo)から叩きます。各アプリケーション共に、controllerを通した上での静的ページと、10件ほどのデータを読み込んで表示させる動的なページを用意して計測しました。

結果

rails static
-----------------
$ ab -n 10000 -c 1000 http://rails-sample1.herokuapp.com/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking rails-sample1.herokuapp.com (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests


Server Software:        WEBrick/1.3.1
Server Hostname:        rails-sample1.herokuapp.com
Server Port:            80

Document Path:          /
Document Length:        485 bytes

Concurrency Level:      1000
Time taken for tests:   82.283 seconds
Complete requests:      10000
Failed requests:        5
   (Connect: 0, Receive: 0, Length: 5, Exceptions: 0)
Write errors:           0
Non-2xx responses:      4
Total transferred:      13326011 bytes
HTML transferred:       4849511 bytes
Requests per second:    121.53 [#/sec] (mean)
Time per request:       8228.335 [ms] (mean)
Time per request:       8.228 [ms] (mean, across all concurrent requests)
Transfer rate:          158.16 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:      161  174   8.1    174     265
Processing:   319 7201 7033.1   4750   59446
Waiting:        0 7193 7013.9   4749   57805
Total:        482 7375 7034.8   4926   59640

Percentage of the requests served within a certain time (ms)
  50%   4926
  66%   6972
  75%   8933
  80%  10621
  90%  16468
  95%  21636
  98%  30056
  99%  35091
 100%  59640 (longest request)

 sails static
-----------------
$ ab -n 10000 -c 1000 http://sails-sample.herokuapp.com/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking sails-sample.herokuapp.com (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests


Server Software:        Cowboy
Server Hostname:        sails-sample.herokuapp.com
Server Port:            80

Document Path:          /
Document Length:        3402 bytes

Concurrency Level:      1000
Time taken for tests:   41.820 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      38747605 bytes
HTML transferred:       34030206 bytes
Requests per second:    239.12 [#/sec] (mean)
Time per request:       4182.031 [ms] (mean)
Time per request:       4.182 [ms] (mean, across all concurrent requests)
Transfer rate:          904.81 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:      161  174   7.3    174     202
Processing:   191 3755 2167.6   3234   26811
Waiting:      191 3753 2167.5   3232   26811
Total:        353 3929 2167.7   3408   26989

Percentage of the requests served within a certain time (ms)
  50%   3408
  66%   3995
  75%   4392
  80%   4828
  90%   6443
  95%   8117
  98%  10287
  99%  12197
 100%  26989 (longest request)

  rails dynamic
---------------------
$ ab -n 10000 -c 1000 http://rails-sample1.herokuapp.com/users
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking rails-sample1.herokuapp.com (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests


Server Software:        WEBrick/1.3.1
Server Hostname:        rails-sample1.herokuapp.com
Server Port:            80

Document Path:          /users
Document Length:        1063 bytes

Concurrency Level:      1000
Time taken for tests:   113.274 seconds
Complete requests:      10000
Failed requests:        122
   (Connect: 0, Receive: 0, Length: 122, Exceptions: 0)
Write errors:           0
Non-2xx responses:      17
Total transferred:      18898109 bytes
HTML transferred:       10508542 bytes
Requests per second:    88.28 [#/sec] (mean)
Time per request:       11327.374 [ms] (mean)
Time per request:       11.327 [ms] (mean, across all concurrent requests)
Transfer rate:          162.93 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:      161  175  11.9    174     492
Processing:   301 10530 10858.2   6178   60166
Waiting:        0 9899 9647.1   5972   59731
Total:        463 10705 10859.6   6364   60342

Percentage of the requests served within a certain time (ms)
  50%   6364
  66%   9713
  75%  13072
  80%  15779
  90%  24772
  95%  34554
  98%  47397
  99%  59697
 100%  60342 (longest request)

  sails dynamic
----------------------------------
$ ab -n 10000 -c 1000 http://sails-sample.herokuapp.com/users
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking sails-sample.herokuapp.com (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests


Server Software:        Cowboy
Server Hostname:        sails-sample.herokuapp.com
Server Port:            80

Document Path:          /users
Document Length:        4151 bytes

Concurrency Level:      1000
Time taken for tests:   56.927 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      46226812 bytes
HTML transferred:       41510000 bytes
Requests per second:    175.66 [#/sec] (mean)
Time per request:       5692.734 [ms] (mean)
Time per request:       5.693 [ms] (mean, across all concurrent requests)
Transfer rate:          793.00 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:      161  174   7.0    174     204
Processing:  2293 5336 662.6   5411    8014
Waiting:     2292 5335 662.6   5410    8013
Total:       2456 5510 664.5   5584    8209

Percentage of the requests served within a certain time (ms)
  50%   5584
  66%   5687
  75%   5759
  80%   5810
  90%   6091
  95%   6234
  98%   7079
  99%   7591
 100%   8209 (longest request)

といった感じで、

ページアプリケーションRequests per second
静的 rails 121.53
静的 sails 239.12
動的 rails 88.28
動的 sails 175.66

割りと有意な結果が出たような気がします。

もうちょっと他のフレームワークも欲しいですね。

ではでは。

1   2   3   4   5   6   7   8   9   10