二维码生成压测实战|二维码图片合成内存爆表 Connection_Dropped_List_Full JS渲染二维码兼容PK赛

 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/
版权归作者所有,转载请注明出处

此条目发表在未分类分类目录。将固定链接加入收藏夹。

发表评论

邮箱地址不会被公开。 必填项已用*标注