2007年02月23日(金)
|
このところずっと、弊社のDICOMストレージサービス・プロダクツの パフォーマンステストを繰り返している。 ***の第2弾***
転送されるファイルのサイズと転送に伴う処理の多寡によって、転送速度に関係する要因がさまざまに変わることが分かって来た。 基本的には、TCP/IPの速度、とりわけ連続して送れる「スループット」が、上限になるのだが、ここでは、1000Base,100base,10baseでそれぞれ、確実に速度が変わる。 この場合は、転送系路上最も遅い速度に準じるので、速度自動調整式の古いハブ等が思わぬネックになることはよくある。 ただし機器によっては、Autoをmanualに変えた途端、PINGすら通らなくなるやつもあるので要注意。 さらに、Windowsの設定やBIOSの設定等でもさまざまなチューニングが、有効であることが分かっている。 CR等の比較的大きな画像を短時間で大量に送る時(過去画像コンバートや車載検査機からのDVD読み込みよるマッチング等)、最近の低価格NASは、大きく足を引っ張る。 USB外付けタイプも同様だが、この手のストレージデバイスはネックになることが多い。 通信処理と書き込み処理をうまく分離したデータフローの設計が求められるが、最後物理的に遅いものは限界がある。 旧来の高価なSCSIタイプの「本物」とは、全くものが違うのだ。 次に、マッチング処理等の通信に伴う「処理」を挟んで、送り出すタイプのゲートウエイ等においては、CPUの性能とメモリーの量、データベース関連では、一番効果が大きいのが処理速度に重点を置いたアルゴリズムだったりする。 小さな画像データが大量にやって来る場合には、CPUよりは通信関連の各種チューニングの影響が大きく出ることが多い。 テスト的には、FTPとDICOMとwindowsファイルコピーのそれぞれで試しながら、試行錯誤してチューニングしてゆく。また、Intel系のマザーを使うときは、チップセットもサーバー用だとパフォーマンスが出易いようである。 手間は掛るが、システム全体の性能を要求仕様とする医療系のユーザー向けIT導入では、 コーディングによる開発と切り離すことの出来ない大切な作業だ。 | | |