はてなブックマーク

去年は初めて予選敗退し悔しい思いをしたISUCONに今年も山形組として参加してきました。 結果は総合二位で本戦出場を決めました。やった！ 事前準備 前日にメンバーで作戦会議をして、「フルスクラッチ書き換えはやらない」という方針で大決定。過去フルスクラッチ書き換えでそこそこの結果を残してきた我がチームですが、去年の予選で手痛い失敗をしたのもあり今年は確実に予選を突破しようということで封印することになりました。 過去問を改めて解いたりはしなかったですが、matsuuさんのazure-isucon-templatesの一つをazureにdeployしてみて、なるほどazureはこういう感じかというのを確認したりはしていました。 当日 10:00 はじまっておもむろにazureにdeployしたところ テンプレート デプロイ 'Microsoft.Template' は、検証プロシージャによって無

毎年でているISUCONに今年も山形組として参加してきました。 今年もオンライン予選があり、9/26(土)の一日目に参加し結果は最高スコアが3000を少し超えるぐらいで惨敗でした。 簡単に何をしたのかをまとめると 事前作戦会議 チーム数多いしボーダーあがって厳しいことになるだろうしトップ狙うつもりでやらないとだろうなとは思ってます イチかバチかで飛び道具でも使って普通じゃないことをやらないと勝てないと思い込み kazeburoさんのこの時のエントリなどを読み込み脳内素振りを繰り返す。 当日 11:00 動作確認、コードリーディング 11:30 apt-get update;apt-get dist-upgrade;apt-get install xxx,xxx,xxx & reboot diskがroの罠にはまる。解決策はわからず、instance作り直し 12:30 第一回作戦会議 今回

ISUCON4本戦に毎度おなじみ山形組で参加してきました。結果は既報の通り、われわれは8千点前後の団子状態から抜け出すことはできず、60倍以上のスコアを叩き出したLINE選抜チームが連覇となりました。おめでとうございます。 ISUCON2で2位を取って以来、ISUCON3で5位、そして今回10位と順位を下げ続けており、年々高まる参加者のレベルが恐ろしい限りです。 やったこと redisを落として本当のインメモリDBアプリ化(aサーバ) 「来年、もう一度来て下さい、本当のインメモリDBアプリで優勝させますよ」 slot-IDベースでのnginxによる3台のサーバへの動画postの振り分け ad-IDはaサーバのアプリに問い合わせて発番した上で動画ファイル保存 asset-URLをあらかじめslot-IDベースで3台のサーバのアドレスに分散 nginxからmp4を直接serve –hostsは

毎年でているISUCONに今年も山形組として参加してきました。 今年もオンライン予選があり、9/27の一日目に参加し結果は暫定で7位でAMI審査に問題がなければほぼ予選通過はすると思われます。 で、今年は何をやったか、というとあいも変わらず去年と同じことをしておりました。去年と同じ方式でかくと やったこと 静的ファイルはnginx serve アプリ全書き換え 1fileなPSGI データはすべてオンメモリ 永続化はテキストファイルへ追記 nginx embedded perl + Plack::Handler::Nginx ←NEW! 最終形の構成をgithubにおいときました。 やれなかったこと 無し 最終提出スコア –workload 8で 62145 コンテスト中の流れ 事前にHDD8G メモリ15Gのm3.xlargeインスタンスだとわかっていたので、それがボトルネックの解消につ

ISUCON3本戦に毎度おなじみ山形組で参加してきました。結果は過去2回の出題者チームであるLINE選抜チームが圧倒的スコアで優勝という結果で、さすがでした。 うちは一応本番計測で完走したため5位という結果でしたが、途中経過では11位ぐらいをさまよっていましたので惨敗といって良いと思います。 ちなみに、予選も含めた過去4回の本番計測すべてを完走しているのはうちだけじゃないでしょうか。パーマネントなチーム自体が少ないので個人単位ならいるかもしれませんが。 やったこと nginx化 serve static x-accel-redirect 既存画像の事前リサイズ 新規画像のPOSTはオリジナルを置くだけにして、リサイズをApp::watcherで実施 明らかに無駄なコードの最適化 やれなかったこと インメモリDB化 画像ファイルのストレージ分散 新規画像のリサイズ処理のCPU分散 コンテスト

毎年でているISUCONに今年も山形組として参加しております。 今年からオンライン予選があり、10/5の一日目に参加し結果は現在のところ暫定で3位で予選通過の予定です。 暫定なのは使ったサーバの運営側による検査が残っているためです。 で、今年は何をやったか、というとあいも変わらず去年と同じことをしておりました。去年と同じ方式でかくと やったこと アプリ全書き換え 1fileなPSGI https://gist.github.com/nihen/6852251 feersum(1プロセスマルチスレッド) データはすべてオンメモリ スレッド間でシェア 永続化はテキストファイルへjsonで追記 html renderのキャッシュ(といってもmarkdownぐらいか) リバースプロキシをnginxにして静的ファイルもそこでserve やれなかったこと benchmark –workloadの試行

