技術的な解決策ではなく、意見や経験について質問があります。
本番環境で JMX コンソールを介して Hibernate 統計と Ehcache 統計をオンにすることについてどう思いますか? それは良い考えに見えますか、それとも恐ろしい考えに見えますか? なぜ?
よろしく
技術的な解決策ではなく、意見や経験について質問があります。
本番環境で JMX コンソールを介して Hibernate 統計と Ehcache 統計をオンにすることについてどう思いますか? それは良い考えに見えますか、それとも恐ろしい考えに見えますか? なぜ?
よろしく
私が取り組んでいる製品には、Hibernate 統計、Ehcache 統計、JMX など、すべてが揃っています。しかし、管理者ユーザーのみがアクセスできる特別なバックエンド (JMX ではなく) を介して Hibernate/Ehcache 情報を公開し、JMX を使用して SLA コントラクトにバインドされているさまざまなものを監視します。しかし、製品にそのようなバックエンドがない場合、JMX を介して db/cache 統計を公開することは、私には間違ったことのようには思えません。
本番環境で統計を有効にすることは大したことではありません。コストは、AtomicLong
incrementAndCount
トランザクションごとにおよそ 1 つの操作であり、事実上無料です。毎秒数百万のトランザクションを処理しない限り、違いに気付かないはずです。
ここには2つの顕著な問題があるように私には思えます:
#1が真であると仮定します(そうでなければ、なぜ私たちはここにいるのですか? :) )
#2 に関する限り、統計の有無にかかわらず、アプリケーションを負荷の下で実際にテストする必要がありますが、私の経験では、両方の統計コンポーネントがパフォーマンスに与える影響はごくわずかです。さらに、これらの統計を定期的に収集して分析すると、キャッシュを使用していないシステムのボトルネックや部分を見つけるのに役立つ可能性があるため、改善される可能性があります。
バックグラウンド スレッドで定期的にログ ファイルに統計情報を書き込むなど、この情報をマイニングするためのより良い方法があると主張できると思いますが、これは「キャッシュ内の要素の数」などのより単純なメトリックでは機能しますが、多くの統計情報はそうではありません。コア エンジンで統計が有効になっていない場合に使用できます (ほとんどの Hibernate のメトリクスと同様)。さらに、JMX は遠く離れており、公開されているデータにアクセスして分析/レポート/視覚化するためのあらゆる種類の創造的な方法があります。
これが役に立てば幸いです。