s3cmdじゃなくてawscli s3を使おう～IDCFクラウドオブジェクトストレージでも | 稲葉サーバーデザイン
awscli s3のほうが、40%ぐらい速いという結果となりました。 1GBのファイル転送で71秒というのは、1024MB/71sec = 14.4MB/sec = 115.4Mbps ということで、これはIDCFクラウド S1のネットワーク帯域の上限なのかな、と感じました。 そうであれば、転送元のネットワーク状況によっては、もっと速くなるでしょう。 実際、先述の記事の場合は、同じ1GBのファイルを16秒で転送完了していますね。 なお、s3cmdのConfigは、デフォルトで、マルチパートアップロードで分割する際のサイズは15MB、送信チャンクサイズ65536となっています。 -- ~/.s3cfg multipart_chunk_size_mb = 15 send_chunk = 65536 -- awscli s3では、マルチパートに分割する際のサイズはデフォルトで8MBです。 （参考
Amazon EFSのディスクベンチマーク | 稲葉サーバーデザイン
考察 EFS (General Purpose)は、ローカルディスクEBSに比べると桁違いに遅いのですが、EC2によるNFSサーバーとはそんなに大きな違いはありません。 つまり、そもそもNFSプロトコルは遅いということです。 僕は、正式リリース前のプレビュー版のときも同様のベンチマークテストを行いました。 正直、そのときは本当にこのままリリースされていいのかな？と思うぐらい遅かったのですが、そのときに比べると、スループット、レイテンシとも大きく改善されています。 とくに、レイテンシはほぼ100msec未満で安定しています。 冗長化されたマネージドサービスでストレージ容量も自動拡張できて運用管理が圧倒的に楽なので、EC2でNFSサーバーたてるよりは、EFSを使うべきでしょう。 これで実際に本番環境で使えるのか？ たとえば、Webサイトであれば 「WordPressをEFS領域に置いてAuto
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
