Stewart Forster <slf@connect.com.au> writes:
> For some time now I've been encountering very slow ICP responses from caches
> under high load (sustained > 30 TCP & > 100 ICP requests/sec). I've managed
> to trace this down to some code that was added a little while ago in the
> effort to reduce CPU usage.
Hmmm. I think the issue is more that icpHandleUdp() will only read one
packet each time it's called. Changing icpHandleUdp to loop unto the
recvfrom() returns EAGAIN is probably a better fix. (certainly, it's
much cheaper on the CPU).
Looking at the code, httpAccept() should possibly do the same thing.
It should result in the same thruput, but with a lower CPU
overhead. (and I think you're suffering the same CPU problem we are,
aren't you? )
A dumb patch for ipc_v2 follows... (checks that it compiles, not that
it works.. :) (this also handles the case where recvfrom returns
0. Not sure if this is possible, but I'm a little paranoid)
Michael.
--- ipc_v2.c.old Wed May 27 09:42:39 1998
+++ icp_v2.c Wed May 27 09:43:31 1998
@@ -307,6 +307,7 @@
int icp_version;
commSetSelect(sock, COMM_SELECT_READ, icpHandleUdp, NULL, 0);
+ again:
from_len = sizeof(from);
memset(&from, '\0', from_len);
len = recvfrom(sock,
@@ -315,14 +316,15 @@
0,
(struct sockaddr *) &from,
&from_len);
- if (len < 0) {
+ if (len < 1) {
#ifdef _SQUID_LINUX_
/* Some Linux systems seem to set the FD for reading and then
* return ECONNREFUSED when sendto() fails and generates an ICMP
* port unreachable message. */
/* or maybe an EHOSTUNREACH "No route to host" message */
- if (errno != ECONNREFUSED && errno != EHOSTUNREACH)
+ if (len<0 && errno != ECONNREFUSED && errno != EHOSTUNREACH)
#endif
+ if (len<0 && errno != EAGAIN)
debug(50, 1) ("icpHandleUdp: FD %d recvfrom: %s\n",
sock, xstrerror());
return;
@@ -350,6 +352,7 @@
icp_version,
inet_ntoa(from.sin_addr),
ntohs(from.sin_port));
+ goto again;
}
void
Received on Tue Jul 29 2003 - 13:15:50 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:11:47 MST