手机浏览 RSS 2.0 订阅 膘叔的简单人生 , 腾讯云RDS购买 | 超便宜的Vultr , 注册 | 登陆
浏览模式: 标准 | 列表分类:PHP

将PHP应用无缝转移到IIS中?

看到这个标题的时候很惊讶,所以我就不小心的转载了一下下,如果真的能够这样无缝移植,对性能有多少损耗?当然如果是企业内部应用的话,真有一些性能开销也是可以被接受的

原文如下:http://www.cnblogs.com/cocowool/archive/2009/09/13/1565931.html

在使用Godday的空间的时候,他就提供了一个将应用从Linux转移到Windows环境的选项(这个转移还被我们用来作为避免被GW封杀的手段), 其实是不知道Godday是如何实现PHP应用无缝在这两个系统之间切换的,今天看到一篇文章介绍Helicon Ape,可以实现将我们的应用从Linux下转移到Windows中,并且提供了模拟Apache配置的环境,这样我们完全可以保留在Linux下开发 PHP的习惯而将应用转移到Windows中。

下面是Helicon Ape的一些特性:

    * Users can move their Apache web sites to IIS without modifications;
    * Current PHP and other Unix oriented web applications can be easily configured for IIS;
    * Flexible user permissions control (as they implemented in Apache world);
    * Powerful URL rewriting compatible with Apache does not require rule redesign;
    * Reverse and forward proxy features available for a web server;
    * Low level controls over web site behavior open extended abilities for optimization, security and performance;
    * Comprehensive protection from site attacks;
    * Flexible compression and cache functions to speed up a server;
    * All-round HTTP-level web developer toolset.
    
对于哪些习惯Windows的开发者,这个看起来是个不错的选择。


参考资料:

1、Helicon Ape
2、Helicon Ape Introduction

Tags: iis, apache

Windows Cache Extension for PHP Beta 发布

本则新闻自于Cnbeta.com,可惜我没有IIS 7及更高版本。否则倒可以尝试尝试。。http://www.cnbeta.com/articles/92522.htm

也许您同时喜欢PHP的开发速度和Windows的易用性,但PHP和Windows的配合似乎永远没有Linux好?今天微软终于可以让Windows的PHP用户向Linux下的朋友们炫耀一下:
Windows Cache Extension for PHP Beta 发布,这是一个面向PHP的Windows缓存扩展,用于提高PHP应用程序的速度,而且无需修改任何代码!支持IIS 7.5和IIS 7.0.

  • PHP 5.2 and PHP 5.3 support
  • Configurable file cache
  • Configurable PHP opcode cache
  • Relative file path cache
  • PHP functions to obtain information about the cache status
  •  

访问:Windows Cache Extension for PHP

Tags: iis, wce, cache, extension

PHP的命名空间真这么糟糕么?

PHP的命名空间啊。被很多人所诟病,理由就是那个反斜杠。被当成转义符的反斜杠承担起了命名空间的重任。可想而知,他承受的压力有多大。。。

还好,还是有人在支持的,以下就是一篇支持文章,翻译过的。翻译人当然不是我,我要会翻译也就不写程序了。去翻译点文章忽悠人了。

» 阅读全文

Tags: namespace, 命名空间

ucapi手册

搜索ucenter的手册时,发现了ucapi.com网站,上面已经有一些内容了,什么使用手册官方API官方例程之类的。
以前下载的都是离线版的chm文件 ,经常会在硬盘里找不到。现在有一个在线版的。方便很多。查起来也很容易

呵呵。也算是推荐一下了。。
如果是用comsenz系统的人,估计都会用到ucenter吧。那么ucapi这样的东西就必须要看了

Tags: ucenter, api, ucapi

NFS,Memcached,Tokyo tyrant实现session共享性能测试

如果不使用passport,那么把用户session存入数据库留给多个程序调用是最方便的手段了。看到这个性能测试方案,想着留下来以备案。
tokyo tyrant现在开始被人推崇了。记得以前ruby也是。为什么这么多的好东西,都是日本人发明的?真是郁闷。。。。

原文如下:

在我负责的某个项目(调查类型的网站),不久前进行了一次推广调查。因为推广邮件是在同一时间发出,所以在5分钟之内,访问量剧增,发生了15000次左右的并发业务操作,整个系统的反映速度降低很明显。

