High traffic applications?

[sotretus]

I was wondering if anyone knows of high traffic applications based on spring ? (more than 50K concurrent users)
Are there any special considerations to take care of when using spring in a Clustered Enviroment (i saw another post like this before, but i didnt find it useful).

I've been told that spring isnt' suitable for 100K+ concurrent users. Is there a reason for that? Am I better off with EJBs for 100K+ users?

Any advices, tips, experiences will be apreciated.

Regards
AB

[Ben Alex]

Spring is not a server. It runs within a server. Provided your chosen server can accommodate your load, it should work fine. Spring does not impose limitations on replicating the HttpSession, should this be required for your particular application. Spring itself uses the HttpSession only in its web MVC package, and you can chose to use a different web framework entirely. Acegi Security (which provides security capabilities for Spring) is also cluster friendly and only uses the HttpSession for storing the Authentication details, and you're free to plug in alternative strategies for this if you prefer.

[davison]

I've been told that spring isnt' suitable for 100K+ concurrent users.

By whom? And how did they verify this themselves?

[sotretus]

Some people at my company. the HOW is not important. I want to know if the Spring Framework is as scalable as EJB's are. What problems may arise, etc. And would be happy to know of traffic-intensive (maybe numbers?) sites deployed that use Spring.
this is NOT a comparisson or a debate or whatsoever. I just need proof to convince my bosses that Spring is what i believe it is, so i dont want to start a topic of stress-test or anything like it.

Greetings,
AB

[kantorn]

Hi sotretus.

I think this is a very important question, and interesting beyond normal extent.

Dut I don't agree with you; the HOW is very important! If your company/colleauges have made discoveries, why couldn't you tell us how they did it? You don't have to reveal company secrets. Then this could be repeated and verified by others in true scientific spirit *s*

The excellent book "J2EE development without EJB" claims that EJB technology will be reduced to handling large distributed systems while IoC/AOP will be able to handle 90% of the areas where EJB is used today. If there is a limit discovered in these techniques, I think they should be discussed.

Furthermore, maybe your colleagues/bosses should be handled a copy of the above mantioned book?

[Ben Alex]

Sotretus, could you elaborate on your intended architecture for the middle tier beans (ie not the web tier).

At a web tier level, typically you will duplicate the same WAR on each of your front end web servers. The web tier should scale well, as it's mostly related to your web container capabilities and its support for HttpSession replication and fail-over.

From a middle tier perspective (AKA services layer and persistence layer) do you intended to collocate all beans in the same WAR? Will these layers be in the same WAR as your web tier? Must you access legacy EJBs? If everything will be in the same WAR, you will not have performance benefits from using EJB. If on the other hand you have extensive remoting being used within the middle tier, or between the middle tier and the web tier, especially if the servers have to pass transaction or security state between them, it's a lot more involved and complex.

In an ideal architecture, you can put everything (web tier, and all layers of your middle tier) into the same WAR. If you need to scale, you add more web servers which contain that same WAR. You then use a (preferably hardware-based) load balancer in front of the web servers which delivers sticky sessions (meaning the same server services the same users). You use HttpSession sparingly, and rely on web container capabilities to replicate HttpSession. If you've got sticky sessions, and your requirements aren't as extensive as needing transparent server failover (let's face it, servers don't fail that often), you eliminate the need for HttpSession replication at all (major simplification, as no need to serialize and it's more performant). The other rule of thumb is you never use the HttpSesion in your middle tier (you use ThreadLocals if you can't pass objects around easily as arguments).

[katentim]

you will not have performance benefits from using EJB

+1

In general, architecture will have more effect on scalability than technologies. That said, Spring should use less resources than EJBs. Spring should also save you development time so you can concentrate more on architecture and performance testing.