CODEWITHSUNDEEP
javahibernatepostgresqlmemcachedvaadin
Flakron Bytyqi
Flakron Bytyqi

Reputation: 3254

Java Web Application for 5000~ Users

For the first time (hopefully not the last) in my life I will be developing an application that will have to handle a high number of users (around 5000) and manage lots of data. I have developed an application that manages lots of data (around 100~ GB of data, not so much by many of your standards), but the user count was pretty low (around 50).

Here is the list of tools / frameworks I think I will be using:

The application will mainly be run inside a company network. It might be run on a cluster of servers or not, depends on how much money the company wants to spend to make its life easier.

So what do you think of my choices and what should I take caution of?

Cheers

Upvotes: 9

Views: 3005

Answers (6)

Marthin
Marthin

Reputation: 6543

Depending on you specification and future goals I would perhaps leave the normal version of tomcat and go for Apache TomEE or my personal preference of jBoss. As I understand it EJB's are not very well supported in the normal tomcat version and that is probalby something sweet to have when you want to create a couple of services, some clustered singleton service and other stuff. But this is just my personal pref of course and if your specification will not allow a more advanced EE server then you should stick with the slick tomcat.

Upvotes: 0

ManuPK
ManuPK

Reputation: 11829

Any reason for not using Spring? It has really became an de-facto standard in the enterprise java applications.

Spring provides an incredibly powerful and flexible collection of technologies to improve your enterprise Java application development that is used by millions of developers.

Spring is lightweight and can stay as a middle layer, connecting the vaadin and hibernate, there by creating a clean separation of layers. The spring transaction management is also superior to the one on hibernate. I will suggest you go for it until you have a strong reason stopping you.

Upvotes: 3

brettw
brettw

Reputation: 11114

Since you asked people to weigh in, I won't hold back my opinion. ORMs in general, and Hibernate in particular, are an anti-pattern. I know, I've worked in shops that use Hibernate over the past 9 years. Knowing what I know now, I will never use it again.

I highly recommend this blog post, as it puts it more succinctly than I can:

ORM is an anti-pattern

But forgive me if I quote the bit from that blog about ORMs and anti-patterns:

The reason I call ORM an anti-pattern is because it matches the two criteria the author of AntiPatterns used to distinguish anti-patterns from mere bad habits, specifically:

  • It initially appears to be beneficial, but in the long term has more bad consequences than good ones
  • An alternative solution exists that is proven and repeatable

Your other technology choices seem fine. Personally, I lean more toward Jetty than Tomcat. There's a reason that Google embeds it in a lot of their projects (think GWT and PlayN); it's a younger codebase and I think more actively developed now that Eclipse has taken it over. Just my humble opinion.

[UPDATE] One more link, very long read but when making architectural decisions, reading is good.

Object/Relational Mapping: The Vietnam of Computer Science

Upvotes: 1

Peter Cetinski
Peter Cetinski

Reputation: 2336

You might want to consider an Apache HTTP server in front of your Tomcat servers. Apache will provide: compression, static caching, load-balancing and SSL.

Upvotes: 5

beny23
beny23

Reputation: 35018

The answer, as with all performance/scaling related issues is: it depends.

There is nothing in your frameworks of choice that would lead me to think it wouldn't be able to handle a large amount of users. But without knowing what exactly you want to do or what your budget is, it's impossible to pick a technology.

To ensure that your application will scale/perform, I would consider the following:

  • Keep the memory footprint of each session low. For example, caching stuff in the HttpSession may work when you have 50, but not a good idea when you have 5000 sessions.
  • Do as much work as you can in the database to reduce the amount of data that is being moved around (e.g. when looking at tables with lots of rows, ensure that you've got paging that is done in the database (rather than getting 10,000 rows back to Tomcat and then picking the first 10...)
  • Try to minimise the state that has to be kept inside the HttpSession, this makes it easier to cluster.

Probably the most important recommendations:

  • Use load testing tools to simulate your peak load and beyond and test. JMeter is the tool I use for performance/load-testing.

When load testing, ensure:

  • That you actually use 5000 users (so that 5000 HttpSessions are created) and use a wide range of data (to avoid always hitting the cache).

EDIT:

I don't think 5000 users is not that much and you may find that (performance-wise) you only need a single server (depends on the size of the server and the results of the load testing, of course, and you may consider a clustered solution for failovers anyway...) for handling the load (i.e. not every one of your 5000 users will be hitting a button concurrently, you'll find the load going up in the morning (i.e. everyone logs in).

Upvotes: 9

Peter Penzov
Peter Penzov

Reputation: 1588

I recommend Glassfish for application server because Apache Tomcat can serve simple content. And Glassfish has full implementation of the Java EE specification.

Upvotes: 0

Related Questions