JMH - Javaでのベンチマークを試してみる - 覚えたら書く
OpenJDK のサイトで公開されているマイクロベンチマーク用のライブラリ。Java Microbenchmark Harness の略。 JMHの存在理由 Javaでパフォーマンス測定（ベンチマーク取得）するのは以下のような理由により簡単ではありません 計測用のコードを書くのが実は難しい 計測用のコードの書き方がまずいと、コンパイラにより最適化で処理部分を削ってしまう場合がある ウォームアップが必要 JITコンパイラによってコンパイルされているかどうかで測定結果が大きく異なる こういう問題を解消して計測してくれるのがJMHです。（OpenJDKで公開されているので、Java公式ツールといってよいでしょう） 使い方（概要） JMHを使った計測の流れは大まかに以下の通りです（Mavenを用いてIDE上で実行する例です） JMHでの計測用のMavenプロジェクトを作成する ↓ 計測したい処理を
GitHub - alibaba/arthas: Alibaba Java Diagnostic Tool Arthas/Alibaba Java诊断利器Arthas
Often times, the production system network is inaccessible from the local development environment. If issues are encountered in production systems, it is impossible to use IDEs to debug the application remotely. More importantly, debugging in production environment is unacceptable, as it will suspend all the threads, resulting in the suspension of business services. Developers could always try to
JVMアプリケーションのCPUボトルネックをasync-profilerで調べてみる | DevelopersIO
こんにちは、事業開発部の齋藤です。 ここ最近ずっと負荷試験をやっていました。 今日はJVMのアプリケーションのプロファイルを取ることが出来る、「async-profiler」を使ってみたので そのツールの紹介記事です。 はじめに 今回使ってみよう、というきっかけになったのは 負荷試験実行中にやけにCPU負荷が高い、ということで プロファイラを試してみるか、という話になりました。 このasync-profilerを選んだ理由は 単に知っている中で一番楽に使えそう、というので選びました。 また、Javaのプロファイラはいくつか商用製品もあるみたいなのですが 今回はちょっと調べてみたい、ということでasync-profilerを選びました。 今回の記事ではprofilerを掛けて 「Flame Graph」というグラフを見るところまでをやってみます。 詳しくは以下の流れでやっていきます。 インス
GitHub - async-profiler/async-profiler: Sampling CPU and HEAP profiler for Java featuring AsyncGetCallTrace + perf_events
This project is a low overhead sampling profiler for Java that does not suffer from the Safepoint bias problem. It features HotSpot-specific API to collect stack traces and to track memory allocations. The profiler works with OpenJDK and other Java runtimes based on the HotSpot JVM. Unlike traditional Java profilers, async-profiler monitors non-Java threads (e.g., GC and JIT compiler threads) and
JDK8(Linux 64bit)のデフォルトヒープサイズ - n-agetsumaの日記
Oracleの公式ドキュメントには、-Xmxが未指定であった場合のエルゴノミクスによる最大ヒープサイズは『32GBを上限として、物理メモリの4分の1』書かれている。32GBは-XX:-UseCompressedOopsにより圧縮Oopを明示的に無効にした場合の最大デフォルトヒープサイズで、何もオプションを付けずに起動した場合は29GBが上限。 ヒープサイズの決定はarguments.cppのArguments::set_heap_size()で計算されている。デフォルトの最大および初期ヒープサイズは、物理メモリ量により異なる。 デフォルト最大ヒープサイズ(-Xmx) 物理メモリが248MB以下の場合 物理メモリの2分の1。 248MBは-XX:MaxHeapSize(デフォルト124MB) x -XX:MinRAMFraction(デフォルト2)の値。 物理メモリが248MBより大きい場合
JVMのヒープサイズとコンテナ時代のチューニング | Folioscope
最近 JVM のヒープ領域とパラメータ、そしてコンテナの関係について調べてました。 案外まとまった情報が少なかったので簡単にまとめました。 Java のヒープサイズを設定 まずは Java のヒープサイズについて簡単なおさらいです。 本番環境で Java アプリケーションを運用する上で、JVM のヒープサイズを決定するのは非常に大事なポイントです。 ヒープ領域の最大サイズを大きくすればガベージコレクション (GC) の回数は減らすことができますが、 必要以上に大きくしすぎると無駄にリソースを消費したり、OOM killer で OS にプロセスを終了させられます。 JVM が使用できるヒープサイズは、Java API の Runtime.getRuntime().maxMemory() で確認できます。 また java の起動オプションに -XX:+PrintFlagsFinal オプショ
JVMアプリケーションを運用する際のメジャーどころチューニングポイントメモ - yoskhdia’s diary
JVMにチューニング項目は多々あれど、プロダクションで運用する際に予めおさえておきたい項目をまとめてみるエントリです。*1 勿論、OSもJVMもデフォルトである程度のパフォーマンスは発揮でき、計測を伴わないチューニングは悪手であることはよく知られています。 しかし、設定しておかないとパフォーマンスにそのまま影響すると分かるものを調べないのは裸で戦場に赴くようなものです。*2 どんな項目をどう変更すれば良いのか知っていることは重要な武器なのです。 なぜ調べるのか 今回、チューニングポイントを調べるにあたって、私のモチベーションはどこにあるのかを考えると、以下の要件を満たしたいということがあげられます。 アプリケーションとして求められる品質水準として動作する → 性能目標 異常時に事象を追うことができる ここでいう品質水準・異常とは、パフォーマンスが明らかに低い、アプリケーションがクラッシュす
8. 負荷テスト計画の立て方
8.1. 負荷テスト計画 これまで、JMeterの様々な機能を紹介してきました。この章では、それらの機能を使い、実際にどのようにテスト計画を作成・実施していくのかを説明します。なお、以下の説明では、対象とするアプリケーションはWebアプリケーションを想定しています。 8.2. 事前に集めておく情報 まず、テスト計画を作成するために、テスト対象となるアプリケーションについて、いくつかの情報を集めておかなければなりません。 一番大切なのは、ピーク時に想定される同時アクセス数です。この数が想定できている場合は、一度の負荷テストでアプリケーションのパフォーマンスについての信頼ある数値を取得することができます。ピーク時の同時アクセス数がほとんど予想できないか、あるいは、どの程度までの同時アクセス数までアプリケーションが耐えられるか知りたい場合は、想定する同時アクセス数を小さい値から順に増やしていく形
初めての負荷テストで、得られた知見、実施後の振り返り | Monotalk
投稿者: kem / 右記内 Web Performance Test & Tips / 投稿日:2016-10-01 ( 9年, 7ヶ月 ago) / 更新日:2019-03-02 ( 7年, 2ヶ月 ago) / コメント 仕事で、人生初の WEB アプリケーションのスループット云々系の負荷テストを実施しました。 負荷テスト実施で得られた知見、実施後に記事を見返して思ッたことを記載します。 何か思い出したら、随時追記をしていこうかと思います。 初負荷テストについて まず、初負荷テストについて記載します。 実施した時期 2016年8月-9月 です。 負荷テスト 対象のアプリケーション構成 HTTP サーバ Apache JAVA AP サーバ Glassfish DB サーバ AWS RDS 評価対象のモジュール どの画面からも必ず呼び出されるされる共通処理です。 1呼び出しの負荷は高く
Trasis Lab » apache, tomcatで負荷分散
概要 apache+tomcat サーバ2台で負荷分散環境設定の記録。 要件 正常時は2台のtomcatサーバで負荷分散。 セッションは DB(postgresql) に格納する。 負荷分散時、stickysession 機能により、一ユーザのアクセスは可能な限り、１つの tomcat サーバに固定する。 1台あたりのtomcatサーバで扱うセッション数はなるべく少なくし、余計なメモリを消費しないようにする。 Apacheサーバ設定 /etc/httpd/conf.d/tomcat.conf を作成し、次のように記述した。 LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_balancer_module modules/mod_proxy_balancer.so LoadModule proxy_http_modul
Apache、Tomcatのチューニング - 3rd lab.
チューニング方法はメモリとインデックスしかない ・メモリ 32bit,64bit 64bitだとメモリの消費量が高いとされて実際高い ・PAE 32bitで4GiB以上のメモリを使う技術 Apache チューニング 1.HostnameLookups -> off これがonだと、ログファイルにホスト名を出力するためDNSLookupしてしまう 2.無駄なログファイルを消す ローテートする 3.無駄なモジュールをロードしない 4..htaccessを無効にする ※アクセスのたびにソンァイチェックをおこなうのでパフォーマンスが劣化する ※AllowOverride -> None 5.KeepAlive -> off ※HTTPはステートフルな接続のためリクエストのたびに接続切断が発生するためコストがかかる ※LBに格納されている場合あまり意味がない 6.MNM(Multi Proccess
Stringの連結はそう簡単なものではない - かとじゅんの技術日誌
追記： 指摘の通りで、現実的な連結回数での計測でもないですし、統計手法を用いた分析をしていないので、このエントリの計測値は当てにしないでください。なので以下のブログを参考にしてください。 currentTimeMillis()で計測しておいて plusTime:14780, concatTime:7053, sbuilderTime:7, sbufferTime:13 とか、その7とか13の有効数字はいくつだっての。 激しく今更感があるタイトルですが(；・∀・) 昔に取り上げたのですが、 文字列の結合をやるからといって、すぐにStringの+をつかってはいけない - じゅんいち☆かとうの技術日誌 Stringの+演算子は間違った使い方するとパフォーマンスが低下しますよっていう話題。若干ネタ成分ありますが、ご容赦ください。 これ系の話題は自分的にはオワコンなんですが、最近、また話題を見つけた
mod_cluster登場、mod_jkやmod_proxyよりも優れたロードバランシング | エンタープライズ | マイコミジャーナル
jboss.org: community driven JBoss Web ProjectおよびJBoss AS Clustering Projectから興味深いプロジェクトが発表された。その名もmod_clusterだ。現在のところ1.0.0.Beta1が公開されている。名前のとおりApache HTTP Serverで動作するモジュールで、背後で動作するTomcatやJBoss Web、JBoss ASなどのアプリケーションサーバへのコネクションを担当する。ロードバランシングの機能とプロクシの機能を備え、mod_jkとmod_proxyの双方の機能をもったような仕組みになっている。 mod_jkやmod_proxyとの大きな違いは、アプリケーションサーバからHTTPサーバへのバック通信をサポートしているところにある。HTTPメソッドでアプリケーションサーバからmod_clusterモジ
Javaの性能を分析する10のツール | エンタープライズ | マイコミジャーナル
JDK16 jconsoleの動作例 JavalobbyにおいてJavaパフォーマンストラブルシューティングに役立つ10のツールがTop 10 Java Performance Troubleshooting Toolsとして紹介されている。OSの限定されるツールもあるため実質的には7つの紹介とみていいだろう。Javaのパフォーマンス分析といえばJDK 6 Update 7からJava VisualVMが同梱されるなど今後のさらなる発展が期待される分野だ。同文書で紹介されているツールは次のとおり。 jconsole - JDK1.5およびそれ以降のバージョンに同梱されているJavaモニタリングおよびコンソール管理ツール。JMX互換のグラフィカルツールでローカルで動作しているJava仮想マシンもリモートで動作しているJava仮想マシンもどちらもモニタリング可能 VisualVM - 高性能な
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
A Guide to async-profiler | Baeldung
Google Code Archive - Long-term storage for Google Code Project Hosting.
JBentoStore - JBentoStore
オープンソース情報データベースシステム(OSS iPedia) のコンテンツについて
IBM Developer
http://sirius.itfrontier.co.jp/wily/press/press_detail.cfm?press_no=55