UnicodeのU+00A5問題 JavaとMySQLの組み合わせでUnicodeのU+00A5を用いたSQLインジェクションの可能性 なるほど。この問題は初耳だったので驚いた。 しかも、PreparedStatementを使っても解決されないという。この部分に非常に驚いたのでどういうことなのか少し調べてみた。 PreparedStatementとは？ mysqlにおける話としてはPrepared Statement (訳）がとてもわかりやすい。 なかでも重要なのは以下の部分だ。 PerlとJava のユーザはかなり長い間prepared statementを使って きました。しかし、これらはクライアント側のprepared statementでした。 クライアント側のprepared statementは同じようなセキュリティの恩恵 をもたらしますが、性能向上には至りません。でも心配いり

というわけで前回に引き続き山形組として参加してきました。 まとめブログはこちら 結果は、スコア18万切りに最初に到達すると頂ける特別賞を16時ごろ10万ちょうどぐらいのスコア(スコアは低いほうが優秀)で頂いたものの、その直後に藤原組さんにさくっと8万あたりのスコアで抜かれ、こちらも9万台のベストスコアはだしたものの、最終結果は10万あたりで、藤原組さんは8万台で2位で終了。 スコア的には僅差だったので正直かなり悔しいですが、藤原組さんは「実運用に突っ込んでも運用が破綻しない状態」を維持されていたようで、うちはかなりチート手法でしたのでこれはもう完敗ですね。次があったら正攻法で戦えるように経験値を上げて望みたいなと思いました。 やったこと アプリ全書き換え 1fileなPSGI https://gist.github.com/4006644 feersum(1プロセスマルチスレッド) データ

参加してきました。YAPC::Asia Tokyo 2012。 初発表してきました Tengにpull requestをよく送っていたからか、nekokakさんにやりませんかとIRCで声をかけて頂いて、やりますーと軽く答えて参加申し込みをしたはいいものの、ちゃんとした話ができるのか不安でしかたがなく、直前は緊張で吐きそうになるなどしつつ、発表者席に向かったところ目の前にnekokakさんが陣取っており(その場ではじめましてのご挨拶(!))、プレッシャーでクラクラしながらも、なんとか発表させていただきました。 反省点は多々ありますが、なんとか最後まで喋りきることはできたので一応満足はしています。今後は自分のプロダクトでの発表や、40分枠で喋れるような濃い発表ができるように日々意識して活動していこうと気持ちを新たにしました。 プレゼン資料公開しておきます。 追記: 2012/10/6 動画アッ

YAPC::Asia Tokyo 2011に参加してきました。 ブログ書くまでがYAPCというわけで印象にのこったセッションを中心に参加報告を。 前夜祭 myfinderさんの「サービス運用者のための継続的監視」はさすが日本で1番目か2番目か3番目のSNSの運用をされてるだけあってさすがという感じでした。自分は小規模システムばかりやっていて開発者も運用についてかなりコミットしなきゃいけない状況で働いているのですが、ここまできちんとできてないなーと痛感。さっそく監視項目をどんどん増やしていこうと思いました。 会場外のプチ懇親会的なものでは、ほぼボッチでしたが夏菜子推しTを装備していたsugyanさんと初めて挨拶させていただくなど。 一日目 寝坊＆体調不良で昼から参加。Jesse Vincentさんの「Perl 5.16 and beyond」とmalaさんの「Webアプリケーション高速化」が

(タイトルはid:hasegawayosukeさんが言ってたよ) ああ、まただよ… 「PHP使いはもう正規表現をblogに書くな」と言わせないでくれ 正規表現って、プログラミング言語間の差が少ないサブ言語なのに、なぜ「DAN」がつくとダメ正規表現ばかり登場するのか。うんざりだ。 飽きたので以下略。 簡潔に。(正規表現はdanさんのものからシングルクォートコンテキストにあわせてエスケープをしてあります) <?php $email = 'test@example.com' . "\n"; $re = '/^(?:(?:(?:(?:[a-zA-Z0-9_!#\$\%&\'*+\/=?\^`{}~|\-]+)(?:\.(?:[a-zA-Z0-9_!#\$\%&\'*+\/=?\^`{}~|\-]+))*)|(?:"(?:\\\\[^\r\n]|[^\\\\"])*")))\@(?:(?:(?:(?

なんでもありのWebアプリケーション高速化バトル、#isuconに山形組として参加してきました。 結果はみなさんご存知の通り、藤原組さんの圧勝という感じになりました。 自分はというと、DBボトルネックの解消までは藤原組さんとほぼ同じ手法で解決して、4700req/minあたりのbest scoreを出した後には有効なチューニングが行えずにnginx導入の罠にひっかかって200req/minとかになってしまって泣きながらapacheに戻したりしつつ、最後はサイドバーのcacheをmmapにいれる作業をしていたらバグでfailするようになってしまってぎりぎりでDBのボトルネック解消直後にロールバックして、10000req/3minくらいがたしか最終スコアだったと思います。failしたチームを除けば下から数えたほうが早い感じになってかなり悔しい結果でした。 DBボトルネック解消直後にappサーバ

YAPC::Kyoto 2023に参加してきました。YAPCにはYAPC::Asia Tokyo 2015以来の参加なので、なんと8年ぶり(!)。 トーク応募もせずに京都までいくのはどうなんだろうとも思ったのですが、実は京都に一度も訪問したことがなかったため家族も呼び寄せ京都旅行も兼ねて行ってきました。 聞いた発表からいくつか感想 2023年春のPerl Perl最新情報ぜんぜん追えてないマンとしてはすごくためになりました。 売上と開発環境を同時に改善するために既存のPerl Web アプリケーションをどのようにリプレイスするか Perlでつくられた古いサービスをどうやって持続的に運用していくのか…。おそらくYAPCに参加されている方の多くに共通する悩みですよね。言語としてはPerlを維持しつつモダンにしていくという選択とその方法とても参考になりました。 ORM – Object-rela

Apache mod_headersでできます Header set X-Content-Type-Options nosniff Nginx add_header X-Content-Type-Options nosniff; 但し、上記だとproxyなんかで既にX-Content-Type-Options: nosniff;が付いていると X-Content-Type-Options: nosniff, nosniff のようなヘッダになってしまう。問題ないかもしれないが気になる場合はNginxHttpHeadersMoreModuleを使って more_set_headers 'X-Content-Type-Options: nosniff'; とすると良いのかも。 Plack Plack::Middleware::Headerを使うと簡単です。 enable 'Header', s

PHPで開発をすることが多くなりPerlの良さを再確認している今日この頃ですが皆さんいかがお過ごしでしょうか。 さて、今日は今もっともナウいPHPのWebアプリケーションフレームワークであるCakePHPのお話を一つ。 CakePHPには組み込みコンポーネントとしてリクエストハンドラ(RequestHandler)が備わっています。 リクエストハンドリング :: 組み込みのコンポーネント :: マニュアル :: 1.2 Collection :: The Cookbook: このRequestHandlerのメソッドであるgetClientIPが小学生には危険そうだというお話。(あ、このエントリのタイトル逆ｗ) まずはgetClientIPの実装コードを。(1.2を例にとっているが1.1もほぼ一緒である) https://trac.cakephp.org/browser/trunk/cak

能書き 前エントリを書いてからいろいろと調べていて驚いたんだけど、日本語のwebsiteで、それなりにまともにRFC822(RFC2822,RFC5322)に準拠した(もしくはきちんと意図的に準拠していない部分を選択している)正規表現はPerlだろうがPHPだろうがRubyだろうが軽くぐぐった程度では見当たらない。PerlのモジュールのEmail::AddressもEmail::Validも程度の差はあれ問題を抱えている。そこらへんの既存の出回ってる正規表現にどういった問題があるかなんてことは次回エントリにて。 というわけで、Perl、PHP、RubyでRFC5322準拠なメールアドレス(addr-spec)の正規表現を以下に示します。尚、addr-specの最終的な正規表現のみならずそれを作成するに至る部分も併記してあります。これは、最終的な正規表現だけでは難解すぎてとても理解できないか

TTの158倍速いというxslateですが、このベンチマークはSyntax::Kolonを使っています。 TT互換なSyntaxであるところの、Syntax::TTerseを使うとどうなるのかなということでhttp://github.com/nihen/p5-Text-Xslate/tree/add_tterse_benchのbenchmark/x-rich-enc.plとbenchmark/x-poor-env.plにTTerseも追加してみました。 以下結果 %perl benchmark/x-rich-env.pl Perl/5.12.1 i686-linux Text::Xslate/0.1056 Text::MicroTemplate/0.15 Text::MicroTemplate::Extended/0.11 Template/2.22 Text::ClearSilver/0

ホーム > mysql | perl > mysqlでskip-character-set-client-handshakeはもう使わないほうがいいと思われ 新しい 古い skip-character-set-client-handshake を [mysqld] セクションに追記すると、クライアントがどんな文字コード設定をもっていようが問答無用で character_set_* を (_system をのぞいて) すべて同じ値に統一してくれる http://d.hatena.ne.jp/a666666/20090826/1251270979 ふーむ。 skip-character-set-client-handshakeを薦める文書がネット上にはやたら転がってるんだけど、これには大きな落とし穴がある。 たしかに表示されるcharacter_set_*は統一されるかもしれないがこれはあくま

最近のwebセキュリティ界隈ではCSRFやDNS-Rebindingが話題ですが、Plackでアプリケーションサーバを立ち上げる際にこれらの対策をどのように行うかについてまとめてみました。 まず、CSRF対策ですが、拙作のPlack::Middleware::RefererCheckを使うことにより、RefererのチェックによるCSRF対策が行えます。CSRF対策としては、onetime token方式も存在しますが、個人的にはRefererチェックが導入が楽で好きではあります。Refererを送信しないクライアントを対象にしたサービスを運営される方は別途onetime token方式の対策をおこなってください。 Plack::Middleware::RefererCheckの使い方はこのようになります。(SYNOPSYSからの抜粋) use Plack::Builder; builde