CF 8 Monitor: what's the impact on production? you may be surprised
The new CF8 monitor is of course very powerful, and naturally some are immediately concerned about its overhead, especially if they're considering running it in production. And it's indeed true that depending on what you enable, it can be very resource-intensive and could even bring down a server under load. But you don't NEED to enable all the features of the monitor to get benefit. I'll explain here what they are and what their impact is. In my next entry, I'll show you how you can even get value from the monitor even if you don't enable ANY of the monitoring features. Sound illogical?
The point to note is that there are three buttons at the top of the monitoring page which "start" different monitoring features. So what are the implications of starting each of the optional monitoring features?
- start memory tracking: this has the highest overhead, very substantial. Even on a low-traffic developer machine, you'll see a big hit from running this. Reserve its use for only brief periods (minutes, seconds) to gather some info for analysis. Use in production only in emergency.
- start profiling: this has much less overhead. The help page for the monitor calls it "minimal"
- start monitoring: again, as with profiling, it's labeled as having "minimal" overhead.
Definitely check out that help page (from the front page of the monitor) to learn more about what each button does.
So what value is there with none of them enabled? I'll pick that up in the next entry.
But if you hear someone say "don't use the monitor in production", please make sure they're clear on all this. There are 3 features you can enable, or none at all, and each provides different info at different costs--some of it zero. Who says there's no such thing as a free lunch?
I'm just saying - keep it in mind.
Thanks,
Hemant
Still, as the next entry clarifies, there does seem to be an awful lot of good info that can be obtained even without ANY of the "start" features enabled. And that, at a minimum, seems an excellent reason to still use the monitor in production. People just need to be sensitive to what costs what. :-)
The memory tracking is, indeed, fairly resource intensive (I seem to recall about a 20-30% overhead in most situations but higher during extensive object creation, e.g., framework startup). I would definitely advise keeping memory tracking off in production except for very brief periods to debug / analyze specific problems. The main impact seems to be that memory usage increases (presumably to store the data that lets CF8 track memory usage?) and that memory does not always seem to be freed up when memory tracking is turned off.
My experience so far has been that monitoring and profiling truly do have minimal impact and can be left enabled all the time. That has been on Red Hat Linux and Mac OS X, on fairly fast servers. I'm sure it's a YMMV kinda thing tho'...
I am getting permission denied status line if I add another instance of the CF server .I have modified the multiservermonitor-access-policy.xml file.
Still the error says:Error #2048 url: 'http://wlpv0002.edc....' Ensure that you have allowed access to this server by
changing the multiservermonitor-access-policy.xml file.
Please help me to resolve this issue.
If not, did you see the troubleshooting tips for this problem that I offered in the 4th part of my series on the CF Server monitor? That article (and the others) can be found here: http://www.carehart....
More specifically, the page on which I disuss xml file and some common challenges is here: http://www.adobe.com... (if the line breaks in my comments here, please be sure to join it back together).
Hope that's helpful
So, if you are using FP versions mentioned on the above article, then simply Ignore the multiserver-access-policy file and put the following crossdomain.xml file, with appropriate client machine permissions where you are running multiserver Monitor, and put this crossdomain under the CF Server wwwroot, which you are trying to connect to. Try it, should work.
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedi...">
<!--Generic policy file for flex app access, it should be made more restrictive -->
<cross-domain-policy>
<site-control permitted-cross-domain-policies="all"/>
<!-- <allow-access-from domain="*.example.com"/> -->
</cross-domain-policy>
First, let's be clear for readers: the multiservermonitor-access-policy.xml is just a different name/location for the same crossdomain.xml file Jayesh mentions, as I discuss in the article I pointed to. Adobe puts it in the CFIDE directory during installation.
But as the article Jayesh points to shows, there has been a change in the player security model. This section seems especially significant to this part of the discussion: http://www.adobe.com...
The good news (for those on CF9) is that I see Adobe is putting this crossdomain.xml file in the webroot (in addition to the other in the CFIDE) and it DOES have that new site-control line that Jayesh points out. More on that in a moment.
But for those on earlier editions of CF, it (the crossdomain.xml) wouldn't be there unless you or someone else put it there. And even on CF9, it's possible that it's not there because depending on how one configures CF (whether using the built-in or external web server, and whether one choose an external web server during installation or later uses the web server configuration tool), you may not even find that crossdomain.xml file having been put in the webroot by Adobe. If it's not there, then it's having no influence.
But if it is there, or if you add it, as Jayesh suggests, my read of this Flash security article is that the "all" value of this new site control line should mean that lower-level policy files can override this root one.
Still, I'm finding that the fact that this default root crossdomain.xml has the commented out "allow-access-from" value is blocking access even if the lower level multiserver policy file does uncomment and change it to allow access (again, see my article on the Server monitor for discussions of the change you need to make in this multiserver xml files).
So I needed to uncomment and change that there, AS WELL AS in the multiserver.xml file.
If I've got this right (that we need to change both the CFIDE multiserver xml and the root crossdomain xml files), it would be nice if Adobe might (in the future) put a reference to that in the multiserver xml file (as a comment) in case it may help someone facing a problem.
And with regard to changing these files, please note this VERY IMPORTANT point I make in my server monitor article, in the section on the multiserver xml file: even when you change it (or the crossdomain.xml file), since it's just a static XML file, it's likely the browser will have cached the page. You need to force the browser to go get the new file version (using techniques I discuss there). Even after doing that, you may still need to close and reopen the browser for the flash-based multiserver monitor to pick up the changed xml.
Then again, it may be that all this is still not at the root of Nimi's problem. :-) Let us know. Even so, it should have been helpful for readers. Thanks, Jayesh, and I hope my additional comments get people still further along.