BPF Performance Tools (Book)
Recent posts: 28 Apr 2023 » eBPF Observability Tools Are Not Security Tools 01 Mar 2023 » USENIX SREcon APAC 2022: Computing Performance: What's on the Horizon 17 Feb 2023 » USENIX SREcon APAC 2023: CFP 02 May 2022 » Brendan@Intel.com 15 Apr 2022 » Netflix End of Series 1 09 Apr 2022 » TensorFlow Library Performance 19 Mar 2022 » Why Don't You Use ... 26 Sep 2021 » The Speed of Time 06 Sep 2021 »
BPF Performance Toolsを読んだ感想 - go_vargoのブログ
BPF Performance Toolsを読んだので、感想ブログです。 先に感想を言っておくと「最高」でした。 BPF Performance Toolsとは？ NetflixでKernel・パフォーマンスにかかわるチューニング・アーキテクチャを専門にしているBrendan Greggさんが書いた本です。BPFのiovisorというTracing分野の第一人者でもあります。 www.brendangregg.com 2019年12月に発売したばかりなので、BPFの分野では最新の本でしょう。他の著書に有名な本として(日本語版の)「詳解システム・パフォーマンス」があります。 BPF Performance Toolsは「詳解システム・パフォーマンス」第二弾と言えるかもしれません。ちなみにページ数は880Pあり、Kindleで表示される読み終わるための平均的な時間は「27時間30分」で、大作R
バッチ処理の一部で 30 分以上かかっていた処理を 14 秒で終わるようにした話 - @watson1978 の日記
Ubiregi Advent Calendar 2018 の 18 日目です。 ユビレジではたくさんのお客様の大量の POS データをお預かりしており、様々なバッチ処理も実行されています。今回は特定のケースでバッチ処理の一部が 30 分以上かかっていた処理を 14 秒で終わるようにした話について書きたいと思います。前回の Ruby 2.5 の SEGV と闘った話 - @watson1978 の日記 に引き続き DTrace を使った話になります。 はじめに ユビレジでは CSV ファイルでお客様が特定のデータをダウンロードしたりアップロードできる機能があります。CSV ファイルにエクスポートしたり、CSV ファイルから DB に取り込む処理を Worker を起動してバッチ処理しています。 大量のデータを保有しているアカウントと同量のデータを用意して手元の環境で試したところ時間がかかるこ
dev.toと阿部寛のホームページについてちゃんと計測させてくれ - Qiita
Twitter見てたら、以下のツイートを見た。 数時間後、dev.toと阿部寛のホームページどっちが速いですか？というブログがTLに現れた。 GoogleのPageSpeed Insightsで測って阿部寛のホームページの方が早かったという結論付けてよいのかという疑問が浮かび、webpagetest.orgで計測することにした。 設定 阿部寛のホームページに関しては、Tokyoリージョンにあるものとする。 そして、dev.toはNY発らしいので、サーバーの設定をNYにして測定する。 The platform was created in 2016. The twitter account, @ThePraticalWeb 評価結果 Webpagetest - 阿部寛のホームページ Webpagetest - dev.to
dev.toと阿部寛のホームページどっちが速いですか？ - くうと徒然なるままに
dev.toと阿部寛のホームページどっちが速いですか？— あれからのぐりだけど (@_guri3) 2017年11月15日 という内容のツイートを見つけたので計測してみる。 ずっとパソコンに向かってて飽きてたので息抜きで。 dev.to というのは、 Qiita の海外版みたなやつです。一番の特徴はナビゲーションの速さ。 対抗するのは、 THE Traditional Web Site というたたずまいで有名？な 阿部寛のホームページ 計測 今回は、Google の PageSpeed Insights を利用していきます。 dev.to まずは、dev.to から 86/100 です！ 阿部 寛 のホームページ 92/100 です！ まとめ 伝統的ウェブサイトの方が早かった！
Node.jsのパフォーマンスチューニングのtips - 技術探し
--inspect, --inspect-brk --trace-opt, --trace-deopt --prof --trace-events-enabled --trace-gc node-report Performance Timing API 優しいコードの書き方へ v8::SnapshotCreator さいごに Node9が10/31に出ました🎉🎉🎉 Node v9.0.0 (Current) | Node.js 今回はNode単体の話なので、Express、Nginx等のチューニングに関してはココには書きません。 また、libuv等のコード内部の話もしません。 --inspect, --inspect-brk もともとあった、--debugから移行されました。(v8.0.0 ~) Chromeを使いデバッグ、プロファイリング等を使えるようになります。 ブラウザで使え
ファイルシステムよりも35％高速に | POSTD
1. 概要 SQLiteを使うと小さなBLOB（例：サムネイル画像など）を読み書きする場合、fread()やfwrite()を使って個別のファイル上に記録されたBLOBを読み書きするよりも35％も速く (*1) 読み書きができます。 さらに、10キロバイトのBLOBを扱うようなSQLiteデータベースを考えた場合、個別のファイルにそれぞれのBLOBを格納する場合に比べてディスク領域を約20％も節約可能です。 このようなパフォーマンスの差が生じる理由は、（私たちの考えでは）SQLiteデータベースの場合、open()やclose()システムコールが呼び出されるのが1回だけなのに対して、個別のファイルに格納されているBLOBを使用する場合は、open()やclose()がBLOBの数だけ呼び出されるためだと思われます。どうやらopen()とclose()を呼び出すオーバーヘッドは、データベース
OTN Japan マニュアル
お探しのものを見つけるために、以下の項目を試してみてください。 キーワード検索のスペルを確認してください。 入力したキーワードの同義語を使用してください。たとえば、「ソフトウェア」の代わりに「アプリケーション」を試してみてください。 新しい検索を開始してください。
GoogleのQUICの論文が知見の塊だった - ASnoKaze blog
20181107追記 QUICプロトコルについての概要は別途記事を書きました asnokaze.hatenablog.com 概要 ACM SIGCOMM 2017という通信系の学会に、Googleの人 総勢21人によって書かれた「The QUIC Transport Protocol: Design and Internet-Scale Deployment」という論文が提出され、学会ホームページより閲覧出来る。 この論文は、QUICの設計仕様と実際にGoogleのサービスにデプロイした結果について書かれている。 すでにGoogler SearchやYoutubeでQUICは有効になっており、一日あたり数十億の接続を処理し、Googleのegress trafficのうち30%がQUICになっており、インターネットのトラフィックの内7%がQUICだと推定されるという説明から論文は始まる。
builderscon tokyo 2017 で【初めてのMySQLサーバーチューニング】について話してきました。 #builderscon - Innovator Japan Engineers’ Blog
こんにちはこんにちは。2017年7月3日より、イノベーター・ジャパン(以下、IJ)の東京オフィスにJOINした、@mamy1326 です。 ※本エントリはbuilderscon登壇、スタッフ報告に、シュッと入社報告エントリが入っています。 では builderscon tokyo 2017 報告から。 builderscon tokyo 2017 登壇者と、ボランティアスタッフとして参加してきました。 buildersconとは？ 本サイトから引用しますと… buildersconは「知らなかった、を聞く」をテーマとした技術を愛する全てのギーク達のお祭りです。 はい、お祭りです。 参加者も、登壇者も、スタッフも。 みんな主役として楽しむことのできる最高のお祭りでした。 トークの内容は様々で、初心者向けから上級者向け、プログラミング、データベースから、設計思想など。 Slackの中の人も来て
sar の pgpgout/s と pswpout/s の関係 - とあるSIerの憂鬱
スワップ・アウトはページ・アウトのサブクラスである。 ページ・アウトはディスクにページを書き出すことすべてを指している。 スワップ・アウトはページを書き出す行為がスワップのために行われる、つまり書き出し先のディスクがスワップ領域である場合のページ・アウトである。 ページ・アウトはスワップ・アウトを含むため、すべての瞬間でページ・アウト回数>=スワップ・アウト回数である。 pswpout/sは『スワップ・アウトした"ページ数"』を表し、pgpgout/sは『ページ・アウトした"キロバイト数"』を表す。そのため、1秒間に100ページをスワップ・アウトした場合、pswpout/sは100となり、pgpgout/sは400となる。これは1ページが通常4KBであるため。 スワップが多発しているかどうかを判断する指標はpswpout/s(およびpswpin/s)であり、pgpgout/s(およびpgp
CPU Utilization is Wrong
Recent posts: 28 Apr 2023 » eBPF Observability Tools Are Not Security Tools 01 Mar 2023 » USENIX SREcon APAC 2022: Computing Performance: What's on the Horizon 17 Feb 2023 » USENIX SREcon APAC 2023: CFP 02 May 2022 » Brendan@Intel.com 15 Apr 2022 » Netflix End of Series 1 09 Apr 2022 » TensorFlow Library Performance 19 Mar 2022 » Why Don't You Use ... 26 Sep 2021 » The Speed of Time 06 Sep 2021 »
Netflix at Velocity 2015: Linux Performance Tools
There are many performance tools nowadays for Linux, but how do they all fit together, and when do we use them? At Velocity 2015, I gave a 90 minute tutorial on Linux performance tools. I’ve spoken on this topic before, but given a 90 minute time slot I was able to include more methodologies, tools, and live demonstrations, making it the most complete tour of the topic I’ve done. The video and sli
sar で収集したリソース使用情報が sadf コマンドで TSV として出力できる - 映画は中劇
sar が出力するテキストファイルは、機械可読性が低いため、リソース使用情報のレポートを作る際などに、難渋していました。 kSar というサードパーティのツールを使ってグラフを描いたり、 CSV を出力したりできるのですが、いちいち GUI ツールを立ち上げるのが手間です。 で、毎度ブーブー文句を言っていたのですが、ついこないだ、 sysstat に sadf というコマンドが付属していることを知りました。こいつは、 sar のバイナリデータを、 TSV や XML など、機械可読性の高い形式で出力してくれます。欲しかったのはこれだ！ sar とは: リソース使用情報を収集するツール sar とは、リソース使用情報を収集する Linux 用のツールで、 sysstat というパッケージの一部として配布されています。 取れる情報は、CPU使用率、ディスクIO、NICごとのデータ転送量など、リ
Locust.io
An open source load testing tool. Define user behaviour with Python code, and swarm your system with millions of simultaneous users. Tweet Follow @locustio Define user behaviour in code No need for clunky UIs or bloated XML. Just plain code. Distributed & scalable Locust supports running load tests distributed over multiple machines, and can therefore be used to simulate millions of simultaneous u
G-WANはなぜ速いのか？をnginxと比べながら検証してみた - blog.nomadscafe.jp
ツチノコブログのWEBサーバベンチマークツール比較の記事で紹介されていた。WebサーバのG-WAN。この記事によると凄く速いようです。 Intel Xeon E5-2640 (6コア/12スレッド 2.50GHz) を2つというサーバで gwan 334944 req/s nginx 111842 req/s と、速いと言われているnginxの3倍の速度を出しています。 このベンチマーク結果がとても気になったので、なぜG-WANが速いのか、自分でも検証してみました。 結論から言うと以下の2つ。 1) G-WANはデフォルトで物理CPUに合わせた数のスレッドを起動する 2) HTMLファイルも一度読み込んでキャッシュする という事です。 今回はAWSのcc2.8xlarge(E5-2670 8コア/16スレッド 2.60GHz *2)を使ってベンチマークを行いました。OSはAmazon L
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CPU Throttling - Unthrottled: Fixing CPU Limits in the Cloud
The DEV Community
Measure before Optimizing
https://events.static.linuxfound.org/sites/events/files/slides/20151006-linux-performance-profiling-monitoring_0.pdf