Session介绍
Cookie是Web产品测试过程中不可缺少的一部分，我们需要通过Cookie信息辨别用户，得到属于自己的结果数据，例如DWR接口测试过程中，需要在请求头信息中传入测试用户的cookie信息，才可以得到该用户学习的课程，发表的博客，或者关注的用户等。Cookie信息通过模拟登陆操作就可以获得。但是，你有没有注意到你获得的Cookie是由什么组成的？是否包含NTES_SESS信息，是否包含SessionID信息？
NTES_SESS是URS返回的Cookie信息，NTESSTUDYSI是云课堂返回的Session信息，NTESSTUDYSI存储SessionID信息，不同的产品会配置不同的变量名。这个信息对于接口测试来说并不是必须的，但是却会在性能测试过程中起到很关键的作用。Cookie和Session有什么区别，为什么性能测试过程中必须需要Session信息？下面，我们一一阐述：
Cookie是什么：
cookie是小甜饼、小型文本文件，因为HTTP协议是无状态的，浏览器无法区分这次请求来自于哪个浏览器，因此产生了随着HTTP请求一起被传递给服务器的Cookie信息。Cookie是保存在客户端的，存在内存中的cookie，浏览器关闭后就消失了，存在时间是短暂的；存在硬盘中的Cookie，但存储时间长度超过过期时间或者用户手动清除时，cookie信息会消失。
Session是什么：
Session是会话，当用户第一次对网站服务器发生请求时，服务器会创建Session信息，生成SessionID用来唯一标识用户，并会把该SessionID返回给客户端浏览器（只存在内存，并不存在硬盘中），在会话结束之前的每次请求，浏览器会自动将该SessionID附加在请求头信息中，服务端接受请求时，检测是否存在SessionID（不存在或者Session过期都会重新生成Session），并通过该SessionID以键值对的方式查询用户信息。服务端的Session使用类似散列表的结构存储用户信息。
Session的常见实现形式是会话Cookie（Session Cookie），即未设置过期时间的Cookie，这个Cookie的默认生命周期为浏览器会话期间，只要关闭浏览器窗口，Cookie就消失了，这种形式的Session是和Cookie绑定在一起的。而平常所说的Cookie主要指的是另一类Cookie——持久Cookie（Persistent Cookies）。持久Cookie是指存放于客户端硬盘中的Cookie信息（设置了一定的有效期限）。持久Cookie一般会保存用户的用户ID，该信息在用户注册或第一次登录的时候由服务器生成包含域名及相关信息的Cookie发送并存放到客户端的硬盘文件上，并设置Cookie的过期时间，以便于实现用户的自动登录和网站内容自定义。
我们在执行接口测试之前，首先会通过URS得到用户Cookie信息，这份Cookie信息中至少会得到NTES_SESS字段对应的Values值，如果在获取Cookie时，我们同时跳转到产品页面，向该产品服务器发送请求（例如云课堂），那么在我们得到的Cookie信息中同样存在NTESSTUDYSI字段，该字段就是该产品的Tomcat服务器产生的32位的SessionID +jvmRoute设置的后缀名。在做接口测试时，如果请求头中没有传入SessionID信息，那么每次执行时，Tomcat都会重新生成一份Session；即便你传入该SessionID信息，如果SessionID过了超时时间设置，Tomcat还是会重新生成一份，Tomcat默认的Session过期时间为30Min。
性能影响
虽然只是一个小小的SessionID，却会对性能测试的产生很大的影响：
1、Session缺失：
在做Lofter产品的性能测试时，测试getHomePage接口，发现响应时间比较慢，JVM内存在测试过程中一直增长，Young GC收集不过来，Old区内存不断增长，最终会导致频繁Full GC，使用Jmap定位到堆内存中java.util.concurrent.ConcurrentHashMap$Segment对象不断增加，但是并不知道这个对象时谁在什么时候产生的。我们Dump出来此时的堆内存，使用MAT (Memory Analyzer Tool)工具进一步分析，到底是什么操作产生了大量的ConcurrentHashMap$Segment。
由上图可以看到这个对象是由org.apache.catalina.session.StandardManager产生的，session.StandardManager就是存储Session的容器。
通过了解Session的原理得知，我们在测试过程中，只是传入了Cookie信息，在Cookie中没有包含SessionID信息，所以每次请求时，Tomcat都会检查是否存在该标识信息，如果没有则会创建。如果我们测试过程中有几十万次请求，那么Tomcat会创建几十万个Session信息，假设一条Session需要2K的数据，那几十万的Session可能会使得Session容器占用上百兆的空间。同时需要注意，因为我们每个请求都会创建Session，这个Session是创建了以后不会被使用的(下次请求中依然没有携带SessionID)，即垃圾Session，但是垃圾Session在过期之前是会一直存在内存中的，默认的Session保存时间是30Min，这样的垃圾Session会在内存中保存至少30Min，如果在这30Min中内我们不停的发送请求，Session容器占用的内容空间会 不断扩大，最终会影响我们的测试结果。
2、Session过期
即便我们在请求中加入了SessionID，但是还可能会产生不停的创建Session问题，这是为什么？因为Session是存在过期时间的，默认的Tomcat中web.xml中设置的session过期时间为30Min，如果我们得到的SessionID在30Min后使用，依据Tomcat的Session机制，首先会检查是否存在SessionID，如果有的话，检测是否过期，如果传入的SessionID已经过期，Tomcat还是会每次都自动生成Session信息。
Mark，Session的过期时间有三种设置方式：一种是Tomcat的配置文件web.xml中设置，一种是webroot项目代码中的配置文件web.xml中设置，一种是代码中设置session.setMaxInactiveInterval(15*60)，所以我们在测试中要记得检测和确认这三个地方。
3、SessionID后缀不匹配
在测试云课堂项目中，我明明已经修改了每个地方的Session过期时间，请求中传入了没有过期的SessionID，可是为什么还是会不停的创建Session？
一般我们的产品架构是Nginx+Tomcat方式，静态请求走Nginx，动态请求通过Nginx访问到Tomcat。Nginx处理Session采用了session sticky方案，需用到第三方模块jvm_route，需要在Nginx的配置文件中upstream.conf中设置：
upstream study {
server 10.120.36.68:8010 srun_id=qa18-8010;
server 10.120.36.97:8010 srun_id=qa19-8010;
jvm_route $cookie_NTESSTUDYSI reverse;
keepalive 100;
}该配置文件中配置了一个Nginx连接两个Tomcat，当请求过来时，会依据SessionID中的后缀来查找请求发送到哪个Tomcat，例如NTESSTUDYSI=1816E5ECBC052F6ABA420FEE7B06DA86.qa18-8010;就会把带这个SessionID的请求发送到 10.120.36.68(qa18)这台机器上去。
在qa18这台机器的Tomcat配置文件server.xml中，会设置jvmRoute="qa18-8010"，这样保证生成的SessionID的后缀是qa18-8010，如果这个两个后缀不一致的话，同样会出现问题。
例如如果Nginx配置文件中upstream.conf中设置的srun_id=qa18-8010，而tomcat配置文件中设置的jvmRoute="qatest18-8010"，那么获取Cookie得到的SessionID后缀则为qatest18-8010，当发送请求到Nginx时，检测到SessionID的后缀和设置的server服务器无法匹配，则会丢失session，使得发送到Tomcat的动态请求依旧是没有Session信息的请求，造成session丢失，测试过程中还会有session不断的创建。
最新内容请见作者的GitHub页：http://qaseven.github.io/
