クラウドのレスポンスはそれぞれの地域やサービスによって様々です。
本格的にクラウドのレスポンスを測定する前に、リサーチとして以下のサイトを確認してみては如何でしょうか?
海外展開する場合にもユーザーへのレスポンスでサービスレベルを計測出来るので、
指標の一つとして参考になるかと思います。

IIJ GIO記事

このサイトはCompuware社が運営しており、Gomezパフォーマンスネットワークを使って各IaaS, PaaSに対する
レスポンスタイムと稼働率の測定を行っています。
具体的にレスポンスタイムを取るやり方は、全世界の主要都市(30都市のうちアメリカが18都市ですが)に配置された
測定箇所から定期的に各IaaS, PaaS上に作ったサイトへアクセスし、そのレスポンスタイムを計測するというものです。
60秒以上応答がなければダウンしているとみなします。この時、IaaS、PaaS上にはCloudSleuthが模擬ECサイトを構築し、
まずは40枚程度のサムネイル画像を表示させ、その中から1つの商品をクリックして大きな画像を表示するという
2つの動作が完了するまでの時間を計測しているとの事

Global Provider View

Cloudsleuth Applications

Cloudsleuth Response

Cloudsleuth Response

Cloudsleuth Chart

Cloudsleuth Response Tables

Cloudsleuth Response Tables

Cloudsleuth Availability

Cloudsleuth Availability


コンパイルしたファイルをCacheして、phpの動作を速くする
APC(Alternative PHP Cache)。
IISでコンパイル済みASP、ASPX等をCacheするのと同じような設定という認識。

http://php.net/manual/ja/book.apc.php

[root@ip-xxxxxxxxx ec2-user]# yum install php-pear php-devel http-devel
Loaded plugins: fastestmirror, priorities, security, update-motd
Loading mirror speeds from cached hostfile
* amzn-main: packages.ap-northeast-1.amazonaws.com
* amzn-updates: packages.ap-northeast-1.amazonaws.com
Setting up Install Process
No package http-devel available.
Resolving Dependencies
–> Running transaction check
—> Package php-devel.x86_64 0:5.3.10-1.18.amzn1 will be installed
–> Processing Dependency: autoconf for package: php-devel-5.3.10-1.18.amzn1.x86_64
–> Processing Dependency: automake for package: php-devel-5.3.10-1.18.amzn1.x86_64
—> Package php-pear.noarch 1:1.9.4-4.8.amzn1 will be installed
–> Running transaction check
—> Package autoconf.noarch 0:2.63-5.1.7.amzn1 will be installed
—> Package automake.noarch 0:1.11.1-2.9.amzn1 will be installed
–> Finished Dependency Resolution

その他、gcc,make,PHP dev,apache dev,pcre,apxs関係など
不足していたパッケージインストール。

[root@ip-xxxxxxxxx ec2-user]# pecl install APC
downloading APC-3.1.9.tgz …
Starting to download APC-3.1.9.tgz (155,540 bytes)
……………………………done: 155,540 bytes
54 source files, building
running: phpize
Configuring for:
PHP Api Version: 20090626
Zend Module Api No: 20090626
Zend Extension Api No: 220090626
config.m4:180: warning: AC_CACHE_VAL(PHP_APC_GCC_ATOMICS, …): suspicious cache-id, must contain _cv_ to be cached
../../lib/autoconf/general.m4:1974: AC_CACHE_VAL is expanded from…
../../lib/autoconf/general.m4:1994: AC_CACHE_CHECK is expanded from…
config.m4:180: the top level
config.m4:180: warning: AC_CACHE_VAL(PHP_APC_GCC_ATOMICS, …): suspicious cache-id, must contain _cv_ to be cached
../../lib/autoconf/general.m4:1974: AC_CACHE_VAL is expanded from…
../../lib/autoconf/general.m4:1994: AC_CACHE_CHECK is expanded from…
config.m4:180: the top level
Enable internal debugging in APC [no] :
Enable per request file info about files used from the APC cache [no] :
Enable spin locks (EXPERIMENTAL) [no] :
Enable memory protection (EXPERIMENTAL) [no] :
Enable pthread mutexes (default) [yes] :
Enable pthread read/write locks (EXPERIMENTAL) [no] :
building in /var/tmp/pear-build-rootBND1Ww/APC-3.1.9

