You should take several full thread dumps with a small interval in between them. Then to examine the thread dump, look for JRun Proxy Service threads beginning with jrpp-xxx where xxx is a number and jrpp-xxx is the thread id. Specifically, to find the running threads that are handling .cfm requests, search for the string (excluding the quotes) ".cfm:". This will lead you to a template and its path with a line number at the end after the colon. You'll also see other mentions of .cfm: further down in the stack of a particular thread, but it the top most one that was executing at that instant.
Truncated example:
-------------------------
"jrpp-96" prio=5 tid=0x477e5008 nid=0xc50 runnable [698f000..698fdbc]
at coldfusion.tagext.NativeCfx.processRequest(Native Method)
at coldfusion.tagext.lang.CFSearchTag.doStartTag(CFSearchTag.java:207)
at coldfusion.runtime.CfJspPage._emptyTag(CfJspPage.java:1871)
at cf_cachelists2ecfm612782408.runPage(/opt/apache/htdocs/_cachelists.cfm:30)
at coldfusion.runtime.CfJspPage.invoke(CfJspPage.java:147)
at coldfusion.tagext.lang.IncludeTag.doStartTag(IncludeTag.java:357)
<snip>
Here, jrpp-96 is the JRun thread which is handling the template /opt/apache/htdocs/_cachelists.cfm. That template is currently executing a tag that is either on line 30 or ends on line 30. In this case the tag is CFSEARCH. If you find that this thread stack exists in subsequent full thread dumps that were taken at short intervals, where the same thread id, same template, and same operation is occurring for both thread stacks, then that should be sufficient proof that the cfm request has been executing for the duration of the interval between the two thread dump instances.
Typically the number of jrpp thread stacks having cfm templates in the stack in a single full thread dump will not exceed the number of Simultaneous Requests set in the CFAdmin, also known as the activeHandler limit for JRun people. The full thread dump is precise enough to do full accounting of all running threads, showing exactly what they are doing at that instant.
Once that is done and you have a list of templates involved and operations that were being executed, then you can focus your effort to debug just that area. There are wide variety of debugging techniques including, but not limited to, ColdFusion debug output, CFTRACE, getTickCount(), CFLOG, and modulating CFAdmin settings. Dissecting the problem areas in smaller and smaller chunks with debugging techniques will help you pinpoint problems to a very granular level rather than lumping everything together into a generic symptom of "server is slow".
HTH,
Steven Erat
-----Original Message-----
From: Ray Bujarski [mailto:[EMAIL PROTECTED]
Sent: Friday, October 03, 2003 1:36 PM
To: CF-Talk
Subject: RE: RE: Server Slowness
No errors, nothing I can see. No timeouts, nothing like that. Any
suggestions of what "pointers" I can look for, because I don't see
anything out of the ordinary in there.
-----Original Message-----
From: Mike Brunt [mailto:[EMAIL PROTECTED]
Sent: Friday, October 03, 2003 10:53 AM
To: CF-Talk
Subject: RE: RE: Server Slowness
Ray, check your ColdFusion logs to see in there are any pointers in
there.
Kind Regards - Mike Brunt
Original Message -----------------------
its your config. we get hit about 10,000 times a day on windows box and
CFMX ROCKS.
what could be wrong? im sure a *nix person on the list will help, but
there
are many config settings
that *might* be wrong, but don't fret, its your config not CFMX.
...tony
tony weeg
senior web applications architect
navtrak, inc.
www.navtrak.net
[EMAIL PROTECTED]
410.548.2337
-----Original Message-----
From: Ray Bujarski [mailto:[EMAIL PROTECTED]
Sent: Friday, October 03, 2003 1:03 PM
To: CF-Talk
Subject: Server Slowness
Does anyone know why CFMX is so slow? I am running CFMX 6.01 on iPlanet
6 from a solaris 2.8 sparc station with 2 750MHz cpu's and 2gig of ram.
The CF server will pin one of our cpu's and only one of them at 50% and
will
never go into a "sleep" mode. It takes the server about a day to get to
50%, but it will never recover back to a normal .31% "sleep"
mode. Considering we are only getting 20 visits per day on this box, and
simple code, we are jumping the band wagon and going with Java because
it is
faster. I hope it is something on my end that I am overlooking, because
so
far we think that Macromedia's product is a P.O.S.
Can anyone help in our desperation?
Thanks,
Ray Bujarski
Direct 858-845-7669
Pager 858-636-9900
________________________________
_____
_____
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
