プロフィール

Author:けい
公開したWebサービス・アプリ一覧はこちら

※2014年12月、私が個人で開発したWebサービス・アプリへの
累計アクセス数は8億を超えました。
負荷対策頑張ります。日々精進していきます!!


■■■ 業務経歴 ■■■
社会人1年目:携帯電話開発。画面周りを1年間
2年目 :海外向け携帯電話ミドルウェア開発
     ブラウザとプロトコルスタック周り
2年目後半~:携帯電話の通信専用チップ開発
3年目:カーナビ。画面周りの開発
3年目後半~:BDビデオカメラ
     組み込みLinux カーネルと
     ドライバの開発。
4年目12月:プロジェクト途中で退社
~ここまではC、またはC++で開発~

~ここからJavaがメインの開発~
4年目1月:Web系の会社に転職
       ~4ヶ月間の研修
5年目5月:製造業向け生産管理システム開発
6年目9月:証券会社向けシステム開発
7年目10月~携帯電話向けコミックサイトの運用・開発
8年目12月:プロジェクト途中で退社

~ここからPHPがメインの開発~
8年目1月~仲介手数料が無料の不動産屋の社内SEに転職
交渉しほぼ完全に裁量労働が可能な立場になる。
業務内容はシステム全般ですが、
最近はSEO対策の作業が多いです。
現在14年目 まだ、しばらくはこの会社に居るつもりです。

あと、全ての記事がリンクフリーです。

最近の記事

過去ログ

全ての記事を表示する

全ての記事を表示する

カテゴリー

FC2カウンター

RSSフィード

SSL証明書を購入する際に4096bitの証明書を買ったらCPU負荷が半端ない件

どうも何か4年に一度くらい暗号化でトラブっている開発者です。
今回は証明書の話なのですが、皆様証明書の暗号化bit数って気にされておりますでしょうか?
1024bit は既に購入ができなくなっており、今後1024bit 未満のHPは
ブラウザ側で警告を出すなどの方針をマイクロソフトは示しています


そして現在、証明書の購入時には
2048bit or 4096bitとという実質2択の選択肢を提示されるわけです。
ここで私は思ったわけです。
新たに証明書を買うのであれば値段も変わらないので、2048bitの証明書よりも
4096bitの証明書を買ったほうが、より安全性をアピールできるのではないか?



結果
CPU使用率とトラフィック

2048bit
newcpu-day.png
new133_242_176_152_2-day.png


↓↓↓↓↓↓↓↓


4096bit
CPU
トラフィック



ま、まさかCPU負荷が2倍近くになるなんて予想外でした。



何か対策があるのかと思い調べてみたところ、
都市銀行やCIA, NSAですら2048bit!
一応、1024bitも未だに解読は行われておりませんし(解読は8年後くらいと予想されています)、
2048bitでも今後20年以上は解読されないと予想されています。

つまりどれだけ重要なデータを扱う機関でも
2048bit の証明証を使用しているわけです。


となると不思議に思うのが、4096bit って誰得なの?という点。


結論から言えば、暗号化は現在は1024bitあれば十分過ぎる状態で、
10年くらい破られなければ良い、という観点で見れば、
殆どのwebサイトが1300bit くらいの暗号化強度がCPU負荷的にもベストプラクティスなのでは?と思いました。

何か1024bitの次は2048bitじゃなきゃいけない理由ってあるのでしょうか?
CIAみたいな情報機関ならばともかくとして、一般人であればクレジットカードや個人情報に
そこまでの価値はないですよね。

仮に10年後に解読できたとしても
10年前のクレジットカード情報や個人情報がそこまで価値があるとも思えないですし、
費用対効果で考えれば情報は名簿屋で、お金さえ出せば最新情報が購入可能です。

私も何となく2048bitの証明書を購入しているわけですが(笑)、
検討した上でより低い、1500bitくらいの暗号化を行っている事例などがあれば教えて下さい。

スポンサーサイト
コメント(0)   2013.11.16    [ Myカテゴリ:未分類 ]

今更ですがWeb負荷測定ツール abの使い方

基本的な使い方は以下のようにテストを行いたいURLに対して
リクエストを発行する。

$ ab -n 100 -c 10 https://ウェブサーバー名/test.html

-n はテストで発行するリクエストの回数でこの数値が大きければ
より長時間テストを行うので精度は上がる。
何かのタイミングを狙うのでなければ100で十分。
特に本番環境に対して何かの確認を行うのであれば100以上にしてはいけない。

-c 同時に発行するリクエストの数。
こちらが同時接続数を表すので、どれくらいの負荷に耐えられるのかは
この数値を用いる。


