FR 3.5.1 standard on CF 7 Enterprise - Upgrade to CF9 Enterprise
Ajas Mohammed
We have FR 3.5.1 standard on CF 7 Enterprise standalone installation. We are planning to upgrade CF 7 Enterprise standalone installation to CF9 Enterprise standalone i.e. straight upgrade and not multi server mode.
As far as I know, after the upgrade, FR 3.5.1 will stop working because its configured for CF 7 at this moment.
So to make it work with CF 9, I have to *rerun* the FR 3.5.1 installation file again and during installation it will find or I can search for instances, and can find CF9 instance. So far so good. Thanks Charlie, I remember these instructions from your mail.
Now the question is
1. When I run the installation file, apart from finding instance, do I need to worry about anything else like the step where in you say Yes, stop CF instance or No, do not stop CF instance based off if your CF is running as local or domain acc. In this case, it will be a domain account.
2. The other question is general question. CF 9 also has its own monitoring built in, so do I really need FR 3.5.1? How difficult will it be if for whatever reason, management says, remove FR 3.5.1 from CF9. Will it be as easy as run the uninstaller and not losing anything or not breaking anything?
Just to clarify for the readers sake, I *LOVE* FR, its amazing tool, awesome product, very lightweight and I will continue to use it, but I want to have my answers ready in case management asks me this question no 2.
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.
John Hawksley
On 8/10/10 16:15 , Ajas Mohammed wrote:
>
> 1. When I run the installation file, apart from finding instance, do I
> need to worry about anything else like the step where in you say Yes,
> stop CF instance or No, do not stop CF instance based off if your CF
> is running as local or domain acc. In this case, it will be a domain
> account.
FusionReactor itself runs as whichever user the CF account is running
under. The installer runs as whomever you're logged in as when you run
it. If the person you're logged in as has the power to restart
services, the Stop and Start instance should go through fine. If they
don't you can stop the service yourself (from a cmd window using runas,
for instance), run the FR installer, then start it again afterwards.
In all cases the person running the FR installer must have permission to
write to CF's files.
>
> 2. The other question is general question. CF 9 also has its own
> monitoring built in, so do I really need FR 3.5.1? How difficult will
> it be if for whatever reason, management says, remove FR 3.5.1 from
> CF9. Will it be as easy as run the uninstaller and not losing anything
> or not breaking anything?
Yes, it should be just a question of running the uninstaller and
restarting CF9. The uninstaller should unhook FusionReactor from
ColdFusion, and delete its own folder cleanly.
We have three manager briefing studies at:
http://www.fusion-reactor.com/fr/benefits/managers.cfm
we also have a feature matrix here:
http://www.fusion-reactor.com/fr/benefits.cfm
In addition to that you can also inform your manager of the considerable
investment in time and know-how you already have in FusionReactor, and
the existing relationship you have with the team here at Intergral :-)
Hope that helps!
All the best,
-John
--
John Hawksley
Senior Engineer
Intergral GmbH - Schickardstr 32 - D-71034 Boeblingen - Germany
Geschaeftsfuehrer: David Tattersall, Darren Pywell
Sitz der Gesellschaft: Boeblingen
charlie arehart
FusionReactor?" The answer is very definitely "yes".
I help people every day with solving server problems, using both tools, and I get
asked this often. I can tell you that not only is there no reason to fear running FR
alongside the CF Server Monitor (FR does not conflict with it in any way, and adds
very little overhead), but more than that, there are in fact several things that FR
offers that the CF Server Monitor does not.
The link John offers for the comparison at the FR site is definitely something to
check out. Beyond that, I've been meaning to put together something to compare the
two. You've spurred me to go ahead and create at least part of that (not so much a
complete comparison of the two, feature for feature, but just addressing your specific
question, of what FR offers that the CFSM does not.)
To be clear, I've written also about the Server Monitor (including a 4-part series at
the Adobe site, available at my http://www.carehart.org/articles/ page), so I
appreciate its benefits, and it does offer things that FR does not. Still, there are
many reasons why I (and many I help) do run both of them, even at the same time on the
same server.
Here are at least some of the reasons why someone who has the CFSM would also still
want to use FR:
1- FR offers tremendous logging, whereas the CF Server Monitor (CFSM) does none at
all. FR logs not only the details of every request, and every query (if query wrapping
is enabled), but the resource log provides high-level metrics every 5 seconds about
the server (number of requests running/finished, queries running/finished, CPU used in
CF/server, memory used/allocated/free/etc, and more). When I help people, this is
often one of the most important things I review with them, both to see what's going on
now, recently, or during/prior to a problem.
2- FR's default behavior is to track every request, showing you the details of all
running and recent requests, with very little overhead. The CFSM only tracks requests
if you turn on "start monitoring", and of course some are leery of turning on any of
those "start" buttons, for having heard warnings of the CF Server Monitor causing
overhead.
3- Similarly, if you want FR to watch the queries for a given DSN, you just wrap that
DSN (again, light overhead). To see queries in the CFSM, you have to enable "start
profiling", which again is another thing some warn can cause overhead, and which
applies to all requests by default (which only adds to why it can seem to increase
overhead, if you may have only wanted to track queries for one or a few datasources).
Also, the "start profiling" does fare more than just enable query tracking....
4- For instance, if you want to get a stack trace for a running request, you have to
again enable "Start Profiling" in the CFSM, whereas in FR you can take a stack trace
on any request at any time. There is never any ongoing overhead you must pay in order
to see the stack trace for any request, at any time.
5- Along the same lines, in order for the CFSM to be able to fire its "alerts", you
have to have enabled "start monitoring" (which is easy to miss, so sometimes people
never notice it as being the reason they are getting no alerts!) With FR, however, if
you enable Crash Protection, it takes effect immediately (and again with virtually no
overhead for having them enabled).
6- FR's memory status graph properly shows the 3 key things needed for managing the
heap: the amount of heap used, allocated, and the max you've configured. Tragically
(in my experience), the CFSM shows only the first two, which can easily lead to
misunderstandings. If memory appears "high" in the CFSM graphs, it may only be that
heap use nearing the current heap allocation amount, which may not be anywhere near
the max! (Fortunately, the CFSM memory alerts are triggered by a set number of bytes,
not a percent used, though I prefer how FR does it instead by a percent of free memory
remaining. I do wish both would instead also offer a means to say "and only fire if
memory remains high x seconds after forcing a GC", which would allow it to recover
from the JVM just not having taken the time to do a GC.)
7- In pages showing requests, FR shows the URL and query string for requests, whereas
the CFSM shows things only by path/filename. This can be a real challenge when working
with front-controller design patterns, where all requests tend to use only one
index.cfm file, varying only by the query string. (There is in fact a little- known
"aliasing" option in the CFSM to help with that problem, as I discuss in one of my
articles above). Conversely, though, this showing the underlying path/filename can be
an advantage sometimes, as FR does not show the underlying path/filename that was used
for a given request, should that ever be important to know.
8- FR offers a "recent request" page, which I think is one of its most important
pages, as it lists the last 100 (by default) requests, so you can see not only what IS
running but also what HAS RECENTLY run, which can be just as valuable to know if CF is
or is not running other requests ok. Sadly, the CFSM has no such page. You might think
you could "fake it" by using the "slowest requests" page and setting it to show
requests slower than 0 seconds, but even then, the page is designed to list things in
order of slowness, not by what have run most recently, so you can't really ensure
you're seeing "the x most recent requests". Also, as some have noticed, the page
refresh mechanism in the CFSM isn't as straightforward as FR's (you sometimes have to
leave and return to a page to get it to update), which can be all the more annoying
when sitting on these request pages to view what's currently happening.
9- While FR offers an option to see the details about Flash Remoting requests (showing
you the CFC and method being called and their arguments, as available in a tab within
the running/recent request detail pages), there's no such equivalent in the CFSM.
10- The FR request details page (for running/recent requests) always shows the details
of any queries run in the request (if wrapping is enabled for its datasources).
Amazingly, the CFSM does not offer that. The best you can do is view the queries in
the "slowest queries" page, with the same issues as above (about the using "slowest
requests" to fake FR's "recent requests"), so you can't ever know "page X ran these
queries", whereas FR shows it both in its interface and (optionally) its logs.
11- the various graphs that FR shows generally always show data over a lot longer
period of time as compared to the CFSM. For instance, FR's "system metrics" graphs can
show a minute or an hour of data, and the graphs on the pages in the Resource section
default to showing about 10 hours of data. On the CFSM, the graphs never seem to show
more than a few minutes of data, at most, even if you open a page showing one and sit
it for an hour.
12- FR shows CF and system CPU usage (both currently, and over time in the graphs or
logs). There's no such CPU data in the CFSM.
13- FR reports how long the server has been up and running (on the System Metrics
page). The CFSM does not.
14- The FR System Metrics page offers a report (near the bottom) showing a count of
requests by their return/status codes, and you can view the details of any in each
category if they are among the "recent" pages (100 most recent, by default). The CFSM
does not offer any such tracking of requests by status code.
15- Many find the FR Enterprise Dashboard (in FR Enterprise only) to be more useful
and straightforward to setup than the CFSM's companion "multiserver monitor" (which
many don't even know exists, from my experience. Again, see my articles for more on
it.) The FR ED also offers a way to group servers (any way, such as by version, by
whether local or remote, etc.), whereas the CFMSM has no such grouping feature.
Finally, the FR ED offers a settings page with details for controlling the heartbeat
check that it does when pinging a monitored server, where the CFMSM does not. FR also
offers an AIR Enterprise Dashboard (separately purchased), which can popup from your
status tray to notify you when a monitored server is in not responding or is reporting
to be in trouble.
16- In case you may want to limit what requests are monitored, FR lets you control
that both for its Crash Protection feature (on the CP>CP restrictions page) and even
from all request monitoring (on the FR>FR Restrictions page). These can each also be
set to indicate whether they are controlling what requests ARE TO BE or instead ARE
NOT TO BE monitored. The CFSM offers no such limitations for what pages are tracked by
alerts (all or nothing), though the CFSM does offer the "filter settings" page in its
"settings" button (top right of the CFSM interface) that lets it limit what requests
are or are not monitored. Even then, though, it does that by the path/filename for the
requested file, rather than by URL as FR does, which could be an important difference
for some.
17- FR offers options to limit what queries are tracked (only track those x queries in
a request taking more than y ms, and separately, only track in the logs those queries
taking longer than y ms. The CFSM has no such query tracking limits at all (again,
which could contribute to why some feel that it can add burdensome overhead, if they
might otherwise fine-tune what it monitors).
18 - FR will monitor requests that are being made to CF in either the CF Admin or from
the CFSM itself, whereas the CFSM hides those by default (it's configurable in the
CFSM settings page). You may wonder if the CFSM or FR could tracks requests made by FR
to the server, but this is where there's an important architectural distinction: FR
runs as a servlet filter. Requests from its Flex interface to the server go to that
servlet filter (which is indeed running in the same process as the CF server being
monitored, just like the CFSM sends requests to the CF server being monitored), and
not really to a CF page. But the CFSM interface is sending request to CFCs in the CF
Admin API using Flash Remoting, and those CFCs execute just like any other CFM page
(albeit in a thread pool that Adobe has set aside for them). The FR interface instead
is never sending any requests to CF request threads. They never make it beyond the
servlet filter (for the CF instance) into CF itself. This means also that there would
never be any request that the CFSM could show about FR running on the server, which
was the key issue being raised for this point. (As an aside, the fact that you see a
.cfm file being requested when you load up FR in your browser address bar is simply so
that your external web server can connect this request to your CF instance. Again,
it's not really running any CF page, but instead that "cfm" file is just a servlet
filter mapping, for those who understand that.)
19- FR offers an option to list all running threads (including not just CF page
request but also scheduler and other important threads, which can sometimes be where a
problem lies, such as in mail spool processing, client variable purge processing, and
so on), and to create a thread dump (a list of stack traces for all running threads).
The CFSM has no such feature.
20- FR offers a feature to enable page request/response "compression" (known perhaps
by some as GZip compression, which means that the page request or response is
compressed between the server and the client, or vice-versa, if enabled in FR and
which will only take place if the browser indicates that it can process such a
compressed stream--most can.) This is configured using Compression section on FR's
left nav bar. The CFSM has no such feature. (Granted, some will note that you can
request page compression via your web server instead, but if you can't or don't know
how to use that, it's nice that FR offers this as an option.)
21- Similarly, FR offers a "content filter" feature (also on the left nav bar) which
lets you indicate if some string with a page's generated output should be changed to a
new value before the response is sent to the browser (whether for all or some URLs).
It's one of the less-used features of FR, for sure, but it's there if you need it, and
again the CFSM does not offer it. (To be fair, neither this feature note the last are
technically about "monitoring", so some would not hold it against the CFSM for not
offering it. I'm just "calling 'em as I see 'em".)
22- FR has always offered (and by default used) its own built-in web server for
serving up the interface when you request it. In the CFSM, such a separate internal
web server for the monitor (only) was added just recently in 9.0.1. Let me clarify a
point: some (even in Adobe) have suggested that this "new feature" somehow makes the
CFSM operate "out of process" from CF, even suggesting that this has some effect on
the long-held overhead concern that many have. But neither is true at all. To be
clear, the CFSM (like FR) is a Flex-based interface that accesses information from the
CF server. All that the internal web server option does (in either FR or the CFSM) is
offer a way to cause requests to that load the monitor (and for it to get its data
ongoing while its open) to use a dedicated web server. This web server would then of
course be separate from either an external one like IIS or Apache, or CF's
long-existing other built-in web server. The web server used also influences what
threads are used, technically, within CF, when the CFSM makes it flash remoting
requests into the Admin API CFC's that it calls. So by using a separate web server, it
also causes the monitor requests to not contend with "real" requests. (Again, FR
doesn't have this issue, because it doesn't ever make requests that contend with real
CF request page threads.)
23- Along those lines (about what web server is used to serve up the monitor
interface), FR also offers an option to control whether you want to be able to access
it from an external web server (like IIS or Apache) at all. Though many FR users don't
seem to notice it, that's enabled by default (so you don't HAVE to use only the
built-in web server for FR, but can access it via your external web server--or you can
disable it if you don't want to allow that.)
24- FR offers an option to let you define 3 levels of user access: administrator,
manager, and observer, with successively fewer abilities to control/change things
within the FR interface, such as if you wanted to let some people see some things,
while others could change things, and so on. Though many never notice it, this feature
is enabled either on installation or via the last section on the left navbar in the FR
interface, on the FusionReactor>Change Password page. The CFSM has no such set of
controls varying access levels (technically, the CF Admin Security page does offer an
option to define different username/password combinations for Admin and CFSM access,
by which you could say "x can access the Admin or CFSM, but y cannot".)
25- Finally, FR can run on more than just CF, including Railo, Open BlueDragon,
BlueDragon Server JX 7.1, and any J2EE/JEE server (including Livecycle), so if one has
a license for FR, it can be used to monitor far more app engines on a given box than
just CF. The CFSM, of course, runs only on CF (and can't monitor LiveCycle
deployments, which run on JEE servers). (Also, from my testing, the CFSM does not show
any JSP or servlet requests that come into CF, even though the Enterprise edition can
in fact run them. FR, of course, shows them without any difference from CF pages.)
So, like I said, the answer to "do I have any reason to still consider using FR if I
have the CF Enterprise Server Monitor?" is definitely "yes".
All that said, I want to be clear: there are still also many things that the CFSM
offers that FR does not. The CFSM has insight into many CF details (like info on
sessions, applications, template and query cache info, cfthread details, and more)
that FR doesn't currently have. Again, FR works the same on all the servers it
supports, so it doesn't currently have specific hooks into the CF Enterprise Admin
API, which the CFSM uses. I won't detail here all that the CFSM adds that FR lacks,
since that wasn't really the point of Ajas' question, and this email is long enough as
it is!
With respect to things they both do, I will grant that the alerts in the CFSM are a
little more flexible (the "unresponsive server" alert warns when "x requests" have
taken "y seconds", whereas FR has only the choice of one or the other: "when x
requests are running" or "when requests are taking y seconds". Also, it's nice that
the memory alert in the CFSM can trigger a GC.
So to be clear, I don't suggest that someone on CF 8/9 Enterprise (the only ones with
the CFSM) choose one monitor over the other, but rather that they simply take
advantage of each for what they offer--and it doesn't need to be an either/or
proposition: I (and many whom I support) have both monitors running (and enabled) at
once (even both CFSM alerts and FR CP alerts).
Finally, in case this may be shared somehow with others, I'll clarify that not only
have I not listed what advantages the CFSM offers, but I also have not even listed
here even all the features and advantages of FR (such as for someone who is not using
any monitoring at all). There are aspects of using it that are the same between the
two, and if someone is using neither, then the info above wouldn't be all that you'd
want to consider in deciding whether to use FR at all.
This was just answering Ajas' specific question about whether one who has the CFSM
might want to use also FR. As I hope I've made it clear above, the answer again is
definitely, YES. :-)
/charlie
PS Of course, if anyone thinks I've left anything out, please do share your thoughts.
I'd appreciate that before I turn it into a blog post.
> --
> You received this message because you are subscribed to the Google Groups
> "FusionReactor" group.
> To post to this group, send email to fusion...@googlegroups.com.
> To unsubscribe from this group, send email to
> fusionreacto...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/fusionreactor?hl=en.
James Holmes
CFTracker is the ability to see how much permgen space is being used.
A number of our issues have been due to permgen filling up and being
able to see this in FR would be really useful.
--
WSS4CF - WS-Security framework for CF
http://wss4cf.riaforge.org/
Barry Chesterman
difference.
With a medium load on the server, just having CFSM running caused our
server to fall over (and that wasn't even with all the monitoring
options on), but we can run FR and hammer our server and it runs fine.
Also, being able to get notice e-mails of thread dumps for slow
running requests and also for memory usage is really good - not sure
if CFSM does that?
Barry.
On Oct 12, 12:12 pm, "charlie arehart" <charlie_li...@carehart.org>
wrote:
charlie arehart
Well, I don't think I'm letting an NDA cat out of the bag when I report that...at
CFUnited, I was asked to demo FusionReactor 4, and one of its features is that it does
in fact gather and log permgen (and news of other juicy JVM memory portions). I didn't
want to mention that in the last note because a) the Intergral guys haven't talked
about FR 4 much and b) it wouldn't be as compelling if the list was of things that
were in the future.
So being the "glass half-full" kind of guy that I am, I'd say that when FR 4 comes
out, we should be able to add several (perhaps dozens of) more new reasons that one
would use FR even if they had the CF Server Monitor. :-)
/charlie
> -----Original Message-----
> From: fusion...@googlegroups.com [mailto:fusion...@googlegroups.com] On
> Behalf Of James Holmes
> Sent: Monday, October 11, 2010 7:42 PM
> To: fusion...@googlegroups.com
James Holmes
another reason to continue doing so.
--
WSS4CF - WS-Security framework for CF
http://wss4cf.riaforge.org/
charlie arehart
memory usage", yes, the CFSM does do that (per its Alerts feature that I referred to).
To be more specific, if one enables the "take snapshot" option when configuring a CFSM
alert, then that will be offered as an attachment in the email (if "send email" is
enabled for the alert). As for the performance differences, I did try to address that
in my list.
/charlie
> -----Original Message-----
> From: fusion...@googlegroups.com [mailto:fusion...@googlegroups.com] On