手軽に負荷テストができるツール「Taurus」がスゴい
modules: jmeter: version: 5.4.1 # ここに書いてあるバージョンを勝手にダウンロードしてくれる properties: log_level.JMeter: WARN log_level.JMeter.threads: WARN system-properties: org.apache.commons.logging.simplelog.log.org.apache.http: WARN 既存ツールのラッパーとして動作 デフォルトでは内部的にJmeterが実行されますが、以下のようなツールで作成されたスクリプトを流用することが可能です。 JMeter Gatling Locust Selenium Vegeta つまり、さきほどはYAMLでシナリオが記述可能とは言いましたが、もちろん既存のスクリプトを流用できるってことです。 いままで作り上げてきたスクリプトや
「最近のWebパフォーマンス改善について知っておきたいコト」についてあほむに聞いてきた
「最近のWebパフォーマンス改善について知っておきたいコト」についてあほむに聞いてきた 白石 俊平（HTML5 Experts.jp編集長） こんにちは、編集長の白石です。 この記事は、9月24日に開催されるHTML5 Conference 2017に登壇するエキスパートに、予定しているセッションのトピックを中心に、いろいろ伺ったものです。セッションの内容をより深く理解する手助けになるだけでなく、本記事単体でも面白く読んでいただけることを目指しています。 今回お話を伺ったのは、株式会社サイバーエージェントにお勤めの佐藤歩さんです（ネット上では「あほむ」「ahomu」のIDで有名）。 （プロフィールはこちら） あほむさんのセッションは「最近のWebパフォーマンス改善について知っておきたいコト」（ホール 13:20-14:00）です。 （現在HTML5 Conference 2017は定員オー
RedisサーバのCPU負荷対策パターン - ゆううきブログ
Redisは多彩なデータ構造をもつ1インメモリDBであり、昨今のWebアプリケーションのデータストアの一つとして、広く利用されている。 しかし、一方で、性能改善のための手法を体系的にまとめた資料が見当たらないと感じていた。 実際、最初にCPU負荷が問題になったときにどうしたものかと悩み、調査と試行錯誤を繰り返した。 そこで、この記事では、自分の経験を基に、RedisサーバのCPU負荷対策を「CPU負荷削減」「スケールアップ」「スケールアウト」に分類し、パターンとしてまとめる。 背景 RedisのCPU負荷対策パターン CPU負荷削減 multiコマンド Redisパイプライニング Luaスクリプティング Redisモジュール(夢) スケールアップ スケールアウト 参照用スレーブ 垂直分割 水平分割 Redis Clusterによる水平分割 その他 スライド資料 あとがき 参考資料 背景 R
MySQLインデックスのお手入れの基本 | Yakst
Percona Database Performance Blogの翻訳。既に運用を始めたデータベースで、インデックスが正しく使われているか、無駄や不足がないかを確認する方法のまとめ記事。クエリをひとつひとつ確認するのではなく、統計情報を元に判断する分かりやすい方法。 このブログ記事では、MySQLインデックスに手入れする基本的なステップについて見ていこうと思います。 データベースは、インデックス次第でハイパフォーマンスにも、役立たずで遅くて大変にもなりうることはご存知でしょう。インデックスは、時々手入れをする価値がある非常に重要なものです。それでは、何をチェックすればよいのでしょうか？順不同ですが、確認すべき点を挙げてみます。 1. 使われていないインデックス sysスキーマで、使われていないインデックスをとても簡単に見つけられます。 schema_unused_indexes ビューを
CPU使用率100％のWebサーバをOSのチューニングだけでCPU使用率20%まで改善する - 人間とウェブの未来
こんばんは、 @matsumotoryです。 hb.matsumoto-r.jp 上記エントリにおいて、プロセスの大量メモリ確保に伴うページテーブルサイズとベージテーブルエントリ数の肥大化によるcloneやexecveの性能劣化とCPU使用時間の専有問題、および、それらの解決方法についてシステムコールレベルで確認しました。 そこで今回は、システムコールやそのカーネル内部の処理の性能、というよりは、より実践的な環境であるApache httpdとmod_cgiを用いて、phpinfo()を実行するだけのCGIに対してベンチマークをかけた時にどれぐらいCPUのidleが空くか、システムCPUの使用量が変わるかを、前回示した解決方法の1つであるHugePagesを使うかどうかの観点で比較してみましょう。 特定条件下のWebサーバ環境のシステムCPUに起因する高負荷問題から、システムコールやカーネ
Railsアプリを66％スピードアップ ― Railsキャッシュの完全ガイド | POSTD
(訳注：2016/3/2、頂いた翻訳フィードバックをもとに記事を修正いたしました。) Railsアプリでのキャッシングは、「たまに夕食を一緒にするけれど、本当はもっと頻繁に一緒にいるべき友達」に少し似ています。パフォーマンスをまじめに考えるRailsアプリのほぼ全てで、もっとキャッシングを使えるはずですが、ほとんどのRailsアプリでは、完全にキャッシングを避けています。それでも普通は、Railsで高速なサーバ応答を達成するための唯一の道は、キャッシングの知的な利用なのです。約250msの応答時間を、簡単に50～100msに高速化できます。 定義についての注意 ― この記事は、アプリケーション層のキャッシングのみを対象としています。HTTPキャッシング（これは全く別の難物で、あなたのアプリケーションに実装する必要はありません）は、別の機会で扱いましょう。 するべきキャッシングをしない理由
シンプルでかつ最高のJavaScriptプロファイラ sjsp を作りました！ ― Webアプリケーションが複雑化する中でプロファイラに求められるものとは何か - プログラムモグモグ
あらすじ Web技術が複雑になる中で、JavaScriptのプロファイリングをとる方法とは。 プロファイリングを取るためのコードを手で書いてみましょう。 とてもシンプルで、かつ最高のJavaScriptプロファイラ sjsp を作りました。 本当にあった怖い話 上司 「とにかくJavaScriptのコードを速くしてくれ」 私 「分かりました、速くします」 (次の日) 私 「いいプロファイラがないなら作ればいいじゃない」 同じチームの人 「えっ？」 私 「最高のJavaScriptプロファイラ作ったよ」 同じチームの人 「「えっえっ？？？」」 私 「早速使ってみたらこことここが遅いって分かったよ」 同じチームの人 「「「この子は一体…」」」 JavaScriptのプロファイリングの難しさ 近年、Webブラウザーの処理速度は著しく向上し、その可用性の高さから、アプリケーションのプラットフォーム
nginxパフォーマンスチューニング〜静的コンテンツ配信編〜 - Qiita
今回はHTMLやCSS、Javascriptといった比較的軽量な静的コンテンツの配信をnginxでやるケースに絞ってチューニングする際のポイントについて紹介しようかと思います。 (注：worker_rlimit_nofileやsysctl.confのネットワーク周りの設定のような定石的なチューニングについてはあえて解説しないのであらかじめご了承ください。) コンテンツをgzip圧縮する 何はともあれgzip圧縮です。ネットワーク帯域に比べればCPUリソースなんて安いものです。 しかし、多くの場合これだけでは十分ではありません。何故ならnginxはデフォルトではContent-Typeがtext/htmlのコンテンツしか圧縮しないためです。圧縮対象のContent-Typeを増やすにはgzip_typesを使います。 単純なWebサイトであれば上記の設定で十分ですが、場合によってはappli
JavaScript・jQueryの改修・高速化のためのメモ - Qiita
たまにJavaScriptやjQueryなどの改修が入ったりすると忘れてしまうので、自分用のメモとして残しておきます。 JavaScriptコーディングベストプラクティス（高速かつ堅牢なコードを効率よく書くために）を参照しながらのメモになります。 随時、この記事に追記予定です。 高速化メモ JavaScript編 スタイルシートは上に、JavaScriptは下に指定する JavaScriptファイルは読み込んだ後、通常はスクリプトを解析している間、他のファイルの読み込みをブロックする JavaScriptはページの上部に指定すると、このブロックによりロード時間が増加する場合がある スタイルシートはなるべく上に、JavaScriptファイルは下部にしていることで、ロード時間が短縮できる 画面描画に関係ないJavaScriptは、</body>の直前に書く $(document).readyを
Webフロントエンドパフォーマンスチューニング
Webフロントエンドのパフォーマンスチューニングについて全体的な話。javascript、Chrome DevToolsの紹介、ボトルネック、ポイントなど。
innerHTML += ... な書き方について - hogehoge @teramako
DOM操作の最適化によるJavaScriptチューニング（前編） | HTML5Experts.jp はてなブックマーク - DOM操作の最適化によるJavaScriptチューニング（前編） | HTML5Experts.jp はてなブックマークで『後でツッコミする』と書いたとおり、ちょっとツッコミたいと思う。 ツッコミ記事のつもりが、自分がツッコミされることとなり、ダメダメな記事です。それでも良ければお読み下さいｗ // サンプル1: パフォーマンスが悪い var ul = document.querySelector('#output'); for ( var i = 0; i < data.length; i++ ) { ul.innerHTML += ‘<li>’ + data[i] + ‘</li>’; } 上記コードはダメなコードであり、理由は、 li要素をループが回るたびに追
G-WANはなぜ速いのか？をnginxと比べながら検証してみた - blog.nomadscafe.jp
ツチノコブログのWEBサーバベンチマークツール比較の記事で紹介されていた。WebサーバのG-WAN。この記事によると凄く速いようです。 Intel Xeon E5-2640 (6コア/12スレッド 2.50GHz) を2つというサーバで gwan 334944 req/s nginx 111842 req/s と、速いと言われているnginxの3倍の速度を出しています。 このベンチマーク結果がとても気になったので、なぜG-WANが速いのか、自分でも検証してみました。 結論から言うと以下の2つ。 1) G-WANはデフォルトで物理CPUに合わせた数のスレッドを起動する 2) HTMLファイルも一度読み込んでキャッシュする という事です。 今回はAWSのcc2.8xlarge(E5-2670 8コア/16スレッド 2.60GHz *2)を使ってベンチマークを行いました。OSはAmazon L
Rails アプリケーションのパフォーマンスについて RubyKaigi 2013 で発表しました - クックパッド開発者ブログ
インフラストラクチャー部の成田です。 先日開催された RubyKaigi 2013 で、 "High Performance Rails" というタイトルの発表をしてきました。 スライドと動画 発表の様子は ustream の録画をご覧ください。 [ustream id=33559705 hwaccel=1 version=3 width=480 height=302] スライドは以下にアップロードしてあります。 High Performance Rails (long edition) // Speaker Deck なお、発表時間の都合上、当日はここから 40 枚ほどのスライドを削除してしまいました。発表に使った短いバージョンのスライドはこちらです。 発表の概要 クックパッドは 2008 年から Ruby on Rails を採用し、ずっと使い続けてきました。サービスが成長するとともに
Rails で、Controller に定義されている action を一度に取得する方法はありますか？ - QA@IT
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
16の言語と57のフレームワークを比較したベンチマークが凄い
いつの時代もより高速に動作するフレームワークや言語に対する関心は高いものですが、そんな疑問に答えるWeb Framework Benchmarksの最新版が公開されています。こちらのベンチマークはテスト用のコードや環境がオープンソースになっており16の言語(C C# Clojure D Erlang Go Groovy Haskell Java JavaScript Lua Perl PHP Python Ruby Scala)と57のフレームワークについて最適な実装が集められてテストされているという点で一般性があります。また実行環境もEC2と実マシンの2種類をそれぞれ実行している点も興味深いです。 気になるテスト結果のうち特に複雑度の高いデータベースから複数件のデータを取得してHTMLページとして出力した場合の結果は下記のとおりです。 堂々のトップに輝いているのはServletで最大で1
Webサイト高速化対策の現状
はじめに はじめまして、こんにちは。クラスメソッド株式会社でWebを担当している野中です。 この度、「これから身につけるWebサイト高速化テクニック」と題して記事を連載させていただくこととなりました。 本連載ではWeb担当者やWebデザイナー、コーダーの方々に向けて高速化に関する手法や技術について調べ、身につけたテクニックを細かな解説を加えて紹介していきます。中には少し難しいテクニックも含まれますが、できる限り分かりやすく、すぐに実践できるよう紹介していきたいと思います。とても長い連載ですが、よろしくお願いいたします。 なお、本連載はクラスメソッド開発ブログで連載されている「身につけておきたいWebサイト高速化テクニック」の増補改訂版です。 本連載の流れ 本連載はできるだけ多くの方に興味を持っていただけるように、最初に高速化対策の全体像と必要な知識を紹介します。その後、具体的な高速化対策と
muninの表示がクソ重くなっていたのを劇的に改善した話 - 元RX-7乗りの適当な日々
某所の"munin"がびっくりするくらい画面表示が重くなっていて、ひょんなことから改善することになった話。 前提条件として、このmuninが動いているサーバは数百台のノード(サーバ)を管理している状態で、muninのバージョンは2.0系でした。 本当は、後学のためにも作ってくれた人に直してもらうべきと思いつつ、あまり悠長なことも言ってられない感じだったので、一人チューニンガソンを敢行。・・・要望があったのでログを残しておきます。(遅くなってごめんなさい) 最初の状態(before) まず、muninのトップページですが、開いてみると、、、 うほっ、19.61秒かかっておりました。これはなかなかのストレスです。 特にHTML部分の出力に19.4秒かかっている。ここをなんとかせねばなるまい。 次に4台分のサーバの各リソースの負荷状況が確認できるページを表示してみると ズラズラと出ております。各
Webサイト高速化のプロセスだって自動化したい
サーバ側にmod_spdyをインストールし、Google Chromeで、HTTP2.0でベースとなるSPDYのデモが行われた「Chrome Tech Talk Night #5」をレポートする。 Webサイト高速化のプロセス自動化と最高のパフォーマンス計測ツール 1月31日、Google 東京オフィスで開催された「Chrome Tech Talk Night #5」の模様をレポートします。Chrome Developer AdvocateのIlya Grigorik（イルヤ・グリゴリック）氏を迎え、SPDY導入方法を含むWebアプリケーションの高速化や、パフォーマンス向上の手法について説明されました。 イベント自体は「Making the Web Fast with PageSpeed」、「Wait, Chrome DevTools can do THAT?」の2部構成でしたが、このレポ
インストールするだけ! お手軽サイト高速化ツールGoogle mod_pagespeedはスゴかった | 初代編集長ブログ―安田英久
どれぐらいスゴいかというと、「サーバーにインストールするだけで、あとは設定ファイルをちょちょっといじれば、かなり高速化できちゃう」というぐらいスゴいのです。しかも、どんなサイトでも、どんなCMSを使っていても「インストールするだけ」。 Webサイトを高速化すると、ユーザーに優しいし、場合によっては検索結果での順位にも良い影響が出るかもしれない……それはわかっていても、なかなか本格的にサイトを高速化するのは難しいものです。 サーバー側の高速化に加えて、HTMLのつくりや画像のファイルサイズ最適化、さらにはCSSを調整しての画像スプライト化やCSS/JSファイルの結合・最適化によるブラウザとサーバーの通信本数削減などなど、実はやらなきゃいけないことがたくさん。 グーグルの提供するmod_pagespeedは、そうしたことの、かなりの部分を自動的に行うものです。 mod_pagespeedはこん
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TechCrunch | Startup and Technology News
