背景

针对食堂经营企业，某堂食软件为客户提供优化堂食就餐流程、提高食堂服务水平和管理效率。

某上海客户使用该堂食系统，在就餐高峰时段，总是出现支付、点餐等操作缓慢，动辄一个操作需要等待几十秒。该客户联系软件厂商，供应商回应，出现这种现象的原因是网络有问题。这个问题一直困扰客户，很长时间都没有解决。

上海客户已部署NetInside流量分析系统，使用流量分析系统提供实时和历史原始流量。重点针对堂食系统性能进行分析，以供安全取证、性能分析、网络质量监测以及深层网络分析。

分析方案

部署NetInside分析系统，旁路采集堂食系统网络流量。

NetInside系统采集网络流量，实时分析堂食系统访问行为，分析和定位故障原因，取证真实信息，不会对网络和应用造成任何影响。

分析结论

本次分析包含，得出如下结论：

1. 堂食系统存在明显的访问慢现象；
2. 部分操作延时超过20秒；
3. 出现故障时，网络是正常的；
4. 故障的根本原因，是应用系统重复发送多次请求；
5. 客户给供应商看了NetInside分析结论，及故障时二进制信息，并阐述：①故障原因是应用造成的；②故障产生时，网络没有问题。该结论得到软件供应商认可。

详细分析内容

堂食系统访问趋势图，从中看到中午进餐时段访问量最高，超过每分钟300次访问量。

单独查看系统慢访问分布状况，下图可以看到12点左右时段，存在大量的慢访问现象，次数最高的时候为中午12点，同时出现了7次。

钻取分析，查看堂食系统语句族信息，根据慢访问数量排序，能看到第一个跟支付有关的访问，在434次访问中，出现了9次慢访问。

详细查看存在慢访问的语句族，从单个交易时间查看，无论是点餐还是支付行为，都存在超过10秒以上的现象。

对第一个点餐提交操作，进行单个交易分析。从交互细节看到，系统连续发送45次query ，最终close，共用时25.68秒。

配合这个操作的报文交易信息分析，从下图看到客户端的确在不停的发送大量query请求，而服务器在收到请求后立即响应，说明网络没有问题。

这与上图中分析结论一致。

建议

通过对堂食系统性能数据的分析，发现原因是服务器响应时间过长导致，是软件问题，与网络没有关系。软件供应商看到原始取证，承认是他们的问题，并承诺尽快改进和优化程序。