Thanks for the reply.
I am just not sure how to read those numbers. When should be a service time considered to high? I am quite sure that my hit service time is good, but I wasn't sure about the miss time.
Unless the average service time seems high or users are noticing delays, then Squid is probably not bottlenecking enough to worry about.
Those service times look fine.
Do you think there is any way for improving the hit ratios? Line is not paid per month and not by traffic, but higher hit ratio should IMHO mean further improving the service time.
Why are you concerned about performance? What bottlenecks are you seeing?
Sometimes they do complain...
Squid tells me number of clients is 1600. Due to pool-based dhcp this boils down to 1000. FD Usage is about 300, IMHO one client means at least 2 connections, this way I guess that I have never more than 150 clients accessing the cache simultaneously.
Main reason for asking: I am just puzzled, that 1000 Clients are not pulling more than 40 requests/second @ 250kbytes/second. (We are talking about a company here, not internet access point or similar.)
We have eliminated couple of bottlenecks already: Squid logging to console (/dev/ttyXX is to slow for squid...), firewall performance and so on.
pppoe on openBSD is not the fastest of his kind, probably there is room for improvement. I may try to switch over to debian/linux on this machine as well.
A big problem is a clogged line when some users start downloading huge files in the middle of the day.
I can not use delay pools, as I need to set smaller delays when going direct over a much smaller line (when parent is down). That is why parent connections are set to no-delay. I can not limit download size either. I am really stuck here.
Regards, Hendrik