该项目使用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代码:
PHP代码
  1. <?php  
  2. function microtime_float()  
  3. {  
  4.     list($usec$sec) = explode(" ", microtime());  
  5.     return ((float)$usec + (float)$sec);  
  6. }  
  7. $time_start = microtime_float();  
  8.   
  9. session_start();  
  10.   
  11. $_SESSION['name']='abcdefghjiasdfsadflklklasdlklkjsfdkjkasdflkjsadfkljkljsdfaasdfsafdlklkjsadfkljsdafkljljksdflkflsadflkjlkjsdaflkjdsfaljklsdfajljfsd 
  12. sadflsadfljklkjsdfjlksdfaljkfjlkfslkjsadfjlksdflakkljsfdlkjsafdlkjsafdlkjlasdfkjlkjasdfljkasdlkjfsdlkjsdflkjlkasjdfljkasflkjasflkjdsaflkjlksdafklasdljksadkljfjklsdfjklfkjlsafkjlsjkldafljksljksaljklksjfdajklsdfakljsafdkljsafkdljkljsfadjklsafdasdfsfdaabcdefghjiasdfsadflklklasdlklkjsfdkjkasdflkjsadfkljkljsdfaasdfsafdlklkjsadfkljsdafkljljksdflkflsadflkjlkjsdaflkjdsfaljklsdfajljfsd 
  13. sadflsadfljklkjsdfjlksdfaljkfjlkfslkjsadfjlksdflakkljsfdlkjsafdlkjsafdlkjlasdfkjlkjasdfljkasdlkjfsdlkjsdflkjlkasjdfljkasflkjasflkjdsaflkjlksdafklasdljksadkljfjklsdfjklfkjlsafkjlsjkldafljksljksaljklksjfdajklsdfakljsafdkljsafkdljkljsfadjklsafdasdfsfdaabcdefghjiasdfsadflklklasdlklkjsfdkjkasdflkjsadfkljkljsdfaasdfsafdlklkjsadfkljsdafkljljksdflkflsadflkjlkjsdaflkjdsfaljklsdfajljfsd 
  14. abcdefghjiasdfsadflklklasdlklkjsfdkjkasdflkjsadfkljkljsdfaasdfsafdlklkjsadfkljsdafkljljksdflkflsadflkjlkjsdaflkjdsfaljklsdfajljfsd';  
  15.   
  16.   
  17. header( "location:./page2.php?sid=".session_id()."&time_start=".urlencode($time_start) );  
page2.php代码:
PHP代码
  1. <?php  
  2. session_id($_GET['sid']);  
  3.   
  4. function microtime_float()  
  5. {  
  6.     list($usec$sec) = explode(" ", microtime());  
  7.     return ((float)$usec + (float)$sec);  
  8. }  
  9.   
  10. session_start();  
  11. $name = $_SESSION['name'];  
  12.   
  13. $time_start = urldecode($_GET['time_start']);  
  14. $time_end = microtime_float();  
  15. $time = ($time_end - $time_start)*1000;  
  16.   
  17. $_file = './log/'$_GET['sid'] . '.log';   
  18. $fp = fopen$_file'a');  
  19. @fwrite($fp$time);  
  20. @fclose($fp);  
  21.   
  22. echo "$time Millisecond<br>";  
  23. echo $name;  
  24. ?>  
从代码可以看出,最后得到的time值并不是单纯的session操作的时间,session操作的时间会比这个值小。这样设计的原因是,这个值更能反映系统session并发操作的真实状况,但需确保测试环境的网络稳定,因为header函数的关系。

最后,再用perl写个简单的统计程序average.pl:
Perl代码
  1. #!/usr/bin/env perl  
  2. my $log_dir = "./log/";  
  3. my $total_times = 0;  
  4. my $file_nums = 0;  
  5. opendir DH, $log_dir or die "无法打开 $log_dir: $!";  
  6. foreach $file (readdir DH) {  
  7.     open LOGFILE, "< $log_dir$file";  
  8.     while (<LOGFILE>)  
  9.     {  
  10.         $total_times = $total_times + $_;  
  11.         $file_nums = $file_nums + 1;  
  12.     }  
  13. }  
  14. print $file_nums . " sessions\n";  
  15. print "average time is:" . $total_times/$file_nums . "\n";  
  16. closedir DH;  

【测试过程说明】
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代码:
Perl代码
  1. #!/usr/bin/env perl  
  2. my $log_dir = "./log/";  
  3. unlink glob "$log_dir/*.*";  
  4.   
  5. my $session_dir = "./session_tmp/";  
  6. unlink glob "$session_dir/*";  
  7.   
  8. my $session_dir2 = "./session_nfs/";  
  9. unlink glob "$session_dir2/*";  
当这个程序用于删除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
tokyo tyrant速度也很快。但稳定性不如memcached,可能对机器的配置要求会高些吧,或者我对tokyo tyrant配置不了解也有可能。

从测试结果看,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的话,还是要有一定的钻研精神才行。

原文请见:NFS,Memcached,Tokyo tyrant实现session共享性能测试

Tags: tokyo tyrant, session共享