タグ

ブックマーク / tagomoris.hatenablog.com (18)

  • Webアプリケーションのベンチマークをとるときに気をつけている10のこと - たごもりすメモ

    10もないかも、と思いながら項目を書き出してみたら10以上余裕であってキリがないので10で収めた。いやあ、あるなあ。 仕事柄よくベンチマークを実行したりしてて色々と思うところが溜まっていたところ、以下のような記事を見掛けたのでなんか書こうと思った。ところでこの記事はベンチマークを実行するための準備作業がループを回して2時間かかるところの待ち時間に書かれている。 sfujiwara.hatenablog.com ISUCONといえば多少縁があるコンテストで、文中でISUCON5のことについても言及されているので、それも含めて。 自分が業務でいじっているのは "Webアプリケーション" というとちょっと違うんじゃないのというものばかりだが、いやー、最近なんでもHTTPで外部APIを作るからベンチマークのコツとしては大体変わんなかったりするよね。 なおこの記事でベンチマークはどのようなものかとか

    Webアプリケーションのベンチマークをとるときに気をつけている10のこと - たごもりすメモ
    hide_o_55
    hide_o_55 2018/10/27
  • GrowthForecastに --kibanize オプションつけた - たごもりすメモ

    要するにおまえらは黒っぽいグラフならいいんだろ? ということで、そのような欲望を現実のものにするためのパッチを書いてpullreqを出しました。 https://github.com/kazeburo/GrowthForecast/pull/63 このグレートなパッチにより --kibanize オプションをつけて起動したGrowthForecastの画面がこのようになります。 色指定などは全面的にこちらから頂きました。グレートなエントリです。 rrdtoolは癒し - 桝原翔市的博客 ※ なお全体的にやっつけのため、Twitter BootstrapがゴニョゴニョやっていてCSSで簡単に色指定を上書きできない場所などが白いまま残ってたりします。みんなで頑張って更に格好よくしよう!

    GrowthForecastに --kibanize オプションつけた - たごもりすメモ
  • use latest cpanm -Lextlib with perl v5.8.8 or earlier - たごもりすメモ

    'cpanm -Lextlib' requires Module::CoreList, but Module::CoreList was first released with perl v5.8.9. So we should install Module::CoreList at first. Do as below (be careful with -l and -I (el and ai)): curl -s -L http://cpanmin.us/ | /usr/bin/perl -- - -l/tmp/module-corelist Module::CoreList curl -s -L http://cpanmin.us/ | /usr/bin/perl -I/tmp/module-corelist/lib/perl5 -- - -Lextlib Module::CoreL

    use latest cpanm -Lextlib with perl v5.8.8 or earlier - たごもりすメモ
  • 本番環境でのperl/ruby/nodeのセットアップ - たごもりすメモ

    番環境にperlとかrubyとかnodeを入れるんだけど、もちろん system perl じゃやってられないので指定したバージョンのものを一般ユーザの管理下に突っ込みたい。 で、そういうのをこれまで perlbrew とか rvm とか rbenv とか nvm とか nodebrew とかでやってたんだけど、さすがに色々疑問が湧いてきた。バッチで単発実行するために eval "$(rbenv init -)" とかさすがにおかしくね? みたいな。 ということで tokuhirom method 的にインストール用の簡単コマンドを使って実行、あとはパスを通せばいいじゃん、ということにしようかと思う。 参考: サーバーのセットアップは perlbrew とかじゃなくてよくね? という時のライフハック - blog.64p.org これ、今朝までは Perl::Build をどうにかしてC

    本番環境でのperl/ruby/nodeのセットアップ - たごもりすメモ
  • Perlでコマンドラインオプションの解析に Getopt::Long を使う時、絶対に忘れてはいけない引数 - たごもりすメモ

    Perlでコマンドラインオプションをparseしようと思うと組込みモジュールとしては Getopt::Std と Getopt::Long がある。が、long style option *1 つまり --option-name のようなオプションを解釈してくれるのは Getopt::Long だけだ。なので普通はこちらを使おう。 ただし 絶対にデフォルト、つまり以下のようにして使ってはいけない。 use Getopt::Long; my (@primary, @secondary, $silent); GetOptions( "server-primary|p=s" => \@primary, "server-secondary|s=s" => \@secondary, "silent|S" => \$silent ); これダメ! 絶対ダメ! 死ぬ! 最初に結論を書く 必ず以下のように

    Perlでコマンドラインオプションの解析に Getopt::Long を使う時、絶対に忘れてはいけない引数 - たごもりすメモ
  • PerlでSTDIN/STDOUTを任意のファイルハンドルに置き換える - たごもりすメモ

    いま書いてるコードで、forkしてexecするんだけど、execする前にSTDIN/STDOUTを任意のファイルハンドルに置き換えたいなー、もっというとexecするプログラムのSTDINにソケットのREADから流れてくるデータを流し込んで、STDOUTの出力をソケットのWRITEに流し込んでやりたいなー、というようなことを考えていた。 で、これが例えば今のプロセスのSTDOUTの出力をファイルに置き換えるには、以下のようにすればいい。 open(STDOUT, '>', '/path/to/file'); シェルスクリプトでも簡単。*1 exec >> /path/to/file さて、STDIN/STDOUTとconnect済みのソケットを結合したい。connect済みのソケットはファイルディスクリプタは持っているがファイルパスを持っていない、ので、普通にopenし直すだけではうまくいか

  • #fluentd 用ログ収集専用のエージェント fluent-agent-lite 書いた - たごもりすメモ

    みんな大好きfluentdはたいへん便利ですが、ログの収集&集約だけをしたい、というときにちょっとオーバースペック気味のところがあります。特に in_tail はログの読み込みと同時に parse をする仕組みになっており、まあログが書かれた場所ならparseのルールもわかってるでしょ、というところは合理的なものでもあるのですが、loadavgが高いサーバでそういうことをするのは正直にいってなかなか厳しいです。 そういうわけで以前に scribeline というエージェントツールを作ったのでこれを fluentd 以降後も使い続けていたのですが、ログをいったん集約するところの fluentd がCPU使用率的にいっぱいいっぱいになって厳しいものがありました。「scribe(Thrift)じゃなくてMessagePackにすれば倍くらいさばけるよ」ということを某開発者が言っていたような気もす

    #fluentd 用ログ収集専用のエージェント fluent-agent-lite 書いた - たごもりすメモ
  • #fluentd のためのプラグインをイチから書く手順(bundler版) - tagomorisのメモ置き場

    前に自分で書いた fluentdのためのプラグインをイチから書く手順 - tagomorisのメモ置き場 はたいへん重宝していたのだが、書いたすこし後になって実は現在すでに bundle gem コマンドを使うやりかたが良さそうだということがわかってしまったがばたばたしてて移行してなかった。 で、またひとつプラグインを書くことにしたのでついでに bundle を使った手順をざっくりまとめておく。以下のエントリをたいへん参考にさせてもらった。 T-POINTを取得するスクリプトをGistから移動, Bundlerを使ったGem作成メモ (自分用) - ただのにっき(2012-02-18) 準備とディレクトリツリーの作成 bundler は必要なので、なにはなくとも入れておこう。 gem install bundler そしてプラグイン用ディレクトリツリーを作成する。今回は DataCount

    #fluentd のためのプラグインをイチから書く手順(bundler版) - tagomorisのメモ置き場
  • #fluentd meetup in Japan に行ってきた&しゃべってきた - たごもりすメモ

    Fluentd meetup in Japanなるイベントをやるけどしゃべらない? というお誘いがあったのでありがたくお受けして参加し、1セッションしゃべってきた。 まだ世に出て半年足らずのミドルウェアのイベントなのに集いも集ったり120人*1、まるまる半日間ひたすら高濃度な時間だった。話してみると、みんなfluentdがフォーカスしてるあたりにやっぱり問題意識をもっていて、ああやっぱりこれは出るべくして出たのだな、という印象だった。 あとからtogetterのまとめページも見たけど異様に長い。どんだけ盛況だったかがわかる。開催時間中、Twitterの日のトレンドに #fluentd が出てたしな。 会場がほんとにすばらしく、運営もUstreamや無線LAN解放、電源の確保から飲み物提供まで極めて良い状態だった。主催や運営協力の方々およびフューチャーアーキテクト様、ほんとうにありがとうご

    #fluentd meetup in Japan に行ってきた&しゃべってきた - たごもりすメモ
  • UserAgent判定器 Project Woothee はじめました - たごもりすメモ

    UserAgent判定ライブラリはCPANに数多くあるし他の言語でも似たようなものだと思うが、ライブラリや言語をまたがって一致した結果を返してくれるようなものは存在しない(と思う)。が、特にHadoopを使うようになってJavaの事情をある程度無視できなくなってくると、これがたいへん問題に思えてきた。Javaで書かれたUserAgent判定ロジックが欲しいが、普段書くコードはJavaではない*1ので、他の言語でも全く同じように判定してくれるライブラリが欲しい。結果がい違っていたり、新しいUserAgentを判定したいときに片方だけ対応されて片方は置き去りになったりすると大変困る。 ということで、作った。v0.1.0。現状ではJavaPerlの実装がある*2。 https://github.com/tagomoris/woothee https://github.com/tagomori

    UserAgent判定器 Project Woothee はじめました - たごもりすメモ
    hide_o_55
    hide_o_55 2012/01/23
  • Hive Client Webアプリケーション shib をつくった - たごもりすメモ

    (2013/04/02追記 see: http://d.hatena.ne.jp/tagomoris/20130402/1364898063 ) まだ完成度がいまいちだからなーと思ってエントリ書いてなかったんだけどLTでしゃべっちゃったので、ちゃんと書いておく。 Hiveにクエリを発行して結果を確認するためのWebアプリケーションを社内用途で作ってるんだけど、普通に他でも使えると思うので公開してあります。 tagomoris/shib · GitHub シブ と読みます。 セットアップ方法はドキュメントを参照のこと。起動してブラウザでアクセスするとこんな画面が出てくる。 使いかたは見ればわかる、と思う。たぶん。クエリは参照専用(SELECTのみ)。 __KEY__ とか __KEY1__ とかがプレースホルダですよってくらいかな。エディタ内でプレースホルダを書くとプレースホルダを置換する値

    Hive Client Webアプリケーション shib をつくった - たごもりすメモ
  • #isucon を支えた技術: ベンチマークmaster/agentの構造とnode.jsの話 - たごもりすメモ

    支えた技術ってほど大層なものでもないんだけど、なんとなくカッコいいのでシリーズ名にしてみようと思った。 で、表題の件。 #isucon のベンチマークツールは1台のmasterと複数台のagentという構造になっていて、agentはベンチマークツールの負荷を複数台のサーバに分散させるために存在する。各agentは交換可能で、仮にagent用サーバが1台壊れたら、別のagentに負荷を振り向けるよう設定を書き換えるだけでいい。役割としてはだいたいこんな感じ。 master 各チームのスコア表示、およびベンチマークの起動・停止操作の提供、agentへのベンチマーク実行状況の問合せ、agentへのベンチマーク起動・停止指示、ベンチマーク実行結果の受け取りと保存 agent ベンチマーク処理の起動・停止、ベンチマーク実行状況の提供 (すべてJSON RPC) masterとagentは両方とも n

    #isucon を支えた技術: ベンチマークmaster/agentの構造とnode.jsの話 - たごもりすメモ
    hide_o_55
    hide_o_55 2011/09/06
    Node.js+JSON RPCはホント簡単にかける
  • Node.jsなWebアプリでJobQueueなしにラクラク巨大処理を実行 - たごもりすメモ

    Node.jsでWebアプリを書いてるんだけど別に大量のリクエストをさばくわけでもないしWebSocketも使ってないし、じゃあなんでそんなことしてんの、という話。 まず結論だけ書くと、 並列度が低くてよいが長時間かかることが確定的な処理を非同期的に走らせる必要がある場合、普通はそのような用途でもJobQueue/Workerを使って構成するがそういうのは管理も面倒だしインストールも面倒くさくなるのであんまりやりたくない。Node.jsなら普通のWebアプリケーションフレームワークだけでラクに書けていいんじゃね? というひとつの提案です。 同期実行のケース 普通Webアプリケーションフレームワークというのは、一連の処理はクライアントにレスポンスを返すことで完了する。そしてひとつのプロセス/スレッドはリクエストをディスパッチされてからレスポンスを返すまでがそのリクエストに占有される。 ここで

    Node.jsなWebアプリでJobQueueなしにラクラク巨大処理を実行 - たごもりすメモ
  • OpenLDAPサーバ(slapd)のperl backendを使う - たごもりすメモ

    長いよ! 社内Webアプリケーションの認証基盤としてあちこちでデファクトになっているのではないかと思われるLDAPだが、その管理は主に人事部がやっていたりして*1中身に迂闊に手を出せず歯がゆい思いをしているエンジニアに捧げるエントリ。俺得。 社内サービスのために認証をやりたいがパスワードの管理は別途LDAPがあるのでそっちに任せたい。しかしLDAPのディレクトリ構造のままだと権限情報がうまい具合に切り分けられず、ああああパスワードは持ちたくねえが権限情報は管理したり変更したり増やしたり減らしたりしたいよおおおおおお、という思いを抱いている人は多いと思う。 そこである日にOpenLDAPのオンラインドキュメントの目次を上から下までだらだらと眺めていると、なんと Perl Backend というものがあるらしい。サーバに来た問合せを任意のPerl moduleに移譲できるという。なんだって。す

    OpenLDAPサーバ(slapd)のperl backendを使う - たごもりすメモ
  • "Hbase at Facebook" に行ってきた - たごもりすメモ

    名称表記が揺れてて微妙だけど Hbase at FaceBook on Zusaar このイベントに行ってきた。Facebookの人は "HBase Tokyo meetup" と認識していたようだ。 内容のまとめはやらないので、以下の各ページなどをご覧になると良いのではないでしょうか。 Tokyo HBase Meetup - Realtime Big Data at Facebook with Hadoop and HB… Hbase at FaceBookのまとめ - Togetterまとめ FacebookがHBaseを大規模リアルタイム処理に利用している理由(前編) - Publickey FacebookがHBaseを大規模リアルタイム処理に利用している理由(後編) - Publickey セッションの内容と自分が考えたことと人としゃべったことをいっしょくたにここに書いておく。

    "Hbase at Facebook" に行ってきた - たごもりすメモ
  • いっしょに仕事をしたいプログラマ 5つの特徴 - たごもりすメモ

    ちょっとこんなことを考えるきっかけがあったので、ざっと書き出してみた。Webに公開されている情報からあるプログラマについて見てみたとき、どういう人ならいっしょに働いてもいいかについて。 ここに書く内容はソースコードの品質以前の問題についてのみにしてある。だからこの特徴を満たしていればどうということに直接なるわけではない。ただ、欠けているところがあれば、少なくとも自分はその人といっしょに仕事をしたいとは思わないだろう。 なお自分は現勤務先の採用活動にはかかわっておらず、このエントリの内容は勤務先の採用基準とは全く無関係です。 学生さんなどの場合にはまた話が違うと思います。 あと割と自分のことは棚に上げてます。「お前これできてねえじゃん」という部分については都度ご指摘をいただけますと大変ありがたく思います……。 1. その人が書いたソースコードが公開されている 日語で何を言われてもぶっちゃけ

    いっしょに仕事をしたいプログラマ 5つの特徴 - たごもりすメモ
    hide_o_55
    hide_o_55 2011/06/08
  • xargs を使ってカジュアルに並列処理 - たごもりすメモ

    シェルからでも重い処理というのはちょこちょこあって、例えば超デカいログファイルを移動して圧縮したりというお仕事は世界中のあらゆる場所で毎日行われていたりする。コマンドラインからでも大量の圧縮済みログファイルをいっぺんに展開したい、とか。 あるディレクトリ以下に存在するたくさんのファイルを(圧縮済みのものを除いて)全部 bzip2 圧縮したい!と思ったら、とりあえずさくっと次のようにコマンドラインで叩けばいい。 $ find . -not -name '*.bz2' | xargs bzip2 これで、まあそんなに問題なく効率的にbzip2圧縮ができる。だがしかし。 最近は複数コアのCPUが普通に転がってるし、あまつさえHyperThreadingが有効になってたりしてOSから見える論理CPU数がハンパない。普通に8とかある。その一方で複数コアを使用してくれるコマンドというのはあんまりなくて

    xargs を使ってカジュアルに並列処理 - たごもりすメモ
  • node.jsの非同期I/Oにおけるデータ受信のパターンのバリエーション - たごもりすメモ

    そもそもなんでnode.jsのThriftライブラリではBufferedTransportがサポートされず、FramedTransportのみが使える状態だったのか。Thriftの歴史的にはBufferedTransportの方が先行して存在しており、また仕様自体も単純のようだ。*1 実装を開始してみてわかったが、node.jsが採用する非同期I/OアーキテクチャのAPIと実に相性が悪い。Thriftが定義ファイルから各言語用のコードを自動生成する仕組みであることも関係している気がする。いざnode.jsの都合に合わないからといって、カジュアルに生成結果のコードを修正するわけにはいかない。また受信データ(を持っているはずのI/Oストリーム)からデータを読み出すところまでがThriftによる自動生成の範囲に含まれる。 (Twitterで言及を読んで追記) 普通にアプリケーション側のコードをコ

    node.jsの非同期I/Oにおけるデータ受信のパターンのバリエーション - たごもりすメモ
  • 1