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 &lt;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
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Reply via email to