crasp protection settings

[Snake]

Greetings,

Can someone enlighten me on what should be put in the request
protection?
If my max requests is set to 8 in the cfadmin, then then every request
over this is queued, how would the Fusion Reactor crash protection
ever kick in as surely I would never exceed that number of requests
anyway, but it seems I do.
Does requests mean something different in FR than it does in the
cfadmin ?

Snake

[Greg Spencer [FusionDebug Team]]

Heya Snake,

Essentially these two features are the same but there are a couple of
reasons to favour our version:

As far as I understand it, the CF Max Requests actually defines the
number of threads which are brought up when CF starts. CF will this
use all of these threads up in order to fulfill requests.

With FusionReactor, you can set the maximum requests lower and, if you
have any other process running within your container, it will still
have free threads. Additionally, you can get into a deadlock situation
if you happen to be running the maximum number of CF requests and all
of these requests are attepting to start a new thread (we have seen
this with a cfx tag which was trying to access another service over
HTTP.) With the FusionReactor method, you can keep a couple of threads
spare in order to service these requests.

I'll grant you, this is a fairly obscure case, but cases like these do
arise and it is our job to be as comprehensive as possible, where as
the CF Admin options are there to cover the basics.

With newer versions of CF, you have a bit more control over the queued
requests, but if you are not planning to upgrade then we give you this
flexibility whatever version of CF you are using. Timeout queued
requests, configure the timeout message or redirect to another page.

But I think the main advantage to our Request protection is one of
reporting. FusionReactor will keep track of the number of times
requests had to be queued and you can see the current an total number
of times this fires in the Enterprise Console.

I hope answered your question...

Greg
FusionReactor Team

[Russ Michaels]

so are u saying, disable the max number of simultanious requests in cfadmin, and use the FR setting instead, with the same recommended value ? which is 5-8 per cpu

 

Russ

 

--
---
Russ Michaels
I.T. Consultant

*Disclaimer:- nothing I say via email  is meant to offend, aggravate, annoy, insult, belittle or in any way imply anything toward any particular person unless expressly stated to the contrary. Mis-interpret this email at your own risk.

[Greg Spencer [FusionReactor Team]]

Hey Russ,

No. We see the two mechanisms as compatible and suggest is using them
together. You can use the cfadmin request limit as your absolute upper
boundary, then use FusionReactor Crash Protection as an ideal upper
boundary. The advantage here is that you will get warnings and
statistics from us if you see slight spikes in request quantity but
should your server be seriously inundated with requests, then CF
itself will also be helping to deal with this. Because the CF request
limit is applied earlier in the process chain, this will result in a
slightly lower overhead and should help keep your server alive.

As far as actual values go, maybe pick something like 5-8 per CPU for
FusionReactor and 8-10 per CPU for CF

I hope that has helped. If you have any other questions then please
let us know.

Kind Regards,

Greg
FusionReactor Team

On Aug 8, 4:40 pm, "Russ Michaels" <russ.micha...@gmail.com> wrote:
> so are u saying, disable the max number of simultanious requests in cfadmin,
> and use the FR setting instead, with the same recommended value ? which is
> 5-8 per cpu
>
> Russ
>

> On 8/3/07, Greg Spencer [FusionDebug Team] <greg_spen...@intergral.com>

> own risk.- Hide quoted text -
>
> - Show quoted text -

[Russ Michaels]

ok if CF has the higher value, how is CF request
limit is applied earlier in the process chain ?

Russ

[Darren Pywell]

Hey Russ,

It's been a while since we last spoke... hope all is well...

Greg asked me to jump in and explain the mysteries of the Maximum
number of simultaneous requests.

Basically Maximum number of simultaneous requests in the CF
administrator changes a JRun setting called activeHandlerThreads in
the JRunProxyService (found in jrun.xml) which controls the number of
handler threads that JRun creates to take requests from the IIS/
Apache/... Web Server Connector. So CF is really reconfiguring JRun!
This is why you have to restart the CF/JRun server whenever you change
this setting BTW.

FusionReactor runs inside JRun and is called as one of the very first
things that a request does but it is the JRun activeHandlerThreads
setting that actually controls the number of requests threads... which
each call FusionReactor at the start of handling a request. So in this
way the "CF" limit is applied earlier in the chain.

All the best,
Darren

On Aug 10, 12:36 am, "Russ Michaels" <russ.micha...@gmail.com> wrote:
> ok if CF has the higher value, how is CF request
> limit is applied earlier in the process chain ?
>
> Russ
>

> On 8/9/07, Greg Spencer [FusionReactor Team] <greg_spen...@intergral.com>

[hay...@gmail.com]

This is great information about how the CF and FR settings are
related. Thanks for the clarification.

