Hi, After some more testing, thread dumps and operating system process monitoring, we have found that there seems to be a performance issue with files when accessed via NFS. The slow part is when file attributes are being requested for a file on the NFS (this was also shown in the thread dumps with the getBooleanAttributes() function coming up a lot).
We have done a couple of tests with rather interesting results (we set up a specific test that loops over some directories and looks at the files in those directories, it does a fileExists(..) on each file in those directories); 1. test local file access time. 2. test file access time via share mounted via NFS path e.g. \\server \path\sharedfiles\ 3. test file access time via an iSCSI mounted drive (still over the network, but the operating system sees it as a lettered drive e.g. d: \sharedfiles\ The local file access time was very fast, for the 20 folders it did it in between 16ms and 50ms The FMS access time was very slow, about 3 seconds for the same 20 folders (I'd expect some delay over the network, but this seems rather a lot). The iSCSI mount was surprisingly fast at about 130ms (indicating that network latency time isn't really the issue?) We're a bit stumped, and the systems guys have had a look at options at the NFS end and there doesn't really seem to be much configuration they can do there. Kai, you mentioned that you run some of your servers with an NFS share, but have no problems, how is your share implemented, do you run it on Linux with the windows servers connecting to that? Regards Barry. On May 20, 11:52 am, BarryC <barrychester...@gmail.com> wrote: > Hi Charlie, It's not a development box, it's a production box , our > soon-to-be production site (well one of them), so everything on it is > essentially enterprise. > I did increase the IIS threads limit (as pointed out by someone > earlier on in this thread) so I don't know if it would be IIS or not. > > The only things remaining now in the thread dumps aside from queries > are reading and writing of files to disk and not much else - I would > have expected to see more code level stuff but there is still a decent > portion of file I/O. > I'll get our systems chaps to have a look at the system I/O > performance and see if they can find anything. > > the 150ms I mentioned was from the sum of those 21 file exists , > expand path checks. And yes it certainly must have been an issue > because the performance has increased a lot - around 40 odd %. > > On May 20, 11:33 am, "charlie arehart" <charlie_li...@carehart.org> > wrote: > > > > > Thanks for the update. I don't know the answer to your question, but I'll > > share a > > thought: you mention that you're load testing stuff. Is that perchance on a > > local > > development box? If so, is it perhaps some trial or lower-end version of > > Win2k8? I > > just ask because I know that in past Windows OS's, the lower-end versions > > did often > > have limits built-in, especially (as many will have noticed) the number of > > simultaneous IIS requests that are processed (others are queued). > > > It may well be that there could in fact be some I/O-level restrictions on > > too many > > requests at once, which could be queued. That's a total guess and could be > > way off > > base. Also, you may well be running an Enterprise or other high-end version > > of Windows > > 2008. Just thought I'd ask, since you're raising the concern. > > > Now, all that said, is this 150ms the sum of the delay that you've been > > concerned > > about? If so, then it would seem at least that you've found your root cause > > problem, > > right? That's at least a step in the right direction and allows you to > > focus solely on > > this one "last mile". > > > /charlie > > > > -----Original Message----- > > > From: cfaussie@googlegroups.com [mailto:cfaus...@googlegroups.com] On > > > Behalf Of > > > BarryC > > > Sent: Wednesday, May 19, 2010 6:45 PM > > > To: cfaussie > > > Subject: [cfaussie] Re: Coldfusion 9 and Windows server 2008 64bit > > > > I've done some debugging on this now, and each request is checking for > > > roughly 21 files to see if they exist (which they don't). The path > > > exists, but the file doesn't. > > > I did a test and found 21 fileexists(expandpath(..)) checks to > > > different files that don't exist takes around 150ms, quite a bit for > > > each page request, but not something I would have thought that would > > > show up so frequently in the thread dumps. > > > > are there operating system file I/O limits? I've got no idea when it > > > comes to operating system I/O level performance, if two requests check > > > to see if a file exists at the same time, does one have to wait for > > > the other to finish? > > > > Barry. > > > -- > > You received this message because you are subscribed to the Google Groups > > "cfaussie" group. > > To post to this group, send email to cfaus...@googlegroups.com. > > To unsubscribe from this group, send email to > > cfaussie+unsubscr...@googlegroups.com. > > For more options, visit this group > > athttp://groups.google.com/group/cfaussie?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "cfaussie" group. > To post to this group, send email to cfaus...@googlegroups.com. > To unsubscribe from this group, send email to > cfaussie+unsubscr...@googlegroups.com. > For more options, visit this group > athttp://groups.google.com/group/cfaussie?hl=en. -- You received this message because you are subscribed to the Google Groups "cfaussie" group. To post to this group, send email to cfaus...@googlegroups.com. To unsubscribe from this group, send email to cfaussie+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en.
