Node.js Performance 改善ガイド - from scratch
Node.js Performance 改善ガイド Memory の場合 メモリリークかどうかを特定する メモリリークではない場合 CPU の場合 どこの処理に時間がかかっているのかを確認する v8 simple profiler flame graph を取得する File の場合 大きなサイズのファイルをどうしても扱う時 Network の場合 keepalive を on にする その他: 全体的にパフォーマンスを改善するためにやること JIT が効いているかを確認する clusterが使えないか検討する C++ addons vs JavaScript libraries まとめ 参考資料 Node.js Performance 改善ガイド この記事は Node.js 2 Advent Calender の 5日目の記事です。 qiita.com Node.js のパフォーマンスに
Node.jsの「構築事例」、そして「向いていること」と「向いてないこと」 - Qiita
Node.jsはシングルスレッド、ノンブロッキングI/O、イベントループなどの特徴があり、「向いていること」と「向いていないこと」があると思います。 言語選定の際に使えるメモとして、Node.jsの構築事例も加えてまとめてみました。 Node.jsに「向いていること」 処理が短時間でイベント処理が重要なアプリ 例えば、チャットアプリなどの大量のアクセスのあるリアルタイムなネットワークプログラミングが得意 シングルCPUのサーバー シングルCPUの環境化でもその性能を十分使い切れるため、比較的性能の小さいサーバ上で大きなパフォーマンスを発揮できる Node.jsに「向いていないこと」 CPU負荷の高い処理 CPUリソースを大量に必要とするJavaScriptの処理を行うとイベントループが回らない状態になり、イベントハンドリングが行えない状態に陥る。このため、CPU処理が大量に必要とされるアプ
uu59のメモ | Node.jsの癌騒動まとめ
承前 まずNode.js is CancerでTedさんは以下の3点を問題視しました。 ブロックしないから速いとかプログラマは未熟でもいけるとかスケーラビリティとか全部大嘘だろう システム管理者にやさしくないアーキテクチャ JavaScript製 あまりに感情的で論点が曖昧なこの記事に、多くの人がtrollingだと指摘しつつも色々と論を展開しました。 2日後に出たTed本人によるフォロー記事では主に1点目について掘り下げています。 まず数学を使ってイベントモデルとスレッドモデルのそれぞれのスループットについて考察していきます。数式や変数展開の説明をしていくと長いので要点だけまとめると以下のようになります。 スレッドの実行数を増やせばCPU-boundなときはもちろんI/O-boundなときでもスループットを伸ばせる 理論的にはイベントモデルでもスレッドモデルでもスループットの最大値（＝限
uu59のメモ | 訳：Node.jsは癌だ
http://d.hatena.ne.jp/yosuke_furukawa/20111002/1317572377で知って、原文を読んでみたら罵倒しまくってて面白かったので全文翻訳してみました。 原文はNode.js is Cancerです。 ウェブデベロッパー逹は伝統的なやり方よりも冴えたやり方が大好きだが、伝統的なやり方がなぜ伝統になってるかというと動きやがるからだ。Node.jsのナンセンスな振る舞いにはしばらくムカついてたが、Node.js作者のRyan Dahlによるこのポストを読むまでは相手しないようにしてた。「UNIX難しいよぅ」とか弱音を吐くよく居るタイプのマヌケに肩をすくめていただけだ。 でも、家族連れのミニバンをガサ入れしたら50kgの上物ヘロインを見つけてしまった警官が世の中間違ってると感じるように、こいつの弱々しいすすり泣きの何が間違ってるのか考えた。たぶん、たぶん
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
