2012年4月25日水曜日

web server benchmark : apache lighttpd nodejs warp yesod tomcat jetty

結論

QCon 2012 で Warp+Yesod がいいと言っていたので、ベンチをとってみました。いいっぽいです

サーバーサイドのチューニングはデフォなので、スレッド数位は合わせてベンチマークをとりたいと思って下ります。 なんかサーセン

環境

Server

Ubuntu 11.10

Intel(R) Xeon(R) CPU 5160 @ 3.00GHz x 2

Memory 2 GiB

|

Switching Hub

corega Fast SW-8D

|

Client

Mac OS X 10.7.3

2.53 GHz Intel Core i5

Memory 8 GB 1067 MHz DDR3

計測の仕方

$ ab -n request_count -c 128 -r -g gnuplot_file_name   http://ubuntu.server:port/path   >& result.txt

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/

計測したもの

Apache Lighttpd

Server Software:        Apache/2.2.20
Server Hostname:        xxx.xxx.xxx.xxx
Server Port:            80

Document Path:          /index.html
Document Length:        85 bytes

Server Software:        lighttpd/1.4.30
Server Hostname:        xxx.xxx.xxx.xxx
Server Port:            8123

Document Path:          /index.html
Document Length:        85 bytes

Node.js Warp + Yesod

version: 0.6.15


Server Software:        
Server Hostname:        xxx.xxx.xxx.xxx
Server Port:            8124

Document Path:          /
Document Length:        80 bytes

ghc: 7.0.3

warp: 1.2.0.1

yesod: 1.0.0.2


Server Software:        Warp/1.2.0.1
Server Hostname:        xxx.xxx.x.160
Server Port:            8123

Document Path:          /index
Document Length:        99 bytes
Tomcat Jetty

Server Software:        Apache-Coyote/1.1
Server Hostname:        xxx.xxx.xxx.xxx
Server Port:            8080

Document Path:          /sample/index.html
Document Length:        85 bytes


Server Software:        Jetty(8.1.2.v20120308)
Server Hostname:        xxx.xxx.xxx.xxx
Server Port:            8080

Document Path:          /sample/index.html
Document Length:        85 bytes

計測結果

wait time 分布図

30000 request

10000 request

wait time について => Between writing request and reading response

Source らしい(何となく怪しい) から一部抜粋

struct data {
#ifdef USE_SSL
    /* XXX insert timings for ssl */
#endif
    int read;                   /* number of bytes read */
    long starttime;             /* start time of connection in seconds since
                                 * Jan. 1, 1970 */
    long waittime;              /* Between writing request and reading response */
    long ctime;                 /* time in ms to connect */
    long time;                  /* time in ms for connection */
};

テスト時間 (sec)

apache, lighttpd はリクエスト数が多いとテストに時間がかかります。


result/apache-time.dat
request  1       2       3       4
  200    0.028   0.035   0.030   0.031
  500    0.081   0.087   0.078   0.069
 1500    0.187   0.172   0.187   0.185
10000   90.143 109.438 107.131 104.303
30000   18.995   3.584  32.986 327.660

result/lighttpd-time.dat
request  1       2       3       4
  200    0.025   0.025   0.027   0.026
  500    0.063   0.069   0.055   0.053
 1500    2.139   0.561   0.168   0.169
10000  50.097   52.646   2.285  34.739
30000 142.147    5.152 165.114 162.209

result/nodejs-time.dat
request  1      2        3       4
  200    0.034  0.039    0.034   0.032
  500    0.097  0.074    0.073   0.072
 1500    0.238  0.235    0.245   0.211
10000    1.560  1.610    5.101   1.505
30000    8.593 24.368   16.838  31.659

result/warp-time.dat
request  1      2        3       4
  200    0.071  0.093    0.074   0.070
  500    0.160  0.309    0.229   0.176
 1500    1.264  1.057    1.326   1.048
10000    3.115 10.991   11.347   5.078
30000   33.264 34.866   33.098  34.690

result/tomcat-time.dat
request  1      2        3       4
  200    0.021  0.024    0.025   0.080
  500    0.052  0.050    0.049   0.043
 1500    0.151  0.167    0.166   0.153
10000    9.062 10.112    6.957   0.965
30000   21.004 12.324   21.602  18.784

result/jetty-time.dat
request  1      2        3       4
  200    0.025  0.025    0.026   0.028
  500    0.087  0.104   14.926   0.059
 1500    1.127 22.815    1.244  14.990
10000   11.779 11.658   11.648  11.617
30000   36.141 36.806   36.773  36.225

2012年4月18日水曜日

組込み Tomcat と Jetty : Embedded in java

TomcatとJettyの組込みです バージョンは下記です
  • Tomcat 7.0.26
  • Jetty 8.1.12

