 |
 |
Hi Andy, Thanks a lot for the prompt response. The use-case is somewhat the opposite; in our case we see some potential correlation between number of simultaneous requests and (total) time taken for deletes. I’m trying to eliminate as many ‘unknowns’ in the chain as I can, so we can focus on where this ‘bottleneck’ may be appearing. This is already quite helpful, so thank you again, James > On 10 Aug 2022, at 18:58, Andrew Hanushevsky <[log in to unmask]> wrote: > > 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 ######################################################################## 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