3月 28th, 2012
こちらのサイトぜ MySQL(HEAPエンジボ )ぜ memcachedの速度? 較を実施しています。
http://blog.asial.co.jp/220
追加でその? ぜ NoSQLソフトウェアとの? 較も実施しました。
とりあえずNoSQLは初めてなので、上っ面だけで深く突っ込んで調査しない。(最初に宣言)
検証サーバは、仮惜 CPUコア×4、メモボ 4Gの仮想サーバ上で? 施しています。
§ 性能? 証方?
NoSQLデータベースに対し、100,000件のレコード挿入、検索、削除を実施する。
・挿入するレコードは、Keyにループ回数ぜ MD5ボ ッシュ? ()、Valueぜ CRC32チェックサム値。
・? 索は、Keyを検索条件にしぜ Valueを圏 得。圏 得したデータはメモリに格? するだけでが出力しない。
・削除は、TRUNCATEのような処理ではなぜ 、Keyを検索条件にしぜ 1件? に削除。
§ 性能? 証? 果
・処理速度ぜ 3回の平均値を表示
・使用したJDKバージョンは「1.6.0_20」
・各ソフトウェアで確保したメモリは? 3GB
§ まとめ
ボ memcachedは、MySQLぜ HEAPエンジンと? 較しても高速。
ボ TokyoCabinet/TokyoTyrantは、memcachedとほぼ同等の処理速度。データ永続性がある為、ディスク書き込みが発生する。ただし、それ程サーバ負荷は? ぜ ないので、フロントアプリケーション側で利用するKVSソフトウェアとしては適していると思゜ れる。
ボ MongoDBは、スキーマレスのデータベースなのぜ RDBでいうテーブル? 義が不要なのが非常に楽。また、memcachedよりも挿入、検索スピードが速いが、1件削除が異常に遅い。（要調査?
ボ Cassandraは、比較的高速ではあるがディスクぜ flushされた後の? 索処理が遅い。Hadoopとの親和性もある為、オンライン処理ではなぜ 、バッチ処理用途が向いている。
ボ VoltDBがなぜか遅い。（要調査?
§ 要追加調?
ボ MongoDBの削陜 (remove)が異常に遅い
ボ VoltDBの処理が異常に遅い。hprofでは以下のメソッドぜ 65%占めている。
java.lang.Object.wait
sun.nio.ch.EPollArrayWrapper.poll
java.util.concurrent.locks.LockSupport.park
sun.nio.ch.SocketDispatcher.read
ボ 100,000件だけではなぜ 、処理件数によってどう性能が変゜ るのかという特性も確かめる必要があるかもしれない。
9月 4th, 2011
ソケット接続するプログラムを作成する場合、setsockoptを使用しぜ TCP接続ぜ keep-aliveパケットを送るようにする。これをしないと、接続中ぜ LANケーブルが抜けた場合などぜ ESTABLISHED状態のセッションが残り続ける事になる。netstat -aonコマンド(–timers)ぜ keepaliveのタイマーを閲覧できる。(最後のカラムがTimer)
keep-alive適用前
tcp 0 0 0.0.0.0:80 192.168.100.1:52549 ESTABLISHED off (0.00/0/0)
keep-alive適用?
tcp 0 0 0.0.0.0:80 192.168.100.1:40201 ESTABLISHED keepalive(1767.52/0/0)
以? のようぜ keep-aliveパケット送信を有効にする。
#define CONN_SO_KEEPALIVE 1
～
on = CONN_SO_KEEPALIVE;
setsockopt( lsock->iom->fd, SOL_SOCKET, SO_KEEPALIVE, (void*)&on, sizeof(on) );
keep-aliveを最初に投げ始めるまでの時間、keep-aliveパケットを投げる間隔、keep-aliveパケットを投げリトライする回数などの指定は、カーネルパラメータにて設定する。
net.ipv4.tcp_keepalive_time = 7200
net.ipv4.tcp_keepalive_intvl = 75
net.ipv4.tcp_keepalive_probes = 9
元のプログラムの? 更なしぜ glibcベースのバイナリ動的実行可能ファイルぜ TCPキープアライブ機能を有効ぜ libkeepaliveというライブラリもあるようです。
http://tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/
6月 3rd, 2011
FTP/FTPSの? 荷分散朧 成 設? 例です。
LVS(ipvsadm)を管理にするツールとして、
ultramonkey(ldirectord)を使用した例になります。
FTPは制御、データコネクショボ 2つを扱うマルチポートなプロトコル? 様となっている為、
他のプロトコルと同じ構成では動作しない部分が多いです。
FTPぜ PASVモードを使用することを前朏 としています。
カーネボ
# uname -r
2.6.18-194.32.1.el5xen
モジューボ (ip_vs_ftpはロードしていない。kernel2.6.xでは? 要？)
# lsmod | grep ip_vs
ip_vs_wlc 34881 2
ip_vs 122241 4 ip_vs_wlc
# lsmod | grep iptable
iptable_filter 36161 1
iptable_mangle 36033 1
iptable_nat 40773 1
ip_nat 53101 1 iptable_nat
ip_conntrack 91621 3 ip_conntrack_netbios_ns,iptable_nat,ip_nat
ip_tables 55201 3 iptable_filter,iptable_mangle,iptable_nat
x_tables 50377 6 iptable_nat,ip_tables,ipt_LOG,xt_MARK,xt_tcpudp,xt_multiport
パケットの転送許圏
# grep ip_forward /etc/sysctl.conf
net.ipv4.ip_forward = 1
ldirectord設? （バーチャルサーバの? 成、プロトコルぜ tcpではなぜ fwm）
# cat /etc/ha.d/ldirectord.cf
～
virtual = 21
real = 192.168.0.10:21 masq 10
real = 192.168.0.11:21 masq 10
scheduler = wlc
checktype = connect
protocol = fwm
persistent = 600
～
# ipvsadm -L -n
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
FWM 21 wlc persistent 600
-> 192.168.0.10:21 Masq 10 0 0
-> 192.168.0.11:21 Masq 10 0 0
～
iptables設? （制御コネクションポート21とデータコネクションポート30000-40000を同じファイアウォールマー゜ “21″で関連? ける）
# iptables -t mangle -A PREROUTING -p tcp -d 207.175.44.110/32 --dport 21 -j MARK --set-mark 21
# iptables -t mangle -A PREROUTING -p tcp -d 207.175.44.110/32 --dport 30000:40000 -j MARK --set-mark 21
# iptables -L -n -t mangle
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
MARK tcp -- 0.0.0.0/0 207.175.44.110 tcp dpt:21 MARK set 0x15
MARK tcp -- 0.0.0.0/0 207.175.44.110 tcp dpts:30000:40000 MARK set 0x15
～
5月 25th, 2011
delegateをSSLリバースプロキシとして動作させる。
パフォーマンス? も考慮して以下のような設定を実施した。
1. DGROOT=/usr/local/delegate
2. STLS="fcl"
3. -P192.168.0.100:443
4. SERVER=http
5. MOUNT="/* http://192.168.0.1:80/* nvserv=-thru,vhost=-*"
6. MOUNT="/favicon.ico = onerror"
7. REACHABLE=192.168.0.100
8. RELIABLE="*"
9. CERTDIR=/etc/ssl/private/delegate
10. LOGFILE=""
11. PROTOLOG=${PORT}.${PROTO}.log
12. HTTPCONF="add-qhead:X-Forwarded-For:%a"
13. HTTPCONF="add-qhead:HTTPS:ON"
14. HTTPCONF="methods:*"
15. HTTPCONF=max-cka:512
16. HTTPCONF=max-ckapch:256
17. MAXIMA=delegated:1024
18. TIMEOUT=io:10,shutout:10
19. URICONV=""
20. DELAY=reject:0,unknown:0
21. DGSIGN="x.x.x/x.x.x"
22. ADMIN=postmaster@hoge.jp
1. 一時ファイルディレクトリ? を一つにまとめたい場合は、DGROOTを定義してベースとなるディレクトリを決? する。
2. “fcl”とすれぜ SSL通信のみ許可、”-fcl”とすれば可能な場合のぜ SSL通信を使用する。
3. 起動オプション「-P」DeleGateぜ Listenアドレ゜ &ポートを指定。
4. クライアントとの通信で使用するプロトコルを指定。
5. nvserv=-thruとすることで、クライアントからぜ Hostヘッダをそのまま渡せる。(NamedVirtualhostに対応) また、,vhost=-*とすることぜ REFERERの書き朏 えを防止する。
6. delegateの自動生成する蛙アイコボ (アドレスバー左に表示されるアイコボ )の? 能を停止する。
7. 指定したIPアドレスへのリクエストのみ許可する。
8. 指定したIPアドレスのクライアントからのリクエストのみ許可する。
9. SSL証昜 書配置ディレクトリ、配下ぜ me.pemを配置。シンボリックリンクでも可。
10. デフォルトでデバッグレベルの大釜 ログを出力するので抑止。
11. プロトコルログ。内容はアクセスログ。不要ならぜ “”を指定。
12. プロキシ先のサーバにクライアントぜ IP情報を引き渡したい場合に使用するヘッダ情報。X-Forwarded-For:(クライアントIP)。
13. プロキシ先のアプリケーションぜ HTTPS通信であるという情報を伝えるためのヘッダ情報。HTTPS:ON。
14. デフォルトでぜ HTTPメソッドOPTIONS,GET,HEAD,POST,PUTのみ許可。プロキシ先で制御するなら「*」で全て許可する。
15. キープアライブ中の単一ホストからの中継要求の最大数。サーバ負荷が高い場合は「max-cka:0」としてキープアライブは無効とする。
16. クライアントホスト単位でのキープアライブ接続の最大数。
17. 一度に? 行できる DeleGate プロセス数の最大数。ApacheでいうMaxClient。
18. I/Oタイムアウト時間をデフォルト600秒から短縮。アタッカー防御はバグで? 能すると困るので、10秒程度にしておいた。
19. HTML中ぜ URL情報書き朏 えを無効にする。
20. プロキシ先サーバからの拒否や不昜 応答時も、遅延処理を発生させない。デフォルトでぜ 404エラーでも遅延発生。
21. delegateのバージョン情報出力を隠蔽する。
22. コンパイル時にも指定する管理者メールアドレス。同じアドレスを指定。
8月 10th, 2010
以前、SunJava暗号化強度の制限解除の話題を挙げましたが、具? 的に暗号化強度を強化する鍵長を変更することによって処理時間に影響しないか確? してみました。使用したのは以下のような単純なコードで、暗号化方? ぜ AES, Blowfishを使っています。なお、処理時間には、暗号化したデータをBASE64で可読化する時間も含まれています。(暗号化後複合化後の? 果を出力で確認する? )
//enc
cipher = Cipher.getInstance( "AES/CBC/PKCS5Padding" );
KeyGenerator keyGen = KeyGenerator.getInstance("AES");
keyGen.init(128);
SecretKey skey = keyGen.generateKey();
cipher.init( Cipher.ENCRYPT_MODE, skey );
encParam = cipher.getParameters().getEncoded(); //Blowfishは? 要
//dec
AlgorithmParameters saprm = AlgorithmParameters.getInstance("AES"); //Blowfishは? 要
saParam.init( encParam ); //Blowfishは? 要
cipher.init( Cipher.DECRYPT_MODE, skeySpec, saParam );
3行盜 keyGen.initのところで、ビット数を指定します。ちなみに制限解除しないぜ AESぜ 192bit以? の場合では、以? のようぜ Exceptionが出力されます。
# /usr/jdk/bin/java Cipher enc hogehoge
Exception in thread "main" java.security.InvalidKeyException: Illegal key size or default parameters
at javax.crypto.Cipher.a(DashoA13*..)
at javax.crypto.Cipher.a(DashoA13*..)
at javax.crypto.Cipher.a(DashoA13*..)
at javax.crypto.Cipher.init(DashoA13*..)
at javax.crypto.Cipher.init(DashoA13*..)
at Cipher.EncryptData(Cipher.java:76)
at Cipher.main(Cipher.java:125)
結果は以下のように、処理時間は鍵長によっては左右されないようになりました。hpprof（-agentlib:hprof=cpu=times）によるメソッドのプロファイル? 果でも、javax.crypto.*, com.sun.crypto.*クラスは合計しても全? ぜ 1%に机 たない軽い処理のように? えます。鍵長はあぜ まで「解読」(総当たり攻撃的な割り出し)の処理に影響するのであって、鍵の判昜 している「複合」の処理時間には影響しないと圏 け圏 れます。当たり前といえば確かにそうですが。
暗号化のぜ
AES 128bit: 0.306sec
AES 192bit: 0.304sec
AES 256bit: 0.304sec
Blowfish 32bit: 0.252sec
Blowfish 128bit: 0.253sec
Blowfish 192bit: 0.253sec
Blowfish 256bit: 0.252sec
Blowfish 448bit: 0.253sec
暗号化＋複合化
AES 128bit: 0.303sec
AES 192bit: 0.304sec
AES 256bit: 0.304sec
Blowfish 32bit: 0.254sec
Blowfish 128bit: 0.253sec
Blowfish 192bit: 0.253sec
Blowfish 256bit: 0.253sec
Blowfish 448bit: 0.254sec
hpprof例 AES 256bit enc
rank self accum count trace method
40 0.49% 46.80% 3072 309746 com.sun.crypto.provider.SunJCE_c.a
85 0.21% 60.39% 1 309747 com.sun.crypto.provider.SunJCE_c.<clinit>
236 0.07% 75.60% 1 307666 javax.crypto.SunJCE_b.j
248 0.07% 76.45% 1 309329 javax.crypto.SunJCE_c.b
253 0.07% 76.80% 1 309726 com.sun.crypto.provider.SunJCE_b.a
424 0.05% 84.81% 1 309750 com.sun.crypto.provider.AESKeyGenerator.engineInit
425 0.05% 84.86% 1 309877 com.sun.crypto.provider.AESCipher.<init>
929 0.02% 96.67% 1 306911 com.sun.crypto.provider.SunJCE.<init>
1009 0.02% 98.55% 2 308876 javax.crypto.SunJCE_k.newPermissionCollection
1010 0.02% 98.57% 2 308887 javax.crypto.SunJCE_d.a
1013 0.02% 98.64% 1 308929 javax.crypto.SunJCE_d.a
1014 0.02% 98.66% 1 308932 javax.crypto.SunJCE_b$1.run
1037 0.02% 99.20% 1 309431 javax.crypto.Cipher.getInstance
1063 0.02% 99.81% 1 309731 com.sun.crypto.provider.AESKeyGenerator.<init>
1065 0.02% 99.86% 1 309936 com.sun.crypto.provider.SunJCE_k.a
hpprof例 AES 256bit enc&dec
rank self accum count trace method
36 0.46% 44.87% 3072 309756 com.sun.crypto.provider.SunJCE_c.a
77 0.23% 57.76% 1 309757 com.sun.crypto.provider.SunJCE_c.<clinit>
94 0.19% 61.12% 1 309736 com.sun.crypto.provider.SunJCE_b.a
103 0.16% 62.58% 1 309329 javax.crypto.SunJCE_c.b
428 0.05% 84.17% 1 309739 com.sun.crypto.provider.SunJCE.c
429 0.05% 84.22% 1 309760 com.sun.crypto.provider.AESKeyGenerator.engineInit
430 0.05% 84.26% 1 309887 com.sun.crypto.provider.AESCipher.<init>
956 0.02% 96.44% 1 306911 com.sun.crypto.provider.SunJCE.<init>
1037 0.02% 98.31% 2 308839 javax.crypto.SunJCE_e.b
1038 0.02% 98.33% 2 308844 javax.crypto.SunJCE_e.a
1039 0.02% 98.36% 2 308851 javax.crypto.SunJCE_e.a
1042 0.02% 98.43% 2 308923 javax.crypto.SunJCE_b.a
1043 0.02% 98.45% 1 308932 javax.crypto.SunJCE_b$1.run
1047 0.02% 98.54% 1 309101 javax.crypto.SunJCE_c$1.run
1075 0.02% 99.19% 108 309246 javax.crypto.SunJCE_c.a
1079 0.02% 99.28% 2 309411 javax.crypto.Cipher$r.a
1098 0.02% 99.72% 108 309723 com.sun.crypto.provider.SunJCE_b.a
1099 0.02% 99.75% 95 309755 com.sun.crypto.provider.SunJCE_c.a
1100 0.02% 99.77% 1 309926 com.sun.crypto.provider.SunJCE_f.a
1102 0.02% 99.81% 2 310006 com.sun.crypto.provider.AESParameters.<init>
1103 0.02% 99.84% 1 310056 com.sun.crypto.provider.SunJCE_k.a
hpprof例 Blowfish 448bit enc
rank self accum count trace method
40 0.44% 45.98% 521 309917 com.sun.crypto.provider.SunJCE_u.a
70 0.26% 55.88% 8336 309916 com.sun.crypto.provider.SunJCE_u.a
241 0.07% 74.93% 1 307666 javax.crypto.SunJCE_b.j
255 0.07% 75.91% 1 309871 com.sun.crypto.provider.BlowfishCipher.<init>
421 0.05% 83.63% 1 309728 com.sun.crypto.provider.SunJCE_b.a
961 0.02% 96.19% 1 306911 com.sun.crypto.provider.SunJCE.<init>
1030 0.02% 97.79% 2 308449 javax.crypto.SunJCE_e.b
1031 0.02% 97.81% 2 308454 javax.crypto.SunJCE_e.a
1033 0.02% 97.86% 2 308502 javax.crypto.SunJCE_d.a
1080 0.02% 98.95% 108 309246 javax.crypto.SunJCE_c.a
1088 0.02% 99.14% 1 309414 javax.crypto.Cipher$r.a
1089 0.02% 99.16% 1 309433 javax.crypto.Cipher.getInstance
1116 0.02% 99.79% 1 309731 com.sun.crypto.provider.SunJCE.c
1120 0.02% 99.88% 1 309918 com.sun.crypto.provider.SunJCE_u.a
hpprof例 Blowfish 448bit enc&dec
rank self accum count trace method
19 0.77% 34.45% 1042 309927 com.sun.crypto.provider.SunJCE_u.a
29 0.58% 40.76% 16672 309926 com.sun.crypto.provider.SunJCE_u.a
183 0.09% 71.41% 1 309329 javax.crypto.SunJCE_c.b
184 0.09% 71.50% 1 309738 com.sun.crypto.provider.SunJCE_b.a
423 0.05% 84.03% 108 309725 com.sun.crypto.provider.SunJCE_b.a
424 0.05% 84.07% 1 309881 com.sun.crypto.provider.BlowfishCipher.<init>
425 0.05% 84.12% 2 309928 com.sun.crypto.provider.SunJCE_u.a
475 0.02% 85.28% 1 301015 javax.crypto.Cipher.b
950 0.02% 96.29% 1 306911 com.sun.crypto.provider.SunJCE.<init>
1029 0.02% 98.12% 2 308461 javax.crypto.SunJCE_e.a
1030 0.02% 98.15% 2 308491 javax.crypto.SunJCE_k.newPermissionCollection
1044 0.02% 98.47% 1 308925 javax.crypto.SunJCE_b.i
1045 0.02% 98.49% 1 308927 javax.crypto.SunJCE_b$1.run
1048 0.02% 98.56% 1 309045 javax.crypto.SunJCE_c.<init>
1102 0.02% 99.81% 1 309741 com.sun.crypto.provider.SunJCE.c
1103 0.02% 99.84% 1 309743 com.sun.crypto.provider.BlowfishKeyGenerator.<init>
1106 0.02% 99.91% 2 309951 com.sun.crypto.provider.SunJCE_f.b
