 |
 |
Hi James -- I think this sounds like a great idea.
For TPC, you found the correct location for increasing the buffer size. Note TPCHandler::m_block_size is the size of the HTTP request generated when HTTP-TPC is doing multistreams and must be a multiple of the block size (otherwise you may hit deadlocks). My recommendation is to make it no smaller than 16MB.
I never did much exploration into optimal block sizes; without it, libcurl would generate extremely small writes (16KB or smaller, depending on how often you poll the TCP socket) and the Ceph RADOS integration would outright fail with unaligned writes. So, I'd welcome your work!
The hard decision point is the buffering in XrdHttp. Right now, the size of the buffer for PUT appears to simply be whatever comes off the socket. You may put the buffer in the XrdHttp layer ... or it might make more sense at the filesystem layer. We already "paid the price" in XrdTpc in terms of code complexity but it's not immediately clear the same decision makes sense for XrdHttp.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
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