为什么apache每次都会recv()-ing一些东西15秒?
我有基于 ZendFramework 的应用程序,它使用 XMLRPC 与其他 ZendFramework 应用程序通信。两者都在同一服务器上(用于开发)。通讯速度非常慢,我正在努力找出原因。经过分析后,我发现 ZF Lib XMLRPC 阅读器的 fgets() 速度变慢。
在对基于 ZendFramework 的 PHP 应用程序进行 strace 时,我使用 recv() 得到了一些模式 等15秒?任何人都知道为什么会发生这种情况?
0.000038 gettimeofday({1278333900, 86101}, NULL) = 0
0.000037 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 32
0.000035 fcntl64(32, F_GETFL) = 0x2 (flags O_RDWR)
0.000033 fcntl64(32, F_SETFL, O_RDWR|O_NONBLOCK) = 0
0.000034 connect(32, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)
0.000076 poll([{fd=32, events=POLLIN|POLLOUT|POLLERR|POLLHUP}], 1, 120000) = 1 ([{fd=32, revents=POLLOUT}])
0.000045 getsockopt(32, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
0.000036 fcntl64(32, F_SETFL, O_RDWR) = 0
0.000113 send(32, "POST /r/?articleId=554&hpr=Pimpl"..., 1180, MSG_DONTWAIT) = 1180
0.000148 poll([{fd=32, events=POLLIN|POLLERR|POLLHUP}], 1, 120000) = 1 ([{fd=32, revents=POLLIN}])
0.028020 recv(32, "HTTP/1.1 200 OK\r\nDate: Mon, 05 J"..., 8192, MSG_DONTWAIT) = 543
0.000105 poll([{fd=32, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, 0) = 0 (Timeout)
0.000050 poll([{fd=32, events=POLLIN|POLLERR|POLLHUP}], 1, 120000) = 1 ([{fd=32, revents=POLLIN}])
15.012976 recv(32, "", 8192, MSG_DONTWAIT) = 0
0.000123 close(32) = 0
I have ZendFramework based application that is using XMLRPC communication to other ZendFramework app. Both are on the same server (for development). That communication is very slow, and I am trying to find out why. After profiling, I got to the point where there is a slowdown within fgets() of ZF Lib XMLRPC reader.
While strace-ing ZendFramework based PHP Application, I get some patterns with recv()
waiting for 15 seconds? Anyone have any idea why is this might be happening?
0.000038 gettimeofday({1278333900, 86101}, NULL) = 0
0.000037 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 32
0.000035 fcntl64(32, F_GETFL) = 0x2 (flags O_RDWR)
0.000033 fcntl64(32, F_SETFL, O_RDWR|O_NONBLOCK) = 0
0.000034 connect(32, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)
0.000076 poll([{fd=32, events=POLLIN|POLLOUT|POLLERR|POLLHUP}], 1, 120000) = 1 ([{fd=32, revents=POLLOUT}])
0.000045 getsockopt(32, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
0.000036 fcntl64(32, F_SETFL, O_RDWR) = 0
0.000113 send(32, "POST /r/?articleId=554&hpr=Pimpl"..., 1180, MSG_DONTWAIT) = 1180
0.000148 poll([{fd=32, events=POLLIN|POLLERR|POLLHUP}], 1, 120000) = 1 ([{fd=32, revents=POLLIN}])
0.028020 recv(32, "HTTP/1.1 200 OK\r\nDate: Mon, 05 J"..., 8192, MSG_DONTWAIT) = 543
0.000105 poll([{fd=32, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, 0) = 0 (Timeout)
0.000050 poll([{fd=32, events=POLLIN|POLLERR|POLLHUP}], 1, 120000) = 1 ([{fd=32, revents=POLLIN}])
15.012976 recv(32, "", 8192, MSG_DONTWAIT) = 0
0.000123 close(32) = 0
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我对 ZendFramework 知之甚少,所以对我的评论持保留态度……但是!
如果我理解正确的话,
这意味着您正在轮询套接字(32),您会收到一个信号POLLIN(传入数据),您会去recv并等待15秒(超时)返回0字节,
这对我来说表明存在错误。可能在 zendframework 中或者你如何称呼它。在接收后收到 0 字节表示套接字已完全关闭(而不是强制关闭)。因此,当您退出 poll 并进入 recv 时,响应应该是立即的(毕竟它只读取 0 字节)
我认为 MSG_DONTWAIT 标志意味着进入非阻塞模式,这意味着无论等待的数据如何,它都应该立即返回,无论是带有数据还是带有 willblock 错误,都会返回到轮询循环。
可能是其他东西冻结了线程,导致线程锁定。尝试将应用程序放置在两台不同的计算机上,看看是否出现相同的错误。这可能是一些奇怪的互动。
直流
I know little about ZendFramework so take my comments with a grain of salt... but!
If I understand this correctly
It means that you are polling on the socket (32) you get a signal POLLIN (incoming data) you go to recv and wait for 15 seconds (timeout) getting 0 bytes back
This to me would indicate a bug. probably in the zendframework or perhaps how you are calling it. receiving 0 bytes after a recv indicates the socket was cleanly closed (as opposed to forced shut). Therefore when you come out of poll and go into recv the response should be immediate (its only reading 0 bytes after all)
The MSG_DONTWAIT flag I assume means to go into non blocking mode which means that irrespective of the data waiting it should return immediately, either with data or with a wouldblock error, to return into the polling loop.
It may possibly be that something else is freezing the thread causing this to lockup. try placing the apps on two different machines to see if you get the same error. it may be some weird interaction.
DC