摘要： 在以前的两篇文章(Discuz!NT 缓存设计简析, Discuz!NT中集成Memcached分布式缓存)中，介绍了Discuz!NT中的缓存设计思路以及如何引入Memcached，当然前者是IIS进程的缓存（本地缓存），后者是分布式内存对象缓存系统。两者通过Discuz!NT中的memcached.config文件中的ApplyMemCached结点的值来决定使用哪一种缓存方式。不过在之后，有朋友反映当使用Memcached时，特别是在大并发来时，效率会打折扣，甚至有很多时间会消耗在socket套接字（创建和传输方面）上。而事实上也的确如此，尽管Memcached在使用池化的方式初始化一定数量的套接字资源（之前测试时实始化为128个链接），在小并发（100左右）时，可能问题不大，但并发上了1000-2000时，其效率要比本地化缓存机制低1/3（loadrunner测试场景），比如loadrunner测试1000并发时，如果showtopic(显示主题)，本地缓存处理时间为15秒，而使用memcached可能会达到25-35秒。 阅读全文

摘要： 在之前的两篇文章中，基本上介绍了如何录制脚本和生成并发用户，同时还对测试报告中的几个图表做了简单的说明。今天这篇文章做为这个系列的最后一篇，将会介绍如何通过测试报告来查看系统的运行情况，找出影响性能的因素，以及如何去进行优化。首先，看一下这张并发用户的图： 阅读全文

摘要： 在上文中，介绍了如果录制脚本和设置脚本执行次数。如果经过调试脚本能够正常工作的话，就可以设置并发用户数并进行压力测试了。 首先我们通过脚本编辑界面上的“工具”菜单项，选择该菜单的第二项“Create Controller Scenario(创建控制场景)”，这时，lr会弹出一个窗口，我们只要在select scenario type项中的number of vusers设置成1000，这样我们就可以用1000并发用户来测试我们上文中所执行的操作了，如下图： 阅读全文

摘要： DiscuzNT3正式版发布已经有一段时间了，最近半年多来很少再写关于这个产品的技术文章了，一是时间，二是精力有限。不过在正式版发表之后，倒是有了些功夫，同时我们的一个商业客户在从2.6版本升级到3.0正式版之后，出了一个小插曲，导致不得不退回到2.6版本。因为这个客户的论坛访问量和发帖量比较大，平时在线人数5000，日发帖量在2-3万左右。所以出了一些性能上的问题，在大并发情况下，服务器响应超时，且在峰值时越发不稳定。之前我在公司内部用了tinyget做了一些简单的压力测试，发现了一些问题，但原因尚不明显，所以在公司会议上就有人提出使用loadruner来做一下压力测试，看看3.0产品的性能倒底如何，是什么造成用户的服务器不稳定。所以就有了今天的这篇文章。 阅读全文