近年の Node.js は API のサーバとしてはもちろん、Nuxt.js や Next.js といった SSR や BFF などフロントエンドのためのバックエンド言語としての人気が高まっています。 フロントエンドエンジニアがコンテキストスイッチ少なくバックエンドの整備ができることは非常に大きな利点です。 ですが、フロントエンド（ブラウザ側）とバックエンド（サーバ側）ではパフォーマンスチューニングで見るべき点が大きく違います。 しかし Node.js アプリケーションのパフォーマンスイシューの見つけ方などがまとまっている資料は少ないです。 そこで、本記事ではフロントエンドエンジニアが Node.js でパフォーマンスイシューを見つけ、改善するため自分が普段パフォーマンスチューニングを依頼されているときにみている基礎的なポイトをまとめていきます。 1. 計測ステップlink Node.js
(注記：6/9、いただいた翻訳フィードバックを元に記事を修正いたしました。) 今回の記事は毎秒300万ものリクエストを処理できるほど強力で高性能なWebクラスタの構築についてのパート1になります。まず初めに、あまり多くはありませんが、私がこれまで使用したことのあるロードジェネレータツールをいくつか紹介します。私のようにてこずって時間をかけてしまわないよう、今回の記事が理解の手助けになれば幸いです。 ロードジェネレータはテストを目的とした数種類のトラフィックを発生させるプログラムです。それによって高負荷においてサーバがどのように動いているか、そのサーバの弱点はどこなのか、などが見えてきます。負荷テストを通じてサーバの限界を知ることは、サーバのレジリエンシーを測定する最適な方法であり、あらゆる問題に対する準備の手助けにもなります。 ロードジェネレータツール 負荷テストをする際に頭に入れておくべ
この記事は VirtualDOM Advent Calendar 2014 - Qiita の2日目です。 mizchi くんから誘われて軽い気持ちで参加したら、初日からえらくエモいエントリー(VirtualDom - なぜ仮想DOMという概念が俺達の魂を震えさせるのか - Qiita) でブルってます。 Virutal DOMとは、と言う話はしません。初日を見てください。いろいろ良いことあるみたいだけど、Virtual DOMってどんだけ早いの？知りたいですよね。 Elmの中の人が作ったTodoMVCのパフォーマンステストがあります。 いつものTodoMVCのデモで、100要素追加して、全て完了して、削除するというテストです。 「Run All」ボタンをクリックすると動きます。 http://evancz.github.io/todomvc-perf-comparison/ Virtua
Instagram のスケール正攻法 -- Kosei Kitahara's Blog
Instagram がどこに買収されたとかは他のニュースサイトにお任せして、Django アプリケーションを正攻法でスケールして "成功" してるのがとても興味深いです。現時点で Instagram Engineering で紹介されていることと TechCrunch にも掲載されたスライドから個人的なメモとしてまとめてみました。 Instagram の哲学は シンプルであること オペレーション負荷を最小化すること すべて装備 とのこと。 Instagram は以下の OSS, サービスで構築されているようです。 >>> OS / ホスティング Ubuntu Linux 11.04 を Amazon EC2 にホスティング。以前のバージョンは高トラフィックになると固まる問題があったようです。運用は 3 人。EC2 にホスティングしている理由は、調査結果によるものではなく、"まだ進化途中だか
100 万行のテキストファイル（test-data）を C/C++ で作成したプログラムで読み込むとき，どのくらいの時間がかかるかを調べた結果です． データ入力がボトルネックになるような状況では，std::fgets(), std::fread(), std::istream::read() を使った方が良さそうです．std::istream については特に極端な差が出ていますので，速度面を重視する場合，便利なインタフェースを封印しないとダメっぽいです．実に惜しい…． 追記（2010-07-28）：id:metaboles さんより，std::ios::sync_with_stdio(false) を使えば std::cin.getline() や std::getline() も std::fgets() と同じくらい速くなるというコメントをいただきました（後述）． $ wc test-
FlashPlayer10.1、いいですね。ネットブックで試すと軽さが体感できます。H.264のデコードも効いてるカンジ。 さて、ActionScript3.0ではかなり自由にBitmapDataをいじれるようになった。 アルファチャンネル付きコピーが簡単にできるので、自前でSpriteの代替クラスつくれるよね、ってことでテスト。 なんか話題的にいまさら感があるけれど気にしない。 環境はFlashPlayer10.0.32.18、WindowsVista32Bit、CPU:Corei7 920です。 ※サンプルページはベンチマークなので重いです。リミッターはついてますが注意してください。なにかあっても免責です。 サンプルは多数のパーティクルを表示するもので、EnterFrameで1個ずつ足していくことにした。Flashの設定FPSは60。 まず、BitmapData.copyPix
MySQLのEXPLAINを徹底解説!!
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
このドメインは お名前.com から取得されました。 お名前.com は GMOインターネットグループ(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込みです。
C++初心者の私がC++をやめたくなった瞬間。 なにをいまさらな。 はじめに C++のstreamはとても良くできていて、これを用いたライブラリを作りたいのだけど、 本当に(主にパフォーマンス的な理由で)大丈夫なのとかそういう話。 初めにお断りしておきますが、以下の内容はすべてlinux+gcc4.3での話です。 streamは遅い ふつうにistreamからget()して、ostreamにputしてるとめちゃくちゃ遅い。 C言語のgetchar, putcharより10進数で1.5桁ぐらい遅いよ。 istream::readとかででかいブロック読めば大丈夫なのだけど、 細かい単位で読みたいことの方が多いよね。 そういうわけで、そういう場合にも速く転送することが可能なのかどうか調べてみる。 テストプログラム istreamの内容をostreamに転送するプログラムを6通り書いた。 その１：
Twitterのスケール関係で、面白い記事を発見したのでまとめ。 一時期「スケールしない」とか「動作が不安定」だとか言われ続けていたTwitter。5月ごろにslashdot.jpでも話題になっていた。論調は総じて「Twitterがスケールしないのは、Rubyを使っているから」というもの。 ところが同じ５月、「Why Can't Twitter Scale? Blaine Cook Tries To Explain（なんでTwitterってスケールしないの？）」という、blog紹介記事がSilicon Alley Insiderに掲載される。記事の元になったblogエントリは、Twitterの前チーフアーキテクトだったBlaine Cook氏によるもの。Cook氏によれば、TwitterのスケールとRubyは何の関係もないという。 Why Can't Twitter Scale? Blai
KOF2008：関西オープンソース2008というイベントに来ています。 はてなの伊藤さんの講演があったので、講演メモを公開。 ＃ボクがメモした内容であって、100%言ったとおりに書いてあるわけじゃないので、参考としてご覧ください。 (続き) アジェンダ 大規模なデータ OSのキャッシュ MySQLの運用 大規模データアプリケーションの開発 データの例 はてなブックマークのデータ量：五千万件くらいのデータ量 このデータに対して何百万人がアクセスしてくる状況でどういう作りにするか レコード数 1073万エントリー 3134万エントリー 4143万タグ データサイズ エントリー2.5GB 何の工夫もなく普通にアクセスすると...200秒待っても結果が帰ってこない 大規模データの難しいところ 開発サーバで開発者が作っている時は快適に動いていても、多数の人間がアク
こんにちは。 今回はFPSで主流の(主流だった?)ネットコード(client side predictionとrewind and replay)を実装してみました。Processingシリーズ第2弾です。 本題の前に応答性と一貫性に言及しておきたいと思います。ふつうネットワークアプリケーションは遅延があることで、先のふたつのバランスをとるという問題に直面します。 AさんとBさんが遅延のあるネットワークを介して撃ち合うFPSを例にとります。 応答性は、キーを押せばキャラクターがすぐに移動を始めるとか、トリガーを引くと弾が発射され命中したかすぐに判明するとか、そうしたキー入力から画面表示までの経過時間と考えてください。 一貫性とはAさんとBさんが常に同じ状態を見ているということです。遅延がとても小さければ、これは簡単に実現できます。では遅延が大きい環境で、Aさん がBさんを撃ち、Bさんはそれ
前回書いた「Javascriptによる大規模開発の覚え書き」が凄いことになってました。 今回は、省略した「5.高速化せよ」について書きます。 僕にとってjavascriptは非常に高速な言語です。それは何が高速か 開発速度が高速である 開発速度、及びそこに至るまでの修得速度はとても高速です。動的言語を上手く操る開発者はもちろん、開発に不慣れな(言葉が悪いけど)新人達でさえ「動く」モノをサクっと作ってしまえる。 また、プラットフォーム(? というかブラウザ)が広く普及しているので、ググればスグに問題解決もできる。 それにローカルで簡単に作れる。javascript、それは動作環境を含めて高速です。 高速にUI操作ができる(UI操作が非常に簡単である) swingとかでUI操作をするには多くのオブジェクト操作をしなければならないけど、javascript(もといDHTML)は非常に簡単に
Googleではその超巨大なコンピュータネットワークを使って、データ処理が分散化されている。これにより、大量のデータを瞬時に処理することが可能になっている。この分散処理システムはMapReduceと呼ばれており、Googleの基盤を支えるコア技術の一つだ。 処理状態を確認するコンソール ごく小規模なシステムであればニーズは発生しないかも知れないが、数十台、数百台のコンピュータを結びつける上で分散化処理は欠かせない技術だ。そこでMapReduceをオープンソース実装したこちらを紹介しよう。 今回紹介するオープンソース・ソフトウェアはSkynet、Rubyで実装されたMapReduceのオープンソース実装だ。 Skynetは多数のワーカーを立ち上げ、それらが互いに監視し合うことで障害発生時にも柔軟にタスクの受け渡しが可能になっている。単一障害点はなく、マスタサーバという位置づけのものですら他の
ダイクストラ法 (Dijkstra's Algorithm) は最短経路問題を効率的に解くグラフ理論におけるアルゴリズムです。 スタートノードからゴールノードまでの最短距離とその経路を求めることができます。 アルゴリズム 以下のグラフを例にダイクストラのアルゴリズムを解説します。 円がノード，線がエッジで，sがスタートノード，gがゴールノードを表しています。 エッジの近くに書かれている数字はそのエッジを通るのに必要なコスト（たいてい距離または時間）です。 ここではエッジに向きが存在しない（＝どちらからでも通れる）無向グラフだとして扱っていますが， ダイクストラ法の場合はそれほど無向グラフと有向グラフを区別して考える必要はありません。 ダイクストラ法はDP（動的計画法）的なアルゴリズムです。 つまり，「手近で明らかなことから順次確定していき，その確定した情報をもとにさらに遠くまで確定していく
松岡研究室は並列分散コンピューティング、特に高性能計算(HPC)に関するソフトウェア基盤技術の研究を行なっています。HPCとはコンピュータシミュレーションなどのより大規模な問題をより高速に計算するための技術です。昨今の科学技術の発展にはHPCにより支えられた非常に高度なコンピュータシミュレーションの重要性がますます高まってきており、松岡研究室では様々な応用分野の方々とも協力しつつより先進的なHPC基盤技術の研究開発に取り組んでおります。 また、近年では機械学習や深層学習（Deep Learning）技術の総称である人工知能（AI）技術が急激な勢いで実用化されつつありますが、この技術の発展には膨大なデータを極めて高速に処理する基盤技術が必要不可欠です。松岡研究室では、特に近年発展しているこのAI技術とHPC技術の融合を一つのテーマとして掲げており、各種アクセラレータ・スーパーコンピュータを用
_ [システム運用][Perl] Apache Combined Log を効率的にパースする正規表現メモ ググるとよく見つかるのははてな - Apache形式のログを解析する正規表現を教えてください (Geekなぺーじ : アクセスログの読み方（apache combined logの場合）) の ($host, $ident, $user, $time, $request, $status, $bytes, $referer, $agent) = ($line =~ /^(.*) (.*) (.*) \[(.*)\] "(.*)" (.*) (.*) "(.*)" "(.*)"/); だが、最長一致の .* が多数登場するためか、マッチ処理がとても遅い。たった10万行パースするのに Core2 使って23.7秒ってあり得なくね? できるだけ最短一致でマッチさせるように ($host,
](https://cdn-ak-scissors.b.st-hatena.com/image/square/6f0a2cd63d112c714b75b4d89011fa25328b373d/backend=imagemagick;height=288;version=1;width=512/https%3A%2F%2Fproxy.goincop1.workers.dev%3A443%2Fhttps%2Fpmakino.jp%2Ftdiary%2Ftheme%2Fogimage.png)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
