This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

We went off topic...whats REALLY important is...

Oct 14th, 2004, 08:42 AM

Guys, once more... i think we are going off topic... im sorry i mentioned the tests my colleges made or might have done. I dont want to go in there... what i am really ineterested in is:Are there ANY solutions around that are accessed by lots of users, based on Spring. (Defining "lots" will be left to your judgement).

I think this is a really important issue, since this will let us see if Spring is being used by small projects by professionals or if its being considered as a possible enterprise-wide solution.

We currently building an platform based on Spring that is about to go under a series of load tests. This application is large and is intended to run high volume sites. So far as we can tell, Spring is going to perform very well. It's the matter of hardware, app server, and database that will be our truly limiting factors (i.e. I/O, both Database and Network).

In most of my experience with EJB, I can say without question, that for the majority of cases (say, 95%), anything you can do with POJOS is going to smoke EJB.

When we have our results I will post them, but we are probably a couple weeks away from that. And our test will simulate having at least 100K users.

Comment

We've just deployed an aggregation platform for the second-biggest Dutch searchengine [1] (of course after Google) that uses almost every aspect of Spring. The actual searchengine itself is based on C code, with an XML interface providing the results. The results from queries users do are merged with related information from other partners (such as the Yellow Pages and relevant government information) and rendered back to the client using a custom view implementation.

The engine is intended to process up to 150 queries per second. So far (in production) we haven't had peak loads, the average amount of queries per second must now be around 30 - 40. CPU usage is still left at around 10 to 20%. I'll try to get some more info on performance today.

The system also monitors Apache access logs and other logs generated by different parts of the aggregation platform (logging is in some cases--where suitable--done using Spring's AOP framework). The logs are processed asynchronously by one of the two frontend servers taking care of the aggregation and rendering. We're using MySQL myISAM here since the whole thing does NOT need to be transactional (it's logging information and not really critical if we miss one, two or one hundred entries).

Most of the database access is done using Spring JDBC (using loads of batchupdaters) and iBatis for simple object relational mapping. We're administering the servers remotely using Spring's RMI support. We've also had Hessian in place, but somehow we've manage to get a object in the domain model that doesn't serialize that well using Hessian's serialization techniques.

So far, we've been pretty happy with the whole framework (disclaimer: I am involved with Spring), especially the flexibility. We never could have manage to get the performance we have right now with an MVC framework that does not have the option to develop custom views. We're streamingly rendering the XML back to the client that is. Also the DAO abstraction layer adds minimal overhead.