Dockerは速いのか？Dockerのパフォーマンスについて重要なことは何か？ - ゆううきブログ
だいぶ前からDocker（Linuxコンテナ）のパフォーマンスについて、速いことは速いだろうけどどの程度速いのか、もし遅いことがあるなら何がパフォーマンスにとって重要なのか（AUFSが遅いとかそういうの）が気になっていたので、今回は で紹介されていた Docker のパフォーマンス検証に関する IBM の Research Report を読んだ。Report の内容をベースに、Docker のパフォーマンスの勘所などをまとめてみた。 Report のタイトルは An Updated Performance Comparison of Virtual Machines and Linux Containers 。 GitHub にベンチマークコードと実験データが置いてあってちゃんとしてる。 前提 まず、VMとコンテナの歴史を振り返るのに知らぬはエンジニアの恥。今さら聞けない【コンテナ/仮想
ISUCON4 で優勝してきました！！！ #isucon - blog.nomadscafe.jp
去年に引き続き、ISUCONにLINEの選抜チーム「チーム生ハム原木」で出場して優勝することが出来ました！！！！ @tagomoris、@sugyan お疲れ様でした！！ #isucon 2014で優勝しました - すぎゃーんメモ 最後の最後、残り15分でnginxの設定を行う場所を間違えていたということに気付き、ローカルのベンチマークでしか検証ができず、どの程度のスコアになるのか、またfailするのか分からない状況でしたが、結果的に良いスコアになってほっとしました。 自分でも何度も言いながら「nginxのrewriteはinternal redirect」の大原則を忘れていました。はい。1日100回唱えるようにします。 予選アプリケーションの復習 劇的なスコアは出ていませんが、地道に復習をしていて、 $ ~/benchmarker bench --workload 8 07:26:29
ISUCON4 いってきた＆勝ってきた！ #isucon - tagomorisのメモ置き場
連覇だ！ ヒャッホウ！！！ #isucon 2014で優勝しました - すぎゃーんメモ ISUCON4 で優勝してきました！！！ #isucon - blog.nomadscafe.jp 特にkazeburoさんのエントリに最終的な状況についての詳細が書いてありますので、ぜひそちらもどうぞ。sugyanは自分で力不足とか言ってますが、ISUCON本戦という場で、業務でほぼ使ったことがないはずのRedisメインのコード改造をごりごりやってちゃんと動かす人なので、チーム外のみなさんは騙されてはいけません。それできるの超すごいんやで。 主催のLINE株式会社、あれこれ提供いただいていたデータホテル改め株式会社テコラス様、問題作成担当 @mirakui, @rosylilly, @sora_h の3氏、本当にありがとうございました。たのしかった！ だいたいこんなんで 大雑把に時系列の経緯だけ書くと
PreforkサーバでOctopusを使うときのDBコネクション管理 - けんちゃんくんさんのWeb日記
unicornに代表されるprefork(する)サーバでは、DBへのコネクションのような各プロセスで共有してはいけないリソースをbefore_forkとafter_forkで適切に管理する必要がある。 ふつうのRails Applicationは以下のように、ARのコネクションをはりなおしていると思う。 before_fork do |server, worker| ActiveRecord::Base.connection.disconnect! end after_fork do |server, worker| ActiveRecord::Base.establish_connection end しかし、Octopusを使っている場合はこれだけでは不十分で、このままだと再起動直後にエラーが大量に出ることになる。今関わっているプロジェクトではNoMethodError: undefi
ISUCON4 お疲れ様でした - 鳩舎
今回の ISUCON 、みんなはどうだったかな？楽しかったかな？ベンチマーカーについての文句？いいよ、こいよ、俺がベンチマーカー実装者だ。 ということで、まずはお詫びを。今回、過去の ISUCON に比べて本当にトラブルが多くて申し訳なかったです。次の出題者になれる機会があるならば、本当にもっとしっかりしたいと強く思っています。本当に、申し訳なかった。 あとは後悔を。正直当日まで実感なかったし、朝の方も徹夜明けであんまわかってなかったんだけど、昼飯が喉を通らないところでストレス過多で死にそうになってることに気づいた。いやーだって考えてみたら今まさに僕よりすごいエンジニアが僕のベンチマーカーを叩き潰すために全神経を注いでるわけですよ。そりゃ胃痛もするわ。もう二度と出題者になんてなりたくないね。 問題についての詳しい解説や、講評なんかは後日 ISUCON 公式ブログの方に乗せてもらえると思うの
最近のHubotの運用とか - ローファイ日記
Hubot、前職から色々試して運用してきたが、1年半ぐらいいろいろいじくってるのもあってそろそろ一旦まとめてみたい感じ。 Hubotに関しては hubot/docs at master · github/hubot · GitHub あたりは一通り斜めに読んだが、「僕はこう思ったッス」ぐらいな感じでやっているコードや運用が多いので、適宜マサカリングしていただければと。 便利スクリプトのご紹介 とりあえずこんなの書いた自慢から。 リンク自動で取るやつ request = require('request') cheerio = require('cheerio') URI = require('URIjs') module.exports = (robot) -> getTitle = (msg, uri) -> request uri, (err, response, html) -> i
#isucon 4の本戦で3位を取ってきました (追記あり)
みなさんISUCON4お疲れ様でした。まずはじめに運営のLINEさん、出題のクックパッドさん、そしていつも大量のサーバを提供していただいているデータホテル改めテコラスさんありがとうございました。ピザとお寿司おいしかったです。 さて、今回はベンチマークの気持ちになってCache-Controlヘッダをつけることが出来たかどうかだけがブレイクスルーできるかどうかを左右するという潔い問題でした。結果は既に既報のとおりで上位2チームだけブレイクスルーし、3位以下はずーっとネットワーク帯域にめいっぱいデータを流し続けてドングリの背比べとなりました。 1Gbpsの帯域を使い切るレベルまでアプリを高速化できると大体スコアが8000〜9000程度となるようで、最後の1時間までほぼ8000台に団子となっていましたが、Cache-Controlでブレイクスルーした2チームを除くと私の所属するfujiwara組
三年予測 | 「三年予測」は、さまざまな分野で活躍する「トップリーダー」へのインタビューを紹介します。「トップリーダー」の考える未来や、エンジニアへのメッセージを発信します。 | dodaエンジニア IT
「三年予測」は、さまざまな分野で活躍する「トップリーダー」へのインタビューを紹介します。「トップリーダー」の考える未来や、エンジニアへのメッセージを発信します。
「文字列」について - 2014-11-07 - はてなるせだいあり
序 「文字列を文字の列とみなす単純化」について議論がありますが、前提が抜け落ちてるように思うので書くことにします。 そもそもこの話はどのような文脈の上にあるかというと、テキスト処理 (wikipedia:en:Text_processing) の文脈になります。ここでいう「テキスト処理」とは plain text (wikipedia:プレーンテキスト) の検索・加工のことで、ここでは特に UNIX Text Processing の系譜が念頭に置かれています。つまり、複雑な装飾を含むリッチテキストではなく、処理の対象を ASCII 文字列といくつかの制御文字へと抽象化することで、正規表現のような強力な道具を用いた処理を可能とした世界です。UNIX でのお話ですから、ここでの具体的な処理の単位は char であり、全体としては char[] になります。この char の中身は上で述べたと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
