Linuxでロードバランサやキャッシュサーバをマルチコアスケールさせるためのカーネルチューニング - ゆううきブログ
本記事の公開後の2016年7月にはてなにおけるチューニング事例を紹介した。 はてなにおけるLinuxネットワークスタックパフォーマンス改善 / Linux network performance improvement at hatena - Speaker Deck HAProxy や nginx などのソフトウェアロードバランサやリバースプロキシ、memcached などの KVS のような高パケットレートになりやすいネットワークアプリケーションにおいて、単一の CPU コアに負荷が偏り、マルチコアスケールしないことがあります。 今回は、このようなネットワークアプリケーションにおいて CPU 負荷がマルチコアスケールしない理由と、マルチコアスケールさせるための Linux カーネルのネットワークスタックのチューニング手法として RFS (Receive Flow Steering) を
Tumblrの省メモリーな無限スクロール - 記録
無限スクロールまたはauto pagingと呼ばれるUIには、読み終えたコンテンツがどんどん画面の上のほうに溜まっていってメモリーを食い潰すという問題がある。 なかでもTumblrは画像などのコンテンツが多いため、ダッシュボードダイバーたちは無限Tumblrユーザースクリプトなどのユーザースクリプトをインストールして、読み終えたコンテンツを定期的にページ上から自動削除するといった対策を講じていた。 ところが最近のTumblrのダッシュボードでは、ポストが画面外に出るとその中の要素が一時的にページから削除され、画面内に表示されると要素が再度復元されるようになっている。どうやらこれによって無限スクロールによるメモリーの圧迫が抑えられているらしい。 関連するコードはhttps://secure.assets.tumblr.com/assets/scripts/dashboard.jsの/*! s
はてなブログにおけるページ表示速度改善の取り組みについて - Hatena Developer Blog
こんにちは、id:hakobe932です。はてなブログではユーザ体験の改善のために、ページ表示速度を向上させるための様々な取り組みを行っています。このエントリーでは、はてなブログで行っている、ブラウザキャッシュの活用、JavaScriptのページ最下部での読み込み、JavaScriptの圧縮、という3つの取り組みについて解説します。 ブラウザキャッシュの活用 同じ内容のJavaScriptやCSSを、ページを表示するたびにダウンロードすると、余分なHTTPリクエストが発生しますし、読み込み時間がかかります。 ブラウザのキャッシュを利用できれば、余分なリクエストを減らすことができます。はてなブログでは、なるべく長い間ブラウザにキャッシュを保存するために、JavaScriptなどの一部の種類のファイルのレスポンスに、以下のようなヘッダを指定しています。 $ curl -I http://hat
卜部昌平のあまりreblogしないtumblr - 最速の memset64 を求めて 今回のお題は char 幅じゃなくて word 幅の...
今回のお題は char 幅じゃなくて word 幅の memset 、つまりプロトタイプだと void* memset64(void* destination, uint64_t image, int num_words); をどれだけ高速に行うかという話。なぜ高速化するかというと、塗りつぶす領域がけっこうでかいから。 候補 1: REP STOSvoid* memset64(void* d, uint64_t i, int n) { asm("cld; rep stosq;" :: "D"(d), "a"(i), "c"(n) : "memory"); return d; } 最近の CPU はクソ賢い。そのため、下手に手で loop unrolling するよりも、逆に CPU に「ここはループなんだぞおおお～」というのを明示的に指示してあげたほうが CPU 側が勝手かつ不気味に最適な
Rubyでフィボナッチ数列の演算が遅い問題についてのその後の考察。@解決編 - CanI's diary
@Python編？何それおいしいの？(ぁ ついに解決！ ずっと、ここ一連のエントリで、Rubyの多倍長演算の遅さについて嘆いてきたわけですが、何度かささださんからアドバイスをいただきつつも、ついにボトルネックを発見し、解消することができました。 ボトルネックの正体。 過去のエントリでは、Pythonとほとんど同じ処理だよ？おかしいね？とか言ってたわけですが、かなり煮詰まってきて、静的にコードを眺めてるだけじゃどうにもいかなくなったので、実行時のプロファイルをとってみることにしました。 使用したプロファイラはgprofです。 Ubuntu 9.04で、 make CFLAGS=-pg とかして、(cygwinでは-pgオプションつけるとmake通らなかった＞＜) 適当に、スクリプトを実行、 ./ruby hoge.rb その後、 gprof ruby gmon.out とかしてあげると、Cレ
「JavaScriptと性能についての本当の話」をしよう。ダグラス・クロックフォード氏
JSONの発見者でJavScript界の重鎮であるYahoo!のダグラス・クロックフォード（Douglas Crockford）氏。米オライリーが主催するイベント「Velocity 2011」で、セッション「JavaScript & Metaperformance」を行いました。 いまWebブラウザ間でJavaScriptエンジンの性能競争が行われていますが、その影響とこの先の展望について語っています。JavaScriptプログラマなら必見の内容を、公開されたビデオを基に紹介しましょう。 JavaScript & Metaperformance これから、JavaScriptと性能についての本当の話をしよう。 JavaScriptはみなさんご存じかな？ いまや世界で最もポピュラーになったプログラミング言語だ。 JavaScriptは、Javaからシンタックスを、Schemeからファーストク
Speeding up Rails startup time –
In which I provide easy instructions to try a new patch that drastically improves the start up time of Ruby applications, in the hope that with wide support it will be merged into the upcoming 1.9.3 release. Skip to the bottom for instructions, or keep reading for the narrative. UPDATE: If you have trouble installing, grab a recent copy of rvm: rvm get head. Background Recent releases of MRI Ruby
PHP “require” Performance | GazeHawk Blog
We recently went through a round of performance improvements for our website, and got a significant performance boost off of a relatively small change. Previously, our code had a section at start of every page: require_once('include/Foo.php'); require_once('include/Bar.php'); . . . require_once('include/Baz.php'); Each file was a single class of the same name as the file. While we’re well aware of
TCMalloc : Thread-Caching Malloc
Sanjay Ghemawat Motivation TCMalloc is faster than the glibc 2.3 malloc (available as a separate library called ptmalloc2) and other mallocs that I have tested. ptmalloc2 takes approximately 300 nanoseconds to execute a malloc/free pair on a 2.8 GHz P4 (for small objects). The TCMalloc implementation takes approximately 50 nanoseconds for the same operation pair. Speed is important for a malloc im
2010年11月18日 "ミラクルパッチ"にLinusも大喜び！Linuxカーネルを高速化させた233行のコード | gihyo.jp
Linux Daily Topics 2010年11月18日"ミラクルパッチ"にLinusも大喜び！Linuxカーネルを高速化させた233行のコード Linus Torvalds氏という人は、少なくともメールの中では、かなりはっきりと感情を表に出す。誰かor何かに対して怒っているときは相手を名指しで批判（というより非難）し、逆にうれしいときはあふれる喜びを隠そうとしない。今回紹介するのは後者のほう。「I'm also very happy」「it is a _huge_ improvement」「Good job.」など、喜びと称賛の表現がたくさん書かれているメールだ。 Linus氏を歓喜させたのは、カーネル開発に携わるMike Galbraith氏が書いた233行のカーネルスケジューリングパッチ。このパッチを適用すると、デスクトップ環境においてパフォーマンスが著しく向上するという。
ループをたくさん回す処理を高速化する初歩の初歩。 - このブログは証明できない。
テキスト処理を中心にやっていましたが、画像処理に興味が出てきて、さっそくアプリを作りました。もともと下の記事のあたりでユーザーとして画像処理に興味を持って、当然の流れながら、自分でもつくってみようと。 Color Splash + TiltShift Generator + Instagramの写真加工が面白い。 - このブログは証明できない。 で、何かを間違えて、普通の画像処理ではなく、カメラの映像をリアルタイムに加工しはじめました。そうすると、パフォーマンスがかなりシビアなんですね。 iPhoneでカメラの映像をリアルタイム画像処理してみる。 - このブログは証明できない。 全ピクセルを操作しなければなりませんから、ループをたくさん回す必要があります。なんとか高速化できないかと考えてみたところ、あっさり高速化に成功しました。私が気づくぐらいですから、初歩の初歩なんだと思います。 追記：
Using MySQL as a NoSQL - A story for exceeding 750,000 qps on a commodity server
UPDATE: Oracle officially released memcached daemon plugin that talks with InnoDB. I'm glad to see that NoSQL+MySQL has become an official solution. It's still preview release but will be very promising. Let's try it to make it better! Most of high scale web applications use MySQL + memcached. Many of them use also NoSQL like TokyoCabinet/Tyrant. In some cases people have dropped MySQL and have sh
グーグルがWebを高速化するために何をしているか
本のページをめくるように、どんなWebページも素早く表示できるようにする。グーグルは以前からWebの高速化に取り組んできました。 6月22日から、米サンタクララで行われていたWebサイトのパフォーマンスと運用に関するオライリーのイベント「Velocity 2010」では、グーグルのUrs Hölzle氏がWebの高速化技術について「Speed Matters」（スピードの重要性）というセッションで紹介ています。 Webを高速化するためにどのような技術があり、あるいはどのような技術が検討されているのか、このセッションの内容を紹介しましょう。 スピードは重要だ 私が話そうとしているのは、「Speed matters｣（スピードの重要性）についてだ。Webは空飛ぶジャガイモより速くなれるだろうか？ どのくらい速くなれるだろうか？ （参考：オペラがやってくれた！ グーグルの空飛ぶジャガイモに対抗）
CSSセレクタの高速化の話し - Webtech Walker
続・ハイパフォーマンスWebサイトを読んでCSSセレクタの高速化の話しが面白かった（というか全然知らなくてちょっとびびった）ので紹介します。 セレクタは右から左に解釈される これは正直知らなくて、結構衝撃でした。 #foo .bar {} これはなんとなく#fooを探して、その中の.barを探している気がしてたんですけど、実は.barを探して、その親要素に#fooがあるかを探すそうです。なので特に#fooが必要なければ .bar {} と書いたほうが高速だということ。 また、以下の様に要素名で指定すると、その要素を全て探します。 #foo a {} これは一度a要素を全て探すので、できればaにclassをふって #foo .anchor {} とするほうが高速のようです。（#fooをとるとより高速） 特にユニバーサルセレクタなどは、 #foo * {} とすると、全ての要素の親要素に対して
ディレクトリの中にある大量の小さなファイルを高速に読み込む方法 - 射撃しつつ前転 改
ディレクトリの中にある大量のファイルを高速に読み込む方法が知りたかったので、実験してみた。想定しているシチュエーションは、一つ一つのファイルは数KB程度だが数が多い、という場合である。適当な順番でアクセスすると、ランダムアクセスになってしまいとても時間がかかる。個々のファイルを読み込む順番はどうでも良く、すべてのファイルを処理することさえできればいいので、原理的にはシーケンシャルアクセスで処理できてしかるべきである。 まず、ファイルシステムについて。HDDやSSDなどのハードウェアにアクセスする際には、ファイル名などという概念はもちろん存在しない。ファイル名と実際のディスク上の対応を管理するのがファイルシステムの主な役割である。ファイルシステムは、ファイル名からそのファイルに対応するブロック番号（メモリアドレスみたいなもんだな）を調べて、そのブロック番号を指定してHDDやSSDにアクセスす
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Is there anyway to read performance counters on OS X Mountain Lion?
0-readme.md
ruby-1.9.3-p194 cumulative performance patch. — Gist
http://pivotallabs.com/users/alex/blog/articles/1232-basic-ruby-webapp-performance-tuning-rails-or-sinatra-
TechCrunch
