ベンチマーク手順の最適化 | 外道父の匠
ベンチマークの採取は昔から度々やってますが、オンプレ時代と比べるとクラウドではより効率的に試行できるようになりました。 聞けば当然のような内容ではあるかもですが、一度整理整頓してみるのもタメになるかと思い、ベンチ付近でマーキングする画像を用意してみた次第です。 目次 短くと心がけた結果、長くなったので。 概要 目的 課題 指針 手順 最適化 ～ 準備 パッケージ整理 インストール判断 インストール実行 イメージ保存 最適化 ～ 試験 リソース選定 分割・起動 実行・結果データ保存 最適化 ～ 集計 結果ダウンロード 数値抽出・成形データ保存 データ整理作業 考察 傾向観察 課題抽出 あとがき 概要 ベンチマークの目的・課題・全体の流れと整理していき、どのようにアプローチしていくのが最適か、ということを考察してきます。 ベンチマークには色々あります。Network, Hardware, Mi
TPCが設定したビッグデータ向けベンチマークテストは、非構造化データや半構造化データの処理、機械学習まで性能測定の対象 ［PR］
TPCが設定したビッグデータ向けベンチマークテストは、非構造化データや半構造化データの処理、機械学習まで性能測定の対象 ［PR］ 「TPC」（Transaction Processing Performance Council：トランザクション処理性能評議会）といえば、データベースの性能を計測するさまざまなベンチマークテストを策定し発表しているベンダニュートラルな団体として、多くのITエンジニアに知られているでしょう。 そのベンチマークテストは事実上の標準として受け入れられ、多くのベンダやユーザーが製品の向上や選択のために参照し活用しています。 TPCが公開しているベンチマークには、オンライントランザクション処理（OLTP）性能を計測する「TPC-C」や「TPC-E」だけでなく、大規模データ分析によるデシジョンサポートのためのデータベース性能を計測する「TPC-H」「TPC-DS」「TPC
ミドルウェア性能検証の手引き | 外道父の匠
インフラエンジニアの多分、華形のお仕事の１つであるミドルウェアの性能検証を久々にガッツリやる機会がありましたので、検証作業の基本的な項目について初心から振り返っておきたいと思います。読みやすさ度外視の詰め込み記事注意警報です。 世の中、雑な検証結果もちょいちょい散乱していて、私自身もそうならないよう注意を払っているわけですが、ガチでやると気をつける項目が多くて、自分で忘れたりしないようにと、誰かにやってもらいたい時に基本を抑えてから取り掛かってもらうために、形にして残しておこうと思った次第であります。 目次 なぜ性能検証をするのか 環境の準備 インスタンスの用意 クライアントの用意 サーバーの用意 ボトルネックになりうる項目 CPU Utilization Memory Network Bandwidth Disk Bandwidth Disk IOPS Disk Latency Disk
Node.js vs Play vs SAStruts - hakobera's blog
前置き Experiences with Node.js: Porting a RESTful Service Written in Java - ZiggyTech 上記記事では、実験的にJava (Jersey + Hibernate on Tomcat) で実装された REST API サーバを Node.js で書きなおしてみたら、少ないリソース（CPU/メモリ使用量）でほぼ同等のパフォーマンスが出せたよ（ただし、O/Rマッパーを使用しない場合）、と書いてあります。この件に関して @koichik さんとやり取りしていた中で以下のような意見を頂いたので、実際にやってみましたという記事です。 @hakobera メジャーってことだと，あの比較が Play ではなく Tomcat なのは正解．日本的には Jersey ではなく Struts (もちろん 1 の方)なら更によかったw 2
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
