Expected IIS memory usage for e-commerce castle app

[Andrew]

I've just launched an e-commerce website based on Monorail and using
ActiveRecord. It's a replacement of a previous PHP solution and we
have on average about 20 - 30 concurrent users at any given time. I'm
also running an admin site in the same application pool.

My issue is to do with memory usage. I'm running on a 1GB VPS box
(also hosting a SQL Server DB on same machine). I've limited SQL
Server to 200MB and my IIS6 worker process to 400MB. However, even pre-
release when testing with 1 or 2 users the memory usage would easily
sit around the 300MB mark. Now with the real load, I'm seeing the
application pool recycle approx every 40 mins (normally should only
recycle at 3am). I'm using the ASP.Net state service so session
details are preserved but still, I'm concerned

As I said, it's an e-commerce site so there's the usual shop stuff:
lots of nice pics, searches, checkout and a bit of 2nd level caching
for things such as categories (max 200 categories), countries, rates
etc. Really not that much is cached and mem usage was high before we
fully optimised the site. I've been careful to have the SQL profiler
beside me as we were testing the app, so I'm confident that I don't
have N+1s all over the place. Oh, and I'm using standard session-per-
request model using Ayende's UOW stuff

I guess what I'm asking is: Is that level of memory usage expected
for that type of site? I would love to hear back from anyone who has
launched a similar type of site.

I did see a previous post about this, but they are talking around the
200MB mark, so I'm wondering what on earth I'm doing wrong!

There is the option of shelling out more cash and go to a 2GB VPS box,
but I'd rather not have to....

cheers

[Ayende Rahien]

that doesn't sound quite right, now

[Stefan Sedich]

Andrew,

I have built a few simmilar sounding shop fronts, with medium load and
have not had issues with memory leaks with the app pools running solid
until their nightly reset.

If you hit your site with a web stress testing tool do you see the
memory continue to climb until app pool reset? If this is the case it
is possible you have a memory leak.

I would suggest getting a tool like ANTS profiler to see if you can
track down any memory leaks in your application and then go from
there. I would say from what I have seen in my apps ~200MB seems
reasonable depending on what it is doing.

In my last project I had similar issues you describe. In my case I was
using Windsor and not releasing my components from the container when
I was done with them. In my case I decided to not release my objects
and use the NoTrackingReleasePolicy instead, as this was fine for my
needs and removed the leak that I had.

I have blogged about this here:
http://weblogs.asp.net/stefansedich/archive/2008/11/05/avoid-memory-leaks-when-using-windsor-and-not-releasing-objects.aspx



Cheers
Stefan

--
Stefan Sedich
Software Developer
http://weblogs.asp.net/stefansedich

[Victor Kornov]

http://stackoverflow.com/questions/49912/best-dotnet-memory-and-performance-profiler

[Andrew Smith]

Hi Stefan,

 you know as soon as I posted that, of course I came across details on this issue. In fact your very blog post. In all the time I've used castle, I never realised I was expected to explicitly release a transient component. By the sounds of it, I'm sure that will be the cause as I'm using windsor integration heavily and can easily repro the issue with a local stress test.

 Thanks for the info

Cheers,

Andrew

[Stefan Sedich]

No problems,

Something that caught me too, I knew a few people that were not aware
and they had never stress tested their apps or realised it was
resetting (dangerous). I am glad I profile my stuff before putting it
anywhere near production. I guess releasing is the way proper way to
handle things, but I have been naughty and just used NoTracking.




Cheers

[Andrew Smith]

just changed the policy and re-ran a local stress test. Immediate improvement. Previous test ended with memory usage of ~200MB, this time round 70MB

thanks again!

[Stefan Sedich]

Excellent glad I could help. But I would look into releasing your
objects properly, not sure maybe someone can comment on negative
impacts of using NoTrack policy.



Cheers

[Andrew Smith]

Yea, I was worried about negative effects of this also. You don't get something for nothing, right? The only mention I've seen so far is a comment from hammett in the another post to this group ("ViewComponent memory leak"):

"The side effects is that you might have disposable components that are
not being disposed by the container"

In my case I know I don't have any disposable components involved, so after some proper testing, I'll be applying the 'fix' to my server

[kurtharriger]

