OpenJDK 8/11 vs. GraalVM 20 vs. Amazon Corretto JVM Benchmarks - Phoronix
OpenJDK 8/11 vs. GraalVM 20 vs. Amazon Corretto JVM Benchmarks Written by Michael Larabel in Software on 25 March 2020 at 02:00 PM EDT. Page 1 of 5. 32 Comments. Following last week's benchmarks of OpenJDK 8 through the newly-released OpenJDK 14 JVM benchmarks, some Phoronix readers expressed interest in seeing Java benchmarks with Oracle's GraalVM as well as Amazon's Corretto JVM implementations.
サーバレスコンピューティングでJVMがよい選択である理由: John Chapin氏がQCon NYでAWS Lambdaについて考察した
QCon New YorkでJohn Chapin氏が"恐れ知らずのAWS Lambdas"というプレゼンテーションをした。JVMがサーバレスコードをデプロイする先となるよいプラットフォームであるだけでなく、JavaベースのAWS Lambdaファンクションから最高のパフォーマンスを引き出す手引きが提供されているとも主張した。鍵となる点は次のことである。開発者がファンクションの"コールドスタート"のインパクトを減らし分割して返済すべきであること、現実世界のパフォーマンスを見極めるために広くファンクションのベンチマークを取るべきであること、固有のオプションよりも完全な機能を備えたロギングとメトリクスライブラリを使うべきであること、である。 Chapin氏は、Symphoniaの共同創立者であるが、"サーバレス"コンピューティングの核となる特徴の考察で話を始めた。長命のホスト（サーバ）管理やア
Javaの謎のパフォーマンス劣化現象との戦い - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。アプリケーション基盤チームの横田です。 Javaの謎のパフォーマンス劣化にまつわる調査をしていたのですが、1ヶ月の苦労の末に原因がわかりましたので、報告させていただきます！ 公開後に頂いたはてなブックマークでのご指摘・社内でのタイポ・読みにくいなどの指摘を受けてたので、謹んで修正させいただきます。 修正した内容につきましては、記事の最後を参照してください。 忙しい人のためのまとめ jdk-7u4以降のjdk-7 *1 でJavaのパフォーマンスが劣化する謎の現象 CodeCacheの容量限界に近づくとJITコンパイラを停止してコンパイルしたコードを捨てる機能が原因だった 起動オプションで回避できるので、長期運用するときは -XX:-UseCodeCacheFlushing, -XX:ReservedCodeCacheSize=128m をつける 上のオプションを設定した時に、C
Java用JSONパーザのベンチマークをした話 | さにあらず
このたび JSON パーザのベンチマークを書きましたので、どうぞご査収下さい。 taichi/json-benchmarks Java8 がインストール済みの環境で、当該リポジトリを clone して と実行する事で追試できます。 結果について#jackson-databind が最速なので殆どの皆様におかれましては安心して下さい。 特に驚きに値するような事は何も起きていません。 僕のマシンで実行した結果はこちらです。（エビデンスが無いとの指摘を受け追記しました。） Json benchmark results結構な長文になってしまいましたので、マニアな皆様だけが続きを読んで下さい。 課題設定について#まず、おおまかな課題設定について説明します。 JMH を使った本格的なベンチマークを書くJava 用 JSON パーザのショーケースを作る事で使い易いものを明らかにする結局どのパーザが速いの
「Javaの鉱脈」でGatlingの記事を書きました | さにあらず
WEB+DB PRESS の Vol.83 で、負荷テストの記事を書いたので是非読んで頂きたい。 2014/10/24 発売ですので、既に購入頂いてる方も多いと思います。 電子書籍版もありますので物理的な媒体に興味がない方は PDF を買って下さい。 WEB+DB PRESS Vol.83@Gihyo Digital Publishing今回の記事における対象読者について#JMeter だ、JMeter を撃滅せよ。 負荷テストスクリプト書くのに GUI なんぞいらないのですよ。 素人騙すんなら、それでいいかも知らんけども、そういう事じゃないでしょう。 GUI なしでも書けますよって、そのヤヴァイ XML を俺に見せるな。 負荷かけてる最中にサーバより先に死んだりするような負荷テストツールを後生大事に使うのをやめて欲しいのです。 今回は、新進気鋭のツールであるところのGatlingを紹介し
High performance networking on the JVM
Red Hat (JBoss) - EAP Core Team Former contractor for Apple Inc Author - Netty in Action Apache Software Foundation Member Netty / Vert.x Core-Developer and all things NIO Java and Scala Twitter: @normanmaurer Github: https://github.com/normanmaurer As always, only optimize if you really need! 1000 concurrent connections != high-scale If you only need to handle a few hundred connections use Block
スレッドプールのサイズを調整する
この他にも "サービスを受けるのを待つ人が，キューの中に立っている平均時間はどれくらいか？" といったような疑問に，Littleの法則で答をだすといった内容のゲームは，他にもたくさんあります。 図１. Littleの法則 同じようにLittleの法則は，スレッドプールサイズの決定にも使うことができます。私たちがしなければならないのは，リクエストの到着率と，サービスに必要な平均時間を測定することです。そうすれば，これらの値をLittleの法則に挿入して，システムの平均要求数が計算されます。その数値がスレッドプールのサイズよりも小さければ，その結果に従ってプールのサイズを小さくすることが可能なのです。逆に計算結果がスレッドプールのサイズよりも大きい時には，問題はもう少し複雑になります。 実行中のリクエストより待ち状態のリクエストの数が多い場合，まず最初に判断しなければならないのは，もっと大きな
Improving startup time
JRuby, being built atop an optimizing VM (the JVM), sometimes tends to start up more slowly than the C-based, non-optimizing standard Ruby. This can often be very frustrating when running lots of commands at the command line. This page offers some tips and tricks to improve startup time Note that some of these tips are not recommended for general execution; for example, disabling JRuby's JIT will
Nailgun: Insanely Fast Java
Important UpdateOctober 14, 2017 Nailgun has been a lot of fun to work on, and it's been great to see how others have used it. And even though I have not updated it myself in several years, it's gratifying to see that not only is it still useful to others, but it also still receives regular code contributions from people who count on it. In particular, Jim Purbrick and Ilya Klyuchnikov of Facebook
HTTPサーバにJava NIOは必要か
0x00. はじめに 筆者はJava製のWAF(Web Application Firewall)、Guardian@JUMPERZ.NETの開発とメンテナンスを行っている。元は自社のシステムを守るために（そして半分趣味で）作ったものだが、数年前にこれをコアのエンジンとしてさらに拡張し、SaaS型の商用サービス「Scutum(スキュータム)」を立ち上げた。 その後順調に顧客を獲得することができ、システムリソース的にも増強が必要となる段階などを経験した。Google、mixiやはてな等、さまざまな大規模サイトのインフラエンジニアの方々がインフラ設計に関する考え方などをインターネット上で公開してくれているおかげで、初期のシステム設計時に「将来的にスケールアウト可能なシステム構成にしておくこと」が重要であるということがわかっていた。その教えに従っていたおかげで、リソースの逼迫（ちなみに今回はCP
Android開発でのパフォーマンスTips(2) | Techfirm Android Lab
AndroidパフォーマンスTips、前回の続きです。 Android開発でのパフォーマンスTips(1) | Techfirm Android Lab 定数はファイナルで宣言する static int intVal = 42; static String strVal = "Hello, world!"; 上記のようにfinalなしで定数を定義した場合、intValを参照するときにフィールド走査が実行されるが、 static final int intVal = 42; static final String strVal = "Hello, world!"; このようにfinal宣言をするとintValは直接VMが参照できるようになるため、高速になる。 メソッドやクラスに関してはfinal宣言をつけてもコード保守の面では効果があるが、パフォーマンス面でのメリットはない。 また、ロー
Android開発でのパフォーマンスTips(1) | Techfirm Android Lab
googleは公式ドキュメントとしてAndroid開発におけるパフォーマンス設計のベストプラクティスを公開しています。 Designing for Performance | Android Developers どんなに優れたUIであってもパフォーマンスの悪いアプリはユーザにとって使いにくいものになってしまいます。 アプリのパフォーマンスチューニングは重要です。 今回は公式ドキュメントをベースにパフォーマンス設計のベストプラクティスのご紹介です。 Javaの世界で当たり前だったものが、Androidの世界では通用しないものも多々あるので覚えておきたいです。 基本的な考え方 Androidで良好なパフォーマンスを得るための基本的な考え方は 無駄な処理はしない 無駄なメモリは使わない ことです。以降に出てくる原則はすべてこれにのっとったものです。 オブジェクト生成は避ける オブジェク
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Jackson開発者のTatu Saloranta氏がJSONベンチマークに回答
https://groups.google.com/forum/#!topic/closure-library-discuss/7w_O9-vzlj4/discussion
Nodejs vs Play for Front-End Apps 翻訳
App performance guide | App quality | Android Developers