---------------------------------------- > Date: Thu, 27 Sep 2012 21:08:12 +0200 > From: esr@xxxxxxxxxxx > To: tcr@xxxxxxxxxxxx > CC: squid-users@xxxxxxxxxxxxxxx > Subject: Re: clarification of delay_initial_bucket_level > > 2012/9/27 tcr@xxxxxxxxxxxx <tcr@xxxxxxxxxxxx>: > >> Hmm, I just noticed Eliazers' reply about how reloading often is a bad > >> idea and one should use ext_acls instead, > > > > I'd be interested to hear why reloading is a bad idea. Squid supports HUP reloading, I've been doing it for years and on my systems it takes about 100ms to do a reload, so even if it blocks for that amount of time it's not a big deal. Unless the reload leaks memory or something, I don't think it's a problem. I have an action item to move my servers to external ACLs, but it's been one of those "if it ain't broke" type things, so I haven't done it yet. > > > > I don't think Eliezer meant reloading per se as much as my question > which was reloading every 5 minutes. > I also reload all the time when I write new configs and sometimes I > even end up reloading several times in one minute without my users > feeling it as far as I can tell (or at least they don't feel it enough > to start sending mail saying the Internet is broken). You can be sure that they feel it. But they are not able to complain because duration is short and they are not sure if the problem is arising on their end or elsewhere. Why don't you just run a cron job to reconfigure squid every minute and try to keep browsing? Bad things can and do happen when squid stops servicing connections while active sessions are going on. If your shutdown timeout is short, you are probably cutting off existing connections abruptly as well. Browsers and OSes behave weirdly. Once a user even had to reboot his computer to be able to get back online when subjected to a reconfigure. Squid also will surely will take more than few seconds to get back online even with the minimal config options (maybe tcr can explain how he came up with 100ms). In my config, it takes 3 seconds (with shutdown_timeout 1). When you are doing 500 requests per second, those couple of seconds mean you lose couple thousand requests, and you probably cut couple thousand in the middle. Moreover, it takes about 1.5 minutes for squid to get back to the speed it was doing before a reconfigure (probably because client machines are waiting for timeouts on failed requests). And I don't even do caching! Moral of the story is... despite Amos's efforts to make it less burdensome on 3.2's, frequent reconfigures must be avoided. Jenny PS: I do a reconfigure once an hour, but my traffic is controlled.
