社会などの複雑系を分析できる手法「マルチエージェント・シミュレーション(MAS)」について紹介し、 「artisoc」でシミュレーションを体験できるサイトです。 ぜひ複雑系の素晴らしい世界を体験し、ご自身で構築してみてください。
こちらのエントリを見て面白そうだなぁと思い、断念されていた箇所の続きをやってみました。 Mavenのpom.xmlにあるプロジェクト情報をJSFで表示する http://kikutaro777.hatenablog.com/entry/2014/01/31/232721 てっきり、pom.xmlの中の依存関係とかの話なのかなと思いましたが、pom.xmlに書かれている自身のアーティファクトのバージョンが欲しいということらしいです。 で、続きをやるのはこの部分。 相談にきた後輩はStackOverflowにあるMETA-INFフォルダにMANIFEST.MFを吐かせてImplementation-Versionを取得する流れで試してうまくいかなかったとのこと。 ちょっと思い当たるところがあるので、やってみようかと。 先のブログの例に習い、このようにpom.xmlを定義します。 バージョン情報
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 のヒープ領域とパラメータ、そしてコンテナの関係について調べてました。 案外まとまった情報が少なかったので簡単にまとめました。 Java のヒープサイズを設定 まずは Java のヒープサイズについて簡単なおさらいです。 本番環境で Java アプリケーションを運用する上で、JVM のヒープサイズを決定するのは非常に大事なポイントです。 ヒープ領域の最大サイズを大きくすればガベージコレクション (GC) の回数は減らすことができますが、 必要以上に大きくしすぎると無駄にリソースを消費したり、OOM killer で OS にプロセスを終了させられます。 JVM が使用できるヒープサイズは、Java API の Runtime.getRuntime().maxMemory() で確認できます。 また java の起動オプションに -XX:+PrintFlagsFinal オプショ
JVMにチューニング項目は多々あれど、プロダクションで運用する際に予めおさえておきたい項目をまとめてみるエントリです。*1 勿論、OSもJVMもデフォルトである程度のパフォーマンスは発揮でき、計測を伴わないチューニングは悪手であることはよく知られています。 しかし、設定しておかないとパフォーマンスにそのまま影響すると分かるものを調べないのは裸で戦場に赴くようなものです。*2 どんな項目をどう変更すれば良いのか知っていることは重要な武器なのです。 なぜ調べるのか 今回、チューニングポイントを調べるにあたって、私のモチベーションはどこにあるのかを考えると、以下の要件を満たしたいということがあげられます。 アプリケーションとして求められる品質水準として動作する → 性能目標 異常時に事象を追うことができる ここでいう品質水準・異常とは、パフォーマンスが明らかに低い、アプリケーションがクラッシュす
どのように何をロギングするかを知ることは、ソフトウェアエンジニアが解決すべき最高に難しいことの一つだ。アプリケーションのログを拡張する手助けとなるのがこの「十戒」だ。 新年の私のブログにようこそ。監視とログのモニタリングについてのParisのdevopsメーリングリストでのスレッドに返信を書いた後、長らく心に留めていたブログ記事を思い出した。 このブログ記事は、私のOpsとしての顔をもって、主に開発者向けに書いた。 どのように何をロギングするかを知ることは、ソフトウェアエンジニアが解決すべき最高に難しいことの一つだ。多くの場合、これは予言をするのと同じようなことだからだ。トラブルシューティング中にどんな情報が必要かを知るのはとても難しい。それが、Opsエンジニアの大きな助けとなるよう、あなたのアプリケーションのログを拡張する手助けとなるこの「十戒」を望んだ理由だ。 1. 自分でログを書くべ
8.1. 負荷テスト計画 これまで、JMeterの様々な機能を紹介してきました。この章では、それらの機能を使い、実際にどのようにテスト計画を作成・実施していくのかを説明します。なお、以下の説明では、対象とするアプリケーションはWebアプリケーションを想定しています。 8.2. 事前に集めておく情報 まず、テスト計画を作成するために、テスト対象となるアプリケーションについて、いくつかの情報を集めておかなければなりません。 一番大切なのは、ピーク時に想定される同時アクセス数です。この数が想定できている場合は、一度の負荷テストでアプリケーションのパフォーマンスについての信頼ある数値を取得することができます。ピーク時の同時アクセス数がほとんど予想できないか、あるいは、どの程度までの同時アクセス数までアプリケーションが耐えられるか知りたい場合は、想定する同時アクセス数を小さい値から順に増やしていく形
投稿者: 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呼び出しの負荷は高く
今回は JVM, .NET といった仮想マシン(VM)についての記事です。 最初、 .NET と仮想マシンの説明のスライドを作っていたのですが、 最近 JVM と BEAM を少し調べて興味がでてきたので、合わせて VM の話としました。 そうすると今度は、スクリプト言語や LLVM の話も外せないなと思って足したら、結構な大作になってしまいました。 JVM に絞った話では、以下の記事にも説明を書いているので、こちらもご覧ください。 JDK のインストール(Windows)と Java 関連用語の説明 | プログラマーズ雑記帳 スライド版です。 ここからブログ版です。 はじめに 仮想マシンといっても、 OS のエミュレーターのようなものではなく、 JVM といったプロセス仮想マシンについてのお話です。 JVM 、 .NET Framework など最近、この仮想マシン(VM)のシェアが大幅
Linux / OS X $ git clone https://github.com/jenv/jenv.git ~/.jenv Mac OS X via Homebrew $ brew install jenv Bash $ echo 'export PATH="$HOME/.jenv/bin:$PATH"' >> ~/.bash_profile $ echo 'eval "$(jenv init -)"' >> ~/.bash_profile Zsh $ echo 'export PATH="$HOME/.jenv/bin:$PATH"' >> ~/.zshrc $ echo 'eval "$(jenv init -)"' >> ~/.zshrc Enable the export plugin $ eval "$(jenv init -)" $ jenv enable-plugin
Java 11正式版がリリース、本バージョンからOracle JDKのサポートは有償に。OpenJDKで無償の長期サポート提供は現時点で期待薄 Java 11正式版がリリースされました。 Java 11は2017年9月から始まった6カ月ごとのJavaバージョンアップサイクルからちょうど1年となるバージョンであり、また2014年3月に登場したJava 8以来、4年半ぶりに長期サポート(LTS:Long Term Support)対象となるバージョンでもあります。 JDK 11 General Available Release is Out! #OpenJDK #JDK11 Download: https://t.co/GxeXcyGUiv Release Notes: https://t.co/h5tqx7d9U5 pic.twitter.com/XByIzINXCj — Java (@j
In Java Servlets, one can access the response body via response.getOutputStream() or response.getWriter(). Should one call .close() on this OutputStream after it has been written to? On the one hand, there is the Blochian exhortation to always close OutputStreams. On the other hand, I don't think that in this case there is an underlying resource that needs to be closed. The opening/closing of sock
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く