While performance tuning an existing Umbraco 6.1.6 installation, i came across rather large values of TTFB (time to first byte). I started investigating and some of the wait was do to application logic, but ImageGen and static files was having the same problem as well with TTFB values of 500ms+ for even small javascript files. After further investigation i found out that the delay mainly occured in the request pipeline event PostMapRequestHandler. Which let me to investigate the handler and module configurations.
I found out that if runAllManagedModulesForAllRequests was set to false, this delay disappeared and the site gained a significant performance boost.
To ensure that only managed requests was send to managed handlers, i added the attribute preCondition="managedHandler" to some of the handlers like this:
I'm curious about this as well. I have an Umbraco 7.4.3 site that uses Umbraco Identity and Owin Middleware for external logins and I just noticed with dotTrace that there is quite a call stack for even a GET for a small CSS file.
Unfortunately we can't turn RAMMFAR off because certain parts of MVC require it and especially OWIN middleware requires it to make sure that all requests get handled by the middleware first (else you would never be able to have effective authentication on all files).
Instead each module should be set on the correct preCondition to avoid major performance overhead. We have had major issues with the SessionModule (which shouldn't do anything with unmanaged requests) which caused all sorts of locking problems freezing up the entire module with workerprocess queues filled with .js and .jpg files wanting to access the SessionModule.
As I recall the use of RAMMFAR was a shortcut to get MVC working in a time where especially IIS 7/7.5 didn't have a correct routing handler for extensionless requests. Therefore the combination of MVC and the use of Session variables was impossible (SessionModule uses preCondition="managedHandler" by default), because the request pipeline of extentionless routes were handled differently.
I recall reading that RAMMFAR will stay in Umbraco's web.config at least until version 8 will maken its debut. Because now there is no knowing of which tooling/add-on/etc. relies on that setting.
If you want to avoid the performance overhead, than you could add ALL modules which are set in IIS (ApplicationHost.config) and decide per module whether it should or shouldn't run for unmanaged requests, leaving only those modules that are actually need to deal with unmanaged requests (e.g. we've overriden the default FormsAuthenticationModule because we want it to act on all requests, instead of only the managedHandler requests) .
Thanks Erik! In my case, because I'm using Owin middleware (and based on Sebastaan's comment), it sounds like I need to keep RAMMFAR on, even though there is a perf hit. I guess it's a good case for offloading non-dynamic requests where possible.
Performance tuning and runAllManagedModulesForAllRequests
While performance tuning an existing Umbraco 6.1.6 installation, i came across rather large values of TTFB (time to first byte). I started investigating and some of the wait was do to application logic, but ImageGen and static files was having the same problem as well with TTFB values of 500ms+ for even small javascript files. After further investigation i found out that the delay mainly occured in the request pipeline event PostMapRequestHandler. Which let me to investigate the handler and module configurations.
I found out that if runAllManagedModulesForAllRequests was set to false, this delay disappeared and the site gained a significant performance boost.
To ensure that only managed requests was send to managed handlers, i added the attribute preCondition="managedHandler" to some of the handlers like this:
Is this safe to do, or is there some requests to Umbraco that will not be processed correctly?
I'm curious about this as well. I have an Umbraco 7.4.3 site that uses Umbraco Identity and Owin Middleware for external logins and I just noticed with dotTrace that there is quite a call stack for even a GET for a small CSS file.
Can anybody explain why runAllManagedModulesForAllRequests needs to set to true? Would like to know the disadvantages disabling this, if any.
Thanks!
Good question!
I am also interested in this
Unfortunately we can't turn RAMMFAR off because certain parts of MVC require it and especially OWIN middleware requires it to make sure that all requests get handled by the middleware first (else you would never be able to have effective authentication on all files).
RAMMFAR shouldn't be used at all.
Instead each module should be set on the correct preCondition to avoid major performance overhead. We have had major issues with the SessionModule (which shouldn't do anything with unmanaged requests) which caused all sorts of locking problems freezing up the entire module with workerprocess queues filled with .js and .jpg files wanting to access the SessionModule.
As I recall the use of RAMMFAR was a shortcut to get MVC working in a time where especially IIS 7/7.5 didn't have a correct routing handler for extensionless requests. Therefore the combination of MVC and the use of Session variables was impossible (SessionModule uses preCondition="managedHandler" by default), because the request pipeline of extentionless routes were handled differently.
I recall reading that RAMMFAR will stay in Umbraco's web.config at least until version 8 will maken its debut. Because now there is no knowing of which tooling/add-on/etc. relies on that setting.
If you want to avoid the performance overhead, than you could add ALL modules which are set in IIS (ApplicationHost.config) and decide per module whether it should or shouldn't run for unmanaged requests, leaving only those modules that are actually need to deal with unmanaged requests (e.g. we've overriden the default FormsAuthenticationModule because we want it to act on all requests, instead of only the managedHandler requests) .
Thanks Erik! In my case, because I'm using Owin middleware (and based on Sebastaan's comment), it sounds like I need to keep RAMMFAR on, even though there is a perf hit. I guess it's a good case for offloading non-dynamic requests where possible.
is working on a reply...