タグ:ベンチマーク ( 5 ) タグの人気記事
ファイルコピーベンチマークのためダミーファイルを作りたい
今回共有フォルダでのファイル転送ベンチマークを測定しようと思ってました。
それで、ファイルサイズが小さい分と、大きい分のテストデータが必要になります。

そのダミーファイルを簡単につくる方法がないかとおもったら、有りました。
@IT:巨大なサイズのファイルを簡単に作る方法に載ってます。

fsutil というコマンドを使えば簡単にダミーファイルを作れるようです。
書式は下記のうような感じ。


fsutil file createnew ファイル名 サイズ


サイズは10進指定なので、WindowsでいうMやGの単位に合わせたいときは注意が必要ですね。(正確には2進接頭辞で表すとMi,Gi)

1Ki = 2^10 =1024
1Mi = 2^20 =1024x1024 = 1048576
1Gi = 2^30 =1024x1024x1024 = 1073741824
1Pi = 2^40 =1024x1024x1024x1024 =1099511627776

(このあたりの単位換算はWikipedia:2進接頭辞伊勢雅英のIT見聞録情報の単位を参照)


ただ、NTFSでファイルを作ったときは注意が必要なようです。
NTFSの場合、ファイルのブロックを予約するだけで実際のデータの記録はしてないようです。
ですので、fsutil でファイルを作ったら一旦コピーしてから使ったほうが無難ですね。


ファイルコピーの時間計測

コピーの時間の計測も参考元@ITにあるように、下記コマンドで測れます。

time /t && copy testfile testfile2 && time /t


しかし、これだと時間が分までしかでません。
ということで、秒単位で測るならバッチファイルにしてしまったほうが良いかと思います。

下記ようなバッチにしました。

@echo off

echo %time%
xcopy testfile testfile2 /q /i /E /Y
echo %time%
pause



これで簡単に任意のサイズのファイルを使ったベンチマークができますね。
[PR]
by Jehoshaphat | 2012-01-14 16:25 | 豆知識 | Trackback | Comments(0)
HP ProLiant GL360 G7のベンチマーク
ラックマウントサーバーHP ProLiant GL360 G7のベンチマークを、CrystalMarkとCrystalDiskMarkで測定してみました。

e0091163_0233372.jpg

