Webアプリ負荷試験ガイド 目次 Webアプリ負荷試験ガイド 目次 前置き 時間がない人向け要約 about me 何故負荷試験を行うのか 負荷試験ツール 負荷掛けるツール 負荷計測 負荷の可視化 負荷試験の流れ 負荷試験スケジュールについて 注目すべきポイント シナリオ作成 アカウント情報は自動生成出来るようにする DB分割を行ってる場合はDB分割を意識したシナリオを用意する。 負荷試験元 http or https サーバ1台 サーバ単体での負荷 アプリの正常性の確認 サーバ複数台 KVS Memcached Redis RDB 問題になりやすいDB キャッシュの話 大前提 注意すべき点 CDNやProxyレベル local cache or remote cache local cache or memory cache(in app cache) references 更新情報 前

どうも、趣味でOpenJDKのコミッタをやってます。JVMの専門家ではないです。 今回はJITコンパイルによる暖気が十分に行われてから処理を受けられるようにする方法を紹介します。 今回の実装は Oracle の有償機能から OpenJDK へ寄贈され OpenJDK 11 に追加された JDK Flight Recorder（JFR）と OpenJDK 14 に追加された JFR Event Streaming を使用します。 JITコンパイルイベント OpenJDK では、JITコンパイラがコンパイルした情報を内部的にイベントとして記録しています。今回はこのイベントを使用していきます。このイベントのデータ形式は以下になります。 @Name("jdk.Compilation") @Category({"Java Virtual Machine", "Compiler"}) @Label("

パフォーマンスに関する各種ブラウザAPI ◯◯ Timing APIはW3CのWeb Performance Working GroupのIlya Grigorikを中心に策定が進められている、ブラウザのパフォーマンスを計測するブラウザAPIである。 User Timing API: 任意のラベルを用いてプログラムの実行にかかったを取得する Navigation Timing API: ブラウザライフサイクルの発生した時間を取得する Resource Timing API: リソースのロードに際して発生した各種時間を取得する Frame Timing API: ブラウザフレームの内訳を取得する Server Timing API: サーバー処理の内訳を取得する High Resolution Time API: 高精度のタイムスタンプを提供する ブラウザのwindowオブジェクトにperf

注意: まだHEADにすらマージされていない機能です。 僕の現状の理解で書いてます。細かいニュアンスは見落としてるかも。 今の課題 異なるチームで、異なるビルドプロセスのものを統合するような巨大なフロントエンド、いわゆるマイクロなフロントエンドやってると、同じようなライブラリが内部的に重複するよね webpack build (chunk) 間で、そういう自明なもののを重複を省いたり、一方向ではなく、相互に読み出せるようにしたいよね ScriptedAlchemy氏の提案 異なるWebpackビルド同士が連携する、Federation という概念を作る。 Host と Remote という概念を追加する。既存のものは Host となる(?)。 Remote は、それぞれに要求する chunk (react, vue など)と、他に外側に提供するインターフェースを明示する。 (optimaz

ターゲット 巨大なSPAを作ってしまった人へ 巨大なSPAを作らないように気をつけたい人へ 今回はJSだけにフォーカスするが、もっというと、 超速本 を読んでください。 注意：本資料は、webpack チャンクの挙動を概念的に説明することを重視しているので、 webpack の詳細な設定や、出力ファイル名などは実際の処理と一致しない。適宜自分の手元にある設定とすり合わせるように。 昨今のJSビルド問題と、その解決のためのゴール設定 巨大なJS(+最近は in JS された各種SVGやCSS)はダウンロードだけではなく、UIスレッドのCPUをブロックする。 これはとくにCPUが貧弱な端末で体験が悪化する。そしてビルド時間で開発者体験を阻害する。 できれば webpack 推奨の 144kb 以内にしたい…が現実的に難しいので、 せめて 350kb ぐらいに抑えたい。 SPAなら (ローディン

(This post is also available in English.) この記事は In defence of swap: common misconceptions を 著者の Chris Down さんの許可 を得て Hiroaki Nakamura が日本語に翻訳したものです。 原文のライセンス は CC BY-SA 4.0 であり、翻訳のライセンスも同じく CC BY 4.0 とします。 長文を読みたくない方への要約： スワップを持つことは正しく機能するシステムのかなり重要なポイントです。 スワップが無ければ、まともなメモリ管理を実現することは難しくなります。 スワップは一般的に緊急事態用のメモリを取得するためのものではなく、メモリの回収を平等に効率的に行うためのものです。 実のところ「緊急事態用のメモリ」は一般的に盛大に悪影響を及ぼします。 スワップを無効にすることは

Learning From Structure: Discord’s Entity-Relationship Embeddings

CSS読み込みの<link rel="stylesheet">は同期なので、レンダリングブロックします。 どういうことかというと、CSSファイルの読み込み・パースが終わるまで画面描写が止まってしまいます。 これに対策する方法としてpreloadというものが策定されましたが、対応状況が微妙です。 2019年7月時点でもブラウザシェアが8割しかなく、Firefoxは当面対応するつもりがないようです。 とはいえ残り2割のためにloadCSSを突っ込んだりとか始めると本末転倒感に溢れます。 全ブラウザ対応のためには、なんにしろ結局JavaScriptをこりこり書くしかない状況でした。 が、なんかすっごい簡単な対処法があったので紹介してみます。 以下はScott Jehlによる記事、The Simplest Way to Load CSS Asynchronouslyの日本語訳です。 ちなみにSco

The following Java program takes on average between 0.50 secs and 0.55 secs to run: public static void main(String[] args) { long startTime = System.nanoTime(); int n = 0; for (int i = 0; i < 1000000000; i++) { n += 2 * (i * i); } System.out.println( (double) (System.nanoTime() - startTime) / 1000000000 + " s"); System.out.println("n = " + n); } If I replace 2 * (i * i) with 2 * i * i, it takes be

[レベル: 中級] 昨日とおとといに続いて、今日も Chrome Dev Summit 2018 のセッションレポートをお届けします。 セッションのタイトルは “Speed Essentials: Key Techniques for Fast Websites” です。 昨日レポートしたセッションと同じようにモバイルウェブの高速化がテーマです。 しかし、こちらはより実践的な内容になっています。 パフォーマンス改善に非常に役立つテクニックが満載です。 パフォーマンス改善の優先対象は画像とJS、フォントの3つ モバイルウェブで 1 ページあたりデータ量が多いリソースは次の順番（HTTP Archive 調べ） 画像 (約 500 KB) JavaScript (約 380 KB) フォント (約 80 KB) この 3 つは Performance Budget（パフォーマンス バジェット）

Uber JVM Profiler provides a Java Agent to collect various metrics and stacktraces for Hadoop/Spark JVM processes in a distributed way, for example, CPU/Memory/IO metrics. Uber JVM Profiler also provides advanced profiling capabilities to trace arbitrary Java methods and arguments on the user code without user code change requirement. This feature could be used to trace HDFS name node call latency

$200K 1 10th birthday 4 abusive ads 1 abusive notifications 2 accessibility 3 ad blockers 1 ad blocking 2 advanced capabilities 1 android 2 anti abuse 1 anti-deception 1 background periodic sync 1 badging 1 benchmarks 1 beta 83 better ads standards 1 billing 1 birthday 4 blink 2 browser 2 browser interoperability 1 bundles 1 capabilities 6 capable web 1 cds 1 cds18 2 cds2018 1 chrome 35 chrome 81

可能な限り最新の情報を反映していますが、追いつけていないこともあります。本サイトに採用していても、記事に反映できていない設定もあります。ページのソースを読んでいただくと、参考になる箇所があるかもしれません。 ウェブページの高速化に関するテクニックは、ネットで検索すれば簡単に見つけることができます。優れた情報も数多くありますが、｢CSSとJavaScriptはminify（ミニファイ）しておけばOK！」のような都市伝説も少なくありません。 そこで、ここでは本サイトのデザインリニューアル時に施した対策をもとに、一歩進んだウェブページの高速化の方法と、それを支える原理について、できる限り分かりやすく説明したいと思います。フロントエンジニアやデザイナーの方からすれば「んなもん知っとるわ！」な情報なのかもしれませんが、都市伝説を駆逐すべく、私なりの仕方で解説（≒加勢）したいと思います。 初めに結果を

JVMにチューニング項目は多々あれど、プロダクションで運用する際に予めおさえておきたい項目をまとめてみるエントリです。*1 勿論、OSもJVMもデフォルトである程度のパフォーマンスは発揮でき、計測を伴わないチューニングは悪手であることはよく知られています。 しかし、設定しておかないとパフォーマンスにそのまま影響すると分かるものを調べないのは裸で戦場に赴くようなものです。*2 どんな項目をどう変更すれば良いのか知っていることは重要な武器なのです。 なぜ調べるのか 今回、チューニングポイントを調べるにあたって、私のモチベーションはどこにあるのかを考えると、以下の要件を満たしたいということがあげられます。 アプリケーションとして求められる品質水準として動作する → 性能目標 異常時に事象を追うことができる ここでいう品質水準・異常とは、パフォーマンスが明らかに低い、アプリケーションがクラッシュす

GotandaJS #9の発表資料です

Redisは多彩なデータ構造をもつ1インメモリDBであり、昨今のWebアプリケーションのデータストアの一つとして、広く利用されている。 しかし、一方で、性能改善のための手法を体系的にまとめた資料が見当たらないと感じていた。 実際、最初にCPU負荷が問題になったときにどうしたものかと悩み、調査と試行錯誤を繰り返した。 そこで、この記事では、自分の経験を基に、RedisサーバのCPU負荷対策を「CPU負荷削減」「スケールアップ」「スケールアウト」に分類し、パターンとしてまとめる。 背景 RedisのCPU負荷対策パターン CPU負荷削減 multiコマンド Redisパイプライニング Luaスクリプティング Redisモジュール(夢) スケールアップ スケールアウト 参照用スレーブ 垂直分割 水平分割 Redis Clusterによる水平分割 その他 スライド資料 あとがき 参考資料 背景 R

Intro Resource Hints とは現在提案されている以下のドラフトであり、ブラウザに「次に必要となるリソースを教える」ことで、投機的な取得を行う API 群である。 https://w3c.github.io/resource-hints/ 主に以下がある。 dns-prefetch preconnect prefetch prerender 今回は本サイトでこれを適用した話。 投機的なリソース取得 例えば、ログインページの次には、そのサービスのメインページに遷移する頻度が高い。 そして、メインページでは、以下のような追加のリソースが必要になるだろう。 追加の JS 追加の CSS 追加の Image 追加の API アクセス それぞれを DNS 解決 -> TCP 接続 -> リソースのフェッチ、と繰り返していくと、イニシャル表示は必然的に時間がかかる。 ところが、この遷移に