Hi Mark,
you wrote:
>
> Basically I am on a witchhunt trying to see why some pages are occasionally
> too slow.
>
> Geoff, Your example is exactly what I am trying to do. (In other words,
> should I touch the CF default settings?)
>
> Lucus, in the Performance Monitor there is a chart of simultaneous requests
> (but I dont know how to log it.
> The number of simultaneous requests at any one time seems to always be an
> even number between 0 and eight)
If you can tickle the code add the GetMetricData("PERF_MONITOR")
function to Application.cfm/c or put it in OnRequestEnd, or both is even
better if you can, and grab some of the parameters shown there. You can
see how many requests are running at that moment, etc., it has some
useful numbers. Store the bits you want incrementally into a application
scope struct with a timestamp or some such and dump that to see what is
going on.
You can also add a getTickCount() to both ends of the page and see how
long the page took to process, it amazes me how ofter a slow page has
nothing to do with CF but is dependent on the connection (FireBug comes
in handy there)
Assuming x86-based CPUs and unless you have an old server they have
HyperThreaded cores and the OS thinks there are two CPUs where there is
actually one with its two internal bits. So the Simultaneous requests
number is always an even number as CF farms out threads per CPU. If you
have a typical dual-dual Xeon box you have 2 Dual Core HyperThreaded
CPUs, really 4 processing cores but the OS will report 8 CPUs. With the
processing speed available now the old rule-of-thumb of 5
threads(simultaneous requests) per CPU is long gone 10 or more is OK
(assuming good SAS/SCSI drives, lots of RAM, etc).
With "Simultaneous Requests" meaning the number of pages CF is
processing at any one moment as soon as the number of requests rise
above the number of CPUs there is internal thread switching going on in
CF as well as the overall OS task switching so other performance issues
creep in. We found on one client's site that it used to suddenly bog for
no apparent reason and it was traced to folk doing file uploads into the
management system of the site (a glorified CMS thingo). When there is a
file upload going on one CPU core gets dedicated to that task and become
unavailable to the task switching pool so there could be a performance hit.
Its only half an answer but I hope it helps. (IOHAABIHIH, is that a new
acronym? I don't think so :-))
--
Yours,
Kym Kovan
mbcomms.net.au
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"cfaussie" group.
To post to this group, send email to cfaussie@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/cfaussie?hl=en
-~----------~----~----~----~------~----~------~--~---
