Hello Guys, Whenever you read a scalability paper.. they tell you you should plan ahead.. and think scalability while designing. This seems a good advice, but I need to know how exactly this affects your design. One can think of making small sessions, to make session replication a �light� operation. I want to hear from you guys about these issues that one should think about. It would be great if one of you guys had to step in and make an application that was not designed for scalability scale well. And what affected the scalability or had to be changed to make the app scale. I think that scaling a J2ee app is reasonably easy. You can just turn on some flags on, and voila, your app server takes care of the big load. What is wrong about this statement? Please let me know what would make a solution not designed for scalability a hard to scale application. After all, we can just put a load balancer (that has fail-over, session replication capabilities) in front of the app servers and it will work. Please clarify with �real life� examples. Deployment issues are not such a big deal, u somehow need to keep the sys. Admin busy. Awaiting your reply!
A couple concrete things to think about: For horizontal scalability on a vendor framework - just add more servers - they had to solve some memory synchronization problems. They have a distributed cache that uses JMS to replicate updates. They use "affinity" to always send a user to the same server. If that server goes down, some number of users are effectively no longer logged in and they have to start the app over. Is that acceptable? If not, you'd want to add session replication or push all the interesting stuff from session to a database or something. Our old system - still running - had scalability challenges. We were pegged at 90% CPU with half the users we had to support. So we tuned, optimized, cut overhead, etc and ran at 90% with 75% of the users. Then we did it all again and ran at 90% with all of the users. Then we did it again. Whew. What worked? Eliminating extraneous calls from fat client to server through caching and bundling of results. Eliminating cross-process calls on the server (not Java). Providing custom APIs for specific business functions instead of reusing generic ones. Eliminating some user requirements! All of the problems were found through extensive stress testing, instrumentation, analysis. And one or two customer calls. The point of all that is to be prepared to make this a life's work [ February 22, 2004: Message edited by: Stan James ]
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Keeping the server stateless. Stateless servers scale well, as a matter of fact they scale excellent. There is a slight problem with it though. The session is kept on web tire (web container) or some other close to client tire. You have to redo the code for each client. You have to break business (aka problem domain) and put parts all over the deployment components. Using stateless session beans and JMS with MDB seems to be very scalable approach but it seems that we are actually going back to transaction monitors like Encina or Tuxedo. Any good paper on scalability that you would recommend?
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop