livedoor Techブログ : 自家製 #isucon のつくりかた
こんにちは、ISUCON というイベントのレギュレーションを考えたり環境の準備をやったりコード書いたりしてた tagomoris です。普段はライブドア開発本部のインフラサービス部というところで働いてます。 先日ISUCONは幸いにも大好評のうちに終了したのですが、へとへとになって疲れ切った状態で帰宅し、寝て起きてみると、公開しておいたソースコードをさっそく自分の手元で動かしている人がいました。説明とか何にもなかったのによくそこまで。どういうことなのと思わずにはいられません。 #isucon に参加してきました＆isuconツールを試してみました - As a Futurist... また翌日にはTwitterでも続々と動かしてみた報告が見られ、エンジニアのみなさんのバイタリティには感服するばかりです。 ざいりょう で、せっかくだから本番と同じデータで同じように試せるようにしたいよね、とい
ISUCONに参加してきた - inuzのブログ
まずは運営のライブドアの皆さま、楽しいイベントをありがとうございました。 さて、俺id:inuzことTwitterID: inuwarumonoは同じ会社のアプリ屋2名と一緒に、チーム名「ツヤマ倶楽部」として出場してきたのでそのメモ/レポートを。 出場者3名とも名前はツヤマさんでは全然なくて、ツヤマというのは弊社技術部門の最高責任者の名前。(会社名は非公開)。 俺はインフラ/ミドルウェア屋なので、主にOSやらミドルウェアの最適化を考える担当。あとの2名はアプリケーション側からの切り口での改善と、それに伴うミドルウェアの最適化。両面からのアプローチというのが当初の作戦だった。 事前準備が肝、ということでツヤマ倶楽部の面々が考えていた事前対策は以下のとおり。 DBのクエリ解析が肝になるはず。的確にボトルネックを探すには断然クエリアナライザ。 パフォーマンスモニタリングが重要、でもまぁsarで良
#isucon に行ってきました (team_karakaniチーム) | カラカニのメモ帳
こんにちは。ほぼ1年に1回しか日記を書かないkarakaniです。重い腰がようやく上がり日記を書いてます。 #isucon 行ってました。[[@mutotaiju>https://twitter.com/#!/mutotaiju まとめと反省点 ・地道なボトルネックの調査は重要。 ・時間的な制約がある中で新しいことはやらないほうがいい(最近使い始めたGitを使おうとしたけど無駄に時間使った) ・経験も重要(他のチームのブログ見ててとても参考になりました) やったこと 次のことをしました。 1. アプリケーション(データベースへのアクセス)のパフォーマンスアップ 2. 静的コンテンツの扱い・リバースプロキシの設定 3. キャッシュ戦略(失敗) キャッシュ戦略は中途半端、というかできませんでした。 データベースはデチューニングされているのでは？ という声がありましたが、私たちのチームではほとん
藤原組長が、Webアプリ高速化バトルで優勝した件 | 面白法人カヤック
8月27日に行われた、ライブドア主催のWebアプリケーション高速化バトルイベント「ISUCON ~Iikanjini Speed Up CONTEST~」。カヤックからは、『fujiwara組』が出場し、ありがたいことに優勝をいただいちゃいました！ fujiwara組は、カヤックNO1との呼び声高いインフラエンジニア・藤原組長を筆頭に、現在パフォーマンス命のソーシャルゲームの開発・運用を担当する松木、グループチャットアプリ「ナカマップ」のサーバーサイドエンジニア杉の3名でチームを構成。 当日はライブドアさんがサーバー100台（！）をご用意してくださり、Webサービスの高速化に日頃から取り組むエンジニア20チームが集結して約8時間にわたる攻防戦を繰り広げたようです。 結果発表 livedoor Tech Blog カヤックで藤原組長と一緒に高速化に取り組んでみたいサーバーサイドエンジニアも募
おそらくはそれさえも平凡な日々: #isucon で優勝させてもらってきました
まずは、ライブドアの皆様、素晴らしいイベントの提供本当にありがとうございました。めちゃくちゃ楽しかったです。 Kayacのエンジニア3人 @fujiwara @sugyan @songmu の3人でチームfujiwara組を結成し、結果優勝することができました。 実際は周りの認識通り、@fujiwaraさんに優勝させてもらったようなもので、@sugyanと僕は手を動かしていただけです。まあ、空気にならずには済んだので、そこは安堵しています。 修正したisuconソースはフォークしてGithubに置きました。プログラムの修正部分のみで、my.cnfの修正なんかはここには反映されていません。 さて、@fujiwaraのコンテストでの動きや、帰宅後のBlogアップまであらゆる仕事が速くてビビるんですけど、詳しくは、#isucon で優勝してきましたを見てもらうとして、 どういうドタバタがあったの
#isucon に参加してきました
なんでもありのWebアプリケーション高速化バトル、#isucon 開催のお知らせ 参加経緯 後、@hansode さんを含め、@kyanny さんと俺の3人、”チーム情熱会” で参加してきました。 結果は審査用の3分間ベンチマークがこけたので、参考数値の100,604/minが最終でした。 チームでやれたこと mysqlのパラメータ調整(innodb周りとか) mysql問い合わせ結果をmemcachedでキャッシュ リバースプロキシをapacheからnginxに変更 刺身さんがアプリで入れてくれたクエリキャッシュが一番効果あったと思います。 俺はリバースプロキシの変更をやったくらいで、nginxにしてパフォーマンス下がったときはちょっと涙目だったけどベンチツールのhttpのkeep-alive罠を回避出来たのは良かったかな。 DBがボトルネックになってて原因になるクエリがあったのは早い段
#isucon で学ぶWebアプリの高速化の話 : As Sloth As Possible
あるいは、お遊びチーム2号は一体何をしていたのかについて。 ISUCONという大変白熱した楽しいお祭を開催するにあたって、その前夜祭的な環境試験のためのチューニング祭が社内の有志数名で行われていて、そのときに色々学んだことをおまけとして書いておきます。 ISUCONて何？ 下記参照。 なんでもありのWebアプリケーション高速化バトル、#isucon 開催のお知らせ 【締め切りました】Webアプリケーション高速化バトル、#isucon 詳細と参加者募集開始 ISUCON に参加してきました #isucon に参加してきました＆isuconツールを試してみました #isucon で優勝してきました isuconに参加してきた＆チーム「いんふらえんじにあー」の戦略など isuconお遊びチーム（事前社内β組）の設定あれこれ #isucon で優勝させてもらってきました #isucon に参加して
blog.nomadscafe.jp
PHPの勉強会なので、いままでお会いしたことのない方とお話ができてよかったです。 発表内容は大きくなってしまったmaster.phpファイルをどうやって高速に読むかというお話です。PHPではリクエストの終了とともに全てのメモリを捨ててしまうので、変わらないデータもリクエストの度にキャッシュからロードしなくてはいけません。大きなphpファイルがあれば当然毎回の読み込みがオーバーヘッドとなってきます。そんな環境でどうやってアプリケーションのパフォーマンスをあげていったのかを紹介しています。 スライドの中でfile sizeを小さくする必要があると書きましたが、@hnwさんによると、VM命令が多過ぎるのが問題で、構造を簡単にしたことでVM命令が減ったのがよかったのではとのことでした。非常に参考になりました。ありがとうございました そろそろ傷が癒えてきた。。 ISUCON5の本選にメルカリのインフ
#isucon に参加してきました＆isuconツールを試してみました - As a Futurist...
「なんでもありの」といううたい文句の通りに楽しめたチューニング大会#isucon に参加してきました。 livedoor Tech ブログ : なんでもありの Web アプリケーション高速化バトル、#isucon 開催のお知らせ 最初は参加するつもり無かったんですが、知ってる方がかなり参加されそうだったのと、MySQL Casual の帰りに@kamipo さんが 「3 人チームで#isucon に申し込んだけど、『kamipo』『未定』『未定』やねん！」 と悲しそうにしていたので、kamipo さんと 2 人チームで参加させて頂くことになりました。kamipo さんホントありがとう！！ちなみにチーム名はふたりとも大好きな「チームやすべえ」 あんま大したことができなかったし、藤原組とかいうや ◯ ざなチームが圧倒的な強さを見せたりしていたので、真面目な話はそちらにお譲りします！ #isuc
#isucon で優勝してきました - 酒日記 はてな支店
なんでもありのWebアプリケーション高速化バトル、#isucon に会社の同僚 @Songmu @sugyan と3人で、fujiwara組として参戦してきました。結果、幸いにも優勝を勝ち取ることが出来ました。 こんなに楽しいイベントを企画、運営していただいた Livedoor の皆様、本当にありがとうございます！！ さて、ざっとチューニングした経過などを記録しておきます。 [追記] もっと詳しいレポートを @Songmu が上げているのでそちらもご覧ください おそらくはそれさえも平凡な日々: #isucon で優勝させてもらってきました [さらに追記] #isucon ではどんなことを考えながら作業していたか - 酒日記 はてな支店 自分でももう少し詳しく振り返りエントリ書きました。 まず説明を聞いて、環境を作るところから。IPアドレスでは作業がしにくいし事故も起こりそうなので、host
isuconお遊びチーム（事前社内β組）の設定あれこれ - hideden.hatenablog.com
ISUCONに行ってきました。社内での事前βテストに参加して問題を知っていたので出場はせず。社内β参加を持ちかけられたときは、正直「めんどくせーなｗ」が素直な感想だったんですが、実際にやってみるとスコアがリアルタイムにわかる＆ちょっとずつ自分のスコアが上がっていくってのは楽しくて、わりと本気でチューニングしてしまいました。 さて、本戦でも14時頃からお遊び用としてサーバー一式が解放されたので、大人げも無くそこで112500req/minをたたき出して参加者のやる気を削いだ（・・と懇親会で言われました。色々すいません！）構成について。 reverse proxy nginx(1.0.5) ngx_http_memcached + ngx_http_ssi_filter + ngx_http_scgi + ngx_http_upstream_keepalive(3rd party plugin
Lampで作るソーシャルアプリの負荷対策～アプリとインフラの調和のテクニック～
2010/07/14 リリース直後から大量のユーザーが流れ込み、高負荷に晒されるソーシャルアプリ。システムダウンによって、ビジネスチャンスを逃さないためには負荷対策が不可欠です。 KLabは長年の大規模・高負荷モバイルサイトの構築・運用によって、対負荷性能を持ったアプリ・インフラのノウハウを積み重ねてきました。ソーシャルアプリ市場においてはオープン当初からSAPとして参入し、ソーシャルアプリならではのアクセス集中を経験したことで、現在はより安定したサービスを提供できるに至っています。 今回は、KLabが実施してきたそんな負荷対策ノウハウを広く紹介いただきます。Read less
Apache 2.2.11 に付属の ab(Apache Bench) は User-Agent を偽装出来る - 守破離
気付いたら一ヶ月も放置してた！ 筆無精でいかんですね、というか仕事が充実しすぎててあまり吐き出す事がない今日この頃でした。 んで、今日はこの前気付いた事の備忘録。 とりあえずHTTPサーバに負荷かけたいなぁ、となると個人的に一番お手軽だと思ってるのが ab(Apache Bench) です。 とは言え、Apache 2.0.41 の頃に使おうとした時は $ ab -H "User-Agent: DoCoMo/2.0 F01A(c100;TB;W24H17)" -n 100 -c 10 http://localhost/sample とかしても、User-Agent が ApacheBench/2.0.41-dev, DoCoMo/2.0 F01A(c100;TB;W24H17) とかになっちゃって、当時は単純に負荷書ける意外の目的ではあんまり使い物にならんかったのです (´･ω･`) で、
ApacheBenchでUA偽装
会社の先輩がみつけてくれました。感謝です。 abで /usr/local/apache2/bin/ab -n 100 -c 10 -H “User-Agent: DoCoMo/2.0 P905i(c100;TB;W24H15)” “http://example.com/” とかってやると$_SERVER['HTTP_USER_AGENT']は ApacheBench/2.0.41-dev, DoCoMo/2.0 P905i(c100;TB;W24H15) になってしまう。しかし!!今日教えてもらった方法 /usr/local/apache2/bin/ab -n 100 -c 10 -H “USER_AGENT: DoCoMo/2.0 P905i(c100;TB;W24H15)” “http://example.com/” でやれば$_SERVER['HTTP_USER_AGENT']は D
[ThinkIT] 第1回：チューニングの基準 (1/4)
データベースのチューニングという言葉からどのようなことを想像しますか。表の設計の見直しやSQL記述を探ること、バッファプールの調整などと主にデータベース自体の調整であったりするかと思います。 しかしこうしたチューニング作業を行ったにもかかわらず、パフォーマンスがあまり変化しなかった、明確に問題が解決されなかったなどといったといった経験はないでしょうか。またより詳細な調査の結果、実はOSの設定やデバイスドライバのバージョンに原因があった、あるいはハードウェアの選択に問題点があったということも聞いたことがあるかと思います。 もちろんデータベース自体のチューニングは欠かせないものですが、なんらかの問題が起こっている場合、システム全体を考慮しなければならない状況に陥ることがあります。 一口にパフォーマンスをチューニングするといっても、ハードウェアを含めたシステム全体を考えると、考慮すべき項目は多い
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
