[squid-users] Slowness in Squid

[Yuri Voinov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
 


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
 
iQEcBAEBCAAGBQJYDKn1AAoJENNXIZxhPexGoloH/2LRFaUccVw1lJHdPW0AhB4b
al73ryEEuXo7y0H42T661Xs2rIReOdyIz68qvOUUq8dJBuY48SIAktd5DDfVEU8z
FyGTzxub4LPzU6xKO+LCPd8Mp2SXLayE7Gb3MuMKq++XzubARKfxHwzft+cvAMAN
GTCa+2WIgtQ3WowN7gaOZmKqW7GVSb0rz2yXSOw1sJMQ+VKvAv+vbWgiRi9osiAR
VDgCYWMPX6aQLQGFweLhDVU84xkvxMnCcUisK+DnNXO9DoLwRBbwDbvXuTutRnik
Wk+k1LB4A2OWdHsvAbNsPORqSaeUzjBLHkWROu4H3A0b5Kd+yDRXYThFSA85AsA=
=Khvr
-----END PGP SIGNATURE-----

-------------- 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/007fd9e3/attachment.key>