「最近のWebパフォーマンス改善について知っておきたいコト」についてあほむに聞いてきた
「最近のWebパフォーマンス改善について知っておきたいコト」についてあほむに聞いてきた 白石 俊平（HTML5 Experts.jp編集長） こんにちは、編集長の白石です。 この記事は、9月24日に開催されるHTML5 Conference 2017に登壇するエキスパートに、予定しているセッションのトピックを中心に、いろいろ伺ったものです。セッションの内容をより深く理解する手助けになるだけでなく、本記事単体でも面白く読んでいただけることを目指しています。 今回お話を伺ったのは、株式会社サイバーエージェントにお勤めの佐藤歩さんです（ネット上では「あほむ」「ahomu」のIDで有名）。 （プロフィールはこちら） あほむさんのセッションは「最近のWebパフォーマンス改善について知っておきたいコト」（ホール 13:20-14:00）です。 （現在HTML5 Conference 2017は定員オー
L2 cache for MySQL
The idea to use SSD/Flash as a cache is not new, and there are different solutions for this, both OpenSource like L2ARC for ZFS and Flashcache from Facebook, and proprietary, like directCache from Fusion-io. They all however have some limitations, that’s why I am considering to have L2 cache on a database level, as an extension to InnoDB buffer pool. Fortunately, there is a project in progress Fla
Percona Toolkit
All of Percona’s open source software products, in one place, to download as much or as little as you need.
本当は速いImageMagick: サムネイル画像生成を10倍速くする方法 - 昼メシ物語
一般的に ImageMagick のサムネイル画像生成は遅いとされており、パフォーマンスが求められるシーンでは Imlib2 などのより高速な画像処理ライブラリが使われることが多いです。 Imlib2 の高速さについては、以前「Imlib2でImageMagickより3倍高速かつ美しいサムネイル画像の生成 - 床のトルストイ、ゲイとするとのこと」という記事で紹介しました。この記事のベンチマークにおいて、Imlib2 によるサムネイル画像の生成は、 ImageMagick の3倍程高速でした。 しかし、 ImageMagick は Imlib2 より画質がよく、高機能で使いやすく、今も頻繁にメンテナンスされており、とてもよく出来ています。その点 Imlib2 は、2004年からメンテナンスされておらず、セキュリティホールが見つかっても、各Linuxディストリビューションがそれぞれパッチを当て
mod_pagespeed Overview
Learn more Overview Page Speed extension mod_pagespeed for Apache 2 Get Started Page Speed extension mod_pagespeed for Apache 2 Security Considerations Documentation Performance Best Practices Optimize caching Minimize round trip times Minimize request overhead Minimize payload size Optimize browser rendering Page Speed rules (alphabetical) Avoid bad requests Avoid CSS expressions Combine external
MySQLのEXPLAINを徹底解説!!
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
Linux チューニング - Ext3 のパフォーマンスを最大化させる
じつは自宅サーバのロードアベレージが上がり続けています。分析の結果、ボトルネックは I/O 処理でした。CPU は Athlon64 X2 4400+ ですが、まだまだ当分この CPU で間に合いそうです。HDD は当時は 7200 回転で最速だった HITACHI Deskstar T7K250 SATA2 250GB を RAID1 構成にしたのですが、今思えば速度優先で RAID0 にしておけば良かったと少しだけ後悔。 I/O がボトルネックに成っている理由ですが、Drk7jp が公開しているサービスの全てがキャッシュファイルを利用した高速化手法を取っているのですが、単純にそれらファイルの write 処理が追いついていません。常に何らかのプロセスで I/O 待ち状態が発生しているような状況です。抜本的な解決方法としては disk を高速なものに交換する以外ありません。 というわけで
The performance effects of new patches
We are going to show the effects of the new patches applied to Percona HighPerf release. As you see from the following graphs, there is significant difference to normal version when the data bigger than buffer pool (right graph shows CPU usage) The workload emulates TPC-C and has a same characteristic to DBT-2 (it is not DBT-2, but custom scripts, we will publish them eventually). There are no del
まいなーずめじゃー:x264 デコード負荷を軽減するために - livedoor Blog（ブログ）
さてさて、ニコニコ動画の H.264/AVC （ MP4 ）で「動画がカクついて見れない」というコメントに対応するべく始めた、x264 でデコード負荷を抑えながら高画質を目指すエンコード設定を探求する旅。出立から２ヶ月以上が経ち、そろそろ大詰めを迎えています。 ニコニコ動画にはビットレート制限があるのでマルチパスによるレート制御を使います。なので、第１パスの高速化についての実験成果も利用できます。やったね！ まあマルチパスをしないでレート制御ができれば最善なのですけど、それは無い物ねだりです。 そんなこんなでエンコード設定のギリギリのところをガンガンに攻めていきます。動画職人の腕の見せ所です。とりあえず現時点で僕が実際に投稿した動画に使った設定とそのログについて紹介し、解説を書いてみました。 前回よりも動きが速くなって、実験にはもってこいですね。本当に他の方が投稿したソニックの動画で
Athlon x2 4850e | teltelの日記 | スラド
買ってみた。本来、amd 780G と組み合わせて実家用に作ってた pc 用だったはずなんだけど。 とりあえず、ベンチマークがわりに ml115 に載せた。 もともと載ってたのは、Athlon x2 5000+ BE で、TDP65W のやつ。ステッピング G1(?かな)。 4850e は、TDP45W で、ステッピングは G2 になっている。 あっさり起動。残念ながら、ml115 の BIOS では、正確に認識されていない。 もっとも、5000+ BE も、電圧設定とか倍率がどのくらい反映されているのか判らなかったけど。 消費電力は CentOS 5 でアイドル時には、65W くらい。5000+ では 85W くらいあった気がする。 tanpaku を走らせて、全力運転のときの消費電力は 129W → 108W 。 計算力は、boinc_cmd --run_benchmarks で 19
95. テンプレート・エンジンSimplateを使ってみよう
PHPのテンプレート・エンジンではSmartyが有名です。SimplateはSmartyテンプレート・エンジンを参考にして、PHP extensionとして動作するようにしたテンプレート・エンジンです。Smartyに比べて機能は制限されますが、非常に高速に動作します。もし Webページへのアクセス速度を向上させたいのなら、Simplateを使ってみてはいかがでしょうか。 まずは、こちらからSimplateをダウンロードし、インストールしてみましょう。各環境に合わせてコンパイル等を行い、php.iniファイルでextensionとして読み込みます。なお、上記サイトではWindows用DLLファイル、Linux用RPMなどをダウンロード可能なサイトも紹介されています。INIファイルでは、以下のような記述になります。 Windows extension=php_simplate.dll Linu
あるプロセスが利用しているメモリサイズを procfs 経由で調べる - naoyaのはてなダイアリー
お題は「あるプロセスがどの程度の物理メモリを利用したかを知りたい」です。 手っとりばやく知りたいときは top や ps などで調べると良いでしょうか。例えば手元の coLinux で top して M キーでソートすると emacs のプロセスが最もメモリを使っているようです。 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1923 naoya 18 0 23120 19m 3096 S 0.0 2.0 0:55.40 emacsメモリサイズは VIRT と RES がありますが、VIRT は Virtual の略で仮想メモリ領域のサイズ、RES が Resident の略で、実際に使用している物理メモリ領域のサイズ。19MB ほど使っているようです。この emacs のプロセスが利用するメモリ領域はざっくり 20MB 程度と
masuidrive on rails - RailsアプリをチューニングするならNew Relic RPM
Photo by Riverman72 あとで自分メモを書こうと思うけど、先に一言。 37signalsも使っているといううたい文句に惹かれて試してみた、Railsのパフォーマンス記録ツール/サービスNew Relic RPM(Rails Performance Management)が、すばらしい。 RPMは開発時用のDeveloperと、実機用のProductionのが二つあり、まだ開発時用のDeveloperモードしか試してはいないんだけど、専用の管理画面で、アクションを実行時のメソッド単位の実行時間、生成されるSQL、SQLの実行時間やインデックスの利用状況などが非常に簡単に把握できます。 Railsで開発している人なら、下のムービーを見れば、そのすごさが分かるはず。 RPM developerのデモ動画 | RPM production のデモ動画 いまこれを使って、PhotoS
memcachedを知り尽くす 記事一覧 | gihyo.jp
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Wow HHVM is fast...too bad it doesn’t run my code
How Percona diagnoses MySQL server stalls
SSD Deployment Strategies for MySQL
Evaluating IO subsystem performance for MySQL Needs
株式会社スタイルズ
HugeDomains.com