Performance and scalability: performance & scalability: duty of server, container or web app
Hi all, What about scalability and performance? is it related to the application, the server or the container? and where to find a good guide or book that teach this stuff? thanks Mohammed
- Posted by: Mohammed Al-Moayed
- Posted on: June 01 2008 04:47 EDT
- Re: performance & scalability: duty of server, container or web by shalon toy on June 03 2008 13:50 EDT
- Re: performance & scalability: duty of server, container or web by Guerry Semones on June 13 2008 17:16 EDT
Performance and scalability are too broad a topic that you can assign to just one component. Each layer has its own share of things that affect P & S. Book : Pro Java EE 5 Performance Management and Optimization. I havent read the book completely but seems like a good one. -Ejaz Ahmed
Hi all,That is a very broad question to ask. Certainly the footprint of a given application and its behavior, requirements, etc. will affect its own performance and scalability. Of course, your app server platform of choice may also have characteristics that affect performance. Within a given application, and within a given app server platform, there are things you can/must do to configure for performance. However, a critical aspect of being able to scale out an application is the choice of platform. To truly scale out, you need to be able to horizontally scale, that is, add additional servers running the same application on the same app service platform. The architecture and design of the app service platform you choose directly impacts its ability to horizontally scale, and to do it well. A given platform may support clustering, but be limited in cluster size by its design, allowing you to only scale out to N servers. This even varies among J2EE implementations, some doing it better than others. Other platforms may allow you to scale out to thousands of servers (for example, grid-based application platforms like Appistry, etc.) Horizontally scaling is just a start. You also get into a number of other issues (for example, the number of tiers involved affects latency, which affects performance). I don't have a book off the top of my head to recommend. Do you have a specific platform or technology you are running on, or concerned about in terms of scale and performance? Specifics would help.
What about scalability and performance? is it related to the application, the server or the container?
For the sake of full disclosure - I work for GigaSpaces Technologies, and our product is all about solving scalability issues with traditional tier based architectures. However I will try to keep the discussion theoretical :) I think that regardless of how a certain application server is implemented, the main issue with traditional JEE applications is that they're architected in a non-scalable manner. At the end of the day, no matter how well your application server is implemented, everything comes down to how scalable your database and messaging servers are. And since those typically use disk for persistency/resiliency, and are very hard to cluster, you're pretty much limited as far as scalability goes. In fact, in most cases, you will get worse performance when clustering them. And most databases and messaging servers will not scale to more than 4 nodes anyway. In order to really scale out, you need to architect your application in a scale out manner - i.e. use paradigms like sharding/partitioning and share-nothing. With traditional JEE you will need to implement this on your own, like Google, Amazon and eBay have done for example. Another important aspect is the use of memory-based technologies instead of hitting the disk. Reliability and resiliency are achieved through replication, such that you always have a backup copy of your data/messages in at least one other node in your cluster. Most in-memory data grids also allow you to partition your data to multiple machines to achieve scalability, and offload the data asynchronously to a persistent store if needed. The end result is that you don't hit the disk in the coarse of a transaction. Internal tests we've done show that this approach can achieve up to 6 times more throughput and 10 times less latency for messaging and data access. If you want to dig into this some more, here a couple of links you may find useful: