该项目使用3台web服务器,2台mysql数据库。3台web服务器间的session共享通过NFS实现。经过后来调查,访问速度骤降是session并发导致的。
因此,开始考虑其他的session共享方案。考虑到未来能更容易的进行横向扩展,所以计划采用memcached和Tokyo tyrant。
memcached在国内的应用已经很广泛了。Tokyo tyrant是日本人 平林幹雄 开发的一款 DBM 数据库,该数据库读写非常快,哈希模式写入100万条数据只需0.643秒,读取100万条数据只需0.773秒,是 Berkeley DB 等 DBM 的几倍,想深入了解的人可以参考:http://blog.s135.com/post/362/。
在论证备选方案的可行性开始之前,先做个压力测试是必须的。
【测试环境】
4台pc安装JMeter模拟client,web服务器一台,一台cache服务器(用来安装NFS服务,Memcached,Tokyo tyrant)。
使用4台pc安装JMeter模拟client的原因是:使用JMETER进行并发测试的时候,单台PC只能发起4100个并发线程(这个不同机器会有不同),因此要做15000的并发测试,必须4*4100.
web服务器上apache设置:MaxClient 256
原来MaxClient 150 的情况下会成为性能瓶颈,改成256之后,apache没有成为瓶颈。针对某个功能做压力测试的时候,务必要做到其他环节不会成为系统贫瘠,不然测试就毫无准确度可言了。
安装NFS, memcached, Tokyo tyrant的cache服务器配置:
CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz
Mem: 256M
HD: 40G
这台机器有点太寒碜了,呵呵,不过据说memcached对硬件配置要求很低,刚好可以验证下。
【测试程序】
因为是测试session的并发性,所以设计成个最简单的session操作流程:
1 page1.php创建session,往session写入1kb的数据,记录$time_start。
2 header至page2.php
3 page.php取得session,记录下$time_end,并计算出时间差$time_end-$time_start。
page1.php代码:
Code
page2.php代码:
Code
从代码可以看出,最后得到的time值并不是单纯的session操作的时间,session操作的时间会比这个值小。这样设计的原因是,这个值更能反映系统session并发操作的真实状况,但需确保测试环境的网络稳定,因为header函数的关系。
最后,再用perl写个简单的统计程序average.pl:
Code
【测试过程说明】
1 使用badboy先生成Jmeter脚本,然后用Jmeter进行分布式并发测试。
2 php对于使用memcached来存储session的实现已经非常简单,只需要进行如下配置:
session.save_handler memcache
session.save_path tcp://192.168.8.2:11211
3 如何使用Tokyo tyrant来存储session呢?因为Tokyo tyrant完全兼容memcached的client,所以配置和memcache几乎完全一样,只要改下IP和端口号就可以了。
1 使用badboy先生成Jmeter脚本,然后用Jmeter进行分布式并发测试。
2 php对于使用memcached来存储session的实现已经非常简单,只需要进行如下配置:
session.save_handler memcache
session.save_path tcp://192.168.8.2:11211
3 如何使用Tokyo tyrant来存储session呢?因为Tokyo tyrant完全兼容memcached的client,所以配置和memcache几乎完全一样,只要改下IP和端口号就可以了。
【测试结果】
使用NFS共享session:
2000 sessions
average time is:57.2385746240701
3000 sessions
average time is:188.679696798311
4000 sessions
average time is:1139.70507353546
5000 sessions
average time is:5486.23318772304
5000 sessions
average time is:5526.97186436598
5670 sessions(说明:发起了6000个访问,却只成功了5670)
average time is:8324.00726914608
5489 sessions(说明:发起了6000个访问,却只成功了5489)
average time is:9749.52457159197
从上面的结果看,NFS支持并发能力非常有限。根本没有办法支持到15000个session。在6000个session的时候,就会发生session 丢失等未知的状况。即使在5000个session以内,虽然可以完成测试,但性能低下。
当然,这和我使用的NFS服务端的机器配置很低有关,相信优化配置,或者“采用session存储的时候,进行目录分级”可以进行一定程度的优化,但NFS的并发操作确实存在问题。
因为有另一个理由:为了方便测试,我写了个perl程序用来删除session目录下的所有文件。
del_files.pl代码:
Code
当这个程序用于删除NFS目录下的session文件时,程序运行的时间明显比用于删除非NFS目录慢非常的多。
使用Memcached共享session:
5000 sessions
average time is:8.691506099701
10000 sessions
average time is:9.07290377616917
15000 sessions
average time is:9.10538846651721
15000 sessions
average time is:9.42796174685197
15000 sessions
average time is:9.43535621960958
从以上结果可以看出,memcached性能很稳定,在5000,10000,15000个session几种情况下,每个流程处理的平均时间稳定在8毫秒到10毫秒之间。
使用Tokyo tyrant共享session:
5000 sessions
average time is:8.92114758491478
10000 sessions
average time is:8.35826919078823
15000 sessions
average time is:10.7764382680262
15000 sessions
average time is:11.4394629955285
15000 sessions
average time is:8.92091128031373
15000 sessions
average time is:10.3760389963784
从测试结果看,NFS用于存储session时候的并发性能明显不如memcached和tokyo tyrant。memcache和tokyo tyrant还可以进行更大规模的并发测试。但是限于我当前的硬件,没有再进行更大规模的测试。
ok了,Memcached和tokyo tyrant的表现都让人满意,符合预期。至于要选择哪个,就得考虑其他因素了:
1 是否需要持久存储,Memcached是不支持持久存储的,当然可以考虑使用 Memcached+DB的方式来达到“一定程度上的持久存储”,即Memcached实时保存session,在每隔一段时间(比如1分钟)将session保存到DB,至于能否接受这种方案,得看业务需求而定了。Memcached和tokyo tyrant的其他差别,可以参考下http://blog.s135.com/post/362/等资料
2 对于这两项技术的掌握程度,整体上说,这两个技术应该都是靠得住,tokyo tyrant在日本也有不少成功的应用。但从国内来看,Memcached应用得较多,使用tokyo tyrant的话,还是要有一定的钻研精神才行。