aspose file tools*
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
Author

Scalability and its relation to performance

Andres Delrotti
Ranch Hand

Joined: Aug 11, 2005
Posts: 139
Hello,

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
Bartender

Joined: Mar 10, 2008
Posts: 1824
    
    7

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
Bartender

Joined: Dec 08, 2010
Posts: 1510
    
    5

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.


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

Joined: Mar 17, 2011
Posts: 8250
    
  23

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 )

Winston

Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
H Paul
Ranch Hand

Joined: Jul 26, 2011
Posts: 471
    
    4
( I have nothing original to say )

I found your question is cool and I sell you this article for free:

Fallacies of Distributed Computing Explained

http://www.cse.unsw.edu.au/~cs9243/14s1/papers/fallacies.pdf

http://www.rgoarchitects.com/Files/fallacies.pdf
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8250
    
  23

H Paul wrote:I found your question is cool and I sell you this article for free:
Fallacies of Distributed Computing Explained

Interesting. I also like your notion of "selling". Maybe it'll catch on...

I was a "jack of all trades" (*n[iu]x, network, db, security) admin for nearly 15 years, so I'm aware of a few of the things you (?) mention, but I'm sure they'll provide good bedtime reading for anyone else who's interested.

Cheers.

Winston
Amit java
Greenhorn

Joined: Jul 30, 2014
Posts: 3
For any enterprise product during design the capacity planning is major task and every capacity planing and performance test is designed to project the growth rate for next 5 years. The best way is run those test for 5 years growth in terms of horizontal and vertical scale. Every software can do the best possible throughput with the desired hardware. If those projections are done and software tuning been done accordingly this will help to achieve the objective. With technology changes and evaluation in next 5 years you may see something new which will turn around the architecture to have suffice your needs.
 
 
subject: Scalability and its relation to performance