Server Farms and Hight Volume web sites

Hi Guys,

After a successful ligghtspeed roll out on a small application we are looking at scaling LightSpeed up to som some of our bigger applications, however there is some concerns over how light speed will handle in a server farm environment, can the session state be shared accross multiple servers with out having to continually hot the database?

Are any of your other clients using LightSpeed on high volume sites, if so how do they do they handle server farming / Load balancing situations?

Thanks Again,

Josh

Hi Josh,

There are a couple of people we know of using LightSpeed on larger sites, but I dont know the specifics on their throughput to qualify them as "high volume" as such.

If you are using a PerRequest scoped UOW and are not storing any entity data in session state you shouldnt run into any issues with LightSpeed. To avoid hitting the database and leverage some caching we recommend you look at page level caching for your site and implementing a 2nd level cache for the LightSpeed entities to achieve scale up.

You could also look at manually caching entities in HttpCache, but be aware you will need to re-attach them to the current request UOW (and avoid any concurrency related concerns yourself) if they have any lazy loads etc otherwise you would run into exceptions stemming from its original UOW being disposed - this can be a bit problematic so approach with caution :)

Any more specifics you can share on your planned implementation?

Jeremy

We were planning on having several servers running on a load balancer, once a user logs in to any of the servers there session will be stored in a out of process, in another database.  This means that each request for a user session could come from a number of servers.  I was hoping to be able to store LightSpeed generated objects in session.   I doubt LightSpeed could currently handle this; would it be on the cards for a future version?

damn it, sorry about the word formatting.

We use memcache for page level caching across our server farm. I think that LightSpeed-level cache could use the same memcache instances? So maybe you could store page output, session data containing Entity Ids and LightSpeed cache data in the same distributed cache? It would involve some more network roundtrips and (bearing in mind my limited understanding of the LightSpeed Entity caching) there would be a chance that further database access would still be triggered.

I would say we have a medium volume site but the page-level caching is essential to keep the pages responding quickly enough. I think this is due to a combination of our very normalised model structure, our inexperience with LINQ and the query (especially join) limitations of LS 2.2, which we are currently stuck with due to using Mono and Apache as our front-end. We don't currently use any session data so I've not had to address these specific issues before.

Thanks,

Chris

You can store the objects in session state, but generally I would really try and avoid this.

The main reason is that an entity has an association to a UnitOfWork which is used if it needs to lazy load any children, if you are scoping your UnitOfWork per request (as you would most likely do for a web application) then that UnitOfWork will get disposed after the original request completes and any subsequent use of that object may cause problems if you attempt to access the UnitOfWork.

If you want to cache entity instances, have a look at the 2nd level cache, as this is designed to be scoped beyond a UnitOfWork. Have a look at the help topic on Caching as a starter for this:http://www.mindscapehq.com/Help/LightSpeed/Help%20Topics/LightSpeed/Caching.html

I am guessing you are also applying a page level caching policy as well and the entity caching would be there to augment that?

Jeremy