Gaurav
Gaurav

Reputation: 1650

What considerations should be made to take care of scalability

In a programming language, particularly Java, what considerations should be made to ensure that the application is scalable? Let's take an example of a web application, which serves 1000 users concurrently and it is expected that the users might grow to 100,000. Also suppose that currently only specific functionalities are provided and in future we may need to add many more functionalities like reporting etc. Do we need to ensure that certain kinds of bottlenecks do not happen or should we avoid certain kinds of designs, which might restrict scalability?

Upvotes: 0

Views: 438

Answers (4)

Kris
Kris

Reputation: 5792

I guess its a waste of time and space to write it all here. I would strongly recommend reading Scalability Rules, its cheap, quite short and well written

Upvotes: 0

Edwin Buck
Edwin Buck

Reputation: 70979

Decide what scalability means to you.

Every application scales in some sense of the word, yet "scalability" only seems to apply to applications that are lacking in ability to scale in a particular problem domain. Your problem domain is different than mine, so if I offer scalability advise, it is the same thing as optimizing for use cases not actually observed in your application. You'll now recognize this as premature optimization (the root of a lot of very bad system design choices).

So figure out what is likely to grow and what is likely to not grow, and put your money (and time) where you pain is. Benchmark it. Measure it.

Once you get a feel for how your application might fail to scale, do a bit of research while attempting to solve the issue. That way you're not totally on your own, you can leverage the tons of scalability work, but for your particular circumstance.

Remember that to achieve better scalability, you have to make a trade-off somewhere. Either your program will grow in time, memory, hardware requirements, or some other way. If you don't have performance metrics on processing time, memory utilization, etc, you haven't met the prerequisite requirements to worry about scalability.

Upvotes: 1

David Waters
David Waters

Reputation: 12038

  1. Avoid locks, especially global locks as much as possible.
  2. Statics often cause situations where locking seems like a good idea, avoid statics as much as possible. They also make testing harder.
  3. How is your data stored? Are you using a Sql database? How will that scale? Can you use a NoSql datastore instead. Hint for accounting type application the answer is no, we need the transacionality of Sql.
  4. Be careful of pull type subscriptions, depending on your load push type subscriptions can scale better. e.g. 10 consumers checking for state change once per second is fine, 10000 consumer checking for state change once per second is more challenging. If data change once per minute publish is much more efficient, if it changes more frequently then 1 per second the publisher can choose to batch changes.
  5. Look for Star shapes in your architecture diagram, what happens when the machine at the center of the star is over loaded? In a lot of cases this will be your data-store and most Sql Databases are expensive/difficult to scale beyond one read/write master with lots of read only replicas. If this is going to be the case and you know you are going to grow big big then think of partitioning (splitting data over multiple read/write masters) early.
  6. Caching - is a shared cache like Memcached going to help you? ( often removes the need for sticky sessions)
  7. Hire experts early to review design at least.

Upvotes: 3

user647772
user647772

Reputation:

Bottlenecks are IO (disk, database, ...) and network. The programming language is not that big an issue.

Upvotes: 1

Related Questions