wood burning stoves 2.0*
The moose likes Performance and the fly likes Scalability and its relation to performance Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Performance
Bookmark "Scalability and its relation to performance" Watch "Scalability and its relation to performance" New topic

Scalability and its relation to performance

Andres Delrotti
Ranch Hand

Joined: Aug 11, 2005
Posts: 136

Have you ever did a design for an application with requirements such as X number of anticipated users of the application in the next 5 years, and should still perform as expected.

How do you guys usually implement design solution for this? the only solution I am familiar with when faced with this type of requirement is the use of EJBs (is that even a correct design for it?).

or do we leave issues like this to infrastructure guys to do solutions such as server load balancing etc.?
Jelle Klap

Joined: Mar 10, 2008
Posts: 1753

Use of EJBs doesn't make an application magically scalable, unfortunately. In an ideally horizontally scalable system you can just throw more nodes at it, but it is certainly not just limited to infrastructure. Your application needs to accommodate this, and that can be hard to achieve. How scalable a system should be is also difficult to determine, because in the architectural phase you don't know how the system is going to perform with a single node, let alone X nodes operating concurrently. That can only be measured. Should it be able to scale dynamically depending on load? Is it allowable to use a BASE consistency model to achieve increased scalability or is ACID required? There are a lot of concerns that conflict with high scalability and a lot of ways to reach a level of scalability that fits. It's impossible to list a set of solutions or technologies that are always applicable. It's always a different puzzle.

Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
Anayonkar Shivalkar

Joined: Dec 08, 2010
Posts: 1502

Hi Andres,

As Jelle mentioned, (fortunately or unfortunately )each problem is different and there are different solutions.

During my experience so far (which is not much acutally )while scaling up the application, I needed to take decision whether to switch to EJB or stay in Core Java, whether I can afford the overhead of EJB etc. There were times where Core Java a was actually a better option (even given the overhead of manual coding for multi-threading and network communication).
Sometimes the issues used to get fixed just by increasing heap size and number of threads, sometimes I needed to fine tune the GC algorithms and relevant JVM arguments and so on.

However, typically, if a code is good enough (i.e. optimum usage of GC, proper thread-safety, no unnecessary synchronization etc.) then usually increasing heap size and number of threads does the trick, but again, it totally depends upon the way the code is written and what is exact bottleneck (e.g. application might work nicely with single JVM, but with multiple JVMs, inter-JVM communication might be one of the bottlenecks etc.)

I hope this helps.

Anayonkar Shivalkar (SCJP, SCWCD, OCMJD, OCEEJBD)
Winston Gutkowski

Joined: Mar 17, 2011
Posts: 7545

Andres Delrotti wrote:Have you ever did a design for an application with requirements such as X number of anticipated users of the application in the next 5 years, and should still perform as expected.

Answers: yes, and (oddly) not as difficult as you might think; it just takes a bit of planning.

The fact is that no system is likely to remain static over the course of five years, and upgrades to memory, CPU, storage, and (possibly most important) your network pipe can do an awful lot to help maintain SLAs. These just need to be planned and budgeted for.

Where choosing EJB might help is in providing increased manageability and flexibility when you do start to expand; but it is quite an undertaking, so you need to be sure that it's not a "sledgehammer to crack a walnut" at this stage.
I'm also not sure that it's a simple "either/or" choice (not an EJB expert, so I really can't say). If you write your system clearly and simply, using good OO principles, it seems to me the sort of thing that could be factored into your "5-year plan", say when you hit some threshold. That way you don't incur a big initial expense before your figures actually reflect a need.

My 2 ¢ (and I could be wrong )


Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
I agree. Here's the link: http://aspose.com/file-tools
subject: Scalability and its relation to performance
Similar Threads
Singleton versus Static class?
Jar Hell Resolution
Online money transaction facility like paypal
Is JDBC faster than JPA?
[URLyBird] What are the persistent properties