我们在专用服务器上托pipe我们的networking服务。 有时候（我会说20分之1）没有收到服务器的响应。 这会导致浏览器退出时出现超时错误。
一个重要的细节：在这种情况下，请求不会被Apachelogging。 服务器没有加载，有大量的可用内存和CPU剩余电量。
我已经用tcpdump实用程序描述了这个问题。 这些是由tcpdump跟踪的“好”和“坏”会话。 这两个实验的要求是一样的。 良好 – 服务器返回响应。 坏 – 没有反应，超时错误。
你明白为什么这些数据会发生问题吗？ 我怎样才能进一步接近错误的来源呢？
我用123.45.67.890取代了我的真实IP地址
---- Bad ---- 12:23:36.366292 IP 123.45.67.890.61749 > myserver.superbservers.com.www: S 2125316338:2125316338(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 12:23:39.362394 IP 123.45.67.890.61749 > myserver.superbservers.com.www: S 2125316338:2125316338(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 12:23:45.365567 IP 123.45.67.890.61749 > myserver.superbservers.com.www: S 2125316338:2125316338(0) win 8192 <mss 1460,nop,nop,sackOK> -------- ---- Good ---- 12:27:07.632229 IP 123.45.67.890.63914 > myserver.superbservers.com.www: S 3581365570:3581365570(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 12:27:10.620946 IP 123.45.67.890.63914 > myserver.superbservers.com.www: S 3581365570:3581365570(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> 12:27:10.620969 IP myserver.superbservers.com.www > 123.45.67.890.63914: S 2654770980:2654770980(0) ack 3581365571 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 6> 12:27:10.838747 IP 123.45.67.890.63914 > myserver.superbservers.com.www: . ack 1 win 4380 12:27:10.957143 IP 123.45.67.890.63914 > myserver.superbservers.com.www: P 1:213(212) ack 1 win 4380 12:27:10.957152 IP myserver.superbservers.com.www > 123.45.67.890.63914: . ack 213 win 108 12:27:10.965543 IP myserver.superbservers.com.www > 123.45.67.890.63914: P 1:630(629) ack 213 win 108 12:27:10.965621 IP myserver.superbservers.com.www > 123.45.67.890.63914: F 630:630(0) ack 213 win 108 12:27:11.183540 IP 123.45.67.890.63914 > myserver.superbservers.com.www: . ack 631 win 4222 12:27:11.185657 IP 123.45.67.890.63914 > myserver.superbservers.com.www: F 213:213(0) ack 631 win 4222 12:27:11.185663 IP myserver.superbservers.com.www > 123.45.67.890.63914: . ack 214 win 108 -------- 有关服务的详细信息。
这是一个天气报告服务。 它是用Perl编写的，由MySQL支持。 该脚本使用了几个模块（来自CPAN和我们自己的）。
代码相对简单。 该脚本从另一台服务器下载天气，转换数据格式并返回XML响应。 天气被caching在MyISAM DB中。 世界位置数据库（INNODB）也可以通过脚本来请求。
主机：SuperbHosting操作系统：Ubuntu
尝试使用tcpdump或wireshark来监视networkingstream量。 这样至less你会知道是否有networking问题。 即检查请求是否打到机器上。
另外，默认情况下，大多数浏览器只能在同一台服务器上进行有限的（2）个连接。 如果你的页面有一些javascript对象“忘记”closures连接等等，那么浏览器可能永远不会发送请求。
你可以尝试只使用IP地址的请求吗？ 如果是这样，这可能有助于缩小问题的范围。
所有的请求都来自同一地点，哪个有问题？ 如果是这样，尝试另一个位置，可能是在星巴克笔记本电脑或其他东西。 如果它发生在多个位置，使用不同的浏览器，在没有AJAX或复杂的Javascript的非常简单的页面上，这是有价值的信息。
如果使用IP地址可靠工作，那么它可能是DNS。 了解正在使用的域名可能有助于缩小范围。
我会和迈克尔·加夫一起去，然后在托pipe公司上投入一些资金 – 这些交通问题很容易发生在配线架，nics，networking驱动器问题或布线不良，以及其他一千个基础设施中。
我指望你已经从不同的地点尝试了这个（或者从其他地方有相同问题的报告），并且得到了同样的问题，无论如何我们可以排除你的问题，是正确的吗？
我是一个硬件怪胎，所以我倾向于把硬件故障视为造成奇怪的软件和networking问题以及一般的大规模破坏的原因。
问题是大量的开放式TCP连接，偶尔会有新的连接因此而丢失。