node.js のメトリクスの計測、ベンチマークの改善、Docker イメージの絞り方を勉強した
フロントエンドのパフォーマンス計測は得意なのだが、サーバーサイド node.js のメトリクスの取り方はあまり知らなくて、いつも勘でやりがちだった。最近は業務でこの周辺で困ることが増えたので、勉強しなおした。 また、最近使ってみたかった cloudflare workers の制限で、メモリ 128MB、CPU 時間 50ms という制約があり、このためにも Node.js の CPU のメトリクスを計測できるようになっておく必要があった。 という目的を踏まえて、今回は OS やデータベースの最適化は扱わず、ネットワークとアプリケーション層だけに絞って学習した。あと仕事の Docker イメージのサイズにも悩んでたので、ここも。 (あと ISUCON 参加者が楽しそうだったのもある。 ISUCON のチューニング対象にフロントエンドは含まれないので…) 計測対象 今回実験したリポジトリはこ
Kazuho's Weblog: ウェブページの描画 (first-paint) までの時間を測定するツールを作った件、もしくはHTTP2時代のパフォーマンスチューニングの話
ウェブページの描画 (first-paint) までの時間を測定するツールを作った件、もしくはHTTP2時代のパフォーマンスチューニングの話 ウェブページの表示までにかかる時間をいかに短くするかってのは、儲かるウェブサイトを構築する上で避けて通れない、とても重要な要素です。 少し古いデータとしては、たとえば、ウェブページの表示が500ミリ秒遅くなると広告売上が1.2%低下するというBingの例なんかも知られているわけです。 「ウェブページの表示までにかかる時間」と言った場合、実際には以下のようないくつかのメトリックがあります。 イベント 意味
DMM inside
日本アニメ初の快挙！海外アニメ賞を受賞した『スキップとローファー』海外ライセンス部長&プロデューサーが語る、奮闘の舞台裏
Scala vs. Go TCP Benchmark | Kifi Engineering Blog
We recently found ourselves in need of some load balancing with a few special features that weren’t available off the shelf quite the way we wanted. We thus set out on a little investigation on what it would take to write our own software load balancer. Since most of our code base and expertise is in Scala, building this on top of the JVM would be a natural choice. On the other hand, a lot of pe
Time::Moment vs DateTime | Christian Hansen [blogs.perl.org]
In December last year released the first version of Time::Moment. I don't foresee any major changes in Time::Moment 0.16 API, so in next release I'll remove the "early preview release" notice in the description. I have been using 0.16 in production two different deployments with great success, by removing DateTime from the ORM we have seen significantly reduced the memory usage and CPU usage and i
The Art of Work：MySQL InnoDB Pluginのデータ圧縮機能 性能編 - SH2の日記
MySQL InnoDB Pluginのデータ圧縮機能の続きです。前回はInnoDB Pluginの独自機能であるデータ圧縮の仕組みを解説し、Wikipedia日本語版のデータが約半分にまで圧縮されることを確認しました。今回はデータ圧縮によって性能がどのように変化するかを、実際にベンチマーク試験を行って見ていきます。 試験の方針 データ圧縮による性能への影響は、以下の二点が考えられます。 メリット：データサイズが小さくなるため、ディスクI/Oが減る デメリット：圧縮・展開の処理が行われるため、CPU負荷が高くなる そこで、これらの特徴がよく分かるように試験パターンを工夫します。Wikipedia日本語版のデータはInnoDB上でおよそ5GBありますが、まず狭い範囲に絞って読み取り処理を行うことでディスクI/Oがあまり発生しないようにします。これでCPU負荷の傾向を確認することができます。次
Ruby では明示的に return を書くほうがちょっと遅い、は 1.9 でも有効か - ruby trunk changes
Ruby ではメソッドの最後の式の値がそのまま返り値になります。どこで読んだのか忘れてしまいましたが「明示的に return を書くとちょっとだけ遅いので、不要なら明示的な return を書かずに返り値の式だけ書くのが Ruby 流」という言説があって、その当時試してみると確かに明示的に return を書かないほうがちょっと速いという結果だったので「不要なら明示的な return は書かないのがジャスティス」というのを信条にしてきました。 しかし先日その話をしていて、ふと 1.9 ではもうこの"常識"は通用しなくなってるんじゃないかと思いついたので確認してみました。 benchmark に使ったスクリプトと実行結果は gist に置きました。 https://gist.github.com/935934 明示的な return の有無と、さらに block の中から return する
[perl] Perlで同じコードを違うバージョンのモジュールでベンチマークする - 酒日記 はてな支店
複数バージョンのモジュールで同じコードを実行してBenchmark.pmで計測したい、というケースにこう書けばいいかな、という例。 普通にBenchmark.pmを使ってしまうと同一モジュールを違うバージョンで複数読み込むことができないため、 バージョンごとに子プロセスを fork 子プロセスで use lib して @INC を追加してから use 計測した結果をファイルに保存して親プロセスで集約、表示 という流れで書きます。 use strict; use Benchmark qw/ :all /; use File::Temp qw/ tempfile /; use Storable qw/ nstore retrieve /; # 計測したいコード my $code = sub { my $c = Cache::Redis->new; for ( 1 .. 10 ) { $c->s
![[perl] Perlで同じコードを違うバージョンのモジュールでベンチマークする - 酒日記 はてな支店](https://cdn-ak-scissors.b.st-hatena.com/image/square/2f4f2e1bfae364f13d3bb5210f048b6e928302dc/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F13208692334729889028%2F8454420450078126085%2F1419604085)
Emscripten によって生成された asm.js 対応コードは本当に人間が書いたコードより速いのか？ : document
12月2 Emscripten によって生成された asm.js 対応コードは本当に人間が書いたコードより速いのか？ はじめに 先日、いつものように Twitter 監視業務に勤しんでいたところ、下記のような発言を見かけました。 asm.jsは対応してないブラウザでは読めないし遅いって説明をされることが多いけど、ams.jsはJavaScriptの中で高速実行可能なものだけを使って更に少し制約を加えて底上げをしてるものなので、多のブラウザであっても普通に人間が書いたコードよりも速いっすよ— dynamis (でゅなみす) (@dynamitter) 2013, 11月 29 なるほど、機械によって生成された asm.js 対応のコードはどんなブラウザでも速いよという主張です。 自分は JavaScript で高速に動作するように注意して書いた zlib.js というのを作っていたので、zl
Redis memcached pdf
This document compares the caching technologies Memcached and Redis. It provides an overview of how caching works and the problems that can occur with caching like cache misses, stale data, and warm-up times. It details the features of Memcached and Redis, including their data structures and operations. Benchmarks are presented comparing the performance of Memcached and Redis for set and get opera
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
uupaa looper 見っけたよー - latest log
(ε・◇・)з hasOwnProperty を使った for in ループより 20%～84% 低コストな、うーぱー式 ループのご紹介だよ～ Object.keys を使い、key を列挙することで、hasOwnProperty を使った for in ループよりも速くなります。 var keys = Object.keys(obj), i = 0, iz = keys.length; for (; i < iz; ++i) { var key = keys[i]; var value = obj[key]; ... ベンチマーク http://jsperf.com/perf-for-in-loop-vs-pre-enum-keys-for-loop/8 Browser for_in_hasOwnProperty loop uupaa-looper Chrome 16.0.912.77
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
length プロパティのパフォーマンス: Days on the Moon
「for 文 2.0」(IT戦記) では length プロパティの評価をループの外に出すことにより高速化を図っています。DOM の NodeList オブジェクト (document.getElementsByTagName() などで取得) や HTMLCollection オブジェクト (document.forms などで取得) の length プロパティは「生きている」(オブジェクト取得後の操作が反映される) 、すなわち誤解を恐れずいえば評価のたびに数えなおす必要があるので遅いというのも納得ですが、JavaScript のネイティブオブジェクトである配列の length プロパティはどうなのでしょうか。実際に調べてみました。 以下は 10000 個の span 要素に対する NodeList オブジェクトと配列の length プロパティのパフォーマンスを調べた結果です。数値は
YappoLogs: TokyoCabinetがPerlのHASHより遅いわけがない！
TokyoCabinetがPerlのHASHより遅いわけがない！ こんにちわ！金曜日担当・Shibuya内フェアリーことYappoです。 mixi Engineers’ Blog » PerlとRubyで省メモリなハッシュを使おうにて 100万件のレコードを格納した場合のメモリ使用量と処理時間を測ってみましょう。Perl（5.8.8）でテストコードを動かしたところ、以下の改善が確認できました。標準のハッシュに比べて、メモリ使用量がTCのオンメモリハッシュだと約61%、TCのオンメモリツリーだと約37%になることがわかります。処理時間に関しては157%ほどになっていますが、まあ許容範囲ですよね。といった事が書かれており、その文面の上の解説で、tieしたので、tieしてるからおせーんじゃねーの？とテストコードも見ないで呟いてたらmikioさんからtie使わないでやってるよ！とつっこんでいただき
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MacBook Air (Mid 2012) のSSDをJetDrive 520に交換！驚きのベンチマーク結果は… | makkyon web
Perl OO performance comparison
156998’s gists
ふふふふんふふん E4X pp.html?e4x.txt
WordPress › インストール
