处理完之后接着跑压力，webpy还是会偶尔打印异常信息，不过已经变成了session访问异常，还好的是出现面积很小，于是开始增加压力测试的并发量，结果表明稳定度还是可以的，性能也在可以接受的范围之内
实验二：保持最终部署环境不变(nginx+fastcgi+webpy)，继续压力测试在上次测试解决完日志的问题之后，我开始以真实环境做相关的测试，要注意的是使用nginx之后，需要访问nginx.conf中配置绑定的相关端口，不再是webpy默认的8080端口
继续做上述的压力测试，性能也在可以接受的范围之内
实验三：模拟用户环境根据测试MM所描述的，浏览器在B子系统出错过程中扮演了很关键的角色，于是我分别使用几个浏览器和纯粹的python代码分别访问相同的地址
几种组合的测试发现：
浏览器在只访问B子系统的情况下，一直表现正常 一旦浏览器访问过A子系统之后，再次访问B子系统即出现测试MM描述的404现象 python代码一直访问正常那么，我猜想问题原因应该在浏览器的某种特殊行为导致了该现象的出现，仔细想想，浏览器和python脚本的唯一区分在于浏览器有保存和发送cookie的行为，而python脚本没有，那么，可以抓包看看
抓包发现，在只访问B子系统的情况下，http头的发送Cookie只有由webpy设置的set-cookie信息，即web_session_id字段，访问过A子系统之后，出现了其他的字段，即截图中的
loginUser=….; xoxoyou@163.com=…此时我才想起来A，B子系统部署在同一台机器上，而且代码都在同一个根目录下，于是A子系统的cookie信息便被浏览器发送到B子系统的webpy环境中解析
为了进一步证实我的想法，我在python脚本中直接使用socket方式，模拟了浏览器的http头信息，直接请求webpy的8080端口，注意，此时需要打开webpy的debug开关
果然，webpy马上报错了
打开python库的相关代码，发现：
1
2
3
D:\Python27\Lib\Cookie.py
line 247
_LegalChars = string.ascii_letters + string.digits + "!#$%&'*+-.^_`|~"
合法的cookie key唯独就没有@符号…
总结至此，bug的根源算是找到了，但我的心情却很是复杂，以往的代码review过程发现开发同事的开发习惯不是很理想，代码编写非常随意，结构比较混乱，由此带来的问题便是代码质量不高，bug频现，该怎么解决这个病瘤一直是我心中的痛…
同时，我们也发现，在服务器代码开发中一定要避免出现异常捕获，由此带来的性能问题和其他诡异的现象非常令人头痛，还有，谙熟相关标准显然也是非常重要的