-----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-----
Attachment:
0x613DEC46.asc
Description: application/pgp-keys
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
