Ajas, yes it's ok to leave FR running in production. Indeed, there is no "on" or "off". If it's installed into a CF (or Railo or BD or J2EE server) instance, it's running, all the time.
Now, you mention opening the FR interface, and specifically the System Metrics page refreshing every 5 seconds. That's a different issue entirely: I have seen some browsers/systems become overwhelmed by that over a long time, due not to any problem with FR itself but due to bugs in Flash. So I would recommend you think twice about leaving it open in this way on a production server. Now, there's no reason you couldn't open it and leave it not refreshing (that's an option in the top right corner). Again, it's not the FR interface being "open and refreshing" that makes FR "do its job". It's monitoring CF (and tracking its data in memory and in logs) all the time. The interface is just one way to look at that data. HTH. /charlie From: [email protected] [mailto:[email protected]] On Behalf Of Ajas Mohammed Sent: Tuesday, July 20, 2010 5:08 PM To: [email protected] Subject: Re: [ACFUG Discuss] CF 7 - Maximum number of simultaneous requests Thanks Steve and Charlie for your suggestions and thoughts. Steve, yes, I have to say we have been very lucky as far as low cpu and low memory usage is concerned. We have had Fusion Reactor for almost 7 months and I have never seen memory or cpu go up. Thanks for the suggestion about upping the max no of requests. Since its 8 now, I am thinking of making it 12 on one server and leave it 8 on the other so that if something happens, its only one server that gets affected. Charlie, yes you are right about 24 request does not mean FR is reporting more. Its very possible that most requests take maybe 1sec and hence 24 requests are possible. Yeap, any requests that couldnt run will be queued by CF. I will try CFSTAT. I know you mentioned that in one of your recordings and how it does not affect the performance etc. Well, in my case, I usually cheat in FR and the way I do it is, I see slow requests, and when I have slow running pages, they are usually queued up like say 4 or 5 them running and then I know server is on load as these pages wont finish running. Ofcourse, I wont get the count of queue like I would using CFSTAT but it gives me an idea that there are requests which are taking time and hence queue is up. Is it a good idea to always keep FR ON on production system? Also, how about keeping the System Metrics page open every day and let it refresh on 5 secs? Is it going to hurt anything? Steve,Charlie,others, this box does CF work only and is purely for our web application. It does not do anything else. So, I will try setting Max no of request to 12 and see how it goes. :-) Thanks, <Ajas Mohammed /> http://ajashadi.blogspot.com We cannot become what we need to be, remaining what we are. No matter what, find a way. Because thats what winners do. You can't improve what you don't measure. Quality is never an accident; it is always the result of high intention, sincere effort, intelligent direction and skillful execution; it represents the wise choice of many alternatives. On Tue, Jul 20, 2010 at 2:34 PM, Charlie Arehart <[email protected]> wrote: Ajas, besides what Steve has rightly recommended, I'm curious about your observation of how the req/sec went "as high as above 24" but the "max simult requests is 8". Just to be clear, the hitting of 24 does not mean that somehow FR is reporting more than should be possible. As you note, that (the dark blue) is reqs/sec, and you could have many reqs that run in less than a second (and I'm pretty sure that average is calculated for all requests executed over a 5 second span). So you could hit 24 and still be only running in the 8 request slots. Notice instead that the gray or light blue (when it's under the dark blue) is instead the number of "active requests" running at each 5 second intervals. You'll note that that never does go above 8 in your reports. So as to whether you should increase it, a factor would be if you found FR reporting that you were ALWAYS at or near that limit, because then naturally any requests that couldn't run would now be queued (by CF, which is not viewable in FR but instead in either CFSTAT [on any version of CF except for multiserver deployments] or the Multiserver Monitor [in CF 8/9 Enterprise/Developer]). If you consistently have lots of queued requests (or FR showing always the active requests count near your Simultaneous requests number), those people are then waiting to run, and as Steven says, if your box is up to the task, you could try to let more of them run at once. Hope that helps. /charlie From: [email protected] [mailto:[email protected]] On Behalf Of Ajas Mohammed Sent: Tuesday, July 20, 2010 10:52 AM To: [email protected] Subject: [ACFUG Discuss] CF 7 - Maximum number of simultaneous requests Hi, I am attaching a snapshot of FusionReactor's system metrics page which shows no. of requests/sec. Recently, it went to as high as above 24. We use CF 7 on Windows Server 2003, Intel Xeon CPU E5450 @ 3.00 GHZ, 3.99 GB of RAM and the setting for Maximum number of simultaneous requests is set to default 8. We have not changed any JVM Memory settings. The Minimum JVM Heap Size (MB) is blank and Maximum JVM Heap Size (MB) is 512. Anyone wants to share their thoughts on the setting for Maximum number of simultaneous requests, Maximum JVM Heap Size (MB) or any general suggestions? Is it ok to up the Maximum no. of simultaneous requests? Thanks, <Ajas Mohammed /> http://ajashadi.blogspot.com We cannot become what we need to be, remaining what we are. No matter what, find a way. Because thats what winners do. You can't improve what you don't measure. Quality is never an accident; it is always the result of high intention, sincere effort, intelligent direction and skillful execution; it represents the wise choice of many alternatives. ------------------------------------------------------------- To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by FusionLink <http://www.fusionlink.com> ------------------------------------------------------------- ------------------------------------------------------------- To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com -------------------------------------------------------------
