question for authors on spring scalability and clustering

[chris coleman]

Here is a question for the authors.

Can you make some comments on the scalability and clustering abilities of a fully spring based web application that does not use a separate persistence layer or presentation layer framework.

Suppose you have 50,000 simultaneous web clients and you desire to use clustering in order to keep the site running at a very high level of reliability in the face of possible hardware or software failure..

Is it possible and wise to architect a site totally on spring, using today's current version of the spring framework ??

CHris Coleman

[Lasse Koskela]

Without being too intimately familiar with Spring MVC (I've so far been using just the container stuff), I'd say the answer is yes, you can architect such a site on Spring. The reason being that "using Spring" has little relevance to how your application performs. The framework itself doesn't hinder your performance unless you use it in a non-performant way (like going over the board with dynamic pointcuts).

[Craig Walls]

Originally posted by chris coleman:
Can you make some comments on the scalability and clustering abilities of a fully spring based web application that does not use a separate persistence layer or presentation layer framework.

I'll try...First, when you say that the application doesn't use a separate persistence layer, what do you mean? Spring, by itself, does not provide a persistence mechanism. It only integrates with several popular persistence options, including Hibernate, JDO, and iBatis. It also make life easier on you if you are using straight JDBC. But Spring does not bring its own persistence mechanism to the table. Thus, part of the answer to your question is dependent on the persistence mechanism you choose.

As far as clustering, a Spring-based web application will rely on the clustering capabilities of the servlet container you deploy to. Spring doesn't do clustering itself.

Regarding scalability, there are a lot of angles to look at this from. The IoC container itself is really lightweight and should place no additional scalability issues upon your application once all of the beans have been loaded and wired. This is mostly a startup activity, but if you have any lazily-instantiated beans then they'll get created along the way at runtime (but that's the norm in a non-Spring application anyway).

With regard to Spring AOP, weaving of aspects is a startup activity unless you are using dynamic pointcuts (which by definition must happen at runtime). And, although I can't speak numbers, I imagine that the Spring MVC framework is at least as scalable as any other Model 2 framework such as Struts or WebWork.

Perhaps Ryan has some insights into this that I've missed.

Originally posted by chris coleman:
Is it possible and wise to architect a site totally on spring, using today's current version of the spring framework ??

Again, there's no such thing as a web application built "totally on Spring". The biggest bottleneck is most applications is persistence and since Spring doesn't have its own persistence mechanism, the answer depends largely on what you choose for persistence. Furthermore, Spring doesn't provide its own servlet container, so you'll need to run Spring on Tomcat, JBoss, WebSphere, or whatever servlet container you choose--thus the scalability and performance of your application will depend somewhat on the container you deploy to. And, in any given application, you're likely to employ other third-party APIs, so those play a part as well.

My best answer for you is that while Spring offers a wealth of features, it's still only a piece of your web application's much larger architecture. I don't see any reason why the Spring piece will cause any scalability issues.
[ April 13, 2005: Message edited by: Craig Walls ]

[Ryan Breidenbach]

Adding on to what Craig said...

The Spring services you will be using, such as transaction support or Spring's MVC framework, scale just fine because they do not depend on any user state. The two areas of your application you need to look at regarding clustering are your web container and your persistence layer.

Your web container (Tomcat, Resin, WebSphere, etc) will be responsible for clustering the web layer. This typically means making the HttpSession object available to multiple server, either by multicasting the HttpSession state to multiple servers or persisting the HttpSession state in a database. Whatever the case, clustering your web layer will be a feature of your web container, not Spring.

As for your persistence layer (Hibernate, JDO, etc)... if you are going to need any caching of your persistence objects, your peristence solution should be clusterable if you want to scale across multiple servers. Again, this is a feature of your persistence solution, not Spring.

Hope this helps.