バリバリチューニングするぜ！Webシステムのパフォーマンスを争った一日―第1回チューニンガソン開催 | gihyo.jp
※ID名は申し込みサイトから引用 1位、methane氏 2位、toshiak_netmark氏 3位、yamaji・tottokugチーム 4位、jun_kanzaki・nntatanoチーム 5位、kazuho氏 6位、goodoo氏 7位、riywo氏 8位、najeira氏 9位、kamipo氏 10位、Ryoutarou Setou氏 APCによるチューニングやPHP自体の再コンパイル 結果発表のあと、各チームからのチューニングのポイント、また、司会進行の山崎氏、クラウドスポンサーAmazon Data Services Japan K.K.の玉川憲氏からの公表が行われました。 優勝したmethane氏は、 ボトルネックの確認をした上で、ちょうど直前に仕入れた情報の「PHP5.4」を導入することを決めたそうで、phpinfoに記載されているconfigureオプションをベースにビ
たった3秒でInnoDBのデータローディングが快適になるライフハック
MySQLに限った話ではないが、データベース管理システムに大量のデータを投入するのは時間が掛かり大変苦痛を伴う作業である。劇的に効能があるわけではないが、MySQLを利用しているとき、特にInnoDBを使っている場合にはデータの投入を高速化するためにいくつかテクニックがあるので紹介しよう。皆さんの作業時間が短縮され、少しでも早く帰路に着いたりサービスインさせたりという形でお役に立てれば幸いである。ちなみに、タイトルはネタであるのだが、もし本当に3秒で以下の全ての設定を行えた人が居たら教えて頂きたい！ ログファイルサイズの調整データ投入時に限った話ではないが、ログファイルサイズを調整するのは更新性能にとって非常に重要なファクターである。バッファプールのサイズが重要なことに代わりはないが、同じぐらいログファイルのサイズも重要である。InnoDBはログファイルを使い切ってしまうと、バッファプール
Javaメモリ、GCチューニングとそれにまつわるトラブル対応手順まとめ - 日記のような何か
GC周りでトラブルシューティングした際の経験や、Web等で調べたことをまとめてみる。 前提 ・JVMは、Sun Javaを想定。(他は使ったことないです。。。) ・Sun Java 1.5-1.6を想定。 目標 マイナーGC、Full GCそれぞれが頻発することなく、かつそれぞれの実行時間を1秒未満に抑えること。 マイナーGCは1秒未満どころではなく、もっと短くなるべき。どれくらいが理想かは？(0.1秒未満ぐらいを目指したい？) 連続した負荷状態(想定されるピークアクセス)でもOutOfMemoryErrorが発生しないこと。 理想的な状態は、上記に加えて、Full GCの発生が低頻度であること。 具体的には、できるだけマイナーGCで短命オブジェクト(1回使ったらもう使わないようなオブジェクト。逆にセッションオブジェクト等は長命オブジェクトとなる)を破棄させて、短命オブジェクトが、Tenu
Googleらしく数値にこだわるWebサイト最適化Firefoxアドオン·Page Speed MOONGIFT
CGM系のサービスでは、Webページの表示速度には徹底的にこだわる必要がある。ちょっととした遅延がユーザのストレスを生み、徐々に心がはなれていく可能性を生んでしまう。最もそれを知っているのがGoogleだろう。 数値による改善点の指摘を行ってくれる 彼らの徹底的な表示速度へのこだわりは初期の頃から今もなお続いている（GoogleドキュメントなどのWebアプリケーションはどうかと思うが）。そんな彼らの表示速度へのこだわりが作り上げたのがPage Speedだ。 今回紹介するオープンソース・ソフトウェアはPage Speed、Google製のFirebugプラグインだ。 Page Speedは表示しているWebサイトの表示に関する問題点、改善点を洗い出してくれるFirefoxアドオンだ。類似のソフトウェアとしてYSlowが知られている。YSlowがA〜Fの判定だったのに対して、Page Spe
［データベース設計編］安易なパーティション分割をしてはいけない
主要なRDBMS製品には「パーティション分割機能」が備わっている。この機能は性能向上に効果的な半面，作業を煩雑にするケースもあるので，安易な利用は禁物である。 テーブルのパーティション分割とは，一つのテーブルを，物理的に「パーティション・テーブル1」「パーティション・テーブル2」のように複数に分割する機能である。テーブルを分割したとしても，アプリケーションからは元の一つのテーブル（論理的なテーブル）に見えるので，そのテーブルにアクセスするSQL文を変更する必要はない。 検索条件によっては，特定のパーティション・テーブルだけを検索するだけで済む。大きな（論理的な）テーブルを検索しなくてもよいので，レコード数が多数ある場合，うまく分割すれば性能向上を期待できる。また，パーティション単位でデータを削除したり，バックアップしたりすることが可能なので，運用の効率化を図ることが可能になる。 パーティシ
パフォーマンスチューニングする時の基礎の基礎 - 宇宙行きたい
みんなパフォーマンスチューニングの環境とかってどうやってるのかなぁと 思ったので書いてみますた． 全然専門外なのでまったく自信無いですが，僕はこうやってるよって事で まずは普通に実装 最初からパフォーマンスを気にして書いちゃうと， 何が有効で何があまり有効でないかわからなくなっちゃうので， とりあえず普通に実装する． (ifelse より switch の方が早いとかやっても微々たるものだし) もちろん，後々のために TDD でやっておく． 計測環境を作る テストケースとして記載する 重い処理を探すために，100回くらい繰り返して実行して 平均を見れるようにする． Java の実行時最適化とかの影響もあると思うので， 最初の一回の時間と平均を見れるようにする． assert も書いておくと，何秒以内を目指すのかが， 残せるので書いておく． StopWatch stopWatch = new
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
日本語版 : IBM Bluemix
