2013年の新卒研修と社内ISUCONやりました - (2) ISUCON死闘編 - KAYAC engineers' blog
技術部新卒研修担当の fujiwara です。 前回の記事「2013年の新卒研修と社内ISUCONやりました - (1) 研修編」に引き続き、新卒研修の最後を飾るイベント、社内ISUCONについて詳しく振り返ります。 社内ISUCONとは レギュレーションはこちらです。 各チーム1台ずつ使用できる仮想マシン上で、お題のアプリケーションを動作させる 外部からベンチマークを行って処理できたリクエスト数をスコアとする アプリケーション、OS、ミドルウェアなど、どのようなチューニングを行ってもよい ベンチマークスクリプトはデータの整合性をチェックするロジックが組み込まれており、アプリケーションとして不整合を起こしていることを検出するとFAIL(スコアなし) 10:00〜17:00 までの作業中には適宜ベンチマークを実行できる 作業終了後の最終計測でのスコアが高いものが優勝 (FAILしたら失格。1
#10 2012年に作ったものを振り返りつつProcletマジ便利 - KAYAC Engineers' Blog
2012年も残すところあと20日ほどとなりましたが皆様いかがお過ごしでしょうか。@fujiwara です。 このエントリは tech.kayac.com Advent Calendar 2012 10日目の記事です。 テーマが「私の中のマイイノベーション 2012」ということで、まずこの1年に作ったものを自分の blog エントリから振り返ってみますと… Perl から Fluentd にログ出力 - Fluent::Logger リリース 今年一番話題になったミドルウェアといえば fluentd でしょうか。その fluentd に Perl からログを出力するためのモジュールです Parallel::Benchmark というモジュールを書きました 並列にプロセスを起動して負荷を掛けるベンチマークを簡単に作るためのフレームワークです。弊社の主にソーシャルゲーム案件で、リリース前の負荷テ
#6「Shardingマジ怖い」tech.kayac.com Advent Calendar 2012 - KAYAC Engineers' Blog
最近子供が産まれたaraga(@ken39arg)です｡ このエントリはtech.kayac.com Advent Calendar 2012 6日目の記事です。 テーマは「私の中のマイイノベーション 2012」 2日目の記事を見て、条件反射的に僕もおっぱいについての記事を書こうと思いましたが、 産まれた子供が「お父さんはいつもおっぱいのことばっかり考えていて気持ち悪い」と思ってしまったらと思うと、こんな危険な橋を渡るわけには行かず、 実際いつもおっぱいのことばかり考えているんですけど、おっぱいのことなんて全然興味ないです。 息子よ、父さんはいつだってまじめに働いているよ！ というわけで今年作った"まじめな"ツールのMySQL::Sharding::Clientを自画自賛したいと思います。 MySQL::Sharding::Client MySQL::Sharding::Clientは一言
今日から始めるCoffeeScript - KAYAC Engineers' Blog
こんにちは。毎年花粉症になりかけている飯塚です。 最近のNode.jsの普及などによってサーバサイドJavaScript界隈が盛り上がっています。 そんなホットなJavaScriptをラクにかつエレガントに書くためのCoffeeScriptという言語をチュートリアル風に紹介します。 何かしらのライブラリを自分で書く程度にJavaScriptで開発している人は絶対に使ったほうがいいと思います。 JavaScriptを知っていれば1-2時間程度で十分駆使できるようになります。 （2011/6/28：@m_satyr様にご指摘頂いた箇所を修正しました。） 目次 CoffeeScriptとは？ インストール Hello World 構文 関数 変数展開 Objectの生成 ループ 存在チェック ヒアドキュメント thisのバインド クラス 無名関数 {var} Tips ?の使い分け 存在チェック
lighttpdでのファイルアップロードを高速化するハック - KAYAC engineers' blog
この時期にも花粉症に苦しむ村瀬です。こんにちは。 軽量で高速な動作がウリの lighttpd ですが、動的コンテンツで大きなファイルのやり取りを行おうとするととたんにパフォーマンスが落ちるという問題があります。 この問題は、lighttpdで動的コンテンツを扱う場合FastCGIを使用することが多いのですが、その構造に問題があります。 FastCGIを使用する場合のデータ通信の構造は以下のようになっています。 ブラウザ <---(1)---> lighttpd <---(2)---> FastCGI ブラウザとlighttpdとのデータのやり取り lighttpdとFastCGIプロセスとのやり取り プロセス数が有限なFastCGIでは、即座にデータを受け取り即座にレスポンスを返すというのが鉄則で、ここで時間のかかる処理をしてしまうとすぐにプロセスが埋まり待ち状態が発生してしまいます。 つ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
