node.js のメトリクスの計測、ベンチマークの改善、Docker イメージの絞り方を勉強した
フロントエンドのパフォーマンス計測は得意なのだが、サーバーサイド node.js のメトリクスの取り方はあまり知らなくて、いつも勘でやりがちだった。最近は業務でこの周辺で困ることが増えたので、勉強しなおした。 また、最近使ってみたかった cloudflare workers の制限で、メモリ 128MB、CPU 時間 50ms という制約があり、このためにも Node.js の CPU のメトリクスを計測できるようになっておく必要があった。 という目的を踏まえて、今回は OS やデータベースの最適化は扱わず、ネットワークとアプリケーション層だけに絞って学習した。あと仕事の Docker イメージのサイズにも悩んでたので、ここも。 (あと ISUCON 参加者が楽しそうだったのもある。 ISUCON のチューニング対象にフロントエンドは含まれないので…) 計測対象 今回実験したリポジトリはこ
Node.jsなWebアプリでJobQueueなしにラクラク巨大処理を実行 - たごもりすメモ
Node.jsでWebアプリを書いてるんだけど別に大量のリクエストをさばくわけでもないしWebSocketも使ってないし、じゃあなんでそんなことしてんの、という話。 まず結論だけ書くと、 並列度が低くてよいが長時間かかることが確定的な処理を非同期的に走らせる必要がある場合、普通はそのような用途でもJobQueue/Workerを使って構成するがそういうのは管理も面倒だしインストールも面倒くさくなるのであんまりやりたくない。Node.jsなら普通のWebアプリケーションフレームワークだけでラクに書けていいんじゃね？ というひとつの提案です。 同期実行のケース 普通Webアプリケーションフレームワークというのは、一連の処理はクライアントにレスポンスを返すことで完了する。そしてひとつのプロセス/スレッドはリクエストをディスパッチされてからレスポンスを返すまでがそのリクエストに占有される。 ここで
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
