Stale-While-Revalidate ヘッダによるブラウザキャッシュの非同期更新 | blog.jxck.io
Intro システムにおいてキャッシュの設計は永遠の課題であり、 Web のパフォーマンスにおいても非常に重要である。 Web では、 HTTP ヘッダを用いてブラウザやプロキシにキャッシュの制御を指定する。 Stale-While-Revalidate ヘッダは、このキャッシュ制御に選択肢を追加する新しい仕様である。 このヘッダの概要と、本サイトへの適用を解説する。 Web におけるキャッシュ キャッシュの種類 まず、ブラウザが持つ従来のキャッシュの機構について整理する。 そもそも、キャッシュを行う意義は大きく二つある。 リソースの取得を高速化する サーバへの負荷を減らす これまでは HTTP ヘッダを用いて、キャッシュを管理させる方法を用いてきた。 Web における、キャッシュの指定には大きく二つの方式がある。 ブラウザはリクエストを発行せず、保持するキャッシュを使用する(Cache-
Twitterはどうやって1秒に3,000もの画像を処理しているのか | FAworksブログ
現在、Twitter は1秒間あたり3,000枚の画像(約200GB)を作成し持続している。 しかしながら、2015年に Twitter はこれら画像ファイル等メディアファイルの保存方法を改善したために、600万ドルを節約することができた。 以前からそうだったわけではない。Twitter は2012年には主にテキストベースだった。 これはまるで、ホグワーツ魔法魔術学校であのかっこいい動く絵が壁にかかってないようなものだ。 2016年の今では Twitter はメディアを駆使した方向へと移行している。 Twitter は、プレビュー、マルチフォト、gif、vine、埋め込みビデオなどで写真をサポートできる新たなメディア・プラットフォームの開発を経て変化したのだ。 Twitter社のソフトウェア開発エンジニアであるHenna Kermani氏が、Mobile @Scale Londonでの興味
JavaScriptでのDOM操作は重いのかという話とForced Synchronous Layoutについて - id:anatooのブログ
2015年にもなるのにJavaScriptでのDOM操作のパフォーマンスについて書く。ウェブページにインタラクションを持たせたい時に、JavaScriptでDOM操作を行うことがよくある。このDOM操作のパフォーマンスについて、よく聞く意見を大別すると次の2つがある。 JavaScriptによるDOM操作は重たい レンダリングが重いだけで、DOM操作そのものはそれほど重たくない JavaScriptでオブジェクトのプロパティを操作したりする単体の処理は通常1ミリ秒もかからないが、DOM操作をするとレンダリングが完了するまでに数十ミリ秒程度かかったりする場合がある。1番目のDOM操作が重たいと言っている人は経験則的にそう言っていることが多い。 レンダリングの仕組みを知っている人は2番目の意見を言うが、重箱の隅をつつくような話をするとこれも必ずしも正しいわけではない。DOM操作するコードによっ
シンプルでかつ最高のJavaScriptプロファイラ sjsp を作りました！ ― Webアプリケーションが複雑化する中でプロファイラに求められるものとは何か - プログラムモグモグ
あらすじ Web技術が複雑になる中で、JavaScriptのプロファイリングをとる方法とは。 プロファイリングを取るためのコードを手で書いてみましょう。 とてもシンプルで、かつ最高のJavaScriptプロファイラ sjsp を作りました。 本当にあった怖い話 上司 「とにかくJavaScriptのコードを速くしてくれ」 私 「分かりました、速くします」 (次の日) 私 「いいプロファイラがないなら作ればいいじゃない」 同じチームの人 「えっ？」 私 「最高のJavaScriptプロファイラ作ったよ」 同じチームの人 「「えっえっ？？？」」 私 「早速使ってみたらこことここが遅いって分かったよ」 同じチームの人 「「「この子は一体…」」」 JavaScriptのプロファイリングの難しさ 近年、Webブラウザーの処理速度は著しく向上し、その可用性の高さから、アプリケーションのプラットフォーム
Webアプリケーション負荷試験実践入門
2015年2月24日 ヒカ☆ラボ発表資料 Webアプリケーション負荷試験実践入門 ■スライドの目的 負荷試験の重要性を認識して頂く 意味のある負荷試験を最短距離で行うための“段取り”を持ち帰って頂く 内容的には、主にAWS上のLAMP構成のシステムに対する負荷試験ですが、負荷試験ツールに依存しない全般的に通用する話を扱っています。Read less
Linuxでロードバランサやキャッシュサーバをマルチコアスケールさせるためのカーネルチューニング - ゆううきブログ
本記事の公開後の2016年7月にはてなにおけるチューニング事例を紹介した。 はてなにおけるLinuxネットワークスタックパフォーマンス改善 / Linux network performance improvement at hatena - Speaker Deck HAProxy や nginx などのソフトウェアロードバランサやリバースプロキシ、memcached などの KVS のような高パケットレートになりやすいネットワークアプリケーションにおいて、単一の CPU コアに負荷が偏り、マルチコアスケールしないことがあります。 今回は、このようなネットワークアプリケーションにおいて CPU 負荷がマルチコアスケールしない理由と、マルチコアスケールさせるための Linux カーネルのネットワークスタックのチューニング手法として RFS (Receive Flow Steering) を
さいきんの Rails サービスを高速化をしてみた - 2nd life (移転しました)
先日のももクロハッカソンで出会った wantedly を作ってる仲さんが と言ってたので、面白そうなので wantedly を速くしてみました。 wantedly ちなみにデータが数百万オーダーもなさそうなのに、どのページもログインすると2-5秒ぐらいかかっていたので、確実に速くできそうだなぁという感覚はやる前からありました。 アプリケーションサイドのチューニング 初心者*1にありがちな問題として SQL に適切にインデックス張ってない キャッシュすべき場所をキャッシュしていない 無駄なデータを引きすぎてる ことがよくあります。ので順に実装を見ていきました。 SQLに適切なインデックスを張ってない 張ってありました！びっくり！＼(^o^)／ キャッシュすべき場所をキャッシュしていない Facebook API を利用したアプリケーションなんですが、ユーザのデータの取得を毎回馬鹿正直に HT
Golang パフォーマンスチューニング - Qiita
この記事は Go Advent Calendar 2014 17 日目の記事です。 Go におけるパフォーマンスチューニングの話をします。 これらは Denco や Kocha などでのパフォーマンスチューニングの経験などから得た知見です。 処理系の話ではありませんのでご了承ください。 前提 プロファイリングを取った後、じゃあどうやって最適化するかというところの話です 「推測するな、計測せよ」 アルゴリズムやデータ構造は最適なものが選択されていると仮定します 小手先の最適化を行うよりアルゴリズム自体を変えたほうが圧倒的に良くなります。 この記事の各ベンチマークは Go 1.4 （go version go1.4 linux/amd64）で下記のコマンドにて取っています
MySQLのパラメーターチューニング at OSC 2014 Tokyo/Spring
去る2014/03/01(土)の OSC 2014 Tokyo/Spring でMyNAとしてセミナーの枠をいただいたので、おはなしししてきました。 雨の中たくさんの方に足を運んでいただきました。本当にどうもありがとうございました。 "MySQLパラメーターチューニングの理屈と定石"と銘打って、普段アプリを書いているような人向けに、俺が普段やってるパラメーターチューニングと同じくらいのことが誰にでもできるように…とか思って資料を作っていたんですが(社内のDB勉強会に使うネタのうち、パラメーター調整の部分だけを切り出した、というのがもともとのコンセプトです)、作れば作るほど、いかに自分が「考えるな。感じるんだ」でチューニングしているのかをむしろ思い知らされました。 「これとこれ見るでしょ？ そうするとなんか変な感じがするじゃない？ で、こことここだからこれかなって。いじってみたら違うから、近
Part4 IOPSを理解する
ディスク単体の性能を，1秒当たりに処理できるI/O数で示したものが「IOPS」である。DBサーバーなど頻ぱんにディスクにアクセスする用途では，IOPSが高いディスクほど性能が良い データ転送時間には，ディスクから磁気ヘッドがデータを読み書きする平均メディア転送速度やインタフェースの転送速度，ドライブの信号処理とデータ転送を制御するCPUの処理時間などが加味される。 実は，これらの値は公開されていないため，正確なデータ転送時間は分からない。ただし，4Kバイトや16Kバイトなど，OSの読み書き単位程度の大きさであれば，数10マイクロ秒から長くても1ミリ秒程度であり，誤差の範囲である。 仮に，4Kバイトのデータを書き込むために必要なデータ転送時間を1ミリ秒とする。平均アクセス時間6ミリ秒のディスクにデータを4Kバイト単位で書き込むとする。このディスクのIOPSは，「1/（6ミリ秒+1ミリ秒）=1
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
負荷分散技術を選ぶときに考えること
計算量と僕とWeb開発 / computational complexity and I and Web
Memory management in Linux
MySQLチューニング