<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
-----BEGIN PGP SIGNED MESSAGE----- <br>
Hash: SHA256 <br>
<br>
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.<br>
<br>
23.10.2016 18:15, Yuri Voinov пишет:<br>
<span style="white-space: pre;">><br>
><br>
><br>
> 23.10.2016 18:09, Matus UHLAR - fantomas пишет:<br>
> >> 23.10.2016 17:40, Yuri Voinov пишет:<br>
> >>> This effect is good known to all who have worked
with relational<br>
> >>> databases. In fact, it is typical in general for
all caches except<br>
> >>> purpose-built highly scalable systems.<br>
><br>
> >>> 23.10.2016 17:37, Matus UHLAR - fantomas пишет:<br>
> >>>> doesn't that imply kind of effectiveness?<br>
><br>
> > On 23.10.16 17:53, Yuri Voinov wrote:<br>
> >> In fact, the explanation is very simple. At some
point soon will get the<br>
> >> content from the disc using an index of any kind
than consequentially<br>
> >> and fully scan the giant structure in RAM.<br>
> >><br>
> >> Performance indicator is expressed in the data
access time. But this is<br>
> >> from the category of personal experience. Everyone
can choose their own<br>
> >> road to hell. :)<br>
><br>
> > saying this you could say that huge in-memory cache for
OSes is<br>
> useless....<br>
> This is not me talking, and tuning specialists.<br>
><br>
> > iirc in some squid versions itwas caused by linear
searching for memory<br>
> > objects.<br>
> Only up to a point and is highly dependent on the server
hardware<br>
> architecture and software process architecture.<br>
><br>
> > using indexes should speed up saerching and bigger
probability to find and<br>
> > higher probability to find object in memory could
outweight searching<br>
> time.<br>
> Certainly. As I said above, it depends on the software
architecture<br>
> access to a cache memory. If there is an effective index
structure (like<br>
> a balanced B-tree), the effect disappears.<br>
><br>
> > databases are much faster when using indexes properly,
aren't they?<br>
> Absolutely yes. But: Most database index structures exist for
disk<br>
> objects and do not exist for the memory structures. There's a
completely<br>
> different mechanism. Indices disk objects (which are the
metadata) are<br>
> loaded into memory and used to access the on-disk data. But
access to<br>
> the memory is carried out mostly through a simple list
structures.<br>
><br>
> Which leads to performance degradation in case of huge
caches. Again we<br>
> come back to the importance of software architecture of the
memory accesses.<br>
><br>
></span><br>
<br>
-----BEGIN PGP SIGNATURE-----
<br>
Version: GnuPG v2
<br>
<br>
iQEcBAEBCAAGBQJYDKrmAAoJENNXIZxhPexGMPEIALfRoGL7EDTi4lS1rmItes6k
<br>
VJATrwChT8uZR+nexYTusVRaiYc2OnbQthTLYSOTYWqXl43l+Haj0+YAAc4edS1J
<br>
8ajAY0FzmGZsLynTsRLq526QsIXBUcuTAnbXbZb16g8sHbWZ/cnZzeR2SBP86qyC
<br>
b7EqAsQV1preTlqXo4WpfaZFDZldjwTaemjb91Rl9HsdBaKxcru35wzZbdvefbng
<br>
y4I9QPAv6xVFvEjw/IsUdpSe9vRPHFaLXF7WyYF2rM9+1mmCWd9YhFK0NASJ8Jxs
<br>
REhMi/WMZHFCh3SK1Dj5H+bH4xONN0AHuf0YogpbgvmjxrJkQhRB88RkH2xNiRE=
<br>
=/YWN
<br>
-----END PGP SIGNATURE-----
<br>
<br>
</body>
</html>