IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.

tmaesakaさんがやってくれました。 ずいぶん前からSQLのベンチマークを測定するのに使いやすいプログラムないかなーと思ってました。個人的にはmysqlslapというのを使ってたのですが、幾らか気に入らない所があったりコマンドラインオプションが複雑で毎回 --help を読んだりしていました。余計な機能なんかなくて、指定したSQLを高速にくりかえしてくれる物が欲しいなぁって思ってたんです。 とあるIRCでこの前、tmaesakaさんから「いま作ってる」という話を聞いて、いろいろ要望を言ってたんですが、ついさっきチュートリアルが公開されました。速いw 名前はskyload。とても小さく、実装コードだと800行程度です。しかもオプションが少ないので使い方が単純です。試しに適当な INSERT の速度を測ってみました。 $ skyload --server=localhost --mysql

原文(投稿日：2009/6/26)へのリンク Twitterサービスチームの主任エンジニアであり、主に最適化とスケーラビリティを担当しているEvan Weaver氏が、QCon London 2009においてTwitterのアーキテクチャ、とりわけ過去一年にわたって行ってきたウェブサイトの最適化について語った。 Twitterで使われているツールの多くはオープンソースである。そのスタックは、フロントサイドにRails、中間のビジネス層にC、Scala、Java、データストアとしてMySQLを利用してつくられている。すべてがRAM上に保持されており、データベースは単なるバックアップである。Railsのフロントエンドはレンダリング、複合キャッシュ、DBクエリ、同期的挿入を扱う。このフロントエンドは、MySQLクライアント、Memcachedクライアント、JSONクライアントなどの、多くはCで書

GoogleがWeb全体のスピードアップにいよいよ本格的に着手, 一社だけではできないと強調 からリンクのあった、 http://code.google.com/intl/ja/speed/articles/optimizing-javascript.html が日本語かと思ったら日本語じゃなかった・・・・。 いやー、意外とというか文字列については、全然知らんかった。 Closureって便利だし、「おぉ〜俺って使ってるジャン」みたいな気になれるからついつい使っちゃうんだけど、高コストなのね・・・・。反省。 ということで、超適当翻訳。どっかの誰かが書いてるかも。 前おき 著者: Google Chromeのエンジニア Gregory Baker, Software Engineer on GMail & Erik Arvidsson 推奨される経験：JavaScriptの実践的な知識 クライ

ドットインストール代表のライフハックブログ

前回のエントリーデータベースを用いたセッションデータ管理についてで、MySQL とメモリの関係について良く分からない部分があると書きました。 実はここに関する理解はかなり曖昧な部分があって、調査して追記します。とくにメモリ利用量について。mysqld のプロセスが利用できるメモリの上限が、32bit OS の場合は3G 程度ということは、innodb_buffer_pool_size もこの制限を受け、これについての警告が、先に紹介したリファレンスマニュアルのものという理解だけどいいのだろうかというのが1つ。 2 つ目は、この理解があっているとすると、4G 以上のクラスのメモリをつんだサーバをDB サーバとして利用する場合、64 bit OS でないとリソースの有効活用ができないか。それとも、先に書いたとおり、OS レベルのキャッシュとして利用できるから、結果としてデータファイルを読み込む

Web アプリケーションとは切っても切れないセッション機構。DB ベースでセッション管理を行なって得られた知見と、それを元に考察した結果をまとめてみます。 セッションデータの特性 DB で管理される他のデータに比べ、セッションデータはかなり特殊です。主な特徴は次のような感じ。 データが増加するのが速い 定期的な削除が必要 頻繁に更新される リクエスト毎に読みに行く必要がある このデータを読めないとアプリケーション全体にアクセスできない アクセス頻度が高いということです。あと、1つ目の特徴からセッションデータについては意識的に管理してやる必要があります。 現在の環境 アプリケーションの領域が少し特殊で、セッションデータがやたらたまります(ユーザ数何百万のサービスとかそういうのではないです)。 RDBMS MySQL 4.0.22 ストレージエンジン InnoDB レコード数 6千万 テータサ

みんなパフォーマンスチューニングの環境とかってどうやってるのかなぁと 思ったので書いてみますた． 全然専門外なのでまったく自信無いですが，僕はこうやってるよって事で まずは普通に実装 最初からパフォーマンスを気にして書いちゃうと， 何が有効で何があまり有効でないかわからなくなっちゃうので， とりあえず普通に実装する． (ifelse より switch の方が早いとかやっても微々たるものだし) もちろん，後々のために TDD でやっておく． 計測環境を作る テストケースとして記載する 重い処理を探すために，100回くらい繰り返して実行して 平均を見れるようにする． Java の実行時最適化とかの影響もあると思うので， 最初の一回の時間と平均を見れるようにする． assert も書いておくと，何秒以内を目指すのかが， 残せるので書いておく． StopWatch stopWatch = new

