なぜ、SQLは重たくなるのか？──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 - エンジニアHub｜Webエンジニアのキャリアを考える！
なぜ、SQLは重たくなるのか？──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 『SQLパフォーマンス詳解』の翻訳者の松浦隼人さんに、8つの「SQLが重たくなる原因とその対策」を聞きました。システムのボトルネックになるような「問題のあるSQL」を回避するノウハウを学びましょう。 データの操作や定義をする言語「SQL」は、どのような領域を担うエンジニアにとっても必修科目です。しかし、その仕様をきちんと理解し、パフォーマンスに優れたSQLを書ける方はそれほど多くありません。問題のあるSQLを書いてしまい、知らぬ間にそれがシステムのボトルネックになってしまう事態はよく発生します。 では、どうすればそうした事態を回避できるのでしょうか？ そのノウハウを学ぶため、今回は『SQLパフォーマンス詳解』の翻訳者であり、自身もエンジニアでもある松浦隼人（まつうら・はやと／@dblmkt）さんに8つ
例えば GC を止める・Ruby ウェブアプリケーションの高速化 - 2nd life (移転しました)
最近クックパッドでは、アプリケーションサーバの大半が Rails 2.3 から Rails 3 に置き換わったのですが*1、リリース前のベンチマークの時点ではあまりパフォーマンスが出ず四苦八苦していました。具体的には Rails 2.3 の時と比べ MRI 1.8.7 だとレスポンスタムが200%ぐらい遅い結果でした。Rails 3 になって実装が Merb core を取り入れ疎結合で綺麗になった反面、より多くのオブジェクトと・メモリを利用する様になった影響かと思います。 そこで Ruby インタプリタの変更*2を行い検証をしたところ MRI 1.8.7 (Rails 2.3と比べ) 約200%遅い MRI 1.8.7 -> Ruby Enterprise Edition 1.8.7 2011.03 (tcmalloc 無効) 約180%低速 MRI 1.8.7 -> Ruby Ente
Hbaseのキャッシュ設定についてのTwitterのログ - Guutaraの日記
Twitterで、@tatsuya6502(Tatsuya Kawano (@tatsuya6502) | Twitter)さんが、色々、教えてくれていたので 揮発性の頭脳としては、忘備録として書いておかなくては。。 補足：http://jp.hmaster.info/で、色々な資料を公開されています。 最初は、キャッシュ設定の例を教えてくれていた。 tatsuya6502. @yutuki_r 今朝の HBase のキャッシュ関連の件ですが、僕のおすすめの基本設定を教えます ( 2010-04-23 01:04:50 )tatsuya6502. @yutuki_r まず、hbase-env.shで、 HBASE_HEAPSIZEを最低でも2000に設定してください。これにより、-XX:+UseConcMarkSweepGCが有効に働いて、ガベージコレクションの影響を受けにくくなります (
Cacoo - Web上で図の作成とリアルタイムコラボレーション
Online diagramming tool for collaborating on wireframes, flowcharts, and more
IEでのテキストノード走査の高速化 - os0x.blog
に釣られて。 HatenaStar.js 1380 行目 テキストノード走査 一番のボトルネックはやはりここですね。IEなので、こんな感じでベタに計測。 makeTextNodes: function(c) { if (c.textNodes || c.textNodePositions || c.documentText) return; if (Ten.Highlight.highlighted) Ten.Highlight.highlighted.hide(); c.textNodes = []; c.textNodePositions = []; var isIE = navigator.userAgent.indexOf('MSIE') != -1; var texts = []; var pos = 0; var st = new Date*1; (function(node,
2007-09-12
MySQLユーザーズカンファレンス2007 ２日目のリアルタイムレポートです。 MTVでMySQLをどう使っているか？ MTV JAPAN patrick Bolduan, 開発環境でかなり使っている オープンソースを利用していきたい 使いやすい。MySQLはフリーなので迅速に仕事ができる。ベンダーと交渉がいらない。ダウンロードしてすぐ使える 開発環境をロールアウトしてプロダクションで使えるのがよい なぜMySQLを使うことにしたか？ MTV JAPAN patrick Bolduan, 個人的に他のオープンソースとともに８〜９年使っていた MySQLに親しんでいた。MTVに移ってからもそれを使い続けたかった 安定性、パフォーマンス、使いやすさについて、MTVの例についてどのように考えているか MySQL AB Monty, もう使っていたということで追加努力が必要なかった 一番は使いやす
最短かつ最速にアクセスする「DB高速化技術」（前編）：ITpro
ポイント ・高度なインデックスやジョインを利用し，最短経路でデータにアクセス ・メモリー不足を自律的に解消し，キャッシュのヒット率を高める ・インメモリーDBは全データをメモリーで処理し，高速化を図る 目的地に早く到着したいなら，最短の経路を最速で行けばよい。これはデータベース（DB）でも同様だ（図1）。インデックスなどを使ってデータへの最短経路を見つけ，メモリー・アクセスを増やして，最速でたどり着く。DBにはそんな技術が詰まっている。 図1●データベース高速化技術のポイント ビットマップ・インデックスなどを使い、データにたどり着く最短の道を選ぶ。また、できるだけメモリーにデータをキャッシュさせておくことで、アクセスのスピードを上げる、という二つのポイントがある [画像のクリックで拡大表示] 以下では，（1）データにたどり着く最短の道を選ぶ仕組みと，（2）アクセスのスピードを上げる仕組みの
Webサイトをスピードアップさせる13のルール - Do You PHP はてブロ
元ネタは、Yahoo! DEVELOPER NETWORKの記事です。 Best Practices for Speeding Up Your Web Site - Yahoo Developer Network 全体的にWebアプリケーション自体ではなく、それ以外のレイヤでどうすればいいか？みたいな話になっています。 で、早速ざっくりと訳してまとめてみました。間違いがあれば指摘してください ;-) 1. HTTPリクエストの回数を減らす レスポンス時間の80%はフロントエンドで費やされるので、画像やスタイルシート、javascript、Flashなど、ページに含まれる部品の数を減らす。以下、具体的な方法。 クライアントサイドマップ：サイズも分割した場合と比べて変わらないし、HTTPリクエストを減らすことができる。ただし、座標定義が面倒 CSS Sprites cakephp.orgの左に
Yahoo!製JavaScriptコンプレッサ"YUI Compressor"登場、高い圧縮率と安全性 | エンタープライズ | マイコミジャーナル
Yahoo!, Julien Lecomte氏は13日(米国時間)、自身のブログにおいてJavaScriptを圧縮するためのアプリケーション「YUI Compressor(The Yahoo! JavaScript Compressor)」を発表した。YUI CompressorはJavaで開発されたJavaScriptソースコードの圧縮アプリケーション。 Yahoo! Exceptional Performance Teamの調査によると、Yahoo!ユーザの40 - 60%がエンプティキャッシュの経験を持っているとしており、またすべてのページビューのうち20%程度がエンプティキャッシュのまま終了しているという。こうした調査結果から、Webページを可能な限り軽量に保持することが重要だと同氏は同ブログにおいて説明している。これを実現するひとつの方法としてJavaScriptを圧縮するという
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Linuxチューニング ---目次：ITpro