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 <[email protected]> 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 <[email protected]>
> 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 <[email protected]>
>> 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 <[email protected]>
>> > 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-leaks-when-using-windsor-and-not-releasing-objects.aspx
>> >>
>> >>
>> >>
>> >> Cheers
>> >> Stefan
>> >>
>> >>
>> >> On Wed, Mar 4, 2009 at 9:04 AM, Andrew <[email protected]> wrote:
>> >> >
>> >> > 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
>> >> >
>> >> > >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Stefan Sedich
>> >> Software Developer
>> >> http://weblogs.asp.net/stefansedich
>> >>
>> >>
>> >
>> >
>> > >
>> >
>>
>>
>>
>> --
>> Stefan Sedich
>> Software Developer
>> http://weblogs.asp.net/stefansedich
>>
>>
>
>
> >
>



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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Castle Project Users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/castle-project-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to