I am having some issues with the performance of the “xrdfs ls” client.

I am trying to access xrootd sever located in Purdue University, US, from CERN and from FNAL. And I see significant difference in response time for
a "xrdfs ls" command depending on whether my client is in CERN and in FNAL.
The difference varies in time, but today I measured 6 seconds for accessing Purdue from FNAL and 40+ seconds from CERN.
The directory I am listing is virtually empty. It only has 2 directories in it. I use plain “ls", not recursive “-R", not long “-l":

From CERN:

$ time xrdfs<  ls /store/test/rucio/int/cms/store
/store/test/rucio/int/cms/store//mcreal 0m45.321s
user    0m1.071s
sys     0m0.078s

From FNAL:

$ time xrdfs<  ls /store/test/rucio/int/cms/store
/store/test/rucio/int/cms/store//mcreal 0m5.947s
user    0m0.300s
sys     0m0.151s

The times are consistent. If I repeat the same command, I get pretty much the same time, so it does not look like there is some sort of caching involved.
Also, I tried the to run it from lxplus and from a OpenStack VM at CERN and got the same results, which tells me it may not depend on the location of my
client wishing CERN LAN.

Does anyone has any ideas how this difference can be explained ?


Use REPLY-ALL to reply to list

To unsubscribe from the XROOTD-L list, click the following link: