タグ

ブックマーク / lestrrat.ldblog.jp (6)

  • ISUCON5初参加して散ってきた : D-7 <altijd in beweging>

    初めてISUCONに参加してきた。ちなみに初めて櫛井さんが主催するイベントに参加してみた。 チームメイト達は何回も素振りという名の練習をしていたのだけど、こちらは家族サービスで鴨川シーワールドに行ってたりして一回練習しただけ。GCPは普段から慣れ親しんでるのでその辺りもあって余裕ぶちかましてましたね! 当日は朝からdotsに陣取り、自分は黙々とコード書いてた。最後に会心の一撃で1400点台から6000点にあげた以外は特にすごい事はできなかったなぁ。トップページが重いのはわかってたけど「その前にやることあるだろ」精神で他のところチューニングし始めたの、時間配分的には間違ってたね。 実装はPerlでデータセットを先にmmapファイルに展開する方式でがんばってやってみました。最終的に会心の一撃はSQLをチューンするより「リクエストごとにKVS的にデータをがっともってきてオンメモリ展開した上でSQ

    ISUCON5初参加して散ってきた : D-7 <altijd in beweging>
    YAA
    YAA 2015/09/28
  • 急成長中の会社をサクッと辞めた事に関して色々言われるので書くつもりがなかった退職エントリを書く : D-7 <altijd in beweging>

    タイトルの通りなんですが、某急成長中/快進撃中のあの企業を11月末ですごくサクッとやめて、イベント運営サポート・チケット販売システムをやっているスタートアップであるPeatixにジョインしました。とりあえずインフラ周りをがっつり整備する方向。 この話をするとわりと真顔で「え、なんで?あの会社を辞めるなんてなんか事件でもあったの?!」って感じの反応をされるんだけど、そういうことではないのでそこだけ説明のため好きでもない退職転職エントリを書いている次第です。 まず、なにか事件があったわけではない。べつになーんもなかった。子供のお迎えとかをしてても基文句も言われなかったとか、色々融通を効かせてくれてたのは明らかだし、そのまま居れば皆も知ってる勢いのある企業でボチボチ高給取りでいられたかなーとは思う。 だから退職せずにもっと良い方法を模索すればよかったのかなぁとは思わないではないけど、やっぱり

    急成長中の会社をサクッと辞めた事に関して色々言われるので書くつもりがなかった退職エントリを書く : D-7 <altijd in beweging>
    YAA
    YAA 2015/01/05
  • dockerデビューしてみた : D-7 <altijd in beweging>

    docker、触ってたけどちゃんとデプロイとかしたことなかったのでこのひと月しこしこ作業しては失敗し直しては失敗しを繰り返してて、この週末やっとデプロイした。yapcasia.orgのことなんですけどね。 以下ベストプラクティスかどうかは知らないけど、とりあえず俺が通った道筋: 最初コンテナ同士のつながりをどう定義するといいのか全然わからなくて困っていた。例えばサイトの基はMovableTypeで構築しているんだけど、その人は当然mysqlと話すから、MT→mysqlの接続を定義するのにどういうふうに名前やポート番号を解決するの?とかnginxからMTへの接続の解決は…?とか dockerコンテナの内容はimmutableであっても、コンテナのインスタンス自体は揮発性が高いものであるから、できればシンボリックな形でそれぞれのコンテナやデーモン等の接続情報を提供して動的に解決したいわけだが

    dockerデビューしてみた : D-7 <altijd in beweging>
    YAA
    YAA 2014/10/14
  • 私家版のgoでホットデプロイの仕組み、もしくは椅子もマサカリも投げられたくないときの気遣い : D-7 <altijd in beweging>

    なんかごく一部に補足されているので、念のため軽く説明しておきます。 masahiro nagano@kazeburo某所のlestrratさんのgolangなアプリはhot-deployが可能になってる。サーバはserver_starter経由で起動されていて、バイナリ消してHUPを送ると自動でビルドしなおしてプロセスを入れ替えてくれる。便利 2014/04/30 12:18:31 これ、ベストな方法だとは思っていないんだけど、最初にこれを書いた当時の考え方は以下の通り: これは自分の部署で初めて 番に設置するgoアプリである一次対応をする人は自分とは限らない細かいコード内容の修正はともかく、明らかなバグっぽいものの修正(例:SQL文の変更)などを自分以外の人間が施した後にサーバーを簡単に再コンパイル+再起動するする方法がないと椅子が降ってくる事が容易に予想される Apache::Log

    私家版のgoでホットデプロイの仕組み、もしくは椅子もマサカリも投げられたくないときの気遣い : D-7 <altijd in beweging>
    YAA
    YAA 2014/05/02
  • Rebuild.fm ep42の補足等 : D-7 <altijd in beweging>

    tl;dr: 別にPerl捨ててないです。Perl大好き。俺はLLはPerlでいい。でも別ドメインの事もやってもいいよね! Rebuild.fmに限らず、公の場でYAPC/Perl以外の話をする事があるとは正直思っていなかったが、このたびRebuild.fm ep 42に置いて1時間Goについてしゃべりまくってきた。1時間ぶっつけ番でしゃべりたい事はだいたいしゃべってきたのだけど、その後のフィードバック等もふまえてまとめておきたいと思ったのでこのエントリでまとめてみます Go事始め そもそもなんでここまでGoをガリガリ書き出したのか。 正直親父ギャグとvimで有名なあの人が「Goいいよ!」と言い出したときにはGoに対してはうさんくさい印象しかなくて特に注意すらしてなかったんだけど、そろそろ違う言語とドメインに向いてみるかーと思って探していた時に「あ、俺もうLL系の言語別にいらないな」とふ

    Rebuild.fm ep42の補足等 : D-7 <altijd in beweging>
    YAA
    YAA 2014/05/01
  • Plack Performance Tips - mount() and query_parameters() : D-7 <altijd in beweging>

    すごいヘビーな負荷を受けているPSGIアプリケーションで「なんでこれで負荷があがるの?」的な現象があったので二つほどTipを。ちなみにこれは 2013/03/06時点での話なので、もしこれをあなたが大分将来に読んでいるのなら、状況に変更がないかちゃんと確認すること! まずこのお話の前提:mod_perlなアプリをPSGIに移行したかった。アプリはmod_perlハンドラで書かれているので、Apache::RequestをPlack::Requestに書き換えたり、ハンドラ部分をオブジェクトにしてキレイにするくらいで、基的な構造は何も変えてない(←ここポイント)。あとはApache側とか設定をもりもりいじって、PSGIファイルを書いて、Starletでデプロイして、パフォーマンスが30%くらい悪くなった。さて、犯人は誰でしょう? まずアプリケーションを組む側が「やっちまったなぁ?」な件:P

    Plack Performance Tips - mount() and query_parameters() : D-7 <altijd in beweging>
    YAA
    YAA 2013/03/08
  • 1