3000req / sec と戦う - だるろぐ
ざっくり概要 ピークで3000req / sec 毎分コンテンツ更新要求 コンテンツ更新の際は他所からデータをapi経由で受け取る コンテンツ更新にはTheSchwartzを使用 なコンテンツを色々してきたログ。 尚、ここに書く技術は大半が周囲のギークな方々にサポートしてもらったもので、僕自身が何かしたわけではない。残念すぎる。 構成 internet -> www(squid -> apache) -> app(memcached -> app) -> db フロントエンド wwwサーバがapacheとsquidを動かしている。apacheがリクエストを受け、squidのキャッシュが有ればそれを返し、無ければバックエンドのappサーバへproxy。 バックエンド appサーバがmemcachedとアプリを動かしている。 それぞれ冗長化してるけど、リクエスト数の割に台数は少ない。 技術があ
Webデザイナーでもできる、サイトのパフォーマンスをあげる5つの方法
Webデザイナーでもできる、サイトのパフォーマンスをあげる5つの方法 2011-08-28 Webデザイナーが、Webサイトのパフォーマンスを重視する傾向はあまり無いように感じますが重要なことです。 Googleでは、0.5秒遅くなると、検索数が20%減少する amazonでは、0.1秒遅くなると、売り上げが1%減少する という報告もあるようです。Webサイトのパフォーマンスはコンバージョンにも影響する大切な部分。 今回はWebサイトのパフォーマンスを上げる方法を取り上げます。 パフォーマンスアップの前に 応答時間の限界 0.1秒までなら、結果はコンピューターではなく、ユーザーによって引き起こされたように感じる。 1秒までなら、"遅れている"と感じるが、ユーザーの思考は途切れずに、自由に動いていると感じる。 10秒までになると、ユーザーがコンピューターに振り回されている気持ちになり、ストレ
#isucon ではどんなことを考えながら作業していたか - 酒日記 はてな支店
前のエントリ #isucon で優勝してきました は当日夜に酔っ払った頭で勢いで書き上げたので、少し冷静に振り返ってまとめてみます。 最初のボトルネック発見 DB が CPU 4コアをフルに使って回っているのですぐに Query が重いのは分かった 重いクエリはキャッシュすれば、という発想は自然 (実際 MySQL のクエリキャッシュだけでスコアは 1.5倍程度上がる)、とはいえ このクエリは実行に 300〜400 ms 程度かかる アプリケーションの要件上、毎秒更新する必要がある 1秒ごとに更新に 0.3〜0.4秒かかる処理をするのは悪手だろう cache が消えてから生成、とすると生成処理が複数同時に走って無駄が大きい (実際ベンチマーク中の slow query を見ると 600〜700 ms 程度の時間が掛かっていた) ということで、DB のテーブル構成を変更して高速化できないか、
おそらくはそれさえも平凡な日々: #isucon で優勝させてもらってきました
まずは、ライブドアの皆様、素晴らしいイベントの提供本当にありがとうございました。めちゃくちゃ楽しかったです。 Kayacのエンジニア3人 @fujiwara @sugyan @songmu の3人でチームfujiwara組を結成し、結果優勝することができました。 実際は周りの認識通り、@fujiwaraさんに優勝させてもらったようなもので、@sugyanと僕は手を動かしていただけです。まあ、空気にならずには済んだので、そこは安堵しています。 修正したisuconソースはフォークしてGithubに置きました。プログラムの修正部分のみで、my.cnfの修正なんかはここには反映されていません。 さて、@fujiwaraのコンテストでの動きや、帰宅後のBlogアップまであらゆる仕事が速くてビビるんですけど、詳しくは、#isucon で優勝してきましたを見てもらうとして、 どういうドタバタがあったの
PHPを使う上で、どう書けば高速になるか？をその場で試せるベンチマーク結果満載なサイト:phpspot開発日誌
PHPを使う上で、どう書けば高速になるか？をその場で試せるベンチマーク結果満載なサイト 2011年05月23日- Benchmarks PHPを使う上で、どう書けば高速になるか？をその場で試せるベンチマーク結果満載なサイトがあるようです。 同じことをやるのに複数の書き方があったりしますが、2つの書き方を並べてそれぞれどちらがどれだけかかったかという結果が記載されていて面白いです。 で、そのいくらかかったか？という秒数も、ページ上でリアルタイムに計算され、リロードすると実行され、実行タイムが表示されます。 サイトの作者環境による比較ではなく、その場で動いて何度も試せるので自分でその差を確認できるのがGood。 個人的には長年PHPをやっているのですが知らなかった物も多々あり、非常に勉強になりました。 1回のロードでは結果が変になることもあるので、サーバの負荷にならない程度に数回確認させてもら
linuxデスクトップ環境をたったの3ステップで高速化する方法 - ぴょぴょぴょ？ - Linuxとかプログラミングの覚え書き -
各所で話題になっていますが、Linuxを劇的に高速化する方法が発見されました*1 *2 *3。特にブラウザなど複数のアプリケーションを同時に起動した状態では、体感速度がびっくりするほど向上します。 高速化する方法も簡単です。カーネルの再構築という難しい作業は不要で、設定ファイルを数行書き換えるだけです。是非試しましょう！ ステップ-1: ~/.bashrc の編集 ~/.bashrc の末尾に以下の4行を追加します。 if [ "$PS1" ] ; then mkdir -m 0700 /sys/fs/cgroup/cpu/user/$$ echo $$ > /sys/fs/cgroup/cpu/user/$$/tasks fi ステップ-2: /etc/rc.local の編集 /etc/rc.local の末尾に以下の2行を追加します(2010/11/24更新。不要なmkdirコマンド
Kansai.pm でウェブアプリのパフォーマンスチューニングの話をしました - 大西日記 - はてなダイアリー
スライドはこちらです。チューニングといいつつ計測とプロファイリングの手法の紹介です。 現在、はてなダイアリーの高速化に取り組んでいます。成果に期待してください。
CSSセレクタの高速化の話し - Webtech Walker
続・ハイパフォーマンスWebサイトを読んでCSSセレクタの高速化の話しが面白かった（というか全然知らなくてちょっとびびった）ので紹介します。 セレクタは右から左に解釈される これは正直知らなくて、結構衝撃でした。 #foo .bar {} これはなんとなく#fooを探して、その中の.barを探している気がしてたんですけど、実は.barを探して、その親要素に#fooがあるかを探すそうです。なので特に#fooが必要なければ .bar {} と書いたほうが高速だということ。 また、以下の様に要素名で指定すると、その要素を全て探します。 #foo a {} これは一度a要素を全て探すので、できればaにclassをふって #foo .anchor {} とするほうが高速のようです。（#fooをとるとより高速） 特にユニバーサルセレクタなどは、 #foo * {} とすると、全ての要素の親要素に対して
なぜTwitterは低遅延のままスケールできたのか 秒間120万つぶやきを処理、Twitterシステムの“今” − ＠IT
ユーザー同士のつながりを元に時系列に140文字のメッセージを20個ほど表示する――。Twitterのサービスは、文字にしてしまうと実にシンプルだが、背後には非常に大きな技術的チャレンジが横たわっている。つぶやき数は月間10億件を突破、Twitterを流れるメッセージ数は秒間120万にも達し、ユーザー同士のつながりを表すソーシャル・グラフですらメモリに載る量を超えている。途方もないスケールのデータをつないでいるにも関わらず、0.1秒以下でWebページの表示を完了させなければならない。そのために各データストレージは1～5ms程度で応答しなければならない。 Twitterのリスト機能の実装でプロジェクトリーダーを務めたこともあるNick Kallen氏が来日し、2010年4月19日から2日間の予定で開催中の「QCon Tokyo 2010」で基調講演を行った。「Data Architecture
SQLiteとトランザクション - とほほのN88-BASIC日記
SQLiteの追加/更新はトランザクションを使うと高速化に効果があるというのはよく効くので実際試してみました。 use strict; use warnings; use DBI; use Benchmark qw(:all); my $count = 100; my $loop = 100; cmpthese( $count, { commit_each_insert => \&commit_each_insert, commit_bulk_insert => \&commit_bulk_insert, } ); sub commit_each_insert { unlink('test1.db'); my $dbh = DBI->connect('dbi:SQLite:dbname=test1.db'); $dbh->do( "CREATE TABLE test (id int not
Now Text::MicroTemplate is even faster than HTML::Template::Pro - Islands in the byte stream (legacy)
前提：Text::MicroTemplateの速度を簡単にベンチマーク Text::MicroTemplateを最適化したので，ベンチマークをとってみた。 スクリプトはほぼ同じだが，loop countは-1*1にした。 http://github.com/kazuho/p5-text-microtemplate/blob/master/author/benchmark_templates.pl キャッシュを有効にした結果*2： $ perl benchmark_templates.pl Perl/5.10.1 (i686-linux) HTML::Template/2.9 HTML::Template::Compiled/0.94 HTML::Template::Pro/0.92 Template/2.22 Text::MicroTemplate/0.09 Benchmark: runn
oinume journal
大規模なコードベースでリファクタリングを省エネ化するためにcodemodを最近調べていて、軽く試行錯誤したのでそのメモ。 やりたいこと 例えば以下のようなTable Driven TestなコードをBEFOREからAFTERに書き換えたい。コード量が多いため人間がやるのは現実的ではなく、codemodで機械的に書き換えたい。 BEFORE package main import ( "slices" "testing" ) func TestContains(t *testing.T) { type args struct { ss []string s string } tests := []struct { name string args args want bool }{ { name: "empty: false", args: args{[]string{}, ""}, wan
oinume journal
大規模なコードベースでリファクタリングを省エネ化するためにcodemodを最近調べていて、軽く試行錯誤したのでそのメモ。 やりたいこと 例えば以下のようなTable Driven TestなコードをBEFOREからAFTERに書き換えたい。コード量が多いため人間がやるのは現実的ではなく、codemodで機械的に書き換えたい。 BEFORE package main import ( "slices" "testing" ) func TestContains(t *testing.T) { type args struct { ss []string s string } tests := []struct { name string args args want bool }{ { name: "empty: false", args: args{[]string{}, ""}, wan
JSONPなAPIの負荷対策にngx_http_jsonp_callbackってのを書いてみた - hideden.hatenablog.com
認証が不要で、結果をJSONPで返してくれるAPI。大体は高速化の為にmemcachedを使用し、cacheが存在すればcacheから、存在しなければDB等から引いてcacheに入れ、その後結果を返す設計になってるはず。 URL: http://api.example.com/count?user_id=12345&entry_id=12345&callback=hoge response: hoge({"status":"success", "count":1000});みたいなの。ほとんどの場合cacheにHitするので一瞬でresponseが返るけど、あまりに簡単なお仕事過ぎてそれの為にmod_perlのプロセスを使うのがもったいない。特に1日数千万回アクセスされるようなAPIだと積もり積もってすごい負荷に。 responseに使うJSONをそのままcacheに入れて、Tokyo T
驚愕の結果３ アルカリ乾電池性能比較実験！ 第3回 有名メーカー電池ガチンコ勝負！ 連続使用決戦！
あんぎゃ～！ ACアダプタが萌えた！ じゃねーっ！ ACアダプタが燃えた───ッ！ いつも通り夜中に電池の実験をしながら原稿を書いていると、部屋の隅からチリチリチリ……という嫌な音。これは電気関係のトラブルっ!? と部屋を見渡すも、5秒もするとシュー！ という音とともに、強烈なオゾン（昔の地下鉄の臭い）の臭いが部屋に充満する。どこかでショートしている!? パソコン？ 問題ナシッ！ 電灯？ 問題ナシッ！ パソコン周りのコンセント？ 問題ナシッ！ くっそー！ どこだっ!? ふと部屋の片隅にあるテーブルタップを見ると、かすかに煙が上がってるじゃないか！ これだ！ とACアダプタの刺さっている状態でテーブルタップを持ち上げると うぉぁ熱ちっちちちっ～！ なんとACアダプタが燃えていたのだ！ 急いで煙の昇っているACアダプタをテーブルタップから外すと、ご覧のとおりだ。
perl - for(1..1e10) と Iterator : 404 Blog Not Found
2006年12月22日11:00 カテゴリLiving on the Edge perl - for(1..1e10) と Iterator いい点に気づかれました。 perl の配列とメモリー: 国民宿舎はらぺこ 大浴場 面白いな、と思ったのは、上記リンク先の話題を手元で試していたときに、 @data = map { rand 10 } (1..1e7); $sum += $_ for @data; だとメモリーを喰いまくるのに、 $sum += rand 10 for 1..1e7; だとほとんどメモリーを喰わないこと。 実は、foreach($from..$to)は、Perl 5.005以来最適化されています。 perl5005delta - what's new for perl5.005 - search.cpan.org foreach (1..1000000) optimiz
perl - for(;;)よりforeach : 404 Blog Not Found
2009年03月29日23:45 カテゴリLightweight Languages perl - for(;;)よりforeach Perlベストプラクティス Damian Conway / クイープ訳 [原著:Perl Best Practices] 最近のid:naoyaのソースがすごく気になったので。 何が気になるかというと、for(;;)の利用。それもCやJavaScriptなど、事実上それしかないソースからそのまま転写したとかならとにかく、編集距離 (Levenshtein Distance) - naoyaのはてなダイアリーでは Python版がちゃんとxrangeを使っているのにPerl版がfor(;;)のでますます解せない。 "Perl Best Practices"でも、読みやすさの観点からCスタイルのforは避けよ(pp. 100-101)と言っているが、もう一つ損な
ウェブページの高速化に必要なもの
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、オークション事業部のさかいです。 ネットサーフィンに慣れている techblog 読者のみなさんの中には、あちこち見て回っているうちに重いページに行き当たり、イライラしながら応答を待ったり、容赦なくバックスペースキーで前のページに戻ったり…という経験をされた方が多くいらっしゃると思います。 そういったストレスのないレスポンスが行えるよう、バックエンドのプログラムの最適化や、サーバーのチューニングを行うのは私たち技術者の仕事のひとつです。 しかし、あるウェブサイトにアクセスして、そのサイトを閲覧できる状態になるまでの時間のうち、そういったバックエンドでの処理に必要な時間は 1〜2 割でしかないというデータがあります。残り
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
とあるアプリの開発運用(トラブルシュート)
BLOGOS サービス終了のお知らせ
