Apache Killer が騒ぎになっている
cles::blog 平常心是道 blogs: cles::blog NP_cles() « t2g で GPS ログを可視化する :: LUMIX G X VARIO PZ 14-42mm/F3.5-5.6 ASPH./ POWE... » 2011/08/26 Apache Killer が騒ぎになっている httpd PoC DoS cve 118 0へぇ Apache Killer という Apache HTTPD への DoS ツールが出現して大騒ぎになっている模様。 プロジェクトからも「Advisory: Range header DoS vulnerability Apache HTTPD 1.3/2.x 」というセキュリティアドバイザリが出ています。 ApacheのDoSツールとしてはSlowloris が騒ぎになって以来でしょうか。 Advisory: Range
Full Disclosure: Apache Killer
Apache Killer From: "HI-TECH ." <isowarez.isowarez.isowarez () googlemail com> Date: Sat, 20 Aug 2011 00:23:26 +0200 (see attachment) /Kingcope Attachment: killapache.pl Description: _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ Current thread:
livedoor Techブログ : ISUCONやりましたーっ！ 最終結果発表 #isucon
ライブドア技術部会の伊勢幸一です。 去る 2011年 8月 27日(土曜日で隅田川花火大会の日)、いい感じにスピードアップコンテスト ISUCONを開催しました。参加者の皆さん、見学者の皆さん、関係者の皆さん、おつかれさまでした！あんど、ありがとうございました。おかげさまで予想以上に盛り上がり、つぶやきやブログエントリー等を見る限り皆さんに楽しんでいただけたようで、スタッフ一同開催してよかったと心から思っています。また、副賞の書籍をご提供して頂いた技術評論社様にこの場をお借りして心より御礼申し上げます。技評さんはエンジニアの味方ですねっ！（あたりまえかｗ） ここで、改めまして、コンテストの最終結果発表をさせて頂きます。 と、その前に ・・・・ コンテスト終了後、即時計測の結果に基づき優勝1チーム、準優勝1チームを表彰させていただきましたが、その際、最終的な結果確認の段階で得点のチェックにミ
エンジニアがやりたいというので 技術コンテスト #isucon の運営をしてみた - 941::blog
こんにちは！くしいです！お元気ですか！ 私ライブドアで働いてるのは結構知られてきたと思うのですが、実は開発本部に所属してまして、だけど開発部において唯一開発しない人という変わったかんじなんですが、何をしてるかっていうと「エンジニアのためになること」全般を引き受けてます。例えばMTGをセッティングしたり、会議室おさえたり、歓送迎会したり、という雑多な細かい仕事から、YAPCとかイベント的なものの運営とか大きなものまで。 で、あれはいつだったか。先月くらい？だったかな。 同僚のエンジニアが「こういうイベントやってみたい」とTweetしてるのを見て「へー」と思ってて、それを社内の技術系の話をするIRCチャンネルでまたしてたので「本気ならメールでえらい人に直談判しては」と返信してみて、ここからうろ覚えだけど「マジでやる気なら俺手伝いますよ」って言ったような気がして、「マジでやる気です」と言われたの
Apache の脆弱性対策：Apache Killer 対策 | 空模様
Apache Killer が危険そうなので対策を実施した。 ●Apache Killer とは GET もしくは HEAD メソッドで、多数のRange指定を含むリクエストを送ることで、ターゲットシステムのメモリとCPUを消費させるというもの。 8月20日に公開されたApacheの脆弱性（英語）をついたもので、現在パッチはリリースされていない（但し、8月25日時点で Apache 開発チームが、48時間以内にパッチをリリースすると発表している）。 ●攻撃を受けると具体的にどうなるか 仮想 OS で立てたサーバに攻撃を行い、どういう事象が発生するか実験してみた # Ubuntu 10.0.4 LTS # Apache 2.2.14 攻撃パケットは以下の画像の通り、Range ヘッダーに複数の指定を行うという単純なもの。尚、攻撃コードを見ると perl の fork を利用して並行で複数の
#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 で優勝してきました - 酒日記 はてな支店
なんでもありのWebアプリケーション高速化バトル、#isucon に会社の同僚 @Songmu @sugyan と3人で、fujiwara組として参戦してきました。結果、幸いにも優勝を勝ち取ることが出来ました。 こんなに楽しいイベントを企画、運営していただいた Livedoor の皆様、本当にありがとうございます！！ さて、ざっとチューニングした経過などを記録しておきます。 [追記] もっと詳しいレポートを @Songmu が上げているのでそちらもご覧ください おそらくはそれさえも平凡な日々: #isucon で優勝させてもらってきました [さらに追記] #isucon ではどんなことを考えながら作業していたか - 酒日記 はてな支店 自分でももう少し詳しく振り返りエントリ書きました。 まず説明を聞いて、環境を作るところから。IPアドレスでは作業がしにくいし事故も起こりそうなので、host
#isucon で学ぶWebアプリの高速化の話 : As Sloth As Possible
あるいは、お遊びチーム2号は一体何をしていたのかについて。 ISUCONという大変白熱した楽しいお祭を開催するにあたって、その前夜祭的な環境試験のためのチューニング祭が社内の有志数名で行われていて、そのときに色々学んだことをおまけとして書いておきます。 ISUCONて何？ 下記参照。 なんでもありのWebアプリケーション高速化バトル、#isucon 開催のお知らせ 【締め切りました】Webアプリケーション高速化バトル、#isucon 詳細と参加者募集開始 ISUCON に参加してきました #isucon に参加してきました＆isuconツールを試してみました #isucon で優勝してきました isuconに参加してきた＆チーム「いんふらえんじにあー」の戦略など isuconお遊びチーム（事前社内β組）の設定あれこれ #isucon で優勝させてもらってきました #isucon に参加して
Pjax に挑戦したら思っていた以上に苦労した話 - present
GitHub が採用している、非同期でぬるぬる動く画面遷移、これ pushState と Ajax を組み合わせたテクニックで実現されているんですね。その名も Pjax。 HTML5 の history.pushState を使うからブラウザの履歴にも対応でき、しかも URL がキレイ。Pjax についての詳細な説明は下記のエントリが参考になりました。 pjax こそが pushState + Ajax の本命 - punitan (a.k.a. punytan) のメモ Pjax 始まったな。 |i ＼ |.| ﾄ＼ /| ﾄ | ﾄヽ / | | ﾄ | | ﾄヽ＼/| | | ﾄ ／ | | | ト＼≧三ミゞ=イ/ ム彡''´￣￣ ￣ ヽ{__.. / Ｖ´ ﾉ ＿＿ ', ,. =＝ y￣, __､＼＿
#isucon に参加してきました＆isuconツールを試してみました - As a Futurist...
「なんでもありの」といううたい文句の通りに楽しめたチューニング大会#isucon に参加してきました。 livedoor Tech ブログ : なんでもありの Web アプリケーション高速化バトル、#isucon 開催のお知らせ 最初は参加するつもり無かったんですが、知ってる方がかなり参加されそうだったのと、MySQL Casual の帰りに@kamipo さんが 「3 人チームで#isucon に申し込んだけど、『kamipo』『未定』『未定』やねん！」 と悲しそうにしていたので、kamipo さんと 2 人チームで参加させて頂くことになりました。kamipo さんホントありがとう！！ちなみにチーム名はふたりとも大好きな「チームやすべえ」 あんま大したことができなかったし、藤原組とかいうや ◯ ざなチームが圧倒的な強さを見せたりしていたので、真面目な話はそちらにお譲りします！ #isuc
The Art of モバゲー Capacity Planning | Carpe Diem
さて、2009 年も残すところ、あとわずかとなりましたが、今日はモバゲー版のキャパシティプランニングを考えてみましょう。モバゲー版は、まだ実際にはサードパーティ製のアプリが公開されていない状況だとは思いますが、開発サイトが公開されています。モバゲー版も、mixi モバイルアプリ版と同様に、パートナー企業のみが開発できるようになっています。 まず、モバゲーの規模を知るために、 月次推移のご報告（平成21年10月度）を見てみましょう。この資料から、2009 年 10 月時点での PV は、次のようになっています。 会員数: 1527 万人 月間 PV: 約 238 億 PV 単純平均して、日間にすると約 8 億 pV、秒間にすると約 9,259 PVになります 次に、モバゲーの成長速度を計るため、月次推移のご報告（平成21年8月度）を見てみましょう。この資料から、2009 年 8 月時点での
ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない - kazuhoのメモ置き場
タイトルは煽り入ってますが。 仮に動的ページを生成するのにかかる時間が1秒、そのうちデータベースやmemcached等リモートサーバへの問い合わせ時間を除くいたCPUの処理時間が0.1秒とする。また、ピークのリクエスト処理量は、平均の２倍とする。 そうすると、クアッドコアのアプリケーションサーバで処理できるリクエストは、 4 core * 10 reqs/sec * 86,400 sec/day * 30 day/mon / 2 = 51,840,000 reqs/mon と、約5,000万PV/月を１台で捌けることになる。 CPUが動いている時間は全処理時間の10倍と仮定したわけだから、アプリケーションサーバの最大同時接続数は 4 core * 10 = 40 程度あればいいことになる。実際には、安全係数を２倍かけて 80 とか。リクエストの処理に必要なメモリ量を 100MB とすると、
データベースサーバを複数台構成とか2010年代には流行らない - blog.nomadscafe.jp
奥一穂さんの「ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない」にフォローのような感じで。 例によってタイトルは煽りです。 奥一穂さんのエントリーでは、「5,000万PV/Month」という見積もりでアプリケーションサーバの台数を1台と計算していますが、これからは「1,000万PV/Day」を超えるサイトが多く生まれてくると予想しています。どんなサイトかというと、mixiアプリやモバゲーなどにソーシャルゲームを提供するサイトです。 ソーシャルゲームサイトのキャパシティプランニングについては中澤さんのエントリーが参考になります。 The Art of モバゲー Capacity Planning The Art of Mixi-mobile-appli Capacity Planning 最も人気がでた場合には数千万から数億PV/Dayという数字がならんでいます。怖い怖
最速TCPサーバーの条件 〜逆襲の Erlang と Haskell の挑戦〜 : DSAS開発者の部屋
釣った反響に応えて echo サーバーを改良していて PyCon JP の発表資料作成が進みません。 自業自得です。 methane です。 Erlangとは何だったのか でのベンチマーク結果では Erlang のスコアが奮わなかったのですが、 github で 性能改善する pull request をいただきました。 性能が悪かった原因ですが、実は backlog がデフォルトだと 5 で、ベンチマーク開始時の 大量の接続要求を捌ききれていないという状況でした。 高負荷サイトのボトルネックを見つけるには で紹介されている事例と同じ現象ですが、こちらのほうが backlog が小さく、 しかもベンチマーク用クライアントはほぼ同時に大量に接続をしてくるという条件で よりシビアに現象が発生してしまいました。 この問題が修正された Erlang は、 Go を超えて一気にランキング上位に踊り出
#isucon に参加してきました
なんでもありのWebアプリケーション高速化バトル、#isucon 開催のお知らせ 参加経緯 後、@hansode さんを含め、@kyanny さんと俺の3人、”チーム情熱会” で参加してきました。 結果は審査用の3分間ベンチマークがこけたので、参考数値の100,604/minが最終でした。 チームでやれたこと mysqlのパラメータ調整(innodb周りとか) mysql問い合わせ結果をmemcachedでキャッシュ リバースプロキシをapacheからnginxに変更 刺身さんがアプリで入れてくれたクエリキャッシュが一番効果あったと思います。 俺はリバースプロキシの変更をやったくらいで、nginxにしてパフォーマンス下がったときはちょっと涙目だったけどベンチツールのhttpのkeep-alive罠を回避出来たのは良かったかな。 DBがボトルネックになってて原因になるクエリがあったのは早い段
チート対策とhttp_loadに仕掛けた罠の話 #isucon - blog.nomadscafe.jp
完全に文化祭疲れで昼寝3時間ぐらいしてしまいましたが、懇親会で聞かせて頂いた話やblogやtwitterをみる限り好評だったようで、うれしく思っています。ISUCONに参加して頂いた方、社内で協力して頂いた方ありがとうございました いくつか至らぬ点がありますが、明日以降に公式にフォローさせて頂きたいと思っています。 さて、既に公開されているので見た方は多いと思いますが、今回ISUCONで使ったベンチマークツールは大きく分けて次の3つのツールに分かれています。 (1) 1post/secでコメントを投稿し、1秒後にコメントをしたページと、インデックスおよび適当な記事のDOMチェックを行う node.js (2) http_load + patch (3) css/js/imageのMD5値を検証する perl script 最終的な順位はhttp_loadが行ったリクエスト数で決まるのでもし
#isucon に参加してきた - @kyanny's blog
#isucon に応募した - 刺身☆ブーメランのはてなダイアリー というわけで参加してきた。まず何よりも、一緒に参加してくれた @tnmt @hansode のお二人に感謝したいです。ありがとうございました！それから運営の皆様、他の参加者の皆様、お疲れ様でした。あと差し入れをもってきてくれた @umazura さん、 Ust で応援してくれた皆さんもありがとうございました。 ベストスコアは 10,000 を超えたものの最終測定時は FAIL というちょっと残念な結果に終わった。個人的にも悔しいことが二点あった。 遅いクエリは早々に突き止めていて、最適化にも取り組んでいたのに、途中で諦めて他のことをやり始めてしまったのが一点目。 id と日時だけを持つ中間テーブルを作ってそこから引くようにスキーマを変更しようとしたのだけど、そのテーブルから引き直したら結果がおかしくて混乱してしまった。いま
暮らしの情報サイトnanapiはサービスを終了いたしました | nanapi [ナナピ]
2020年8月31日(月)をもちまして、nanapiに関わるすべてのサービスは終了いたしました。 nanapiは、2009年のサービス開始より「みんなで作る暮らしのレシピ」という考えのもと、ユーザーの皆さまに生活に関する様々な「ハウツー」を投稿していただく投稿型ハウツーサービスとして運営してまいりました。 約11年間にわたって皆さまからご支援をいただきサービスを継続できたこと、nanapi編集部一同、心より御礼申し上げます。 掲載されていたコンテンツなどのnanapiについてのお問い合わせは、nanapi@supership.jp までお願いいたします。 長きに渡りnanapiを応援してくださり、本当にありがとうございました。
小規模Webサービス向け安上がりシステム構成と開発フロー（怖話.jp） - Fjord, Inc(株式会社フィヨルド)
こちらのエントリーが大変参考になったので、僕らが作ってる怖話.jp（kowabana.jp）のシステム構成や開発方法についても公開していこうと思います。 怖話.jpはスマホ向けWebサービスなのでPC向けとはPVとかの傾向がちょっと違うかも知れません。 怖話.jpとは スマホで17,000話以上のサウンドノベル風の怖い話が閲覧・投稿できるサイト（アプリではありません）です。詳しくは下記エントリーを参照してください。 スマホでサウンドノベル風怖い話投稿サイト | FJORD, LLC（合同会社フィヨルド） 7月16日にRubyKaigi2011に合わせて無理矢理ベータテストオープンして、8月9日に正式オープンしましたので正式オープンからは１ヶ月経ってないまだまだのサイトです。開発期間は約１ヶ月ぐらいです。 サイト情報 （これAnalyticsを直接貼るのはどうやればいいんだろう？） 直近一ヶ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
YASUYUKI OKAMURA | 岡村靖幸
journalplus.net
Journal+ : Google+ の人気投稿ランキング
グーグルの担当者が答えるグーグル検索Q&A あなたが聞いてみたい質問を募集します！ | Web担当者Forum
PyCon JP 2011 (8/27 開催) #pyconjp + Party & Sprints
http://blog.yuku-t.com/entry/20110823/1314111340
はぁはぁブログ