Are you sure that XFormPageUnknownActionHandler is the guilty guy here? Did you commented it out and reran the tests?

Another question - why you are creating new instances of this type? Just to validate incoming captcha?

Thanks Valdis.  Yes, I commented out that code and re-ran the tests, and that had appeared to have no direct impact on fixing high memory usage we are seeing.  Also, yes I believe the only reason we are creating new instances of that type is to validate the recaptcha.  This is my first exposure to that handler, and documentation that I found didn't really clarify it for me. Hence the original question.

For background, we identified other code that caused a memory leak, both in views and in the compiled C#, which was written by other developers.  Last week I fixed some views where the code was creating new instances of the EpiServer.DataFactory.Instance in the Razor for multiple views.  At this point I've been focused on cleaning up the code, by employing using statements when possible and disposing objects when necessary.

Back to the XFormPageUnknownActionHandler, is there a better place to instantiate it for recaptcha than in the BasePageController?  Or is putting it there actually a good idea?  Thanks.

I do see here few issues though..

a) you are "not allowed" to do anything other than rendering stuff from viewmodel to markup in razor views :)

b) you should not touch DataFactory directly (even worse - creating new instances manually)

c) if you need any stuff from DataFactory, you should instead go via some interface (like IContentLoader)

d) those interfaces should be access from underlying controller

e) underlying controller needs to get these interfaces "from above" (preferrably via constrctor of the controller - Constructor Injection pattern).

f) if you are explictly using any of disposable dependencies - either rely on nested container disposal procedure or dispose those manually

Thanks for your insights Valdis.  Unfortunately the code doesn't align with your recommendations.  I'm coming in after the fact (the sites were built by other developers).  One of the patterns they employed was to push a lot of business logic into the views.  So that's an anti-pattern that I'll be targeting.  And we have multiple instances of sites, based on a common template, but nevertheless multiple sites.

To give you an idea of one of the fixes I applied, we had multiple views on a couple of dozen sites where there was code similar to this:

IContentLoader contentLoader = EPiServer.DataFactory.Instance;
var home = contentLoader.Get<HomePage>(ContentReference.StartPage);

I converted that code to this instead:

var home = DataFactory.Instance.Get<HomePage>(ContentReference.StartPage);

That made a dramatic improvement on the memory usage.  DataFactory already exists in those contexts, so there is no need to create a new instance.  But we're still seeing problems.  Since the scope of this is so large, I'm trying to initially target some of the more obvious memory offenders, like undisposed StreamReaders and StringBuilders.  When it comes to the EpiServer objects, like the DataFactory and the XFormPageUnknownActionHandler, those are new territory for me.

Your provided code fragment above shouldn't affect memory usage as you are just assigning DataFactory instance to a variable and calling Get() method from that assigned variable. It's not creating a new instance of DataFactory. "Best way" I would say - would be to ask IContentLoader interface from a ServiceLocator (ServiceLocator.Current.GetInstance<IContentLoader>()). This will make sure that IContentLoader dependency is respecting it's lifetime specifications (usually it's singleton anyway).

Was this the only change and then you saw dramatic improvements in memory consumption?

We also set the primary memory limit for each application pool to 500,000 KB.  Originally those limits were set to zero. We applied the changes incrementally; first adjusting the memory limits, then testing, then adjusting the code.  And we saw an improvement in each case.

Additionally, there were a few files that created the DataFactory like so, which I adjusted in similar fashion to the fix above.

IContentLoader contentLoader = new DataFactory();
var home = contentLoader.Get<HomePage>(ContentReference.StartPage);

This was definitely wrong :)

Actually pretty strange its even possible :) definitely wrong yes. If you use content events it's always good to double check that you also remove the events in the initialization module. I've seen a few sites that trigger those events multiple times...tricky error to find

Btw, what were tools you used to "test" memory consumption?