Skip to Main Content
  • Questions
  • Resource Estimation for Deploying News Application in Production

Breadcrumb

Question and Answer

Connor McDonald

Thanks for the question, Ehsan.

Asked: August 07, 2025 - 10:21 am UTC

Last updated: August 12, 2025 - 2:13 am UTC

Version: 24.2

Viewed 100+ times

You Asked

I have developed a news application using Oracle APEX, and I am now preparing to move it into a production environment. I would like to estimate the required resources for both the Oracle database and the application server (Tomcat) to support approximately 600 concurrent users.

Could you please advise on:

1.The recommended CPU, memory, and storage specifications for the Oracle Database server.

2.The required configuration for the Tomcat application server (e.g., JVM heap size, thread pool settings, etc.).

3.Any best practices or architectural considerations for scaling and ensuring high availability in such a setup.

and Connor said...

Not really... because you need to size YOUR application. You have this totally 100% unique beast that no one else on the planet has.

You might have a cpu intensive algorithm no one else does ... or maybe not.
You might have long running transactions which means you need a massive connection pool ... or maybe not.

You need to benchmark your system and size from there. See what load 60 users in Test creates, and make some meaningful estimates for what 10x might be to get to 600.

Even the type of CPU that your server will have depends on your expected current and future requirements. I did a video on that here https://youtu.be/jwaRsu5O9DU

One key thing I will mention. When it comes to "600 concurrent users" there can be a large difference between

"600 occasionally active users"

and

"600 constantly active users"

600 sessions *constantly* on CPU means hundreds of cores. 600 sessions on CPU for a second every 5 minutes might mean just a few cores.

For high availability, check out the MAA resources we have https://www.oracle.com/database/technologies/maximum-availability-architecture/

There are various "tiers" of high availability - typically it comes down complexity/cost vs how close to the absolute 100% uptime you want to get close to. This is typically a business decision that needs some common-sense applied by your business reps. They'll often say "We must NEVER go down".... Once you explain what that *really* means in terms of hardware/software/application/data centre/region redundancy, they'll often come around to something more realistic from a cost/benefit/risk perspective.