 |
 |
Hi James, No, there is no throttling of deletetion requests. What have you seen that would indicate such a feature is needed? As for going through a memory proxy, the only additional overhead is a small amount of latency introduced to see if a memory copy needs to be discarded. Thhough, in practice, few people use the memory cache for writing as well as reading so we have very limited data on this. Andy P.S. While we could add a deletion queue for xroot protocol it's very difficult to do for http protocol (potentially possible for http/2) as we would occupy a thread for each queued request (unless you don't care about the result) and the problem would shift to another resource. On Wed, 10 Aug 2022, James William Walder wrote: > Hi, > I?m wondering if there?s any configuration parameter - or internal design - that limits the number of concurrent deletion requests that can be processed simultaneously in XRootD endpoints. > For example, say 100+ deletion requests (via https/davs) are (simultaneously) issued against an XRootD endpoint, where might one expect the bottleneck to appear? > > I appreciate it might be a vague question (with a suitably vague answer), which depends somewhat on the storage technology, but I?m trying to ascertain if there is something in XRootD (ideally configurable) that might queue / batch / throttle deletion operations ? > > Also, if the deletion requests goes through a memory-cache proxy, could that introduce additional effects ? > > Thanks in advance, > James > > > ######################################################################## > Use REPLY-ALL to reply to list > > To unsubscribe from the XROOTD-L list, click the following link: > https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1 > ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-L list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1