>>> 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
> 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
Also, should this use 95+% of my CPU...? Or is it something else
(depencey check) using my CPU while the JniStream is waiting?
>> 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
>> and 41% of the time is spent in
>> java.io.File.length called 28000 times from
> 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
com.caucho.server.webapp.Application.isModified() (also some from
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> (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:
I also tried to get a dump with Strace, and that's when it's getting
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.
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
>>>> 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
>>>> 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
>>>> I tried to copy the project to the internal drive to see if there
>>>> 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!
resin-interest mailing list