実行例
$ ab -n 1000 -c 10 https://ウェブサーバー名/test.html
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking ウェブサーバー名 (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Finished 1000 requests


Server Software: Apache/2.2.3
Server Hostname: ウェブサーバー名
Server Port: 443
SSL/TLS Protocol: TLSv1/SSLv3,DHE-RSA-AES256-SHA,4096,256

Document Path: /test.html
Document Length: 8592 bytes

Concurrency Level: 10
Time taken for tests: 47.588888 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 8915323 bytes
HTML transferred: 8592000 bytes
Requests per second: 21.01 [#/sec] (mean) ※ここの数値が秒間処理リクエスト数となる
Time per request: 475.889 [ms] (mean)
Time per request: 47.589 [ms] (mean, across all concurrent requests)
Transfer rate: 182.94 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 144 347 315.4 268 5541
Processing: 76 125 77.4 110 1033
Waiting: 48 92 69.8 80 1002
Total: 229 473 333.6 394 5622

Percentage of the requests served within a certain time (ms)
50% 394
66% 446
75% 491
80% 537
90% 735
95% 932
98% 1264
99% 1507
100% 5622 (longest request)


アクセス中のサーバー側の $ vmstat 10
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
2 0 76 96440 179424 1507060 0 0 0 52 1108 317 15 1 84 0 0
0 0 76 96068 179424 1507080 0 0 0 22 1074 196 9 1 91 0 0
1 0 76 100284 179424 1507100 0 0 0 38 1075 233 9 1 90 0 0
26 0 76 53556 179424 1503444 0 0 0 53 1533 336 98 2 0 0 0 #プロセスとcpuのsystemが上昇
12 0 76 56892 176776 1487420 0 0 0 109 1528 367 98 2 0 0 0 #が上昇
16 0 76 68892 176776 1487492 0 0 0 61 1572 424 98 2 0 0 0
11 0 76 73400 176780 1487548 0 0 0 73 1541 359 98 2 0 0 0


abでは問題無かったため、実運用してみたところ↓


$ vmstat 10
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 0 908 100648 29800 1533076 0 0 256 228 1677 1101 65 3 32 0 0
0 0 908 123352 29844 1535844 0 0 256 86 1699 1144 72 3 24 0 0
0 0 908 130180 29876 1538132 0 0 205 100 1662 1090 64 4 32 0 0
9 0 908 133224 29900 1540504 0 0 231 99 1639 998 62 3 35 0 0
18 0 908 98904 29944 1542428 0 0 154 81 1766 1127 85 4 11 0 0
8 0 908 101620 30012 1545792 0 0 333 121 1714 1158 72 4 24 0 0
4 0 908 109612 30060 1547788 0 0 182 214 1626 1139 70 4 26 0 0

abの場合、procやcpuが大変な状態になったのだが、
実運用してみたところ
ioの bi、boや systemの in、csが大変なことに。


更にload average 6とかの超高負荷時
r b swpd free buff cache si so bi bo in cs us sy id wa st
3 0 908 340916 29040 1313884 0 0 0 83 1546 1083 78 4 18 0 0
11 0 908 344636 29064 1314032 0 0 0 81 1625 1124 88 4 8 0 0
3 0 908 342404 29124 1314240 0 0 0 118 1550 1254 77 4 18 0 0
3 0 908 355796 29136 1314516 0 0 0 73 1525 1050 73 3 24 0 0
5 0 908 366212 29148 1314572 0 0 0 111 1474 1025 65 3 31 0 0
2 0 908 368940 29208 1314756 0 0 0 159 1463 1022 64 3 33 0 0
2 0 908 365840 29244 1314900 0 0 0 171 1476 952 66 3 30 0 0
5 0 908 356664 29256 1315088 0 0 0 66 1495 996 66 3 31 0 0
0 0 908 369064 29284 1315388 0 0 0 90 1531 1120 70 4 27 0 0
3 0 908 381960 29332 1315460 0 0 0 103 1597 1166 79 4 18 0 0
0 0 908 404156 29348 1315696 0 0 0 97 1502 1015 72 3 25 0 0
3 0 908 392252 29400 1315912 0 0 0 164 1486 991 77 4 19 0 0
1 0 908 403908 29424 1315940 0 0 0 112 1418 862 63 3 34 0 0
26 0 908 385432 29448 1316220 0 0 0 183 1567 928 84 4 12 0 0
3 0 908 337196 29524 1316284 0 0 0 159 1532 1206 91 5 4 0 0
1 0 908 356044 29540 1316552 0 0 36 120 1564 1107 77 4 18 1 0



Requests per secondが低いのでこれを10倍くらいにしたいです。
余談ですがアクセスが増大して負荷が問題になるっていうのは
エンジニアにとっては幸せな喜びなのかもしれないですね。
コメント(0)   2013.11.07    [ Myカテゴリ:未分類 ]
Template Designed By
ぐらいんだぁ