JDE HTML Web Server JVM Sizing Calculator
How many JVMs does the JDE web tier need? The honest answer depends on session memory, which varies by how people use the system. This calculator gives a transparent first estimate you can adjust as you gather real numbers.
Your numbers
Assumed placeholder. Measure from a heap dump or monitoring under real use.
Application classes and caches before any user logs on.
Your results
Starting point only. Validate with load tests and your Oracle sizing guidance before buying hardware.
JVMs needed vs peak users
Sweeps Peak logged-in users from 50 to 2000, holding your other inputs fixed.
Sizing sanity check
Optional: a short review of your JDE sizing assumptions.
Optional. The tool and every export work without this. No spam.
How to use it
Count peak concurrent logged-in users, not named users. Estimate session memory from monitoring on your current servers if you have it. Enter the heap you plan per JVM and a target utilization that leaves headroom for garbage collection. The result is the JVM count and a count with one spare for failover.
The logic
Total session memory is users times megabytes per session. Each JVM contributes heap times target utilization, minus its base footprint. Dividing gives the number of JVMs. A spare keeps the service up when one instance restarts or is patched.
- Smaller heaps often collect faster than huge ones.
- Active users drive CPU; sessions drive memory.
- Keep headroom for peak days such as quarter close.
What this does not cover
It ignores CPU, the enterprise server, the database and network latency. A web tier can be memory-sized correctly and still be slow because logic runs on the enterprise server. Treat this as one input to a sizing exercise, not the answer.
Frequently Asked Questions
What memory per session should I use?
There is no universal number. It depends on applications used, grid sizes and caching. Measure on a comparable environment and update the default.
Why use a utilization target?
Running a heap near full causes long garbage collection pauses. A target such as 60 to 70 percent leaves room for spikes.
Does this work for cloud deployments?
The memory arithmetic applies, but cloud autoscaling and instance sizes change the economics. Use it to size the baseline.
How often should I re-run it?
Re-run after user growth, new modules, or a tools release upgrade that changes memory behavior.
Netray can help review your monitoring data and sizing assumptions with your CNC team.
Related Tools
JDE Orchestrator API Concurrency Sizing Calculator
Convert peak calls per hour and average response time into concurrent requests, threads and JVM count, with a burst factor.
OracleJDE UBE Batch Window Calculator
Model UBE elapsed time against your batch window as you add parallel queue slots, including a contention penalty for each extra slot.
OracleJDE F0911 Table Growth Forecast Calculator
Project F0911 Account Ledger size over a horizon from daily documents, lines per document, row bytes, index overhead and annual volume growth.
OracleJDE Package Build and Deployment Request Template
A change request document for JDE package builds and deployments with objects, targets, approvals, back-out and verification steps.
More Oracle tools
See all- JD Edwards Document Types Reference (OP, SO, OV, PV)
- JD Edwards UBE Job Scheduling Worksheet
- JD Edwards Table Reference (F4211, F4311, F0101, F4101, F4102)
- JD Edwards Tools Release Upgrade Checklist
- JD Edwards Orchestrator Design Template
- JD Edwards Security Workbench Worksheet
- JD Edwards Environment Refresh Runbook Template
- JD Edwards UBE Runtime Log Worksheet
- JD Edwards Next Numbers Capacity Worksheet