Google が Google Code でオープンソースとして公開しているソフトウェアの解説シリーズ(前回のエントリ)の第 4 回です。今回は Performance tools について紹介します。この Performance tools は、実際に Google 社内で広く使われており、特に、C++ でテンプレートを使用するマルチスレッドアプリケーションを開発する際に役立ちます。Linux 環境を主に対象としています。 Performance tools とは? C や C++ でプログラムの書いたことのある多くの人は、「プログラムを高速化したいけれど、どこが一番のボトルネックか分からない」とか、「メモリリークがあるようだけれど、どこで発生しているか分からない」といった問題で苦しめられた経験が一度くらいはあると思います。もちろん、こうした問題の解決策として、アドホックにプログラムをチ

はじめに 現在のWebシステム開発・運用では、特に大規模化するシステムの安定稼働、パフォーマンスの向上、システムのスケールアップやスケールアウトの実現が求められます。また開発フェーズではこれまで以上の効率化に加えて、新しい技術的な取り組みを踏まえたシステム開発も必要となります。 本連載では、これらシステム開発者を取り巻く要求事項をどのように解決していけばよいのか、解決のためのソリューションとしてはどのようなものがあるのかについて、日立のAP（アプリケーション）サーバであるCosminexusを題材として取り上げながら解説していきます。連載第1回の今回は、多重度・流量制御を中心に、DB（データベース、I/O）のチューニング（最適化）などにも触れて解説します。 チューニングとは システム構築においては、CPUやメモリ容量など限りあるリソースを最大限に有効活用するとともに、機能要件を満たすレスポ

はじめに 現在のWebシステム開発・運用で踏まえるべき新しい技術的な取り組みについて、日立のアプリケーションサーバ（APサーバ）であるCosminexus（コズミネクサス）の製品群を題材として取り上げながら解説する本連載、前回は流量制御およびDB（I/O）の最適化について触れました。 第2回は、Java仮想マシン（Java VM）によるメモリ管理が主題です。Webシステムにおいては、JavaVMのメモリ管理機能であるガベージコレクション（GC）が性能劣化を引き起こすことが知られています。ここでは日立が開発したJava VMにおけるメモリ管理技術や、日本語処理の高速化を中心に解説します。 GCの基本的なしくみと問題点 GCとは、作業領域のうち使用済みの領域を破棄して空き領域を整列させるしくみのことです。Java VMでは、自身が管理するメモリ領域（ヒープ領域）において使用されなくなった領域の

東京エレクトロンデバイス CN事業統括本部は、米Akorri（アコーリ）と国内総代理店契約を結び、AkorriのIT性能管理ソフトウェア「BalancePoint」の国内販売開始を発表した。 BalancePointはアプリケーション・レスポンスを監視し、性能問題の分析やキャパシティ・プランニングを支援するツール。データベースなどのアプリケーション、OS、仮想化ソフトウェア、ストレージにそれぞれ管理アクセスをすることで、自動的に構成、利用、性能関連情報を収集する。 BalancePointは物理環境の管理支援も行えるが、特にターゲットとしているのは仮想化された環境。仮想マシンの動的な移動も発生するサーバ仮想化環境では、アプリケーション、仮想マシン、ハイパーバイザ、ストレージにおけるLUNやRAIDグループの接続関係を追跡し続けることが難しい。このため「思ったようなパフォーマンスが出ない」と

こうして見ると、仮に5分程度ライムラグがあってもさほど影響が無いものが多い、つまり毎度APIに問い合わせるのが無駄とも言えないでしょうか。（毎度通信すべきはなのは、上の表では「高」の部分のみ）。 そこで、APIから取ってきたデータ（XML）を少しの時間だけとっておくのはどうでしょう？（リアルタイム性が高いものや検索結果については毎度通信し、それ以外のものはキープしておき再利用）アクセスしてきたAさん、Bさん、Cさん・・・誰が見ても同じ内容ならなおさらみんなでシェアできれば、通信の数もそれにかかる時間も減るはずです。 このように一定時間データを溜めて再利用するシステムや行為を、キャッシュ(cache ※1)といいます。　どんな言語でも、こんな流れのロジックが書ければ実現できるでしょう。 if ( とっておいたXMLが賞味期限切れ ) { 捨てる; } if ( とっておいたXMLがある )