近年の Node.js は API のサーバとしてはもちろん、Nuxt.js や Next.js といった SSR や BFF などフロントエンドのためのバックエンド言語としての人気が高まっています。 フロントエンドエンジニアがコンテキストスイッチ少なくバックエンドの整備ができることは非常に大きな利点です。 ですが、フロントエンド（ブラウザ側）とバックエンド（サーバ側）ではパフォーマンスチューニングで見るべき点が大きく違います。 しかし Node.js アプリケーションのパフォーマンスイシューの見つけ方などがまとまっている資料は少ないです。 そこで、本記事ではフロントエンドエンジニアが Node.js でパフォーマンスイシューを見つけ、改善するため自分が普段パフォーマンスチューニングを依頼されているときにみている基礎的なポイトをまとめていきます。 1. 計測ステップlink Node.js
前書き - インデックスの作成はなぜ開発者のタスクなのか インデックスの 内部構造 - インデックスは何に似ているか インデックス リーフノード - 二重連結リスト 検索 ツリー(Bツリー) - バランス木 遅いインデックス パートI - インデックスを遅くする2つの原因 where 句 - 検索のパフォーマンスを改善するためにインデックスを作成 等価 演算子 - 一致するキーの検索 プライマリキー - インデックスの使い方を確認 複合インデックス - 複数列に対するインデックス 遅いインデックス パートII - 前の問題点が再び 関数 - where句の 中での関数 大文字・小文字を区別する 検索 - UPPERと LOWER ユーザ定義 関数 - 関数インデックスの制限 インデックスの作り過ぎ - 冗長性の排除法 パラメータ化 クエリ - セキュリティとパフォーマンスのために 範囲 検
Linux女子部 「Fedora最新技術情報＆Systemd勉強会」 http://connpass.com/event/3859/ で使用した資料です。 変更履歴 2013/11/04 ver1.0 初版 2013/11/05 ver1.1 誤植修正、少し追記 2013/11/06 ver1.2 daemon-reload,mask,テンプレート機能を追記 2013/11/12 ver1.3 User/Groupオプションの説明追加 2013/11/24 ver1.4 誤植修正 2014/05/05 ver1.5 imjournalモジュールの説明追加
超チューニング祭 ちょっと遅くなったけど、2014/4/26-27の二日間、ニコニコ超会議3内のまるなげひろばの一角で開催された超チューニング祭にドワンゴチーム(メンバーは 江添亮さん, kmizuさん, masarakkiさんと合わせて4人)として参加したり表彰などをした話。 参加チームは全部で18チームかな?(チーム番号は20までだけど、2チーム欠番?)。 競技ルール ルールは、niconicoのスマートフォン版webのコピーの一部改変版を主催者サーバー上に配置し、速度とUIの改善を競うというもの。チームごとにコピーが配置され、各チームに秘密鍵が配られ、その鍵でSFTPで各チーム用サーバーにuploadする。 UIのユーザー投票と測定結果のそれぞれの順位の合計が一番少ないチームが総合優勝となるため、速度だけでもデザインだけでもだめ、というものであった。 投票以外では、UI要件(どの要素
トップページ > 旬ネタ > 『ニコ超3』の超チューニング祭で、“創世神”戀塚昭彦氏を上回ったカップルが見せたバランス感覚 『ニコ動』と聞いていったい何を指すか知らないネット民はほとんどいないだろう。そう、ドワンゴの運営する動画サイト『ニコニコ動画』である。 そんな『ニコニコ動画』のリアルイベント『ニコニコ超会議3』（以下、『ニコ超3』）が2014年4月26、27日の2日間にわたって、開催された。 昨年の『ニコニコ超会議2』では会場来場者10万3561人、ニコニコ生放送の視聴者数509万4944人を数え、ネット民の度肝を抜いたが、今年は会場来場者12万4966人、ニコニコ生放送の視聴者数は759万5978人と、回を追うごとに巨大イベントに成長している。 そんな『ニコ超3』の中には、企業がスポンサードするブースや主催者のドワンゴが運営するブースだけではなく、『まるなげひろば』という企画・準備
ただ、WebRTCで顔認識させようとすると遅くてしかたがなかった。 最初は速いこともあるが、10回ぐらい認識をさせるとすぐに遅くなる。 とりあえず、デモ。 そこで、チューニングをしてみることにした。 まず、JavaScriptの定番の高速化を試してみた。 例えば、正の数で使える「Math.floor(x)」を「(x | 0)」に、整数で使える「x * Math.pow(2, y)」を「x << y」にする等。 これで、10~30%高速化できた。 次に、遅くなっている部分を調べたら、Web Workersで分散するための仕組みが遅くなる原因だとわかった。 これは、Web Workersを使わない場合にも影響が出ていた。 じゃあ、Web Workersを使えば速くなるのかといえばその逆で、20倍遅くなっていた。 詳しくは調べてないけど、多分Workerスレッドに処理データを渡す時にJSON化が
はじめに コメントサーバーは、ニコニコ関連サービスのコメントを司るサーバーである。本稿は、ニコニコ広場で起こったコメントサーバーメモリ使用量増大問題について、我々コメントサーバー担当が行った調査と対策のまとめである。 今回のメモリ増大問題の解決にあたり、「仮説を立てる + 計測する→修正する→確認する」というパターンを繰り返した。このパターンは、ソフトウェアの様々な問題を調査するのに適用できる、基本パターンである。 コメントサーバー概要 コメントサーバーについて簡単に概説する。 コメントサーバーはニコニコ関連サービスのコメントを管理するサーバーである。基本的な機能は、新しいコメントの保存、およびコメントの出力である。ニコニコサービスのユーザーがコメントサーバーに直接触れることはなく、ニコニコのプレイヤーがコメントサーバーと直接やりとりを行う。ニコニコ動画の例でいうと、コメントサーバーを使用
1つ前の記事「JavaScriptをいかに高速化するか、IE9、Firefoxの取り組み」では、IE9とFirefoxにおけるJavaScriptの高速化について紹介しましたが、そもそもJavaScriptの実行速度はなぜ遅いのでしょう？ その理由について、Mozilla Japanテクニカルマーケティング担当の浅井智也氏が、スライド「Trace Monkey」でポイントをまとめています（このスライドはタイトルから分かるとおり、Firefoxの当時の新しいJavaScriptエンジン「Trace Monkey」を紹介するために1年以上前に作成されたスライドですが、1つ前の記事を見ると、ここで示された課題はいまも変わっていないようです）。 全67枚のスライドの20枚目から24枚目の5枚を以下に紹介します。 JavaScriptが遅い原因は、以下の4点にまとめられています。 インタープリタ型言
“Web高速化”に取り組むGoogleが、開発者向けにWebアプリの高速化を支援するツールをGoogle Chromeの拡張機能として公開した。 米Googleは12月8日、Webアプリ開発者向けの性能分析ツール「Speed Tracer」を、Google Chromeの拡張機能として公開した。同日公開のAjaxアプリ開発ツールの新版「Google Web Toolkit（GWT） 2.0」のツールの1つという位置付けで、GWTのページからダウンロードできる。対応するのは開発者チャンネル版のGoogle Chrome。 Speed TracerをインストールしたGoogle ChromeでWebアプリを開き、ブラウザ上部に表示されているストップウォッチのアイコンをクリックすると、それ以降の操作が記録される。一連の操作は「Sluggishness（鈍さ）」グラフに表示され、y軸が高い部分でス
Webサイトを制作するとき、「パフォーマンス」を気にしたことがあるだろうか？ もしまったく気にしたことがないなら、気をつけた方がいい。閲覧に時間のかかる“遅いWebサイト”はユーザーにフラストレーションを与え、閲覧をやめさせてしまう恐れがある。 下記のグラフは、「Simple-Talk」という海外のオンラインメディアで発表されたユーザー調査の結果だ。アンケートページの表示にかかる時間を意図的にコントロールし、表示時間によってユーザーが感じるフラストレーションの違いを調べたものだ。 縦軸がフラストレーション（10段階）、横軸が表示までの時間を表している。1～5秒以内にページが表示された人に比べ、ページ表示までに5秒以上かかった人は2倍以上もフラストレーションを感じている。フラストレーションがあまりに高ければ、せっかく何らかの目的を持って訪れてきたユーザーも待ち切れずにブラウザーを閉じてしまう
DoRuby! (ドルビー!) は現場のエンジニアによる、主にRubyなどの技術に関する様々な実践ノウハウを集めた技術情報サイトです。 こんにちは、O2 です。今回は、postgresql の設定ファイル（postgresql.conf） に関しての、私が最近設定しているデフォルト値を公開しようと思います。 実際、インストール直後の設定では、「ロースペックのマシン環境でも動作する」設定の為最近のサーバースペックにあった、デフォルト値を記述してみようと思います。 とは言っても、私が扱っている最近のサーバーのメモリは、8GB、16GB、32GB で、さらにPostgreSQL 8.3以降を使用しているので、PostgreSQL 8.3以降での、メモリ3パターンでのデフォルト値を紹介します。 注意．あくまでも、私が割り出したデフォルト値ですので、どのように使用するかによってチューニングは必要にな
データベースの醍醐味は、パフォーマンスチューニングにあります。 チューニングによっては、同じ処理でも1時間掛かる場合もあれば、 1秒で終わるということもあり得る世界です。 僕はDBの魅力に取り付かれた者の一人です。 DBという技術の奥深さが気に入っています。 DBを極めると、どこの現場に行っても絶対に必要とされます。 また、どこの現場に行っても正解を導く方程式は一緒なので応用が利くのです。 しかし、その基本原理を体系的に学べる手段はあまりありません。 OracleMasterやMCDBAといった資格試験でも学べることは限られていて あとはWebで調べるなりマニュアルを読むなりするしかありませんでした。 とくに肝であるパフォーマンスチューニングについては、 経験則でチューニングしている部分も多いです。 Oracle、SQLServer、MySQLと色々なDBのチューニングをしてきましたが、
さらにMySQLを高速化する7つの方法
MySQLを高速化する10の方法という記事がとても好評だったようである。記事を読んで頂いた皆さん、ありがとう。 この記事に対する便乗（？）でWeb屋のネタ帳: PostgreSQLを高速化する16のポイントという記事を書いて頂いたようだが、そちらの方もかなり人気だったようである。他人が作ったソフトウェアに改良を加えるというフリーソフトウェアやオープンソースソフトウェアの精神も基本は便乗であるので、便乗については大いに賛成したいというかむしろ取り上げてくれてありがとう！！と思うわけであるが、ここでさらに俺はこう考える。 と。 Web屋のネタ帳さんの記事では16のポイントが紹介されているが、漢（オトコ）のコンピュータ道の記事は10の方法だったのであと6つ足りない。オトコは数で勝負！！というわけで今日はネタを振り絞ってさらに7つのMySQL高速化テクニックを紹介しよう。 1. インテルコンパイラ
漢(オトコ)のコンピュータ道: MySQLを高速化する10の方法
ちょっとキャッチ−なタイトルをつけてしまったが、今日は独断と偏見でMySQLを高速化する方法を10個紹介しよう。MySQLサーバをチューニングするときや初期導入する場合などに参考にしてもらいたい。 1. バッファを増やす、または減らす チューニングの基本中の基本であるが、適切なバッファサイズを設定することはパフォーマンスチューニングの要である。主なバッファは次の通り。 innodb_buffer_pool_size・・・InnoDBだけを利用する場合は空きメモリの7〜8割程度を割り当てる最も重要なバッファである。余談だが、実際にはここで割り当てた値の5〜10%ぐらいを多めにメモリを使うので注意が必要だ。 key_buffer_size・・・MyISAMだけを利用する場合は、空きメモリの3割程度を割り当てるといい。残りはファイルシステムのキャッシュ用に残しておこう。 sort_buffer_
プロファイリングで快適MySQLチューニング生活
MySQL 5.1からデフォルトで有効になっている便利な機能としてプロファイリングというものがある。MySQL 5.0でも利用出来たのだが、実験的な機能という位置づけであり、搭載されていたのはGPL版のMySQL Community Server限定だった。MySQL 5.1からは全てのエディションでプロファイリングを利用することができる。 プロファイリング機能を利用すると、クエリの状態（特に状態遷移やリソースの消費状況）を詳細に分析できるのでとても便利だ。MySQLエンジニア必携の機能といって良いだろう。というわけでプロファイリング機能の使い方を説明しよう。 MySQLサーバにログインしたら、まずは次のようにしてプロファイリングを有効にする。 mysql> SET profiling=1; すると、クエリの情報が記録されるようになる。次に、分析したいクエリを実行する。クエリはなんでもいい
本稿では、前回に続き実際にいくつかのFirefoxのチューニングを行ってみます。 注意:本稿ではFirefoxのチューニングを行っておりますが、チューニングは使用者の責任において行ってください。 半透明効果を無効にする Mozilla Firefox 3(以下、Firefox)では、画像や文字列はもちろん、URLやタブをドラッグした際に、そのオブジェクトが半透明になる機能が加わりました。もちろん、この半透明効果はオブジェクトによって異なりますが、一定のパフォーマンスを必要とし、数世代前のコンピュータでFirefoxを使っているユーザーには、パフォーマンスダウンにつながります(図1、2)。 図1 画像をFirefoxのウィンドウ内やデスクトップにドラッグしますと、その画像が半透明になります 図2 ドラッグによる半透明効果は、画像のほかにもリンクやfavicon、タブ、文字列などが対応してい
id:HolyGrail (堀愚霊瑠氏) の「はてなブックマークが重い件について、Page Detailerというツールを使って調べてみる - id:HolyGrailとid:HoryGrailの区別がつかない日記」とか見てて、色々問題点が指摘されてて、うん、まぁそうだねーとか色々と思いつつ、YSlow は、有用なツールである反面、減点基準が必ずしも全てのサイトに適合しないというか、ハッキリ言ってしまえば Yahoo! Inc. 基準すぎるので、鵜呑みにし過ぎるのもどうかなーとか思ってた。 で、気になったのは 13. Configure ETags ETagsっていうのはサーバ上のファイルとブラウザのキャッシュが一致しているかどうかを検証するためのものなのですが、正しく利用できていないのであれば、ETagsは無駄なだけなので取り除いてやりましょう、という項目です。 http://s.hat
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
