On 04/11/10 02:19, Martin Sperl wrote:
To add to the confusion on the buffers used by squid:I have observed something that looks similar to this issue:squid is writing to the network with 4k buffers, even if it has got everything in its local buffers, so it could do a write of the whole buffer... Here an example that delivers: 17961 body-bytes to the peer from the filled buffers: 1288787592.475200 epoll_ctl(6, EPOLL_CTL_ADD, 58, {EPOLLOUT|EPOLLERR|EPOLLHUP, {u32=58, u64=18133351923770}}) = 0 1288787592.475324 epoll_wait(6, {{EPOLLOUT, {u32=58, u64=18133351923770}}}, 32768, 10) = 1 1288787592.475358 gettimeofday({1288787592, 475366}, NULL) = 0 1288787592.475387 write(58, "HTTP/1.0 200 OK\r\nContent-Type: text/html;charset=UTF-8\r\nCache-Control: no-cache\r\nContent-Length: 17961\r\nDate: Wed, 03 Nov 2010 12:33:11 GMT\r\nVary: User-Agent,Accept-Encoding\r\nPragma: no-cache\r\nConnection: keep-alive\r\n\r\n<?xml version=\"1.0\" "..., 4222) = 4222 1288787592.475537 gettimeofday({1288787592, 475546}, NULL) = 0 1288787592.475584 epoll_wait(6, {{EPOLLOUT, {u32=58, u64=18133351923770}}}, 32768, 10) = 1 1288787592.475615 gettimeofday({1288787592, 475624}, NULL) = 0 1288787592.475645 write(58, "/center></d"..., 4096) = 4096 1288787592.475784 gettimeofday({1288787592, 475794}, NULL) = 0 1288787592.475828 epoll_wait(6, {{EPOLLOUT, {u32=58, u64=18133351923770}}}, 32768, 10) = 1 1288787592.475858 gettimeofday({1288787592, 475867}, NULL) = 0 1288787592.475887 write(58, "ody><tr><td"..., 4096) = 4096 1288787592.476044 gettimeofday({1288787592, 476069}, NULL) = 0 1288787592.476098 epoll_ctl(6, EPOLL_CTL_DEL, 72, {0, {u32=72, u64=20385083017920584}}) = 0 1288787592.476140 epoll_wait(6, {{EPOLLOUT, {u32=58, u64=18133351923770}}}, 32768, 10) = 1 1288787592.476585 gettimeofday({1288787592, 476594}, NULL) = 0 1288787592.476615 write(58, "refront?"..., 4096) = 4096 1288787592.476758 gettimeofday({1288787592, 476767}, NULL) = 0 So you see that there is no IO what so ever that comes from ICAP or the backend system. What is also surprising is that communication with ICAP is reading at 65536 bytes....
Not that surprising, Squid reads and writes in a long single stretches as it can. In the 4KB case the "buffer" is not a single stretch, but a series of 4KB pages.
In Summary: * read from Network (proxying call - FD=48) 4094 bytes * write to ICAP (FD=72) writes header and body separately (no upper limit found - I assume limit is 65535 bytes - as below) * reads from ICAP (FD=72) with buffer of 65535 * writes to network (final response - FD=58) first 4222 bytes (header and body together) and then subsequently 4096 bytes (for the body). The question is: why so many different buffer sizes are used for the different use-cases.
Your question ends with its own answer.
Also: why does squid write only 4096 bytes at a time to the network, when it could write everything in one go to the OS (non-blocking)?
Depends on where the data comes from. The system limits it. Memory swap page size, or disk IO page size, or TCP packet max on your OS will be 4KB.
Amos -- Please be using Current Stable Squid 2.7.STABLE9 or 3.1.9 Beta testers wanted for 3.2.0.2
