“ Yuema约吗？一起学技术，一起成长！学海无涯 高人带路系列”
程序的世界，就是有坑的地方！分享踩坑的心得与体验！每天分享一点点！
关注公众号，进入学海无涯，高人带路模式！！压测再难，有人带路，轻松搞定
这是当面付的续集，想不到继集这么多。这回是压测的故事了。收银台的二维码是自己生成的，本身的逻辑比之前调用支付宝的更加“轻量级”，无需进行外网的请求，只涉及到自身的缓存操作。所以这个环节的压测数据不会是一个问题，于少会优于当前的。最大的问题是，生成二维码图片了。
一、服务器端合成图片
压测目标定得高的话，会导致大量的 503请求。
通过查看如下IIS日志
%Systemroot%\System32\LogFiles\HTTPERR\httperr1.log
可以查看到onnection_Dropped_List_Full、QueueFull的状态。加大IIS队列之后，压测数值更漂亮掉了。
合成图片，优化了一下LOGO图片，因为都是一样的，所以搞成了一个单例，避免重复读取文件。测试退化成了压测ThoughtWorks.QRCode.Codec与IIS队列了。
二、巧妙的给自己找台阶下
最后的压测结果，划一道线的话，会比较尴尬。结果实际峰值估算出一个合理的预期峰值来当压测标准的话，就很好的过了。这里有个不太好解决的事情是，优化图片合成有点像个死胡同，时间与技能都确实。这个台阶找得好，华丽的结合业务峰值，即不打脸，也不耽误进度，还有历史数据说话。
三、被抛弃的客户端JS渲染二维码图片方案
服务器端合合成二维图片，占内存，未调整IIS队列之前，未优化之前，压测数据惨不忍睹。我是很想使用JS来处理二维码图片，不让服务器端生成图片，这样子可以完美的绕过压测性能问题。但是这个方案不给过，考虑到js兼容性问题，也没法测试兼容性，就罢了。
四、内存暴表
作者：钟代麒
出处：http://www.jishudao.com/
版权归作者所有，转载请注明出处