Re: Request Protection setting vs. CF's Simultaneous Template Requests setting
David Stockton
On Wednesday, March 27, 2013 7:42:12 PM UTC, Richard Davies wrote:
I'd like to better understand the relationship and interaction between FusionReactor's request protection setting and the "Maximum number of simultaneous Template requests" setting in the CF Admin.Both of these settings supposedly control the number of concurrent requests that the server can handle before additional requests are queued.
* Should both settings be set to the same value? Or is there a reason one might set them to different values?
* What happens if the settings are different? Which one overrides the other one?
* Are there any advantages to using one setting over the other?
Charlie Arehart
Thanks for the thoughts, David. This is of course an area that’s fraught with lots of peril as there’s generally little information (about CF request queuing) and lots of opportunity for misunderstanding (about its settings). I want to offer first just a couple of points of clarification for readers, and then some questions and new considerations for those with this question, or interested in the relation of FR CP alerting/queuing and CF’s request thread settings (sadly, this is another long “Charlie note”. I just don’t see how I could shorten it. Hope it’s helpful to those with the patience to press on, especially to Richard as you’re trying to sort things out as you asked.)
First, David, you say that “ColdFusion also has a configurable queue size for the requests in its queue”, but readers should note that this queue size setting he refers to (“Maximum number of queued JRun Threads”, at the bottom of the CF Admin Request Tuning page) is only available in Enterprise, Developer, or Trial editions. In Standard, it doesn’t even appear as an option (though I think it is set to what is in fact the Enterprise default of 1000).
Second, you say, “If you want to use only the ColdFusion queue, you would not set its value (or set it higher than the CF queue size).” You surely meant “you would not set FR’s value”, but I’m just clarifying if it wasn’t clear to anyone.
And by FR’s value, it may be worth clarifying that he’s referring to the CP settings page and its setting for “request protection”, as the number at which to detect and implement protection, and he means setting the action to “queue and notify”. (Richard and he of course knew exactly what they were referring to. I add this for any who may have missed it. BTW, I never tend to use anything but “notify” for CP alerts on servers I work with, to focus solely on fixing problems rather than trying to “prevent” them, but that’s a personal preference.)
Finally, you say, “If you want to use both, you would set them in this order (highest first) CF queue size, FusionReactor value, CF Maximum simultaneous requests.” I have a few thoughts (and a question) on that.
In case any may read that too casually, we should note that the “queue size” is not like the other two values. It’s a max number of requests that could be held in the queue (before they would timeout—another setting that’s configurable in CF Enterprise but defaults I believe to 60 for Standard), so by “in order” I suppose you mean it would be a large number, like 1000.
Then in saying set the “FR value” higher than the CF “max simult reqs”, though, I’m curious: if the former was 25 and the latter was 20, I’m not sure what that would gain. Generally one would think that there should never be more than the “max simult reqs” number of requests running, to therefore ever reach a higher FR CP alert or queue value (at least in CF Standard. I’ll offer a thought on Enterprise in a moment).
On the other hand, someone may reasonably think that if they set the FR CP alert (or queue) value to LESS than CF’s “max simult reqs” value that then FR would step in BEFORE that limit was reached. And again, that would be so, at least in CF Standard.
But there’s a real gotcha to consider with respect to CF Enterprise (or Trial or Developer) because that “max simult requests” is then NOT the sole limiter to simultaneous requests, despite its name. That name’s actually a holdover from before CF 6, when (again in Enterprise at least) were were now allowed to configure separately from that a max number of flash remoting requests, and incoming web service requests, and CFC requests made via HTTP (such as from Ajax clients, or Flex apps not using remoting, for instance).
Here again is an area that is fraught with lots of peril, for lack of information and general misunderstanding. The “max simult requests” (in Enterprise) refers to any CFM page requests which are NOT of those other 3 sorts, which is why the Admin (in Enterprise) says that the 5th field (“max jrun threads”) should be greater than or equal to the sum of the 4 numbers above it. So my point is that in Enterprise, “max simult reqs” is not the only thing to consider in deciding how to set the FR CP “request protection” value. But even then, it’s not as easy as it seems.
First I want to ask, David, if you’d agree that FR does NOT pay attention (in CF Enterprise) to which kind of those “4 types” of requests it would be watching out for in its “request protection” setting.
Because, therefore, someone could have FR CP’s “request protection” set to 25, and have the CF “max simult requests” value set lower at 20 (as it seems you’re proposing), and STILL find that FR CP alerts about “too many requests are running” (or starts queuing requests) when there are, say, only 18 CFM requests (less than the “max simult reqs”) but also 3 flash remoting requests (perhaps 2 viewers of FR and someone watching the CF Server Monitor), and 5 incoming web service calls (just as an example), for a total of 26 total requests. Note that this is alerting (or queuing) even BEFORE the “max simult reqs” value is reached, which may be what you were thinking when you proposed (David) that one might want to set the FR CP level higher than “max simult requests”. It’s just that in CF Standard, I couldn’t see how that would make sense (to have the FR CP queuing value higher than CF’s).
But then the converse is true also: one may have FR CP’s “request protection” set lower (let’s say 20), and have the CF “max simult requests” value set higher (let’s say 25), under the thinking that (at least for alerting) you would want to be notified before it reached that “max” level. But again, considering that in CF Enterprise there are those 3 other types of requests, one could find that FR never sent an alert even when a problem condition did exist. Consider if the max flash remoting value was set to 5 (as I often see in some shops). What if all 5 such threads were bottlenecked for some reason? That would cause any new requests (that used Flash remoting) to queue up now (again, in CF Enterprise) because that flash remoting limit was reached. But FR would never detect that as a condition, because it does not break down those 4 different types of requests (in CF Enterprise).
That would be a really nice addition, especially now that with FREC (FR Extensions for CF, a free extension for FR 4+), you would have (from CF) that information (unless somehow that’s not available at that point yet in the code doing the CP checking), as it’s something that not even the CF Server Monitor handles (its alerts, too, are based solely on “all requests”, not distinguishing the potential impact of bottlenecks in reaching the limits for the “4 different kinds of requests”). At least FR can be excused because it was created before these Enterprise distinctions were added (and also, FR is technically a generic Java server monitor, not specific to CF, as the CF Server Monitor clearly is. Fortunately for us FR users, FREC does give us lots of info that is far more CF-specific, at least in the logs it creates.)
Anyway, Richard, if you’re still reading, I offer all this because you were asking about the relationship of FR to CF’s queuing. As I hope I’ve explained well, it’s just not as easy as it seems on the surface, given especially these differences in CF Enterprise and these 4 different kind of “request pools” (and their queuing).
If I’ve misunderstood or mistakenly said anything, I welcome feedback, of course.
/charlie
--
You received this message because you are subscribed to the Google Groups "FusionReactor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fusionreacto...@googlegroups.com.
To post to this group, send email to fusion...@googlegroups.com.
Visit this group at http://groups.google.com/group/fusionreactor?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
David Stockton
David and Charlie,
Thank you both very much for your replies. They were very helpful and informative (and like Charlie mentioned, bring up many of the nuances involved with these settings that aren't immediately obvious.)
I would be interested in another response from David regarding Charlie's question in regard to how FR sees/handles the 4 different types of requests that can be configured in CF. I too assume that FR doesn't distinguish between them, but it would be nice to know for sure.