ぢろーらものおもちゃ箱:引っ越し後

写真付きで日記や趣味を書くならgooブログ

ボディパンプ:ラストレッスン

2010-05-29 14:32:21 | フィットネス

今日の午前中、いつもどおり地元のフィットネスクラブでボティパンプを受けに行きました。ただし、いつもと違うのは、今日は以前からお世話になっていたイントラさんの最終レッスン、ということです

なんでも家庭の事情で仙台に帰ってしまうとのこと。まあ、会社自体を辞めるわけではなく、仙台方面に異動届を出したらしいです。まあ、それなら仕方ないか・・・確か、6年くらいいたはずです。そっか、そんなに経つか・・・。

ラスト、ということで曲自体もイントラさんが好きな曲をチョイス。そのこともあり45分クラスでしたが、けっこうみんな盛り上がっていましたけっこうきつい曲が多く、ぢろーらもは昨日の疲れもあり珍しくベンチプレスでつぶれてしまいました。最後の肩の曲もやっぱりバーオンリーのあれか・・・きついってば・・・「(^^;)。でも、楽しかったですよ。

本当のラストは夜のボディアタックなので、イントラさんはまだまだ勤務時間が続きます。クラスが終わっても余韻にひたる暇もなく、すぐに次の仕事にはいっていました。

ひとまず、これで最後になってしまうので、挨拶と握手のみしてきました。

いままでありがとうございました。仙台に行っても元気に過ごしてくださいね。


この記事が気に入りましたら、また、お役に立ちましたら、以下のアイコンをクリックしていただけると嬉しいです(^^)

ブログランキング・にほんブログ村へ



回線のスループット測定

2010-05-29 03:07:02 | IT(ネットワーク&セキュリティ)

こちらも仕事ですが、回線のスループット(実効速度)を動的に測る、という話題がでました。

スループットの測定とかだと、ぱっとイメージしやすいのは、RBB TODAYやgoo、BNRなど、インターネットのスピードテストのサイトですかね。まあ、これについてもなんとなくわかっている、というくらいなので、ちょっと調べてみました。

スピード測定のサイトもいくつかあり、それぞれJavaのアプレットを使用するもの、Flashを使用するものなどいろいろありますが、基本となる考え方としては、ファイルをダウンロード/アップロードのように、データのやりとりを行なった際にかかった時間からスループットを計算しています。

各方式の比較については http://netspeed.studio-radish.com/aboutnetspeed.html や http://mpw.jp/blog/2009/10/45.html などが参考になります。少し古い情報になりますが、RBB TODAYではユーザ側にJavaアプレットをダウンロードさせ、そのプログラムで測定を行うようです。このプログラムではFlashやJavaScriptを使用する場合と異なり、HTTPを使用しないので、汎用的な基準であるTCPスループットが測れるという利点はあります。

次に、各スピード測定サイトの比較ですが、RBB TODAYはプロバイダ間を相互接続するIXに接続されたサーバ、Gooはデータセンターに接続されたサーバとの間で測定をします。これに対して、NTTのフレッツ・スクウェアの場合はパソコンからフレッツ・スクウェア(東京に設置したサーバ)までが測定対象です。

もちろんNTTのアクセス回線を経由してISP(プロバイダ)からインターネットを使用する(契約しているのがNTT回線ならこのパターン)のであれば、「フレッツ・スクウェアの結果はいいけど、ほかのスピードテストの結果が悪いか、それともフレッツ・スクウェアの時点で悪いか」ということから、ある程度の問題切り分けはできるのかな、と思います。

ただし、IXやデータセンターに接続されているサーバに対しての計測であれば、結局はいろいろな要因によってまちまちな結果しか得られないようです。基本的には測定結果はアクセス回線の部分に大きく依存するとはいえ、RBB TODAYにしても、当然ユーザが契約しているISPによって経路も違うでしょうし、サーバの負荷状況なんかもあるかもしれません。当然「サイトAへの通信は速いけど、サイトBへの通信は遅い」ということもありえます。

あと、測定に関してはクライアント側のスペック(あまり低すぎるとサーバとやりとりするデータを処理しきれない)、スイッチングハブ等のネットワーク機器の速度(いまどき10Base-Tは少ないと思いますが、オートネゴシエーションが失敗して半二重通信になっていた)なども影響します。

結局は、絶対的な基準というのはないようです。まあ、あくまで参考値でしょう。

上記はインターネット回線、というくくりになりますが、会社の拠点間の通信であればまた別の方法があります。簡単なところでは、拠点間にそれぞれクライアント-サーバ(こちらはあくまで「役割」の問題なので、サーバはサーバOSでないといけない、ということではありません)を用意し、Iperfなどのスループット測定のソフトをいれて両者間で通信させてスループットを測る方法はあります。Iperfについてはhttp://homepage2.nifty.com/protocol/iperf/iperf.htm などが詳しいです。Iperfはフリーのもので手軽に使えるようです。もっと専門的なものであれば、ネットワーク機器メーカーなどが使用するSPIRENT TestCenter(主にL2/L3の測定。IP層レベルで比較的単純なパケットを作って大量に流せる。たとえば、負荷がかかった状況でルーティングがうまくいくか、などを見れる)やAvalanche(主にL4/L7トラフィックの測定。HTTPなどアプリケーションのシーケンスまで考慮した負荷テストができる)などがあります。これらの機器は普通のPC使うよりも大量のデータを流すことができる、というのもありますし、フレームサイズやパケットの送信量、送信間隔、の柔軟な調整、HTTP/SMTP/CIFSなどのアプリケーションの疑似トラフィック送信など、いろいろと豊富な機能があります。

あと、拠点間の通信でいえば興味深いのはYAMAHAルータが対応している帯域検出機能があります。こちらも対向のYAMAHAルータ同士をIperfを使うのと同じようにクライアント/サーバの役割を持たせてスループットの測定をします。この場合、一定時間ごとにスループットを自動的に測定するので、測定結果のスループットをQoSに反映できるので、より精度の高い帯域制御が可能になります。測定方法に関しても、IperfなどでUDP通信を行うとそれ自体が回線を圧迫してしまうことがありえるので、スループット測定方法についても工夫されているようです。

(参考サイト http://www.rtpro.yamaha.co.jp/RT/docs/pdf/bandwidth-measuring-20060424.pdf http://www.rtpro.yamaha.co.jp/RT/docs/bandwidth-measuring/ )

我々に関係ありそうなのは後者のほうかもしれません。機会あればこちらももう少し勉強しておこうかな・・・。


この記事が気に入りましたら、また、お役に立ちましたら、以下のアイコンをクリックしていただけると嬉しいです(^^)

ブログランキング・にほんブログ村へ