InfoQ Software Architects' Newsletter A monthly overview of things you need to know as an architect or aspiring architect. View an example

ヌーラボでScalaを書くRubyistの谷本です。ヌーラボでは、Backlogの開発を担当しており、最近ではBacklogをJavaからScala / Play Frameworkに移行するプロジェクトのメンバーでした。 BacklogのPlay化プロジェクトでは、OutOfMemorryError(以下、OOM)の発生やCPU使用率とロードアベレージが上がったままという、Java Virtual Machine(以下、JVM)上で動くBacklogのパフォーマンスに関する問題に対処すべく、何度かHeap/Thread dumpを見る機会がありました。 私がPlay化プロジェクトで取り組んだパフォーマンス改善の知見や経験をもとに、本記事では「JVMで起こったパフォーマンスの問題の切り分け方」についてお届けします。 はじめに 本番環境でしばらく動かしていると、コード自体は正しく実行できるけ
私は以前、Linuxでのシステムコールはとてつもなく高コストだと思っていましたが、この測定で、その考えが誤っていたことが判明しました。実際にはシステムコールにコストはかかりますが、例えば、L3キャッシュミス(100ns)に比べれば低コストです。 ただし、行われるアクションが短いとしても(TSCベースの gettimeofday 向けだから)、システムコールを避ける方が有利です。その場合は、vDSOの方が断然役に立ちます。私たちのケースでは、ほぼ3倍実行が速くなりました。 どうすればいいのか 最良の方法は、TSCタイムソースを持つWindowsまたはLinux以外では絶対にプログラムを実行させないようにすることです。それが不可能なら、純粋なJavaの中にいながらこの呼び出しを高速化する方法はなく、解決策は、 currentTimeMillis() があまり頻繁に呼び出されないようにすることで
JVMはプロファイリングを利用してコードの最適化を行います。対象は頻繁に利用されるコードパスのみですが,徹底的に行うことで大きな効果を上げています。JITコンパイルされたコードに関しては,現在では多くの場面において (その割合も増えつつあります) C++の実行速度を凌駕しています。 このような事実にも関わらずJavaが今でも低速なプラットフォームとして認識されているのは,おそらくは初期バージョンのJavaプラットフォームでの経験が,歴史的な負のバイアスとして働いているためでしょう。 早まった結論を出す前に,客観的な見地に立って,最新のパフォーマンス結果を評価するようにお勧めします。 2. Java コードの1行にはそれ自体で意味がある 次の短いコード行を考えてみてください: MyObject obj = new MyObject(); Java開発者ならば誰でも分かるように,このコードはオ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く