[squid-users] Slowness in Squid

[Yuri Voinov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
 
In the final, I do not think Squid architecture is designed for fast
access to huge amounts of memory. It came from a time when computers
were young, memory cost like Boeing and hardly Squid itself seriously
reworked in this part since then.

23.10.2016 18:15, Yuri Voinov пишет:
>
>
>
> 23.10.2016 18:09, Matus UHLAR - fantomas пишет:
> >> 23.10.2016 17:40, Yuri Voinov пишет:
> >>> This effect is good known to all who have worked with relational
> >>> databases. In fact, it is typical in general for all caches except
> >>> purpose-built highly scalable systems.
>
> >>> 23.10.2016 17:37, Matus UHLAR - fantomas пишет:
> >>>> doesn't that imply kind of effectiveness?
>
> > On 23.10.16 17:53, Yuri Voinov wrote:
> >> In fact, the explanation is very simple. At some point soon will
get the
> >> content from the disc using an index of any kind than consequentially
> >> and fully scan the giant structure in RAM.
> >>
> >> Performance indicator is expressed in the data access time. But this is
> >> from the category of personal experience. Everyone can choose their own
> >> road to hell. :)
>
> > saying this you could say that huge in-memory cache for OSes is
> useless....
> This is not me talking, and tuning specialists.
>
> > iirc in some squid versions itwas caused by linear searching for memory
> > objects.
> Only up to a point and is highly dependent on the server hardware
> architecture and software process architecture.
>
> > using indexes should speed up saerching and bigger probability to
find and
> > higher probability to find object in memory could outweight searching
> time.
> Certainly. As I said above, it depends on the software architecture
> access to a cache memory. If there is an effective index structure (like
> a balanced B-tree), the effect disappears.
>
> > databases are much faster when using indexes properly, aren't they?
> Absolutely yes. But: Most database index structures exist for disk
> objects and do not exist for the memory structures. There's a completely
> different mechanism. Indices disk objects (which are the metadata) are
> loaded into memory and used to access the on-disk data. But access to
> the memory is carried out mostly through a simple list structures.
>
> Which leads to performance degradation in case of huge caches. Again we
> come back to the importance of software architecture of the memory
accesses.
>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
 
iQEcBAEBCAAGBQJYDKrmAAoJENNXIZxhPexGMPEIALfRoGL7EDTi4lS1rmItes6k
VJATrwChT8uZR+nexYTusVRaiYc2OnbQthTLYSOTYWqXl43l+Haj0+YAAc4edS1J
8ajAY0FzmGZsLynTsRLq526QsIXBUcuTAnbXbZb16g8sHbWZ/cnZzeR2SBP86qyC
b7EqAsQV1preTlqXo4WpfaZFDZldjwTaemjb91Rl9HsdBaKxcru35wzZbdvefbng
y4I9QPAv6xVFvEjw/IsUdpSe9vRPHFaLXF7WyYF2rM9+1mmCWd9YhFK0NASJ8Jxs
REhMi/WMZHFCh3SK1Dj5H+bH4xONN0AHuf0YogpbgvmjxrJkQhRB88RkH2xNiRE=
=/YWN
-----END PGP SIGNATURE-----

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20161023/54138799/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x613DEC46.asc
Type: application/pgp-keys
Size: 2437 bytes
Desc: not available
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20161023/54138799/attachment.key>