I don't understand why this isn't the default setting either. IMHO,
Transient objects should not be tracked by default.

As many several have noticed the issues arising tracking transient
objects for dispose is greater then the risk of not calling dispose at
all (and unless the object holds unmanaged resources, dispose is not
all that necessary anyway). A disposable component that *must be
disposed* should also implement a finalizer and that doesn't change by
using a container since there is no guarantee dispose will be called
on container either. Since release accepts the object to dispose as a
parameter there isn't any reason to track it, if object is not tracked
then assume it is transient and call dispose if implemented.

- Kurt

On Mar 3, 4:57 pm, Andrew Smith <andy78sm...@gmail.com> wrote:
> Yea, I was worried about negative effects of this also. You don't get
> something for nothing, right? The only mention I've seen so far is a comment
> from hammett in the another post to this group ("ViewComponent memory
> leak"):
>
> "The side effects is that you might have disposable components that are
> not being disposed by the container"
>
> In my case I know I don't have any disposable components involved, so after
> some proper testing, I'll be applying the 'fix' to my server
>

> On Tue, Mar 3, 2009 at 11:45 PM, Stefan Sedich <stefan.sed...@gmail.com>wrote:
>
>
>
> > Excellent glad I could help. But I would look into releasing your
> > objects properly, not sure maybe someone can comment on negative
> > impacts of using NoTrack policy.
>
> > Cheers
>
> > On Wed, Mar 4, 2009 at 9:43 AM, Andrew Smith <and...@emertech.ie> wrote:
> > > just changed the policy and re-ran a local stress test. Immediate
> > > improvement. Previous test ended with memory usage of ~200MB, this time
> > > round 70MB
> > > thanks again!
>

> > > On Tue, Mar 3, 2009 at 11:37 PM, Stefan Sedich <stefan.sed...@gmail.com>

> > > wrote:
>
> > >> No problems,
>
> > >> Something that caught me too, I knew a few people that were not aware
> > >> and they had never stress tested their apps or realised it was
> > >> resetting (dangerous). I am glad I profile my stuff before putting it
> > >> anywhere near production. I guess releasing is the way proper way to
> > >> handle things, but I have been naughty and just used NoTracking.
>
> > >> Cheers
>

> > >> On Wed, Mar 4, 2009 at 9:33 AM, Andrew Smith <andy78sm...@gmail.com>

> > >> wrote:
> > >> > Hi Stefan,
> > >> >  you know as soon as I posted that, of course I came across details on
> > >> > this
> > >> > issue. In fact your very blog post. In all the time I've used castle,
> > I
> > >> > never realised I was expected to explicitly release a transient
> > >> > component.
> > >> > By the sounds of it, I'm sure that will be the cause as I'm using
> > >> > windsor
> > >> > integration heavily and can easily repro the issue with a local stress
> > >> > test.
> > >> >  Thanks for the info
> > >> > Cheers,
> > >> > Andrew
>
> > >> > On Tue, Mar 3, 2009 at 11:24 PM, Stefan Sedich <

> > stefan.sed...@gmail.com>

> > >> > wrote:
>
> > >> >> Andrew,
>
> > >> >> I have built a few simmilar sounding shop fronts, with medium load
> > and
> > >> >> have not had issues with memory leaks with the app pools running
> > solid
> > >> >> until their nightly reset.
>
> > >> >> If you hit your site with a web stress testing tool do you see the
> > >> >> memory continue to climb until app pool reset? If this is the case it
> > >> >> is possible you have a memory leak.
>
> > >> >> I would suggest getting a tool like ANTS profiler to see if you can
> > >> >> track down any memory leaks in your application and then go from
> > >> >> there. I would say from what I have seen in my apps ~200MB seems
> > >> >> reasonable depending on what it is doing.
>
> > >> >> In my last project I had similar issues you describe. In my case I
> > was
> > >> >> using Windsor and not releasing my components from the container when
> > >> >> I was done with them. In my case I decided to not release my objects
> > >> >> and use the NoTrackingReleasePolicy instead, as this was fine for my
> > >> >> needs and removed the leak that I had.
>
> > >> >> I have blogged about this here:
>

> >http://weblogs.asp.net/stefansedich/archive/2008/11/05/avoid-memory-l...