[Russ Michaels]

right so the FR setting will kick off before the CF setting. But other than the alerts to tell me there are queued requests, is there any other benefit. I.E. is there any difference between FR queuing requests or CF queuing requests ?

The impression I get is that if FR alerts me of queued requests then this means there is a long running/hanging request or requests that is causing this. But this is pretty normal on a shared server with all the shitty code people upload, and when I had this enabled and set it to a value of 8 (same as CF setting) | immediately started getting shedloads of alerts, so I couldn't really see any benefit of it, as I just spend all day reading and deleting those alerts.

 

Russ

 

[Greg Spencer [FusionReactor Team]]

Well, if you put it that way then no. If your machine is permanently
throttled and you don't care why then you can create almost the exact
same effect from both CF and FusionReactor. The only difference I've
seen so far is with earlier versions of CF where you can't timeout
queue elements and so CF can end up with a huge queue of requests for
pages which users are probably not even waiting for anymore.

FusionReactor was really designed for a system where you want the best
CF performance possible, rather than a system that you assume people
are going to abuse and you have no problem blindly queuing and killing
requests in order to protect the server from malicious code. One of
the functions of Crash Protection is as an early warning system, but
it sounds like your server is constantly in this state so that aspect
really doesn't bring you anything special.

I'd recommend just using CF in this case, that way you can still
enable the other two forms of Crash Protection and get notifications
for them without having to worry about your inbox being flooded with
Request Count notifications.

I hope that helped.

Kind Regard,

Greg
FusionReactor Support

On Aug 14, 12:45 am, "Russ Michaels" <russ.micha...@gmail.com> wrote:
> right so the FR setting will kick off before the CF setting. But other than
> the alerts to tell me there are queued requests, is there any other benefit.
> I.E. is there any difference between FR queuing requests or CF queuing
> requests ?
> The impression I get is that if FR alerts me of queued requests then this
> means there is a long running/hanging request or requests that is causing
> this. But this is pretty normal on a shared server with all the shitty code
> people upload, and when I had this enabled and set it to a value of 8 (same
> as CF setting) | immediately started getting shedloads of alerts, so I
> couldn't really see any benefit of it, as I just spend all day reading and
> deleting those alerts.
>
> Russ
>

[hay...@gmail.com]

In 7 years of CF development, the most overlooked development item I
see is performance and scalability. People just assume that if
something works then it's okay to deploy, regardless of scale. Greg's
right, the perceived value of the FR crash protection settings depends
highly on the operating environment and what is deemed to be
acceptable server performance. If you don't mind queuing up requests,
you'll probably become quite annoyed at the continual e-mails. From
my perspective, *any* queued requests is a bad thing as people are
just waiting in line as slow requests finish up. FR crash
notification has given us previously unavailable and valuable insight
into what CF pages may need some tweaking.

On Aug 14, 3:27 am, "Greg Spencer [FusionReactor Team]"

[Russ Michaels]

but then you probably have a dedicated server with just your site on it, not hundreds of different sites.

 

I think what I am still not getting is how is fr queuing requests any better than letting CF do it, other than the alerts.

Gregs reply seems to imply that i'm "letting CF throttle the server". Surely a queued request is a queued request ?

 

Russ

 

[Greg Spencer [FusionReactor Team]]

I agree that, in your situation there really is no benefit in using
Request Quantity Crash Protection over CF queuing. As already noted, I
would actually recommend you use CF in this case so that you can have
full use of the other forms of Crash Protection.

The benefit of FusionReactor (relating specifically to this feature)
is that it enables you to see how often, and pinpoint exactly why your
server is so loaded that it is forced to queue requests. (We assume
that this is an abnormal state rather than standard behaviour.) If
this doesn't interest you then it really isn't any better. Arguably it
is worse if you are receiving unwanted notification emails.

As far as queued requests being the same wherever they are queued:
That really depends upon the queue management. Features such as queue
timeout and redirect pages are features which have now also been added
to CF8, but with FusionReactor you can take advantage of them whatever

version of CF you are using.

Out of curiosity, what would we need to add to this feature for it to
become a benefit for you over the standard CF queuing?

Kind Regards,

Greg
FusionReactor Team

On Aug 15, 1:13 am, "Russ Michaels" <russ.micha...@gmail.com> wrote:
> but then you probably have a dedicated server with just your site on it, not
> hundreds of different sites.
>
> I think what I am still not getting is how is fr queuing requests any better
> than letting CF do it, other than the alerts.
> Gregs reply seems to imply that i'm "letting CF throttle the server". Surely
> a queued request is a queued request ?
>
> Russ
>

> ...
>
> read more »- Hide quoted text -