Scott wrote: >>> Also, what is the stack trace for the slow read() call? >>> >> With JNI, 57% of the time for loading a single page (total 78 s) is >> spent in >> com.caucho.vfs.JniStream.read cased by (only!!!) 22 calls from >> com.caucho.vfs.ReadStream.readBuffer >> com.caucho.vfs.ReadStream.waitForRead >> com.caucho.server.port.TcpConnection.run >> > > That's the keepalive waiting for the next browser request. It's normal. > Not that I am used to JProfiler, but I interpret the data as if this is "running" time, not I/O blocked or waiting for another thread (I may be wrong though!). Also, should this use 95+% of my CPU...? Or is it something else (depencey check) using my CPU while the JniStream is waiting?
Scott, continued: > >> ... >> >> >> Without JNI 43% of the time (total 33 s) is spent in >> java.io.File.lastModified caused by 28000 calls (depency checking over >> and over) from >> com.caucho.vfs.FilePath.getLastModified >> com.caucho.vfs.Depend.isModified >> ... >> and 41% of the time is spent in >> java.io.File.length called 28000 times from >> com.caucho.vfs.FilePath.getLength >> com.caucho.vfs.Depend.isModified >> ... >> > > Can you give more of the stack trace? It's conceivable that there's > a huge number of dependency files for some reason (or somehow Resin's > checking the same files repeatedly.) > Oh, sorry. (I was lazy 'cause I haven't found a way to copy the FQNs from JProfiler...) com.caucho.vfs.Depend.isModified() com.caucho.loader.ClassEntry.isModified() com.caucho.make.DependencyContainer.isModified() com.caucho.loader.DynamicClassLoader.isModified() com.caucho.loader.DynamicClassLoader.isModified() com.caucho.server.webapp.Application.isModified() (also some from com.caucho.server.cache.CacheFilterChain.useCache()) com.caucho.make.DependencyContainer.isModified() com.caucho.server.dispatch.Invocation.isModified() com.caucho.server.dispatch.DispatchServer.getInvocation() com.caucho.server.http.HttpRequest.handleRequest() (enought?) I just realized that the analyzis was complicated by the fact that the inital page load of the page I tested was so slow that subsequent image and scripts request also triggered dependency checks. Therefore I created a page as simple as 1+1 = <%= (1+1) %> Requesting this page takes a couple of seconds (inside the particular webapp on one of the computers). If you want to analyze futher, I will put a profiling snapshot here: <http://www.jiderhamn.se/noJNI.jps>http://www.jiderhamn.se/JNI.jps <http://www.jiderhamn.se/noJNI.jps> (Note! Memory data is not in sync with CPU data, use only CPU data) > A truss (or strace or equivalent) would give the exact files that are > getting tested. I uploaded a FileMon dump here: http://www.jiderhamn.se/filemonSimplePageLoad.txt I also tried to get a dump with Strace, and that's when it's getting really strange! When I attach Strace (IntellectualHeaven's GUI version) to java.exe, the problem (almost) dissapears!? The page now loads in a fraction of a second, about 9 times out of 10. (Dependency checks still seem to happen now and then). When I stop tracing, every single request takes a couple of seconds again. Could this give any hint????? Rob Lockstone wrote: > ... > > I've seen cases of bizarre slowness that turned out to be due to > either a problem with a particular DNS server, or with an individual > machine's DNS cache. > > ... > I've thought about that too, regarding external DTDs. Although I cannot make any difference with using another DNS server. Thanks anyway. Chris Chen wrote: > Finally, after about 6 hours trying diagnose this problem, I went > ahead and downloaded the newest Resin snapshot (dated Sep 27, 2007 on > Caucho's download page). I was this close to moving over to using > either JBoss or Tomcat. But the good part is that the new snapshot > actually solved my problem. I checked the bugtrack and didn't notice > any bug fixes related to this issue so I wasn't sure. > > Anyways, try installing the newest snapshot version (not the stable > 3.1.2 release, which apparently was too stable for my own good) and > see if it solves your problem. Well, of course I ran into the "lt;thread-idle-max> (10) must be greater than <thread-idle-min> (25)" bug. Not sure when I could find the time to migrate my 3.0 configuration to 3.1 syntax, to add a workaround. Also, since it has been working fine on 3.0.22 before, and still is on my other machine, I really should not have to migrate for this (but it might save me time to do so). >> >> >>> By the way, the CPU usage is peaking all the way through. Around >>> 49% on >>> my dual core system. >>> (And there is even more memory on the computer with the problem >>> than the >>> other one) >>> >>> >>> >>>> -----Original Message----- >>>> From: [EMAIL PROTECTED] >>>> [mailto:[EMAIL PROTECTED] Behalf Of Mattias >>>> Jiderhamn >>>> Sent: Friday 05 October 2007 11:20 >>>> To: Resin >>>> Subject: [Resin-interest] Slooow file reads (really weird!) >>>> >>>> >>>> Hi list. >>>> I have my J2EE webapp on an external hard drive, which I carry >>>> between >>>> my office and my home computer. >>>> On each computer - running Windows XP and Java 1.5 - I have a Resin >>>> (3.0.22) installation and a shortcut to start Resin with the >>>> server root >>>> on the external drive. >>>> This has worked flawlessly for over a year. >>>> >>>> Now suddenly (ok, after returning from vacation), the application is >>>> immensely slow - on one of the computers! >>>> Starting Resin and the application now takes anywhere from 3 to 5 >>>> minutes on my home computer, compared to the usual 30 or so seconds. >>>> Loading a simple page can take 40 seconds. It seems that most of the >>>> time is spent inside the disk access of the dependency checking. >>>> (Turning dependency checking off was much faster, but still >>>> slower than >>>> normal). >>>> I tried to copy the project to the internal drive to see if there >>>> was >>>> some interface hardware issue - no difference. >>>> I profiled the application with JProfiler, and it thinks there is a >>>> hotspot in com.caucho.vsf.JniStream.read(). Why...? >>>> >>>> I am running out of ideas on what could be wrong and how to track >>>> it down. >>>> >>>> Any tips would be much welcome! >>>> >>>> /Mattias
_______________________________________________ resin-interest mailing list [email protected] http://maillist.caucho.com/mailman/listinfo/resin-interest
