经常看到很多介绍安装php的文章中，提到安装一个eaccelerator加速php程序，我按照他们的需求安装了，确实能用了，可是经过我的压力测试，发现他确实没有实现那些文章所谓的加速功能，是我配置错了，还是具体哪有问题，下面介绍一下我的配置情况，对于php的安装，搜索引擎一搜索网上一大堆，我就不累赘了，现在说说我的安装和eaccelerator的过程
php安装软件及版本
nginx/0.8.7
php-5.2.8
eaccelerator-0.9.5.3
eaccelerator安装

/usr/local/bin/phpize
./configure --enable-eaccelerator=shared --with-php-config=/usr/local/php/bin/php-config
make
sudo make install

eaccelerator配置
分成两块，一块是采用eaccelerator加速的就在php.ini文件中加入如下内容

[eaccelerator]
extension_dir = "/usr/local/lib/php/extensions"
extension="/no-debug-non-zts-20060613/eaccelerator.so"
eaccelerator.shm_size="16"
eaccelerator.cache_dir="/tmp/eaccelerator_cache"
eaccelerator.enable="1"
eaccelerator.optimizer="1"
eaccelerator.check_mtime="1"
eaccelerator.debug="0"
eaccelerator.filter=""
eaccelerator.shm_max="0"
eaccelerator.shm_ttl="0"
eaccelerator.shm_prune_period="0"
eaccelerator.shm_only="0"
eaccelerator.compress="1"
eaccelerator.compress_level="9"

添加cache目录

mkdir /tmp/eaccelerator_cache

另一块就是初始化安装不配置任何参数进行测试
eaccelerator加速测试
ab -c 200 -n 10000 http://www.test.com/phpinfo.php
测试结果

Server Software: nginx/0.8.7
Server Hostname: www.test.com
Server Port: 80

Document Path: /test.php
Document Length: 25 bytes

