EC2のc4/m4などの第4世代のインスタンスでSystem.currentTimeMillis使うと遅くなるよ、みたいな話でベンチマーク取ってみた。 第5世代になると早くなるよ、みたいな話。この例はDocker上で動かすと、Dockerというかseccompのオーバーヘッドで遅くなる話。
この辺にも似たようなことが書かれている
ベンチマークソース
https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/deployment-type-external.html の和訳
一部APIのパラメータを省略しています
==================================
External Deployment Type はECSサービスの完全なコントロールのためのサードパーティのデプロイメントコントローラを使うことを可能にします。
The external deployment type enables you to use any third-party deployment controller for full control over the deployment process for an Amazon ECS service.
サービスの詳細はサービスマネジメントAPI（CreateService, UpdateService, DeleteService）もしくはタスクセットマネージメントAPIアクション（CreateTaskSet, UpdateTaskSet, UpdateServicePrimaryTaskSet, DeleteTask）によって管理される。
The details for your service are managed by either the service management API actions (CreateService, UpdateService, and DeleteService) or
Notes on BPF (1) - A Tour of Progam Types
Notes on BPF (2) - BPF helper functions
Notes on BPF (3) - How BPF communicates with userspace - BPF maps, perf events, bpf_trace_printk
| FROM amazonlinux:1 | |
| RUN yum update -y \ | |
| && yum install bcc -y \ | |
| && pip-3.6 install prometheus_client | |
| && rm -rf /var/cache/yum/* |
あなたのシステムで、失敗の根本的な原因を探すのにどのくらい時間がかかりますか？5分？5日？ もし、5分近くで答えられたなら、あなたのプロダクションシステムやテストは素晴らしいロギングを持っていることでしょう。 多くの場合、ロギングや例外ハンドリングや（あえて言いますが）テストなどの一見、本質的ではない機能は実装の後に行われます。 例外ハンドリングやテストと同様に、あなたのシステムやテストの両方にロギングの戦略が本当に必要です。 ロギングの力を過小評価しないでください。最適なロギングは、デバッガの必要性を排除することさえできます。
今日は負荷試験の合間にブログを書いてみます。
前回やった async-profiler の記事 の続きで 今回はDocker コンテナ上で 動くJVMアプリケーションに対してprofilerを動かしてみます。 コンテナのOSはdebianです。
今回はperformanceのメトリクスを取るために
spotbugsが遅い・・・？
うーん、、、、やはりFindBugsからSpotBugsに変更すると2倍ぐらい時間がかかるなぁ。継承が多いからだろうか。 https://twitter.com/megascus/status/1101381565479702528
ということで、取得できました。実行時の情報は入れてあります。 https://twitter.com/megascus/status/1101431168577134592
| module github.com/wreulicke/explore-aws-cli | |
| require ( | |
| gopkg.in/src-d/go-billy.v4 v4.2.1 | |
| gopkg.in/src-d/go-git.v4 v4.10.0 | |
| ) |
