To eliminate the possibility of any network related issues, you could
simply remote in to the server itself and request a page off it (if
your setup allows) and see how it goes?
Also, have you set up a basic page that only outputs a hello world
type message to make sure there is not something else on the page
causing slowness at the client end? (If you try this, don't forget to
put it in its own folder with an empty Application cfm file so you are
not having any other application cfm or cfc files including stuff into
your page automatically), or even just a basic .html file, does that
take a long time if you request it and bypass coldfusion all together?
Barry.
On Apr 25, 12:29 pm, MrBuzzy <mrbu...@gmail.com> wrote:
> One other gotcha to consider;
>
> If when you installed the jrun connector you ticked 'turn on verbose
> debugging'* the connector spends a significant time writing its log
> file, which gets big very quickly. CF appears to be working fine, but
> the page takes a long time to return to the browser.
>
> *may not be the exact wording.
>
> On 4/25/10, Andrew Myers <am2...@gmail.com> wrote:
>
>
>
>
>
> > Fantasic Charlie, this sounds like it could make sense.
>
> > I will check this out.
>
> > Sent from my iPod
>
> > On 25/04/2010, at 2:47 AM, "charlie arehart"
> > <charlie_li...@carehart.org> wrote:
>
> >> Here's still another thought, though I do agree Mr.B and Kai that
> >> this could
> >> reflect time spent pulling down and rendering the debugging info.
>
> >> I'll point out as well that it could instead be a problem with the
> >> page not
> >> executing immediately in CF. The debugging output shows the actual
> >> time
> >> spent executing once it gets to CF, not the time getting to and from
> >> it.
> >> While some may realize that would not include network time to and
> >> from the
> >> server, perhaps as important is that it also does NOT reflect the
> >> time spent
> >> *waiting* to execute in CF (queued) on the server.
>
> >> If ever there's a situation where all the simultaneous request
> >> threads are
> >> full or nearly full, then new requests may queue waiting to get a
> >> chance to
> >> run. Again, it's easy to miss that this time is NOT reflected in the
> >> debugging output (nor is it tracked in the CF Server Monitor,
> >> FusionReactor,
> >> SeeFusion, etc.)
>
> >> Among the easiest ways to determine if that's happening (queuing) is
> >> to
> >> watch the CFSTAT command line output (available in [cf]\bin) or
> >> getmetricdata("perf_monitor") or Windows PerfMon. Note that you do
> >> need to
> >> enable these (cfstat, perfmon) in the CF Admin, and also important:
> >> NEITHER
> >> is available for Multiserver deployments.
>
> >> For multiserver deployments (and indeed any CF deployment from CF 6
> >> on) you
> >> can also see queuing if you enable JRun metrics. Finally, a little
> >> known tip
> >> is that the CF 8/9 Enterprise Multiserver monitor shows queuing in its
> >> "detail view", if you mouse over the "active requests" column, or
> >> double-click on a monitored server to see it in the details shown at
> >> the
> >> bottom of the screen.
>
> >> To be clear, each of these can at least report how much queuing (if
> >> any) is
> >> happening. (Beware the "avgQ time" metric in CFSTAT and
> >> getmetricdata/perfmon report the average of the last two completed
> >> requests,
> >> so not always useful.)
>
> >> HTH
>
> >> /charlie
>
> >>> -----Original Message-----
> >>> From: cfaussie@googlegroups.com [mailto:cfaus...@googlegroups.com] On
> >>> Behalf Of Andrew
> >>> Sent: Saturday, April 24, 2010 8:17 AM
> >>> To: cfaussie
> >>> Subject: [cfaussie] Performance Tuning Again
>
> >>> Hi Folks,
>
> >>> A quick question. If when I enabled debugging it is showing that a
> >>> page is taking say 200ms but it's more like 4-5 seconds before the
> >>> browser gets a response, does that point to a network issue? Or
> >>> could
> >>> there be something else CF related going on that the debugging view
> >>> isn't showing?
>
> >>> Many thanks,
> >>> Andrew.
>
> >>> --
> >>> 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.
>
> >> --
> >> 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
> >> .
>
> > --
> > 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.
>
> --
> Sent from my mobile device
>
> --
> 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.
