ISUCON6 予選で得た知見やノウハウなど（デキル ISUCON スタイル） - だるい
今回の初期構成は 3 つのマイクロサービスで構成されるウェブアプリケーションでした。そのうち 2 つは例年通り各言語での実装が用意されていましたが、3 つ目は単にコンパイル済バイナリが置いてあるだけという感じでした。そのため、前者 2 つのアプリケーションはコード内容を含め改善しつつ、3 つめのアプリケーションについては本体を改善不可能と諦めそもそもアプリケーションを極力呼ばないようにするのが重要だったかなと思います。 今回の主題となるアプリケーションは isuda と呼ばれるシンプルなオンライン辞書投稿サービスでした。単語の解説記事部分のテキストには他の単語へのキーワードリンクが挿入されているという仕様があったので、新しい単語が投稿されるたびに、その単語を含む既存の単語の解説記事部分を再生成する必要があるというものでした。 我々のチームでは Ruby 実装を改善していきましたが、Ruby
Rubyist Magazine - RubyOnRails を使ってみる 【第 10 回】 パフォーマンスチューニング
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、日本 Ruby の会の有志による Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0058 号 バックナンバー Rubyist Magazine 0058 号 RubyKaigi 2018 直前特集号 Rubyist Magazine 0057 号 RubyKaigi 2017 直前特集号 Rubyist Magazine 0056 号 Rubyist Magazine 0055 号 Rubyist Magazine 0054 号 東京 Ruby 会議 11 直
30分でできる！Webサイトを高速化する6大原則 (1/4)
Webサイトを制作するとき、「パフォーマンス」を気にしたことがあるだろうか？ もしまったく気にしたことがないなら、気をつけた方がいい。閲覧に時間のかかる“遅いWebサイト”はユーザーにフラストレーションを与え、閲覧をやめさせてしまう恐れがある。 下記のグラフは、「Simple-Talk」という海外のオンラインメディアで発表されたユーザー調査の結果だ。アンケートページの表示にかかる時間を意図的にコントロールし、表示時間によってユーザーが感じるフラストレーションの違いを調べたものだ。 縦軸がフラストレーション（10段階）、横軸が表示までの時間を表している。1～5秒以内にページが表示された人に比べ、ページ表示までに5秒以上かかった人は2倍以上もフラストレーションを感じている。フラストレーションがあまりに高ければ、せっかく何らかの目的を持って訪れてきたユーザーも待ち切れずにブラウザーを閉じてしまう
JavaScriptの最適化について、code.google.comの記事の適当訳 - それ図解で。・・・tohokuaikiのチラシの裏
GoogleがWeb全体のスピードアップにいよいよ本格的に着手, 一社だけではできないと強調 からリンクのあった、 http://code.google.com/intl/ja/speed/articles/optimizing-javascript.html が日本語かと思ったら日本語じゃなかった・・・・。 いやー、意外とというか文字列については、全然知らんかった。 Closureって便利だし、「おぉ〜俺って使ってるジャン」みたいな気になれるからついつい使っちゃうんだけど、高コストなのね・・・・。反省。 ということで、超適当翻訳。どっかの誰かが書いてるかも。 前おき 著者: Google Chromeのエンジニア Gregory Baker, Software Engineer on GMail & Erik Arvidsson 推奨される経験：JavaScriptの実践的な知識 クライ
HowFriendFeedUsesMySqlToStoreSchemaLessData - FriendFeed では MySQL を使いどのようにスキーマレスのデータを保存しているのか
HowFriendFeedUsesMySqlToStoreSchemaLessData - FriendFeed では MySQL を使いどのようにスキーマレスのデータを保存しているのか 目次 この記事について FriendFeed? では MySQL を使いどのようにスキーマレスのデータを保存しているのか 背景 概観 詳細 一貫性と原子性 性能 FriendFeed? では MySQL を使いどのようにスキーマレスのデータを保存しているのか この記事について "How FriendFeed? uses MySQL to store schema-less data" の日本語訳です http://bret.appspot.com/entry/how-friendfeed-uses-mysql CC 2.5 でライセンスされています: http://creativecommons.org/
PerlとRubyで省メモリなハッシュを使おう - mixi engineer blog
サボっていた早朝ジョギング＠駒沢公園を再開して2週間たち、やっと抜かれる数より抜く数の方が増えてきたmikioです。今回は、PerlやRubyのハッシュの代用としてTokyo Cabinetを使うことでメモリ使用量を激減させられることを説明します。 抽象データベースAPI Tokyo Cabinetには抽象データベースという機構があり、先日、そのPerlとRubyのバインディングをリリースしました。それを使うと、各種言語のハッシュとほぼ同じような共通したインターフェイスで、以下のデータ構造を利用することができます。 オンメモリハッシュ：各種言語に標準のハッシュと同じく、メモリ上でkey/valueの関係を表現する。 オンメモリツリー：メモリ上の二分探索木としてkey/valueの関係を表現する。 ファイルハッシュ：いわゆるDBMとして、ファイル上でkey/valueの関係を表現する。 ファ
やってはいけない!!MySQLに悲鳴をあげさせる10の方法
いつも「MySQLを使うときはこうするべき」という観点から記事を書いているが、今日は逆に犯してはいけない過ちをリストアップしようと思う。 1. 全てのカラムにインデックスをつけるデータベース初心者がもっともやってしまいがちな間違いはコレではないだろうか。インデックスはいい。検索がとても速くなるから。しかし、それと引き替えにインデックスは更新するときにコストがかかるし、その分多くのディスクスペースを消費する。特に更新にかかるコストは時に甚大で、該当するインデックスのページがキャッシュ上にない場合はディスクからいったんそのページを読み込まなければいけない。ディスクアクセスは動作にとても時間がかかるので、インデックスが多数、例えば全てのカラムに付いていたりすると「あれ？固まったか？」というような状態になってしまうことがあるだろう。インデックスは必要なカラムにだけつけるようにテーブルを設計しよう。
MySQLのEXPLAINを徹底解説!!
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
ウェブページの高速化に必要なもの
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、オークション事業部のさかいです。 ネットサーフィンに慣れている techblog 読者のみなさんの中には、あちこち見て回っているうちに重いページに行き当たり、イライラしながら応答を待ったり、容赦なくバックスペースキーで前のページに戻ったり…という経験をされた方が多くいらっしゃると思います。 そういったストレスのないレスポンスが行えるよう、バックエンドのプログラムの最適化や、サーバーのチューニングを行うのは私たち技術者の仕事のひとつです。 しかし、あるウェブサイトにアクセスして、そのサイトを閲覧できる状態になるまでの時間のうち、そういったバックエンドでの処理に必要な時間は 1〜2 割でしかないというデータがあります。残り
MySQLレプリケーションを安全に利用するための10のテクニック
MySQLのレプリケーションは非常に簡単に使える割には応用の幅が広いので非常に人気のある機能の一つである。レプリケーションの応用分野は例えば、 バックアップ 参照系の負荷分散 HA（高可用性） ディザスタリカバリ（サイト間レプリケーション） BI（レポーティングetc） という風にとても多くのバリエーションがある。このブログを読んで頂いている皆さんの中にもレプリケーションを使っている方は多いのではないだろうか。ご覧の通りMySQLのレプリケーション機能はミッションクリティカル分野でも利用されているが、レプリケーションの使い方が適切でないとシステムの安定稼働に支障を来してしまってDBAやシステム管理者の肉体的、精神的負担が増大してしまう。逆にレプリケーションを堅牢に運用することが出来ればマクラを高くして眠れるというものだ。レプリケーションはMySQLの代表的な機能であるので、レプリケーション
さらにMySQLを高速化する7つの方法
MySQLを高速化する10の方法という記事がとても好評だったようである。記事を読んで頂いた皆さん、ありがとう。 この記事に対する便乗（？）でWeb屋のネタ帳: PostgreSQLを高速化する16のポイントという記事を書いて頂いたようだが、そちらの方もかなり人気だったようである。他人が作ったソフトウェアに改良を加えるというフリーソフトウェアやオープンソースソフトウェアの精神も基本は便乗であるので、便乗については大いに賛成したいというかむしろ取り上げてくれてありがとう！！と思うわけであるが、ここでさらに俺はこう考える。 と。 Web屋のネタ帳さんの記事では16のポイントが紹介されているが、漢（オトコ）のコンピュータ道の記事は10の方法だったのであと6つ足りない。オトコは数で勝負！！というわけで今日はネタを振り絞ってさらに7つのMySQL高速化テクニックを紹介しよう。 1. インテルコンパイラ
APIとの通信効率をよくする実装例(1) curl_multi
こんにちは。ライフスタイル事業部のアリタと申します。 Yahoo!のサービスも裏側ではWebAPIが多用されています。1つのページを構成するのに5、6個のAPIを使うこともざらですが、それではさすがにパフォーマンスが問題となってきます。その原因と対策例を紹介していきましょう。 ■モデルケース 例として、3つのAPIから取得したデータをマッシュアップしたページがあるとします。（ここではサンプルコードを簡単にするため、APIの代わりに以下のRSSで説明としました） Yahoo!トピックス エンターテインメントRSS http://dailynews.yahoo.co.jp/fc/entertainment/rss.xml Yahoo!ミュージックマガジン最新情報RSS http://magazine.music.yahoo.co.jp/rss/ALL/rss.xml Yahoo!検索トレンドR
FriendFeedはどのようにスキーマレスなデータをMySQLに格納しているか - モジログ
FriendFeedのBret Taylorが、スキーマレスなデータ（スキーマ（型）に制約されないデータ）をMySQLに格納する方法を紹介している。実際にFriendFeedで使っている方法で、最新のものらしい。 Bret Taylor's blog - How FriendFeed uses MySQL to store schema-less data http://bret.appspot.com/entry/how-friendfeed-uses-mysql MySQLを通常のRDB的な方法でなくストレージ的に使い、JOINを使わないでスケールさせるというもの。CouchDBなどにも近い、最近有力になりつつあるアプローチだ。これを、実績もあり普及しているMySQLを使って実現し、言語はPythonで実装している。 メインのテーブルは次のようなもの。 CREATE TABLE ent
Ywcafe.net
Ywcafe.net This Page Is Under Construction - Coming Soon! Why am I seeing this 'Under Construction' page? Related Searches: Free Credit Report music videos Migraine Pain Relief Best Mortgage Rates Credit Card Application Trademark Free Notice Review our Privacy Policy Service Agreement Legal Notice Privacy Policy
漢(オトコ)のコンピュータ道: MySQLを高速化する10の方法
ちょっとキャッチ−なタイトルをつけてしまったが、今日は独断と偏見でMySQLを高速化する方法を10個紹介しよう。MySQLサーバをチューニングするときや初期導入する場合などに参考にしてもらいたい。 1. バッファを増やす、または減らす チューニングの基本中の基本であるが、適切なバッファサイズを設定することはパフォーマンスチューニングの要である。主なバッファは次の通り。 innodb_buffer_pool_size・・・InnoDBだけを利用する場合は空きメモリの7〜8割程度を割り当てる最も重要なバッファである。余談だが、実際にはここで割り当てた値の5〜10%ぐらいを多めにメモリを使うので注意が必要だ。 key_buffer_size・・・MyISAMだけを利用する場合は、空きメモリの3割程度を割り当てるといい。残りはファイルシステムのキャッシュ用に残しておこう。 sort_buffer_
あなたのウェブサイトを高速化する方法 - builder by ZDNet Japan
そして同氏は、世界で最も高速なウェブサイトの1つであるGoogleのパフォーマンスにかかわる仕事をしているのである。 ウェブのパフォーマンスには2つの重要な側面、すなわち効率性と応答時間がある。効率性は、世界ランキング100位に入るようなウェブサイトを構築する際に出てくるスケーラビリティという難問に取り組むための武器である。あなたのウェブサイトが何百万人単位のユーザーと、何十億単位のページビューを擁するような規模のものである場合、バックエンドアーキテクチャ全体に対する理解を深めておくことが重要となるだろう。 ページの速度というものは、HTMLドキュメント内に記述する一連の指示によって決定されると言っても過言ではない。 iGoogleを例に挙げると、バックエンド処理に費やされる時間、すなわちデータがキャッシュされていないために毎回リクエストされることで費やされる時間は、ページ全体の処理時間の
満足せる豚。眠たげなポチ。:大規模サービスの運用事例まとめ
ここ数年の大規模サービスのシステム運用について調べてみたので参照したページやファイル、本へのリンクをまとめておく。PDF へのリンクも多数含まれているのでご注意を。 時代が時代なら企業のノウハウとして隠されていたような情報がこれだけ公開してもらえているというのが非常にありがたい。公開してくれている各企業や公開してくれている人に感謝。 あとで気付いたが、Google や Facebook の事例も探しておけばよかった。Thrift とかあったのに。「こんな情報もあったよ」などあればぜひ教えてください。追記していきます。 youtube http://d.hatena.ne.jp/stanaka/20070427/1177651323 digg http://d.hatena.ne.jp/stanaka/20070427/1177651323 livedoor http://labs.cybo
マルチコア時代のロードアベレージの見方 - naoyaのはてなダイアリー
ちょっと煽り気味のタイトルですが、CPU がマルチコアになり 2個、4個と増えていく中 Linux の負荷の指針になるロードアベレージをどう読むべきか、という話です。気になったところを少し調べたのでそのまとめを。 http://d.hatena.ne.jp/naoya/20070222/1172116665 でも書いたとおり、Linux のロードアベレージは「ロードアベレージは過去1分、5分、15分の間の実行待ちプロセス数の平均数 = 実行したくても他のプロセスが実行中で実行できないプロセスが平均で何個ぐらい存在してるか」を示す値です。ボトルネックが CPU、メモリ、ディスク等々どこにあるかは関係なく、仕事の実行までにどれぐらい待たされているかを示す値なので、システムのスループットを計測する指標の入り口になる値です。 このロードアベレージですが、実装を見るとランキュー(待ち行列)に溜まった
sanonosa システム管理コラム集: サーバのボトルネックはどうやって調べるか
サーバのレスポンスが遅くなると経験のないサーバ管理者は無意味にメモリ増強を行ったりしますが、行き当たりばったりのシステム拡張は無駄な投資につながります。ボトルネック個所の調べ方は案外簡単なので、この際押さえるところをきちんと押さえて正しい方法論でシステム拡張をしていきましょう。 【一般論】 ボトルネックとなりうる要素は主に４つです。 ①CPU使用率 ②メモリ使用量 ③ディスクI/O ④TCPコネクション数 これらを押さえておけばボトルネック個所の把握とその解消は難しくありません。これを踏まえた一般論を述べてみたいと思います。 WEBサーバの場合は多くの場合、TCPコネクション数から先に限界が来ます。OSやApache等のWEBサーバのパフォーマンスチューニングを十分施すことが前提ですが、その場合TCPコネクション数1万くらいまではなんとか保てると思いますが、それ以上のTCPコネクショ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Web ページを高速化する