问题：300多人同时登录的时候，有部分考生登录不上系统，并出现卡死现象。需要关闭浏览器，重新登录。
分析问题：
1，从浏览器到服务器，从HTTP请求到响应的全部过程进行分析。（HTTP(响应了多少数据),中间件（配置多少线程），应用程序（登录是否存在逻辑问题），JVM（参数是否不合理），操作系统，硬件（学校带宽，CPU利用率，磁盘利用率，内存利用率）都需要思考）。
2，系统的初始登录页面，加载了一些js，css第三方类库，jquery,bootstrap。
3，当考生输入用户名和密码进行登录并成功后，响应了大量的第三方类库。大约有6M，也就是每一个考生登录成功后，都将响应6M数据到浏览器。
4，为了找到问题的原因，我利用Jmeter工具进行压力测试。准备了300个考生，在2秒内进行登录，在结果集中查看响应数据，发现很多考生几乎都无法正常获取响应数据。所以确定是因为每当考生登录成功后响应了庞大的数据量。
解决问题过程：
1，利用gzip方式进行压缩。一开始我采用Java代码进行压缩，也就是当浏览器响应此js，css文件的时候，都用Java代码进行gzip压缩，然后响应到页面，文件大小减少了三分之二左右。
2，修改1的方式，采用gzip.exe先把文件压缩后，直接放到资源路径下。
3，采用分步骤加载。在初始登录页面上，先加载部分js，css文件。一旦考生登录成功后，在加载另一部分js,css文件。（利用浏览器的缓存）。后续考生在答题的过程中，不响应任何的js和css文件。考生答题过程非常流畅。考生实时取题，提交答案，系统保存答案。
4，另一个思路，尽量把静态资源，放到离用户更近的地方。CDN技术或者Nginx技术。又考虑到学校考试是内网，所以放弃CDN技术。Nginx又服务于集群或者把资源缓存起来，但是学校又是一台服务器，所以没有这个必要。
5，300个考生，每个大约会响应3.5M（压缩后）左右的数据量。也需要1.05G的内存。所以，将32位的JDK换成64位的JDK，并分配了4G的内存。
6，在server.xml中配置了300大小的线程池，增加请求总数，排队总数，增加连接时长等。
效果：现场300个考生同时（短时间内）登录，未出现卡顿现场。
收获：分步骤加载。离用户更近。调节JVM参数。配置server.xml参数。