CrystalMarkですが、CPUのスコアが予想以上に低かったです。
これじゃ自宅メインPCの Core i5 750 と変わりません。
と、思ったらCrystalMarkってCPU負荷は4スレッドまでしかできないのですね。
GL360 G7 は Xeon E5640(4コア+HyperThreding有) x 2CPUなので論理的には16コアある事になります。
なので、正確なスコアとしてはこの結果の値の4倍ということになるんでしょうか。。

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
CrystalMark 2004R3 [0.9.126.452] (C) 2001-2008 hiyohiyo
Crystal Dew World [http://crystalmark.info/]
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

------------------------------------------------------------------------------
CrystalMark Result
------------------------------------------------------------------------------
Display Mode : 1280 x 1024 16bit (None)

CrystalMark : 204990

[ ALU ] 48320
Fibonacci : 19280
Napierian : 11463
Eratosthenes : 5736
QuickSort : 11819
[ FPU ] 45044
MikoFPU : 5171
RandMeanSS : 23338
FFT : 8417
Mandelbrot : 8096
[ MEM ] 47841
Read : 16542.85 MB/s ( 16542)
Write : 12823.53 MB/s ( 12823)
Read/Write : 9803.38 MB/s ( 9803)
Cache : 86510.10 MB/s ( 8651)
[ HDD ] 56036
Read : 1007.57 MB/s ( 10537)
Write : 833.81 MB/s ( 9669)
RandomRead512K : 919.27 MB/s ( 10096)
RandomWrite512K : 779.18 MB/s ( 9395)
RandomRead 64K : 566.82 MB/s ( 8334)
RandomWrite 64K : 501.11 MB/s ( 8005)
[ GDI ] 811
Text : 35
Square : 278
Circle : 288
BitBlt : 210
[ D2D ] 6120
Sprite 10 : 725.05 FPS ( 72)
Sprite 100 : 492.60 FPS ( 492)
Sprite 500 : 221.55 FPS ( 1107)
Sprite 1000 : 136.54 FPS ( 1365)
Sprite 5000 : 27.82 FPS ( 1391)
Sprite 10000 : 16.93 FPS ( 1693)
[ OGL ] 818
Scene 1 Score : 796
Lines (x1000) : ( 84378)
Scene 1 CPUs : ( 16)
Scene 2 Score : 22
Polygons(x1000) : ( 169)
Scene 2 CPUs : ( 1)

------------------------------------------------------------------------------
System Information
------------------------------------------------------------------------------
OS : Windows NT6.1 Enterprise Edition (Full installation) [6.1 Build 7600]
Display Mode : 1280 x 1024 16bit
Memory : 24566 MB
DirectX : 10.0
------------------------------------------------------------------------------
CPU
------------------------------------------------------------------------------
CPU Name : Intel
Vendor String : GenuineIntel
Name String : Intel(R) Xeon(R) CPU E5640 @ 2.67GHz
CPU Type : Original OEM processor
Number(Logical) : 16
Family : 6
Model : C
Stepping : 2
Feature : MMX SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 XD Intel 64
Clock : 2666.82 MHz
Data Rate : QDR
------------------------------------------------------------------------------


次に、CrystalDiskMarkの結果です。

e0091163_0233170.jpg


-----------------------------------------------------------------------
CrystalDiskMark 3.0.1 x64 (C) 2007-2010 hiyohiyo
Crystal Dew World : http://crystalmark.info/
-----------------------------------------------------------------------
* MB/s = 1,000,000 byte/s [SATA/300 = 300,000,000 byte/s]

Sequential Read : 1040.082 MB/s
Sequential Write : 864.448 MB/s
Random Read 512KB : 907.405 MB/s
Random Write 512KB : 796.785 MB/s
Random Read 4KB (QD=1) : 64.653 MB/s [ 15784.4 IOPS]
Random Write 4KB (QD=1) : 60.173 MB/s [ 14690.6 IOPS]
Random Read 4KB (QD=32) : 271.124 MB/s [ 66192.3 IOPS]
Random Write 4KB (QD=32) : 252.694 MB/s [ 61693.0 IOPS]

Test : 100 MB [C: 63.0% (126.0/200.0 GB)] (x5)
Date : 2011/06/01 0:00:00
OS : Windows Server 2008 R2 Enterprise Edition (Full installation) [6.1 Build 7600] (x64)

かなり高速です。
さすがはディスク4台のRAID5ですね。
ディスクはSAS2.5インチの1000prmでした。
e0091163_023365.jpg



このようなサーバ機触っていると普通のPCが遅く感じます。
[PR]
by Jehoshaphat | 2012-01-10 00:25 | ハードウェア | Trackback | Comments(0)
(ネットワーク)回線速度測定ツールNetPerfを使ってみた

(ネットワーク)回線速度測定ツールJperfを使ってみた ではIperfをラッピングしたGUIベースのJperfを紹介しました。
しかし、JperfでUDPで測定すると、「WARNING: did not receive ack of last datagram after 10 tries.」 とか 「read failed: Connection reset by peer」と表示され、うまく測定できません。(バージョンは2.0.2です。)
また、UDPは測定時に帯域幅(UDP Bandwidth)を指定するのも意味が分かりませんし、どれくらいパケットロスしたのかも分かりません。

ということで、さらにネットワークベンチマークソフトを探してみたところ、NetPerfというのを見つけました。
ダウンロードはftp://ftp.cup.hp.com/dist/networking/benchmarks/netperf/からできます。(メインはLinux向けのようですが、ちゃんとWindows用のバイナリも有ります)

使い方ですが、サーバ側となる方は、下記のようにサーバ用のexeを起動しておくだけでOKです。(デフォルトだとポート12865が使われます)

>netserver-2.1pl1.exe
Starting netserver at port 12865


TCPのスループットを計測する場合は、クライアントで下記のようにします。

>netperf-2.1pl1.exe -H 192.168.0.10

結果は下記のようになります。

TCP STREAM TEST to 192.168.0.10
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec

8192 8192 8192 10.00 20.57

RecvSocketSizebytesというのが受信側のソケットバッファでしょうか。デフォルトは8KBのようです。
SendSocketSizebytesというのが送信側のソケットバッファでしょうか。デフォルトは8KBのようです。
SendMessagebytesが送信パケットサイズでしょうね。これもデフォルトは8KBのようです。
ElapsedTimesecsが測定秒数のようです。デフォルト10秒です。
結果が、Throughput 10^6bits/sec ですね。Mbpsで表現されるようです。今回だと、93Mbpsという結果になりました。

オプションは下記のようになっています。

Usage: netperf [global options] -- [test options]

Global options:
-a send,recv Set the local send,recv buffer alignment
-A send,recv Set the remote send,recv buffer alignment
-c [cpu_rate] Report local CPU usage
-C [cpu_rate] Report remote CPU usage
-d Increase debugging output
-f G|M|K|g|m|k Set the output units
-F fill_file Pre-fill buffers with data from fill_file
-h Display this text
-H name|ip Specify the target machine
-i max,min Specify the max and min number of iterations (15,1)
-I lvl[,intvl] Specify confidence level (95 or 99) (99)
and confidence interval in percentage (10)
-l testlen Specify test duration (>0 secs) (<0 bytes|trans)
-o send,recv Set the local send,recv buffer offsets
-O send,recv Set the remote send,recv buffer offset
-n numcpu Set the number of processors for CPU util
-p port Specify netserver port number
-P 0|1 Don't/Do display test headers
-t testname Specify test to perform
-v verbosity Specify the verbosity level
-W send,recv Set the number of send,recv buffers

グローバルオプションを指定し、テストオプションを指定するという感じですね。
テストオプションで、メッセージ長やソケットサイズが指定できます。

テストオプションは下記のような感じです。

TCP/UDP BSD Sockets Test Options:
-D [L][,R] Set TCP_NODELAY locally and/or remotely (TCP_*)
-h Display this text
-m bytes Set the send size (TCP_STREAM, UDP_STREAM)
-M bytes Set the recv size (TCP_STREAM, UDP_STREAM)
-p min[,max] Set the min/max port numbers for TCP_CRR, TCP_TRR
-r bytes Set request size (TCP_RR, UDP_RR)
-R bytes Set response size (TCP_RR, UDP_RR)
-s send[,recv] Set local socket send/recv buffer sizes
-S send[,recv] Set remote socket send/recv buffer sizes


例えば送信ソケットサイズ64KB,メッセージサイズ64KBとするには下記のようにします。

netperf-2.1pl1.exe -H 192.168.0.10 -- -m 64512 -s 64512
TCP STREAM TEST to 192.168.0.10
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec

8192 64512 64512 10.00 93.00




UDPで測定するときは下記のようにします。

>netperf-2.1pl1.exe -H 192.168.0.10 -t UDP_STREAM -- -m 1024

結果は下記のようになります。

UDP UNIDIRECTIONAL SEND TEST to 192.168.0.10
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # 10^6bits/sec

64512 1024 10.00 111620 0 91.44
8192 10.00 85967 70.42

上段が送信、下段が受信側の結果のようです。
Messages Okay というのはどれくらいのメッセージを送信したかの数のようです。
送信時は 91Mbps も送信してるのに、受信時は 70Mbps になってますね。これはUDPのパケットが途中でロスしたからだと思われます。
ということで、実の実行スループットは下段の Throughput 10^6bits/sec になるようです。
LAN内だとあまりパケットロスしないですが、上記のテストのようにWAN(VPN)だとかなりUDPはパケットロスするのが分かります。


より詳しい使い方やオプションは下記参考サイトが役立ちます。
Netperf - TECHNERD::INIT:
Netperf でLANをチェック:
P2P@i 開発メモ: netperfを使った測定
netperfでネットワークパフォーマンスを測定
netperf の使い方 - takatan blog
[PR]
by jehoshaphat | 2011-08-26 12:11 | ネットワーク | Trackback | Comments(0)
(ネットワーク)回線速度測定ツールJperfを使ってみた
仮想化のキャパシティプランニングでそのサーバが実際どれくらい転送能力があるのかを測定する必要が出てきました。
(NICやスイッチは1Gbpsなんですが、実測は違いますからね。。)

ということで使ってみたツールが Jperfというものもです。(ほんとに費用掛けて評価するならSmartBitsとかIXIAとかを使うこともできるんですが。。)
これは Iperf というツールのGUI版みたいです。
(上記リンク先からダウンロードできるのはソースのみです。IperfのWindowsバイナリは Jperf の bin フォルダ内にありました。Linuxで使いたいときは #./configure → #make → #make install ってする必要があります。参考元:ネットワークのスループット測定Linux編(nuttcp、Iperfのインストール))

Javaで書かれてるのでJREが必要ですが、Linuxとかでも動くのはうれしいですね。
ダウンロードは Google Code本家のページからできます。
(Linuxで Jperf 動かすには上記にあるように Iperf のソースをコンパイルしてパスを通しておく必要があります。CentOSで既定の設定でビルドすると /usr/local/bin/iperf が作成されます。ここはパスが通っているようです)

デフォルトだと TCP のパケットサイズは 8KB なので適宜サーバの用途に合わせて調整は必要かもしれません。
(ファイルサーバとかだともっと大きい値を指定しないといけないでしょうしね。)

結果がグラフででるのも好感です。

いくつか測定してみたのでスクリーンショット載せてみます。

↓100MbpsのLANでデフォルトの設定で測定したものです。(TCPパケットサイズ8KB)平均49Mbpsです。時間経つうちにスループットが落ちてます。
e0091163_8174555.jpg



↓100MbpnのLANでTCPパケットサイズを1MByteで測定したものです。平均83Mbps出てますね。
e0091163_8174760.jpg



↓OpenVPNを使ってインターネットVPN拠点との速度を測定したものです。設定値はデフォルトです。平均1.1Mbpsです。パケットサイズが小さいとオーバヘッドが大きいのでスループットは落ちますね。
e0091163_8173280.jpg



↓OpenVPNでTCPパケットサイズを1Mbpsにしたものです。平均7.7Mbpsです。やはり安定してますね。
e0091163_8174062.jpg



↓Linuxでサーバとして動かしたときのイメージです。
e0091163_8174278.jpg



参考:
Bio & Ubiq Weblog Iperfの場所
iperfの使い方


補足というか修正

上記で、Jperf の Buffer Length という項目(Iperfだと-lオプション)が、テストを行う 「TCPのパケットサイズ」 というように説明してましたが、これは間違いのようです。
正しくは、read、writeするときのバッファ長のことのようです。(デフォルトはTCP:8KB、UDP:1470B)
なので、あまり気にする項目ではなさそうです。このバッファにデータが溜まったら、Jperfに通知するというのものみたいですね。余りに大きい値にするとバッファに溜まるまではJperfに通知しないので、結果が乱高下した感じになります。
(ただ「10GbE で性能出そうと思ったら、これだと小さすぎるので、-l 64kとか128kにするとよいかも」ということが、ここに書かれてました。)

重要なのは TCP window size サイズですね。WindowsとかだとRWINと呼ばれており、一時期ブロードバンド回線ならこの値を大きくすることでネットの高速化につながるというような情報もちらほら見られました。
(ウィンドウサイズというのはTCPにおいて、送信側のパケットに対して受信側が毎回のACK(受信確認)を返すと効率が悪いので、送信側が複数のパケットを送信し、その複数パケットに対してまとめて1回のACKを返すというウィンドウ制御で、どれくらいのパケットが来たらACKを返すかというサイズです。詳しくは@IT:基礎から学ぶWindowsネットワーク 1.信頼性のある通信を実現するための仕組みRWINを調節する意義や、ウィンドウとは -- Key:雑学事典が参考になります。)

参考追加:
Iperf version 1.7.0(英語)
Iperfの使い方 - TECHNERD::INIT
[PR]
by jehoshaphat | 2010-11-13 08:20 | ネットワーク | Trackback | Comments(0)
EFSを使ったらどれだけパフォーマンスに影響するのか調査してみた
新しいHDDをかったので重要なドキュメント類は暗号化して保存しようと考えています。
最初パフォーマンスの影響も余り少なく強度な暗号化が期待できる BitLocker を使おうと思っていたんですが、これVista以降じゃないとだめなんですよね。(パフォーマンスについてはASCII.jp:Vistaの暗号化機能 BitLockerを本気で試してみた |ここが変わったWindows Vista 100連発!参照)
現在メインPCはWindows7とXPのデュアルぶーとで両方から重要ファイルにアクセスしたいので、BitLockerは断念しました。

次に思いついたのがNTFSファイルシステムで以前のOSから使える EFS です。
EFSだとBitLockerのようにドライブ単位ではなく、ファイルフォルダ単位で暗号ができるのも特徴ですね。

さて、このEFSですが、以前にパフォーマンスがよろしくないという記事を読んだことがあります。
それで、実際自身のPCで測定してみました。

測定環境は下記のとおりです。
CPU:Pentium4 530J(3.0GHz)
Memory:1.5GB
HDD:Hitachi HDT725032VLA360

以前の記事でも書きましたが、3流PGのPCはWindows7で動かすとかなり重いです。
それを踏まえ WindowsXP と Windows7 の両方でテストしてみました。

測定方法ですが、小サイズのファイル1000個(合計24MB)と、700MBのファイルにおいてそれぞれ、通常のノーマルコピー、非EFS領域からEFS領域へのコピー、非EFSファイルをプロパティから暗号化、EFSファイルのコピー、EFSファイルから非EFSファイルへの暗号化解除のテストを行います。なお、コピーについてはWindowsエクスプローラとフリーソフトのFireFileCopyの両方で測定してみました。

結果はこんな感じとなりました。
e0091163_15334849.jpg


FireFileCopyをのぞいた結果をグラフにしたものが下記です。
e0091163_15341436.jpg


やはりEFS化するとかなりパフォーマンスが悪くなるようです。
プロパティから暗号化や暗号化解除のパフォーマンスが悪いのは、この時いったん一時ファイル(efs0.tmp)を作りながら処理してるからのようですね。この一時ファイルですが、削除済みの平文データが復元される場合があるによると、一時ファイルから暗号からされたファイルの平分データが読み取れてしまうようです。
パフォーマンスやセキュリティを考えると、EFS化するときは、プロパティからするのではなく、EFS有効のフォルダにコピーするという運用がよさそうですね。
また、3流PGのPCではやっぱりWindows7のほうがほとんどで遅い結果になっていますね。
小さいファイルで数が多い場合の暗号化操作はかなりパフォーマンスの影響度も高いこともわかります。

さて、予想以上にパフォーマンスへの影響が高いEFSですが、暗号化するべきか否か悩みどころですね。。。。
[PR]
by jehoshaphat | 2009-12-12 15:34 | 豆知識 | Trackback | Comments(0)