关于一次系统慢的反思，建议新手朋友好好看看，定能有不少体会。
故障现象：
前段时间接到市场人员反应，有一个产品平台下载参数很慢，平常正常情况下大概需要几秒时间，但是现在需要10多分钟左右。甚至还会下载失败，产品部门手工维护参数后上传到该平台也是失败。平台正常运行了两年时间左右。有时候出现连接简单问题重启应用即可解决！
平台描述：
该平台是某个产品的备份平台，会备份企业的一些基本信息和相关配置参数，为了就是保证企业的电脑故障时，快速的恢复企业的数据。平台主要有两个功能，一个是客户端上传的http报文，另外一个是通过另外一个系统手工维护的企业参数，简称jmx报文。当然这两种报文协议走的端口肯定不一样。
故障分析：
首先确认了该平台无任何压力。
再次确认了数据库的性能，各方面DBA巡检也正常。
最后确认了网络无任何故障。
检查应用log，提示调完查询接口后直接再调下一个查询接口，正常应该是调完查询接口后就会返回消息。
万不得已重启此平台的应用后，还是很慢。
故障解决步骤：
1、程序上本身走的是两种协议，先确认是http出现问题还是jmx出现问题？我们用iptables拒绝了所有客户端的http连接后，再手工从另外一个平台维护企业参数后上传备份平台后无任何延迟，提示发送成功。所以暂时把问题定于http问题。
2、我们在业务低峰期查看tcp连接数，FIN_WAIT1状态始终有40个左右连接不释放。而且还是同一家企业的IP地址占据连接，ESTABLISHED大概150个连接左右。这家企业今天只有激活没有发单，应该不会占用大量连接不释放，基于这种连接状态，重启应用肯定不会解决任何问题，故只有重启机器，重启服务器后再启动应用，连接又会马上上来，而且还大于40个，通知市场人员联系企业后，该企业停掉安装我们软件的电脑后，故连接消失！
3、和平台研发人员沟通后，确认该应用内嵌了叫jetty的servlet容器，也是开源的产品之一，和tomcat差不多，但是应该比tomcat更轻量级。试着修改http的参数，将最大线程数增大，但是ESTABLISHED状态的也会增多，假如最大线程数调到400，ESTABLISHED也会相应的网上增加到350左右，但是最大调到1000，ESTABLISHED会到600多，这也就是最高峰值。依次调了线程稀少时的时间，连接空闲时的最大连接数等等，貌似都不行。
4、试着调优内核参数优化tcp连接和修改tcp连接打开的文件数和进程数，都还是下载参数很慢很慢。
5、尝试了各种办法后，最后只能决定临时增加一台负载（DNS轮询方式），加负载后等域名解析生效，市场反应企业从平台下载参数基本恢复了正常。
6、问题是解决了，但是为什么会造成平台jetty的程序的瓶颈呢？一方面是恶意攻击，另一方面是客户端软件本身所引起。排除恶意攻击，经过和客户端研发人员沟通后，这个产品客户端比较特殊，用户可以自己设定连接平台时间，假如轮询的时间单位是10，客户不知道的情况也许会调成5或者更低，更或者如果说是毫秒级别的呢？
7、这里大概就是处理的步骤，步骤可能比较啰嗦，但是通过这一次的故障，让我们做IT的人好好反思了一下。
反思总结：
1、客户端研发尽量减少给平台带来的压力，开发人员应用尽量不用轮询的方式，尽可能采用触发的方式与平台交互。
2、平台研发尽量控制好会话超时时间，这样就保证了没有堵塞的现象。
3、平台运维尽可能的做好控制程序的线程数和系统本身优化工作，尽量采取保护平台的模式，应根据平常工作累积的经验值得出机器硬件配置所能承受住的请求和并发值。
4、只有各个部门相互配合才能让系统稳定，安全，可靠的运作！