…… 省略

Build process completed successfully
Installing ‘/usr/lib64/php/modules/apc.so’
Installing ‘/usr/include/php/ext/apc/apc_serializer.h’
install ok: channel://pecl.php.net/APC-3.1.9
configuration option “php_ini” is not set to php.ini location
You should add “extension=apc.so” to php.ini

[root@ip-xxxxxxxxx ec2-user]# echo “extension=apc.so” > /etc/php.d/apc.ini
[root@ip-xxxxxxxxx ec2-user]# pecl list
Installed packages, channel pecl.php.net:
=========================================
Package Version State
APC 3.1.9 stable
[root@ip-xxxxxxxxx ec2-user]#

[root@ip-xxxxxxxxx ec2-user]# /etc/init.d/httpd restart
Stopping httpd: [ OK ]
Starting httpd: [ OK ]
[root@ip-xxxxxxxxx ec2-user]#

APCの状況確認用ページ 「httpでアクセス出来るところにコピー」
[root@ip-xxxxxxxxx ec2-user]# ls -l /usr/share/pear/apc.php
-rw-r–r– 1 root root 46148 Apr 7 09:17 /usr/share/pear/apc.php
[root@ip-xxxxxxxxx ec2-user]#

APC

APC

[ec2-user@ip-xxxxxxxxx ec2-user]$ php -i | grep apc
Additional .ini files parsed => /etc/php.d/apc.ini,
apc
apc.cache_by_default => On => On
apc.canonicalize => On => On
apc.coredump_unmap => Off => Off
apc.enable_cli => Off => Off
apc.enabled => On => On
apc.file_md5 => Off => Off
apc.file_update_protection => 2 => 2
apc.filters => no value => no value
apc.gc_ttl => 3600 => 3600
apc.include_once_override => Off => Off
apc.lazy_classes => Off => Off
apc.lazy_functions => Off => Off
apc.max_file_size => 1M => 1M
apc.mmap_file_mask => no value => no value
apc.num_files_hint => 1000 => 1000
apc.preload_path => no value => no value
apc.report_autofilter => Off => Off
apc.rfc1867 => Off => Off
apc.rfc1867_freq => 0 => 0
apc.rfc1867_name => APC_UPLOAD_PROGRESS => APC_UPLOAD_PROGRESS
apc.rfc1867_prefix => upload_ => upload_
apc.rfc1867_ttl => 3600 => 3600
apc.serializer => default => default
apc.shm_segments => 1 => 1
apc.shm_size => 32M => 32M
apc.slam_defense => On => On
apc.stat => On => On
apc.stat_ctime => Off => Off
apc.ttl => 0 => 0
apc.use_request_time => On => On
apc.user_entries_hint => 4096 => 4096
apc.user_ttl => 0 => 0
apc.write_lock => On => On
[ec2-user@ip-xxxxxxxxx ec2-user]$


INNODBのデータファイルは,後から追加することが可能。その場合には,innodb_data_file_pathの最後に
追加すれば可能です。また,最後が自動拡張(autoextend)の場合には,自動拡張(autoextend)指定と
なっているデータファイルの容量を初期値+8MB倍数で近い値に指定すれば容量固定のデータファイルと
して運用でき,その後に新たなデータファイルを追加できる。
運用開始後に削除やサイズの変更はできない。その場合には,InnoDBの再構築が必要となる。

innodb_grep

innodb_log_files_in_group=2の設定を変更して、innodb_log_files_in_group = 3に設定変更してみました。

————————————————————————————
[root@colinux DB01]# grep -v ^# /etc/my.cnf | grep innodb
innodb_data_home_dir = /usr/local/mysql/data/
innodb_data_file_path = ibdata1:10M;ibdata2:30M:autoextend:max:60M
innodb_file_per_table
innodb_log_group_home_dir = /usr/local/mysql/data/
innodb_log_file_size = 8M
innodb_buffer_pool_size = 16M
innodb_log_buffer_size = 32M
innodb_log_files_in_group = 3
[root@colinux DB01]# l
————————————————————————————

innodb_grep_option

ログのオプション追加後

[root@colinux DB01]# ls -l /usr/local/mysql/data/ib*
-rw-rw—- 1 mysql mysql 8388608 2009-07-20 23:31 /usr/local/mysql/data/ib_logfile0
-rw-rw—- 1 mysql mysql 8388608 2009-03-18 00:55 /usr/local/mysql/data/ib_logfile1
-rw-rw—- 1 mysql mysql 0 2009-07-20 23:31 /usr/local/mysql/data/ib_logfile2
-rwxrwxrwx 1 root mysql 10485760 2009-07-20 23:31 /usr/local/mysql/data/ibdata1
-rw-rw—- 1 mysql mysql 31457280 2009-07-20 23:31 /usr/local/mysql/data/ibdata2
[root@colinux DB01]#

logtuika

既にトランザクションログが存在していて,innodb_log_file_sizeの設定値の方が大きい場合,
サイズアンマッチでInnoDBが起動しないので注意が必要だ。
トランザクションログは,サイズを大きくすることによって,ローテーション(チェックポイント)の発生回数
を減らすことが可能だ。トランザクションログのデフォルトは,10MBが2個であるから,
大量のデータ更新を行う場合などは拡大することを薦める。

以前社内で運用していたオラクルのREDO LOGは、1024Mを3つ程作成して利用していました。
ここら辺はパフォーマンスやデータ保護の観点で考えれば良いかと思います。

MySQL は .frm ファイル内のテーブルのデータ ディレクトリ情報をデータベース ディレクトリに格納します。
これは全ての MySQL ストレージ エンジンに言える事です。しかし全ての InnoDB テーブルも
テーブルスペースの内側にある InnoDB 内部データ ディレクトリ内にそれ自体のエントリ
を持っています。MySQL がテーブルやデータベースをドロップする時、それは .frm ファイルと InnoDB データ
ディレクトリ内の対応するエントリの両方を削除する必要があります。
これが、単に .frm ファイルを移動するだけで InnoDB テーブルをデータベース間で移動する事が
できない理由です。

InnoDBのクラスタードインデックスの値としては、プライマリキーが使用されるため、プライマリキーの
値順にレコードが並んだ構成のテーブルとなります。プライマリキーが定義されていないテーブルの場合は、
InnoDBが自動的に6バイトのローIDと呼ぶフィールドをレコードに追加し、このローID を用いて
クラスタードインデックスを構成します。

全ての InnoDB テーブルは、行のデータが格納されている clustered index と呼ばれる特別な
インデックスを持っています。もし PRIMARY KEY をテーブル上で定義したら、主キーのインデックスは
集合インデックスになります。

InnoDB では、非集合インデックス(セカンダリ インデックスとも呼ばれる)内のレコードは、
行に対して主キー値も含んでいます
InnoDB は、この主キー値を集合インデックスから行を検索するのに利用します。
もし主キーが長いと、セカンダリ インデックスがより多くの領域を利用する事に注意しなければならない。

————————————————————
InnoDBのトランザクション機能
————————————————————
※ 読み込み一貫性機能を持つ
※ ロック単位はレコード単位で、ロックのエスカレーションがない
※トランザクションの分離レベルは4つ持つ
━ リードアンコミッティド
━ リードコミッティド
━ リピータブルリード
━ シリアライザブル

InnoDBの読み込み一貫性機能の仕組みは、変更前データをロールバックセグメントに格納することに
よって実現しています。このロールバックセグメント(RBS)は、テーブルスペース内に格納されます。

ロックエスカレーションが発生しない理由は、少ないリソースを個々のロックを実現しているため。
※ 実際には5.0.13以前では、ロックエスカレーションが起こるようです。

InnoDB は、短い方の文字列の残りの長さが領域で詰められたかのように扱われるように、
長さの異なる CHAR と VARCHAR 文字列を比較します

InnoDB テーブルの物理的なレコード構造は、テーブルが作成された時に指定された行フォーマットによって
決まります。MySQL 5.1 ではデフォルトで InnoDB が

    COMPACT フォーマット

を利用しますが、
MySQL の古いバージョンとの

    互換性を保持する為にはREDUNDANT

フォーマットが有効です。

    参考サイト

13.5.13. InnoDB テーブルとインデックス構造

13.5.13.4. 物理的なレコード構造