Concurrency Level: 200
Time taken for tests: 1.523543 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Non-2xx responses: 10000
Total transferred: 2160000 bytes
HTML transferred: 250000 bytes
Requests per second: 6563.65 [#/sec] (mean)
Time per request: 30.471 [ms] (mean)
Time per request: 0.152 [ms] (mean, across all concurrent requests)
Transfer rate: 1384.27 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 1.8 0 15
Processing: 4 22 7.9 24 67
Waiting: 1 18 9.7 20 66
Total: 6 23 7.4 24 67

Percentage of the requests served within a certain time (ms)
50% 24
66% 24
75% 24
80% 25
90% 31
95% 32
98% 41
99% 61
100% 67 (longest request)

不采用eaccelerator加速测试
ab -c 200 -n 10000 http://www.test.com/phpinfo.php
测试结果

Server Software: nginx/0.8.7
Server Hostname: www.test.com
Server Port: 80

Document Path: /test.php
Document Length: 25 bytes

Concurrency Level: 200
Time taken for tests: 1.373767 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Non-2xx responses: 10011
Total transferred: 2162376 bytes
HTML transferred: 250275 bytes
Requests per second: 7279.25 [#/sec] (mean)
Time per request: 27.475 [ms] (mean)
Time per request: 0.137 [ms] (mean, across all concurrent requests)
Transfer rate: 1536.65 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 2 3.0 2 21
Processing: 4 24 11.4 23 94
Waiting: 2 17 12.9 15 93
Total: 5 26 11.1 26 94

Percentage of the requests served within a certain time (ms)
50% 26
66% 29
75% 31
80% 31
90% 32
95% 34
98% 83
99% 92
100% 94 (longest request)


结果说明：
通过ab的测试，从结果来看（只需要看黑体部分的内容就OK了），Requests per second（每秒事务数)，Time per request（平均事务响应时间），Time per request（每个请求实际运行时间的平均值），这3个值在不采用eaccelerator加速的情况下，性能更强
总结：
不知是我的配置和测试的问题？还是在新的php版本中eaccelerator确实出现兼容性问题？

当数据量比较小时我们会选择使用占用空间相对较小的char或varchar数据类型，当数据量相对较大时通常会选择blob或text数据类型来存储他们。他们都可以存储可变数量的文本数据，在TEXT或BLOB列的存储或检索过程中，不存在大小写转换。两者的区别在于，blob能保存存储二进制数据，比如相片，blob也没有字符集概念，并且排序和比较基于列值字节的数值值。TEXT列有一个字符集，并且根据字符集的校对规则对值进行排序和比较。有4种blob类型，分别为：TINYBLOB、BLOB、MEDIUMBLOB和LONGBLOB。它们只是可容纳值的最大长度不同。text类型也有相对应的4种数据类型，分别为：TINYTEXT、TEXT、MEDIUMTEXT和LONGTEXT。在大多数方面，可以将BLOB列视为能够足够大的VARBINARY列。同样，可以将TEXT列视为VARCHAR列。BLOB和TEXT在以下几个方面不同于VARBINARY和VARCHAR：
1、当保存或检索BLOB和TEXT列的值时不删除尾部空格。(这与VARBINARY和VARCHAR列相同）。
2、请注意比较时将用空格对TEXT进行扩充以适合比较的对象，正如CHAR和VARCHAR。
3、对于BLOB和TEXT列的索引，必须指定索引前缀的长度。对于CHAR和VARCHAR，前缀长度是可选的。
4、BLOB和TEXT列不能有 默认值。
当对blob和text数据类型执行大量删除操作时存在很到的性能问题，删除操作能给数据表格留下很大的的空洞，以后填入这些空洞的插入操作存在性能问题，下面通过一个具体事例来说明这个空洞问题。

mysql> create table t(id varchar(100), context text);
Query OK, 0 rows affected (0.02 sec)
mysql> insert into t values(1, repeat('beijing', 100)),(2, repeat('beijing', 100)),(3, repeat('beijing', 100));
Query OK, 3 rows affected (0.00 sec)
Records: 3 Duplicates: 0 Warnings: 0

再连续执行如下语句16次

mysql> insert into t select * from t;
Query OK, 196608 rows affected (1.20 sec)
Records: 196608 Duplicates: 0 Warnings: 0

退出mysql，在操作系统下查看mysql数据文件夹下的，t.MYD文件大小

[root@backup ~]# du -sh /usr/local/mysql/data/test/t*
12K /usr/local/mysql/data/test/t.frm
268M /usr/local/mysql/data/test/t.MYD
4.0K /usr/local/mysql/data/test/t.MYI

从上面看到数据文件大小为268M。
进入mysql中删除id为1的数据，通过以上数据插入操作，我们知道id为1的数据应该为总数据的1/3。

mysql> delete from t where id=1;
Query OK, 131072 rows affected (1.11 sec)

退出mysql，继续在操作系统下查看mysql数据文件夹下的，t.MYD文件大小

[root@backup ~]# du -sh /usr/local/mysql/data/test/t*
12K /usr/local/mysql/data/test/t.frm
268M /usr/local/mysql/data/test/t.MYD
4.0K /usr/local/mysql/data/test/t.MYI

从上面可以看到数据大小并没有发生变化，这就产生了上面所说的空洞，接下来通过optimize table对表进行碎片整理，避免空洞造成的性能问题

mysql> optimize table t;
+--------+----------+----------+----------+
| Table | Op | Msg_type | Msg_text |
+--------+----------+----------+----------+
| test.t | optimize | status | OK |
+--------+----------+----------+----------+
1 row in set (0.99 sec)

再次退出mysql，在操作系统下查看mysql数据文件夹下的，t.MYD文件大小

[root@backup ~]# du -sh /usr/local/mysql/data/test/t*
12K /usr/local/mysql/data/test/t.frm
179M /usr/local/mysql/data/test/t.MYD
4.0K /usr/local/mysql/data/test/t.MYI

可以发现表的数据文件变小了，说明空洞所占领的空间已经被回收。对于采用了blob字段或text字段的数据表格，建议定期对表格进行optimize table操作，避免因空洞带来的性能问题。
由于text和blob数据量大，对于text和blob数据类型的检索，一般不建议直接采用mysql对他们进行检索。同时建议吧text和blob数据列分离到单独的表中，这样避免text或blob数据删除所带来的性能问题。

也许在使用mysql创建数据表时经常有这样的疑问，是选择char还是varchar，text还是blob数据类型呢？其实选择什么都行，都能完成我们的需求，但是，选择好合适的数据类型不仅能节约磁盘空间还能提高访问速度达到mysql调优的目的。
1、char和varchar
char和varchar都能存储字符串，其中char是固定长度，varchar是可变长度字符类型。下面通过一个实例来来说明两者的数据存储的区别

mysql> create table c(c char(4), v varchar(4));
Query OK, 0 rows affected (0.03 sec)
mysql> insert into c values('ab ', 'ab ');
Query OK, 1 row affected(0.00 sec)

通过在mysql函数cancat，在字符的末尾添加字符的功能可以看出他的存储情况

mysql> select concat(c, '+'), concat(v, '+') from c;
+----------------+----------------+
| concat(c, '+') | concat(v, '+') |
+----------------+----------------+
| ab+ | ab + |
+----------------+----------------+
1 row in set (0.00 sec)

从上可以看出在mysql检索时通常会删除掉char数据类型的空格。
由于char是固定长度，所以他的处理速度比varchar要快得多，但是他比较消耗存储空间，程序还得考虑他末尾的空格问题对于那些长度变化不大，并且对查询速度有较高要求的数据可以考虑使用char数据类型来存储。
下面来说说在不同的存储引擎条件下两者的使用原则
1、myisam存储引擎：建议使用固定长度的char数据类型来代替可变长度的varchar数据类型
2、memory存储引擎：都使用固定长度的数据行存储，因此使用char或varchar都没有关系，两者都被当作char数据类型进行处理
3、innodb存储引擎：建议使用可变的varchar数据类型，理由：对于innodb数据表，内部的行存储格式没有区分固定长度和可变长度列（所有的数据行都指向数据列值的头指针），因此使用固定长度的char数据类型不一定比使用可变数据长度的数据类型性能好，因而，主要的性能因素是数据行使用的存储总量，由于char数据列占用的空间比varchar数据列要大，因此varchar存储的空间要小，对于磁盘io来说越小的空间，处理数据能力越强。

作为一名linux的sa，每天都会跟ssh终端打交道，选择配置好一个优秀的ssh终端工具对提高工作效率有很大的帮助。一般情况下有两种选择，一种是免费的putty和收费的SecureCRT。最初我选择的是免费putty，当我管理几台服务器时，确实是比较好的一种选择putty，不会记住用户名，密码，安全性好。在没有配置的情况下，putty的显示效果要比SecureCRT好。再者文件小，功能齐全，而且不需要安装，可以随时的打开使用。当我管理的不是几台linux服务器，而是几十台服务器后发现就不好了，每次都要输入IP地址，打开多台服务器时，不能作为tab显示，结果显示的窗口过多，当打开多个窗口是在任务栏上显示的标题不能标示对应打开的服务器，而是需要打开每个窗口去确认，确实不方便。而采用SecureCRT就没有这些问题。同时通过配置SecureCRT能够基本达到putty的显示效果，下面是我的配置SecureCRT的参数
1，配置终端类型，显示颜色
Options->SessionOptions ->Emulation,然后把Terminal类型改成xterm，并点中ANSI Color复选框。
2，配置字体，编码方式
字体设置：Options->SessionOptions->Appearance->font然后改成新宋体，文字大小设置为11号。
character改成utf-8的方式。
3，去掉显示的下划线
Options->SessionOptions->Appearance->Current color选择编辑，在新打开的窗口去掉show underline
4，vi中颜色显示效果
在打开的终端中，编辑/etc/profile 在文末添加如下内容
export TERM=xterm-color
添加完毕后执行如下内容，使之生效
source /etc/profile
同时用vi打开文件转入命令形式，输入如下命令
syntax on
如果是c语言的文件就接着输入set filetype=c，如果是jsp的话就输入，set filetype=jsp，对shell语言的话，不设置也能颜色显示，其它同理。就完成终端vi的颜色显示，不过遗憾的是对vi颜色显示支持不是很好，需要配置很多的系统参数。

DBM（DataBase Manager）的特征是：按键-值对的方式进行存储，使用hash进行查找，由于没有提供更高级的sql功能,它的效率远远超过传统的关系型数据库。现主流的dbm有:Berkeley DB（现属于oracle公司，是互联网部署最多的一款dbm），Gdbm（GNU Database Manager） QDBM: Quicker Database Manager，Tokyo cabinet，CDB：Constant Databases,Tokyo cabinet是基于QDBM再开发的一款DBM，它本身也只提供数据库引擎，所谓数据库引擎是指它提供了除SQL处理层以外的所有关系数据库的功能（如事务性（ACID）支持，数据存储，数据恢复等）。前面提到dbm的特征是一些键-值对的形式出现，那么Tokyo Cabinet作为一款dbm，它也不例外，怎么样才能实现跟普通的关系数据库一样的表格功能呢？Tokyo Cabinet的作者开发了一款Tokyo Tyrant的工具，可以采用它调用Tokyo Cabinet数据库引擎，实现跟管理数据库一样的数据库表格的功能，下面通过一个普通的员工信息表进行演示说明
表格内容如下

在普通的关系数据库mysql中建立这个表格的sql语句如下
create table staffs (
id int primary key,
name varchar(255),
sex enum ( 'male', 'female' ),
birthday date,
div varchar(255)
);

而根据上面所说的按键-值对方式进行存储，那么这样想的话，那不是得分成，几个db，分别是名字db，性别db，出生年月db和职务db，那这样的话表格的逻辑不是乱了吗！如果这样的话，估计没有几个人用，下面介绍采用tokyo tyrant的命令就可以做成这个表格，实现与普通关系型数据库提供的sql使用方式。
建立数据库
tctmgr create casket
插入数据

tctmgr put casket 1 "name" "张三" "sex" "male" \
"birthday" "19900101" "div" "brd,dev"
tctmgr put casket 5 "name" "李四" "sex" "female" \
"birthday" "19850523" "div" "dev"
tctmgr put casket 23 "name" "王五" "sex" "male" \
"birthday" "19881013" "div" "hr"

查询所有数据
tctmgr list -pv casket
--------
1 name 张三 sex male birthday 19900101 div brd,dev
5 name 李四 sex female birthday 19850523 div dev
23 name 王五 sex male birthday 19881013 div hr

条件查询
通过主键进行查询，查询用户id为23的职员信息
tctmgr get casket 23
--------
name 李四
sex female
birthday 19850523
div dev

通过不是主键进行查询

#查询以王开头的用户
tctmgr search -pv casket name STRBW "王"
-------
23 name 王五 sex male birthday 19881013 div hr
#查询以85年出生以后的男职员
tctmgr search -pv casket birthday NUMGE 19850101 sex STREQ "male"
--------
1 name 张三 sex male birthday 19900101 div brd,dev
23 name 王五 sex male birthday 19881013 div hr

附查询条件表达式（前面加~，相当于标准sql中的非）
* STREQ : 完全包含字符串，相当于标准sql中的where 字段=‘字符串’
* STRINC : 包含此字符串，相当于标准sql中like ‘*字符串*’
* STRBW : 以此字符串开头的内容，相当于标准sql中like ‘字符串*’
* STREW : 以此字符串结尾的内容，相当于标准sql中like ‘*字符串’
* STRAND : 包含在某区间内的内容，如标准sql中like ‘a-z’，那么他只能是a到z的字母
* STROR : 不包含在某区间内的内容，如标准sql中like ‘!a-z’，那么他只能是数字或其他的符号
* STRRX : 组合式结构，如标准sql中like “a“!b-m”#”
* NUMEQ : 数值大小一样 相当于标准sql中 where a=‘1’
* NUMGT : 数值大于某一值 相当于标准sql中 where a>‘1’
* NUMGE : 数值大于等于某一值 相当于标准sql中 where a>=‘1’
* NUMLT : 数值小于某一值 相当于标准sql中 where a<‘1’
* NUMLE : 数值小于某一值 相当于标准sql中 where a<=‘1’
* NUMBT : 数值处于某一数值区间，相当于标准sql中 where a> 1 and a < 10
* NUMOREQ : 数值不处于某一数值的区间，如果是a大于1，小于10的话，那这个表达式右边的内容应该相当于标准sql中 where a< 1 or a > 10
附排序
* STRASC : 按字面大小的升序排序
* STRDESC : 按字面大小的降序排序
* STRASC : 按数字大小的升序排序
* STRDESC : 按数字大小的降序排序
删除操作

tctmgr out casket 23
#确认结果
tctmgr list -pv casket
--------
1 name 张三 sex male birthday 19900101 div brd,dev
5 name 李四 sex female birthday 19850523 div dev


今天下午放在idc机房的机器无缘无故的就down掉了，打电话给机房的人要求重启，并要求告知原因，机房人告知机器没有打开，我把服务器上的日志分析了半天，发现没有任何down掉了日志，排除了机器故障，而处在同一个机柜里的服务都是好的，排除了供电故障，那么只有一种可能就是有人人为的把我的服务器的电源给拔掉了。我严重鄙视做这种事情的人。

在网上看到很多文章在介绍web站点的优化方案，确实有作用，但都是片面的单独从一个角度去写的一个优化方案，很少有人比较全面的写一个优化方案，几乎都是要不从web页面上讲优化的条条款款，要不单独的从服务器上讲优化的条条款款，要不从db上写优化的条条款款。但这些优化方案局限性很大，很少有文章能提到一个全面的优化方案，下面是我自己所理解的一点web站点优化方案，个人认为前端优化是最重要的。当你的一个页面很大，到了一个页面2M，你服务器端优化做得再好，也是空的，你能及时的响应用户的请求，但是国内的用户现在的一个带宽情况你应该知道，光打开一个也面要多久时间，同时你服务器端的带宽是多少，带宽能承受得多少个用户同时并发，算算就知道了。再如果一个页面链接请求几百个，你服务器端优化得再好，承受的并发单台也只能做到不到十万个并发连接，同时浏览器还有对同一域名的并发限制，多域名的话，查询dns也是需要时间的。而国内做前端做得好的不是很多，包括alex排名非常高的各大网站（去掉google,baidu，页面元素太少,它们也确实做得很好），几乎前端做得很烂，真正做得好的是美国yahoo网站，大家可以去看看他的做法。yahoo工程师写了web前端优化的34条建议可以去看看，同时通过yahoo工程师写的firefox插件yslow去分析优化结果及优化建议。
再一个就是后端db的优化，因为db的连接是有限的，当数据量达到一定得规模，及出现db大并发时，db应该也是一个最慢的，当一个不合理的sql，很有可能就导致你网站的性能大打折扣，前端的web服务器优化得再好，也是空的，后端的db反应不过来，前端永远等待后端的结果，最好的做法就是少用db，能静态化页面，尽量静态化，能把数据缓存到cache中尽量缓存到cache中，优化sql链接，优化sql语句，当数据达到一定得数量级就分库，分表等操作。
第三个就是服务器的优化，这个做好，能基本提高大的并发，优化的方法应该用压力工具压（如：ab，webbench）几个简单的测试页面，进行调优，不是水平特别菜的sa的话，通过搜索引擎去查找别人的方案，依葫芦画瓢，基本上能达到一个不是很坏的结果。
再往后优化的话就是从架构上去做服务器的优化，不在本文讨论范围之类，这基本是包括最基本的优化方案，也是大部分站点能做的事情。做了以上的优化为老板节省了服务器及带宽资源。同时也使sa的工作量变少，因为管理的服务器越少，花在服务器维护的时间就越少，节省出来的时间可以做更多有意义的事情。
附yahoo的调查结果，后台只占5%，而前端高达95%之多，其中有88%的东西是可以优化的。