I tried rock store and smp long time ago (squid 3.2 I guess), Unfortunately I definitely drop smp because there are some limitations (In my case), and I fall-back to diskd because there were many bugs with rock store. FI I also switched to aufs without big differences.
But now with the latest 3.5.20 ? Sadly SMP still not for me but rock store ?
There is someone who are using rock store with a high load, more than 800 r/s, without any problem ? There is a real difference in this situation, cpu, speed, memory ?
My configuration is
16 cores Xeon E5-2637 3.50Ghz
64 Go ram
2 drives sata - 15k - dedicated to caches (+ one for OS) 150 Go each
Delay pool -> BP limitation by ldap account
Authentication digest + basic
> I tried rock store and smp long time ago (squid 3.2 I guess), Unfortunately I definitely drop smp because there are some limitations (In my case), and I fall-back to diskd because there were many bugs with rock store. FI I also switched to aufs without big differences.
> But now with the latest 3.5.20 ? Sadly SMP still not for me but rock store ?
> There is someone who are using rock store with a high load, more than 800 r/s, without any problem ? There is a real difference in this situation, cpu, speed, memory ?
We use SMP and Rock under the 3.5 series without problems. But I don't
think any of our sites have as high req/sec load as you.
> Please can you describe your load and configurations ?
We supply Squid based online safety systems to schools across the UK,
utilising Rock store for caching and peek/splice, external ACLs and ICAP
for access control/filtering/auditing. Typically I think our biggest
schools probably top out at around 400,000 requests/hour, but I don't
have any hard data to hand to back that up at the moment.
The only serious Squid issue we've been tracking recently is the memory
leak associated with spliced connections, which we've now fixed (and
submitted patches). That said, with the schools currently on holiday
those fixes haven't yet been well tested on real-world servers - we'll
find out if there are any issues with them when term starts again :)
On 09/13/2016 05:01 AM, FredB wrote:
> One thing, squid restart is very slow because of time required to rebuild the cache
> 2016/09/13 00:25:34| Took 1498.42 seconds (3972.24 objects/sec). -> Rock
> 2016/09/13 00:00:51| Took 5.71 seconds (533481.90 objects/sec). -> Diskd
This is a known problem, with several important wrinkles, including:
* Squid start itself is not slow. Cache index build is slow.
* Squid can serve requests, including cache hits while it builds rock
index, but indexing does affect overall Squid performance and hit ratios.
* Avoid comparing loading a "few" ufs entries (from the clean swap
state) with scanning all available cache slots for rock. The biggest
difference is observed for a virtually empty ufs cache that was in use
for a short time (small swap.state). Rock focus is on Squid running for
a long time with a full cache (the common and intended use case).
* We are essentially comparing a from-scratch index build for rock with
a clean index loading for ufs. If you remove all swap state files, ufs
indexing time will probably be worse than that of rock. If you leave
dirty swap state files, then ufs indexing may slow down significantly;
this happens after Squid crashes, for example. Rock indexing does not
depend on the previous Squid state.
* Rock indexing can be optimized in various ways, of course. Many trade
offs are involved, and some optimizations may hurt runtime performance.
For example, there is a trade-off between
- maintaining a disk index (i.e., swap state files) at runtime
(and then saving a clean index at shutdown) like UFS stores do and
- building an index from scratch by scanning the entire cache at
start like rock stores do.