I am using 5.16/00 on winXP. My application is a compiled DLL built with msvc++.net 2003. I have been experimenting with xrootd on our LAN to see if there is any benefit to using TXNetFile to read large (>10**8 byte root files) relative to directly reading them from mapped drives using TFile. I noticed that some things get quite a bit slower once I access a file via TXNetFile - for example, tab completion now takes about 3-4 seconds per line (e.g. gSystem-> takes many minutes to display the methods and members of gSystem instead of less than a second) Even if I subsequently open a file using TFile (first deleting the TXNetFile) the slowness persists. When I start a new session and access files with TFile, tab completion is fast. There are other things that slow down too, but have yet to isolate them. Is this a known problem? Or does it suggest some other problem(s)?
Note: xrootd is running on a linux (fedora) box. The files are not physically on the linux box, but on a CIFS share.
Rene,
I inderstand that there should be no connection between the two - I did’nt look for it, it found me! I do not see any noticable improvement using xrootd/TXNetFile relative to reading tha mapped drive with TFile(). Both improve with TTree cache size set somewhere between 10-100 MB.
Its not just TAB completion that gets slow, other things like gSystem->AccessPathName() or TFile(“local filename”) also takes several seconds to return. If my root session never uses TXNetFile, this odd slowdown does not occur.
I am still concerned about the xrootd performance. When I read a 698 MB file using xrootd (I look at all branches) it takes 1.00 minutes to read, 29.938 sec cpu. If I then read the same file immediatly, it takes only 00:38 minutes, 31.719 sec of cpu. I’ve attached SysInternal’s Process Explorer for the root job. the two ramps in the “Private Bytes History” are the two reads (When I read the input file I create memory resident ttree’s with sampled data - in this case one out of each 111 records) The first ramp is 1:00 minute long; the second ramp is 00:38 minutes long.
This is qualitative behavior is reproducible - a root file takes much longer the first time to read than the second This is true even if I read directly from mapped drive (w/out xrootd). My tree chache size is 50 MB. Does xrootd use this? Thanks
I am not completely sure I understand what you are saying. 1) Reading a file with xrootd takes twice longer than reading the same file from local disk? If so, what is you network bandwidth, compared to disk? 2) Reading a file twice via xrootd, the second time is twice as fast? File might be cached in the server. Is the thrid time and more also twice as fast as the first time?
Hello Fons,
I am saying the second thing: that reading the file twice via xrootd, the second time is almost twice as fast. It does sound like the server is caching. Yes, the third time is also about twice as fast as the first read.
If I am reading a file only once (typical usage) the xrootd read time is less than the time to read the file w/out xrootd. I was just wondering if was extra performance that I’m leaving on the table - are there configurations to xrootd I should know about?
Whenevener I read the same file more than once, regardless if its local, mapped or via xrootd, the second and subsequent reads are always faster than the first.
clearly all modern OS’es use aggressively the buffer cache which caches file access up to the amount of available memory. This explains why with xrootd as well as with local access you are faster the subsequent times (as long as all or most of the file fits in this buffer cache). By default with xrootd and the other network protocols we use read-ahead and some local client caching to reduce the typical network access latencies. The defaults should work fine out of the box (have a quick look at etc/system.rootrc to see the different local caching options).
