 |
 |
Hmm, I wasn't anticipating that my comment would produce such a reaction. Xcache has nothing to do with high performance disk or whatver. The simple fact that Xcache is multithreaded and optmized for data files puts it ahead of squid for data applications, especially when resources may be potentially scarce. It's generally a 1-for-1 replacement. I don't see any issue in suggesting that from a resource optimization perspective that Xcache would be a better choice. Andy On Wed, 23 Oct 2019, DrDaveD wrote: > In what way? Are you suggesting that we put an xcache server at every site like we do squids? Assuming they're all configured with high performing and relatively large disk caches, that's not something we can expect small sites to do. Squids could be configured with high disk performance too, but that's more expensive and it wasn't needed for their current applications which have a very high hit rate and small working set, so that's why they have slow and small disks. Edgar's use case is also high hit rate and small working set, so it fits naturally into the ordinary cvmfs existing infrastructure. @bbockelm's design for the cvmfs integration with xcache was intended for partially shared & larger files, not for the completely shared smaller files of Edgar's use case. > > -- > You are receiving this because you were mentioned. > Reply to this email directly or view it on GitHub: > https://github.com/xrootd/xrootd/issues/1073#issuecomment-545618099 -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/xrootd/xrootd/issues/1073#issuecomment-545631653 ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-DEV list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1