Chrome Developer Toolsを使いこなそう！
2018年12月4日 Japan Container Days 講演資料 谷脇大輔 Preferred Networksでは1000個以上のGPUとInfiniBandからなるオンプレミスのクラスターを自社で構築しており、研究者が様々な目的、リソース量、実行時間の機械学習ジョブをKubernetes上で実行して研究成果を出しています。 KubernetesはKubeflowの登場など、機械学習基盤としても非常に注目されている一方で、現実的には未だ発展途上です。 講演では機械学習基盤としてのKubernetesの導入理由、その実用性と将来性、Preferred Networksの挑戦についてお話ししました。
サーバのリソース使用状況レポートを作る - mikedaの日記
数百台のサーバに対して CPU メモリ HDD の使用状況をサクッとチェックしたいなーと思ったのですが、さすがにmuninのグラフで見るのはダルすぎる。 というわけで日次でこういうページを作ってチェックするようにしました。 上記の情報が数字でダーっと並んでて、ついでに簡単に色付けとか、muninへのリンク張りとか、各項目でのソート機能付けたりとかをやってます。 CPUとメモリの使用率は前日の平均、ディスク使用率はバッチ実行時の値です。 最初はmuninのRRDファイルから作ろうかと思ったのですが（gist）、この程度の情報ならsysstatやdfの結果から作るほうが簡単なので、sshで集めてくることにしました。 とりあえずHTMLに出力してますが、CSVで出したりDBに突っ込んだりすれば各種調査に便利ですよ！ ソースコード Ruby1.9版です #!/usr/local/bin/ruby
第17回 Webアプリケーションのパフォーマンス改善（1） | gihyo.jp
大きな効果を上げるために チューニンガソン#1～#3の改善率を見ると、アプリケーションや全体のアーキテクチャに手を入れないで改善できるのは最大でも10倍以下です。もちろん数倍速度が違えばサーバ台数を大きく減らせるので有意義なのは間違いないのですが、ISUCONやチューニンガソン#4のような飛躍的な高速化は望めないことがわかります。 つまりチューニングでは、単にパラメータ設定を変更するのみではなく、ボトルネックになっているコードやクエリ、アーキテクチャに的確に手を入れていくことで大きな効果を上げることができるのです。 ボトルネックの発見と解消が大事 システム全体の処理時間についてパレートの法則（経験則）を適用すると、「全体の処理時間の80％は20％の部分で発生している」ということになります。実際にシステム全体で一番ボトルネックになっている部分を解消しないことには、ほかの部分に手を入れても大
Webサーバの性能を測る | IIJの技術 | インターネットイニシアティブ（IIJ）
（※）このページで紹介している事項は記事初出時点の情報に基づいたものです。本ページはアーカイブとして掲載しています。 ツイート 2012年12月18日 UNIX系のOSで利用できるWebサーバの性能測定ツールといえば、Apache Benchやhttperfを思い浮かべる人が多いのではないでしょうか。これらの計測ツールは、残念ながら最近の高速なWebサーバを計測するには非力です。この記事では、高速なWebサーバにも負けないweighttpの使い方を紹介します。 weighttpとは何か weighttpは、Webサーバlighttpdの開発者が実装したWebサーバの性能測定ツールです。以下のような特徴を持ちます。 Webサーバのスループット（リクエスト毎秒）を測定できる ネイティブスレッドを複数起動し測定性能を向上できる libevを利用することで、モダンなポール・システムコールを利用する
OProfileの使い方備忘録 - hogelogの日記
プログラムのボトルネックがどこにあるのか、なんて調べるときには計測する必要がありますね。プログラム中の特定処理の前後でrdtsc命令使って時間を計測して処理時間を求める、とかそういうこともできるんですけど、まあめんどうじゃないですか。プロファイラを使いましょう。 プロファイラとはなんぞや、Wikipediaの性能解析のページに色々書いてますね。 そういうわけでOProfileというLinuxで動くプロファイラを使っているので、未来の自分とか「OProfile動かしてみてーけどさっぱりわからん！」みたいな人のためにまとめておきます。 OProfileの特徴 OProfileは 計測したいプログラムに対して特別な処理をしなくてもいい 低レイヤーの情報も計測できる gprof形式のコールグラフも表示できる オーバーヘッドがとても小さい これらの特徴があるらしいです。使ってみて特に嬉しいと感じたの
予定外 Visual C++ Express Editionでプロファイラを使ってみる
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。 ソフト開発の技術書には、パフォーマンス最適化について書かれているものも多いですが、そこで必ずと言っていいくらいに述べられているのが、「コードを書く時点から最適化をしない」「手を加える前にまずパフォーマンスを測定せよ」ということです。 「プログラムの処理にかかる時間の80%はコード全体の20%の部分が占める」という、いわゆるパレートの法則に則り、まず測定によってプログラムの実行時間の大半を占めるわずかな部分のコードを割り出して、そこを集中的に改善しましょう、というのが定説です。 コードの測定には通常、プロファイラと呼ばれるツールを使います。 プロファイラは、どの関数がどのくらいの時間実行されていたか、何回呼び出されたかなどの方法を収集して解析し、ボトルネックとなっている部分を探すこ
Linux用パフォーマンス評価ツール UnixBench
UnixBenchは、Linux環境で動作するパソコンの処理性能を評価するためのソフトである。CPUの演算性能や、2次元、3次元のグラフィックス性能を、数値として出力する。マルチコアにも対応している。 月額1000円以下で利用できる格安VPS（仮想専用サーバー）サービスが登場し、「UnixBench」がにわかに注目を集めている（写真1）。ネット上では、UnixBenchで測定した格安VPSのベンチマークが数多く公開されている。UnixBenchの数値が、格安VPSのコストパフォーマンスを測る指標となっているのである。 UnixBenchは1983年1月、オーストラリアのモナッシュ大学で開発された。名前にあるとおり、当初はUNIXシステムのベンチマークツールとして開発されたようだ。1989年、米国のコンピュータ雑誌「BYTE」が採用したことで広く知られるようになった。Linux向けに移植され
「バックエンドの経験はなかった」Instagram創業者は、どうやってシステムをスケールさせてきたか
昨日のPinterestの記事「Pinterestの急成長を支えてきたアーキテクチャとは？ Pythonで開発しAmazonクラウドで運用」に続いて、やはり写真を中心としたサービスで急成長してきたInstagramのスケーラビリティについて、まとめてみました。 InstagramもPinterestと同様に、基本はAmazonクラウド上でPythonとフレームワークのDjangoを使ったシステムを構築しています。興味深いのは、創業者の二人ともバックエンドの経験がないなかで試行錯誤をしてシステムをスケールさせてきた点です。 Instagramは先月、Facebookに買収されると発表されています。この先、Instagramのシステムはどう変わっていくのでしょうか。 Instagramのシステム構成 約半年前、昨年12月にInstagramのブログに投稿された記事「What Powers In
Webアプリのパフォーマンスアップ作戦 - ゆーすけべー日記
予定している機能を実現するアプリが完成するだけでWebサービスが成り立つわけではありません。 運用の最中にパフォーマンスにまつわる問題が出てくる可能性があります。 それは突然大きなトラフィックがやってきたというような時だけではありません。 知識が無いうちですと、いざ運用に乗せてみるとずいぶんとサイトの読み込みが遅いといったケースが発生することもあります。 僕はいくつかのエロサイトを管理しているのですが、 その中に月間700万PVのアクセスをいただいている「サイトA」があります。 サイトAの場合、トラフィックもそこまで無かった当初からパフォーマンスに関する問題がいくつか発生し、 その都度調べては実践で試して対策をしてきました。また、できる限り少ないリソースでの運用を目指しています。 今回はWebアプリのパーフォマンスアップ作戦として、 サイトAでの運用経験からのいくつかの方針やTipsを紹介
味のりとこんにゃくゼリーのエンジニアブログ: phpを高速化する60の方法
2012年3月15日木曜日 phpを高速化する60の方法 01. static にできるメソッドは static として宣言しよう。（4倍速い） 02. echo の方が print より速い。 03. echo ‘文’,'字’; （カンマ区切り）の方が、’文’.'字’ （ドット連結）より速い。 04. ループの最大値は、ループ「内」ではなく「前」にセットしておこう。 05. 大きい配列のような変数は unset() してメモリを解放しよう。 06. マジックメソッド（例： __get, __set, __autoload）は使用を避けよう。 07. require_once はハイコストなのです。 08. include や require でファイルはフルパスで指定しよう。 09. スクリプト開始時間は time() でなく $_SERVER['REQUEST_TIME
Python高速化テクニック - atsuoishimoto's diary
ここ２〜３日、InfoPileのパフォーマンスチューニングをしており、ちょっともたつきを感じるような部分をほとんど解消することができた。InfoPileで使用した高速化テクニックの中で効果が大きく、よくつかわれそうなものを紹介しよう。尚、以下のスクリプトはPython 2.6.4で実行した。 listよりtupleを使う 可変長である必要のないシーケンスは、できるだけlistではなくtupleを使って構築しよう。listの生成/解放コストは意外と大きいのだ。 import time def run1(): for i in xrange(1000000): [i, i+1, i+2, i+3, i+4, i+5, i+6, i+7, i+8] def run2(): for i in xrange(1000000): (i, i+1, i+2, i+3, i+4, i+5, i+6, i+
サーバやPCのボトルネック箇所の簡単な見分け方(Linux編)：佐野裕のサーバ管理者日記：ITpro
前回はWindowsでのサーバやPCのボトルネック箇所の簡単な見分け方をご紹介させていただきましたが、要望がありましたので今回はLinuxの場合をご紹介いたします。 4つの主要ボトルネック要素の復習です。 サーバやPCには4つの主要ボトルネック要素があります。このいずれかがボトルネックとなった場合システム全体のレスポンスが低下します。 CPU使用率 メモリ使用量 ディスクI/O TCPコネクション数 Linuxにおいてはボトルネック箇所を以下のように見分けることができます。 1. CPU使用率 CPU使用率が常に100%に近い場合はCPUがボトルネックであることが判明します。CPU使用状況を簡単に調べるには3つの方法があります。「top」「w」「vmstat」コマンドを使う方法です。 -----------------------------------------------------
PHP：eAccelerator で PHP 高速化 - Y-110's Wiki
最新文章 2018-12-26 05:10▪ 龙岩一公交车遭劫持致5死应急办称嫌犯从居委会“逃出” 2018-12-26 05:10▪ 徐汇区科协第九次代表大会：发挥人才优势助推技术创新 2018-12-26 05:10▪ 山东将迎大风降温局部地区降温超10℃ 2018-12-26 05:10▪ 骗子称销赃低抛iPhoneX年轻候车人中了调包计买走模... 2018-12-26 05:10▪ 昆明首座装电梯天桥提供人性化便捷服务受欢迎 2018-12-26 05:10▪ 中组部要求：在元旦春节期间走访慰问生活困难党员、老党员、... 2018-12-26 05:10▪ 涉及30万人，葛洲坝集团宜昌基地六大类职能分离移交宜昌 2018-12-26 05:10▪ 央行：四季度88.8%的居民认为收入增加或基本不变 2018-12-26 05:10▪ 一男子高速“飙车”后拍视频晒微信群因涉嫌危险
Apacheの負荷状況をモニタリングするツール「apachetop」
DoRuby! (ドルビー!) は現場のエンジニアによる、主にRubyなどの技術に関する様々な実践ノウハウを集めた技術情報サイトです。 TOPコマンドのようにapacheログからモニタリングできる「apachetop」 このツールのCentOS5.3へのインストールを実施してみます。 インストール方法はいくつかありますが、rpmでインストールしてみました。 (「yum install apachetop」もあります) # wget http://centos.karan.org/el4/extras/stable/i386/RPMS/apachetop-0.12.5-2.el4.kb.i386.rpm # rpm -ivh --nodeps apachetop-0.12.5-2.el4.kb.i386.rpm これでインストールは終わりです。 利用方法は下記のようなので、実行してみます。
Apache Bench で性能測定だ - IT革命～
情報技術(アイティー)革命ではなくイット革命！IT化推進に役立つソフトウェアやWeb制作に関するネタを扱います。 Apache に付属しているベンチマークソフトを使ってみました。 Apacheには、標準で「ab」(Apache Bench) というツールが付属しています。 同時接続数とリクエスト数とURLを指定すれば、性能が測定できます。 ab コマンドによって、リクエストを発生させ、接続時間・処理時間・待ち時間などの統計を取得することができます。 例えば、同時接続数が 100で、リクエスト数 1,000 になるまで、http://example.com/index.html にアクセスするならば ab -n 1000 -c 100 http://example.com/index.html 認証が必要なページには、-A オプションを使用します。 -n 数値：テストで発行するリクエストの回
プログラミング言語の速度とアプリケーションの速度がいかに関係ないかがわかるグラフ - kなんとかの日記
まずは次の表をご覧あれ。これはプログラミング言語のベンチマークとして有名な Computer Language Benchmarks Game のベンチマーク結果。上にいくほど高速で、下に行くほど遅い言語になる。 これを見れば、最速な言語は C/C++ であり、Java や Haskell や OCaml といった静的な言語は軒並み上位に登場する。これに対し、Ruby や Python や PHP といったスクリプトは全部下のほう (つまり遅い)。その速度差は非常に大きく、このベンチマークで見ると Python3 や Ruby1.9 は C/C++ の約50倍から60倍遅く、Perl は約90倍、PHP にいたっては約130倍遅いことになる。 (ちなみに JIT つきの Lua が驚異的に高速なのが目をひく。この結果が本当だとしたら、言語の速度に大きく関係するのは動的か静的かではなく、どれ
上流工程から「性能を作り込む」大切さ
性能トラブルを避けるために、開発工程全体で性能について留意することは確かに重要だ。限られた時間のなかで、具体的に何ができるのか---。日経SYSTEMS 2010年11月号で「応答3秒の作り方」という特集を企画したときに、まずこんな疑問がわいた。 システムの設計や実装の工程では、「機能要件をいかに実現するか」が最優先される。その過程で処理性能の目標値を達成するための作業、いわゆる「性能の作り込み」にはそれほど大きなコストはかけられない。これが多くのプロジェクトでの現実だろう。 通常の設計や実装を進める際に、多くの手間をかけることなく、性能トラブルの原因を回避できるのか。そうした視点で取材で進めたところ、まず出てきたのが「画面からデータベース（DB）処理を想像する」という方法である。 画面から応答時間が見えてくる 「画面設計の際に、裏側でどんなDB処理を実行するかを想像してみる。すると、応答
mod_pagespeed をちょっとだけ試してみた - 酒日記 はてな支店
Google の Page Speed の Apache module 版 mod_pagespeed をインストールして、ちょっとだけ動きを見てみた。 インストールは Ubuntu に deb パッケージで。 $ wget https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-beta_current_amd64.deb # sudo dpkg -i mod-pagespeed-beta_current_amd64.debconfig はデフォルトで入るものそのまま。 <IfModule pagespeed_module> SetOutputFilter MOD_PAGESPEED_OUTPUT_FILTER ModPagespeed on ModPagespeedUrlPrefix "http://localhost/mod_p
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Web高速化 || パフォーマンスチューニングBlog: インターオフィス
https://kikairoya.hatenablog.com/entry/20100718/1279465696