Tomcat 参考サイト

embedding-tomcat

コマンド

起動は下の感じで、止めるのは Ctrl-C でお願いします
# tomcat
$ java -cp srv.jar:lib/* web.server.WebServer

# jetty
$ java -cp srv.jar:lib/* web.server.WebServer -jetty

# set port
$ java -cp srv.jar:lib/* web.server.WebServer server.port 8123

他のパラメータはソースを見てください
動かした感じ, jetty の後 tomcat 動かしてます










ソース

2012年4月11日水曜日

タネマキは使える

週末にフラッとタネマキに行ってきました。

混む時もあるそうですが、おおよそ使えるのでは無いでしょうか?

ここです!!タネマキ

2012年3月27日火曜日

CAEmitterCell のパクリネタ

ネタが無いので、パクリました。_( TxT)_

Emitting (発光 by Google 翻訳先生) のパクリネタ

本家を読んでくださいね。

パクリ元

UIKit Particle System in iOS 5 Tutorial

参考という名目のパクリ元

CAEmitterLayer and CAEmitterCellアップるぅぅぅの記事ですよね

その他ぽいの


プロパティの説明

CAEmitterCell
birthRate毎秒どれくらいオブジェクトを作るか
lifetimeセルのライフタイム
colortint 色合いを設定
contentsCGImageRef を設定


Layer は emitterShape と emitterPosition を設定するくらいでしょうか

CAEmitterLayer
emitterShapeオブジェクトの作成方法を設定

動かすとこんな感じ


使った適当な画像はこれです


ソース

ファイルのコメント的にはコピペはOKそうだったのですが。
問題ありましたらご指摘ください

2012年1月25日水曜日

続 NSURLConnectionDelegateで証明書(ry..方法

前回の記事が適当すぎたので、少ししっかり調べたーー

参考になると幸いです

結論

SSL周りのリリースノート、仕様書とかきちんとでてますか?

知っている方いたら教えてください

環境

  • iOS 5.0
  • tomcat 7.0.23 / 6.0.32
  • xcode 4.2.1

適当にする方法(改め)

- (void)connection:(NSURLConnection *)connection willSendRequestForAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge {
  NSURLProtectionSpace * protectionSpace = [challenge protectionSpace];
  NSURLCredential* credentail = [NSURLCredential credentialForTrust:[protectionSpace serverTrust]];
  [[challenge sender] useCredential:credentail forAuthenticationChallenge:challenge];
}

ハマった事

結論

RSAはOKでDSAはNG

ハマっている世界

iOS 5.0 は 証明書に MD5 を非サポートになったので、

keytool のデフォルト動作だと MD5withRSA なので

自己証明のSSL通信が軒並み エラーになると思っていた

SHA1withRSA とかkeystoreを作り直すと上のコード動いたと勘違いした。

安心したので,MD5の証明書でもやってみたら案の定動作したので、アレ?と思い

DSA で作成したら軒並みエラーなった。

--- 以上 ----

エラーの違い

xcode: Console

SHA1withRAS, MD5withRAS

SHA1withDAS

iPad : Safari : RSA

iPad : Safari : DSA

証明書一部

2012年1月23日月曜日

NSURLConnectionDelegateで証明書周りを適当にする方法

自己証明書だと、通信に失敗するでの軒並みOKにするには下のコードで行ける!!

おすすめはしない!!

※ コマンドラインでしか試してません ※


- (BOOL)connection:(NSURLConnection *)connection canAuthenticateAgainstProtectionSpace:(NSURLProtectionSpace *)protectionSpace {
  return YES;
}

- (BOOL)connectionShouldUseCredentialStorage:(NSURLConnection *)connection {
  return YES;
}

- (void) connection:(NSURLConnection *)conn didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge {
  NSURLProtectionSpace * protectionSpace = [challenge protectionSpace];
  NSURLCredential* credentail = [NSURLCredential credentialForTrust:[protectionSpace serverTrust]];
  [[challenge sender] useCredential:credentail forAuthenticationChallenge:challenge];
}

リンク

参考またはこうすべきサイト

サンプルコード

2011年12月6日火曜日

USB Vender ID

USBのベンダーIDの取得方法

MAC

$ system_profiler SPUSBDataType
USB:

    USB High-Speed Bus:

      Host Controller Location: Built-in USB
      Host Controller Driver: AppleUSBEHCI
      PCI Device ID: 0x3b3c 
      PCI Revision ID: 0x0006 
      PCI Vendor ID: 0x8086 
      Bus Number: 0xfa 

        Hub:

          Product ID: 0x2514
          Vendor ID: 0x0424  (SMSC)
                       ^^^^ <- vender id

Linux

$ lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
                       ^^^^ <- vender id

実行結果

参考

lsusb on OS X