Nidam Benchmark
Result Example
Show Result in new tab
What it is
Nidam Benchmark is a real-world, full-stack server workload benchmark designed to stress CPU Cores and memory, using a modern Java + OAuth 2.0 microservice architecture. Unlike synthetic tests, Nidam Benchmark measures how hardware performs under production-style backend load, including authentication, API processing, database access, and reverse-proxy routing.
Downloads
https://github.com/Mehdi-HAFID/Nidam-Benchmark-Application/releases/tag/2.0
- Important: I have not tested the ARM builds because I do not have an ARM-based PC. They are expected to work, but please report any issues.
- The Windows ARM GUI and CLI versions are not 100% ARM-native. One internal tool used by Nidam Benchmark is not available for Windows ARM, so part of the benchmark will still run using a non-ARM-native component.
How To Run
Windows
GUI Version
- Extract the ZIP file and launch
Nidam Benchmark.exe(Windows). - In the Threads field, enter the list of thread counts you want to benchmark, for example:
1,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32(No spaces allowed.) Then click Start. - When done benchmarking, Click Stop Button to terminate all background processes. Simply closing the GUI will not stop them..
CLI Version
This works the same as the GUI version but without the graphical interface. Ideal for automation.
- Extract the ZIP file, open a Terminal, and run:
Here,PowerShell Example
.\run-benchmark.ps1 "1,8""1,8"represents the thread sequence you want to test. You can also use longer sequences, e.g.:1,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32
Do you want to allow public and private networks to access this app? Zulu Platform x64 Architecture
Click Allow, Zulu Platform is simply Java.
To Stop the Benchmark Background Processes run: .\stop-all.ps1
Linux
GUI Version
I tested the GUI version on a Virtual Machine running Ubuntu 25.10. Extract, the resulting folder contains a Nidam Benchmark executable file.
you can double-click it to run. The same instructions as for Windows apply.
Shortcut
Since in Linux you cannot just right-click to create a shortcut, I added a install.sh script to the folder that adds
Nidam Benchmark to the list of applications. To install it, open Terminal and run ./install.sh.
The application will be added to Show Apps menu.
To create a desktop shortcut, go to /home/yourusername/.local/share/applications/ and copy the file nidam-benchmark.desktop in the desktop.
then right-click on it and click Allow Launching.
CLI Version
Extract, open a Terminal, and run:
bash run-benchmark.sh -r 1,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32
To Stop the Benchmark Background Processes run: bash stop-all.sh
Why hardware reviewers should care
Most server and workstation benchmarks focus on isolated CPU math, compression, or single-process throughput. Nidam Benchmark instead answers a different question:
How does this hardware perform when running an actual modern backend stack under load?
It exposes bottlenecks in:
- Single-core vs multi-core scaling
- Memory bandwidth and latency
What the benchmark actually does
The benchmark deploys and exercises a complete production-style backend stack: Reverse proxy / gateway, OAuth 2.0 Authorization Server, Backend-for-Frontend (BFF), Protected Resource Server (API), In-Memory SQL database (H2), Single Page Application (SPA), Load generator (k6)
Simulated users authenticate, obtain tokens, and call protected APIs through the full stack. Every iteration traverses multiple services, cryptographic operations, and database queries.
- The benchmark uses an in-memory database to avoid the bottleneck of disk I/O.
- Load Generator is the application that simulates a real world user authenticating and accessing the protected API.
What Nidam Benchmark Actually Stresses
Nidam Benchmark is not a synthetic CPU stress test — it models a real OAuth2/OIDC authentication workload end-to-end. Each Virtual User (VU) simulates a complete login through your system, exercising the same code paths used in production authentication servers.
Here is a breakdown of what Nidam stresses internally:
- Integer math pipelines, Branch prediction, Multiprecision multiplication
- Core frequency under sustained RSA workloads, single-thread JSON parsing and object creation
- The JVM’s thread scheduler and OS context switching
This workload is CPU-bound and can expose limits in SMT (Hyper-Threading / efficiency cores), especially at high thread counts.
What Nidam Does Not Stress
- No disk I/O
- No external network latency (all services run locally and communicate through in-process HTTP)
Defensive Password Hashing (Real-World Behavior)
In real production systems, password hashing is intentionally slow and memory-hard. Algorithms like scrypt (used in Nidam) deliberately avoid hardware acceleration so attackers cannot use CPU AES/SHA instructions to brute-force logins.
Scrypt stresses:
- CPU cores with repeated iterative work
- Memory bandwidth and latency
- RAM capacity per thread
This makes Nidam effective for comparing CPUs, memory speeds, and memory channel configurations under real authentication workloads.
Metrics reviewers get
Nidam Benchmark produces review-ready full HTML report for easy sharing, it shows:
- Throughput (logins/sec): Number of users authenticated per second across tested thread counts, e.g., for each thread count tested—such as 1, 4, or 8 threads—you get a corresponding logins/sec value.
- Average Latency per iteration (seconds): Time for a full iteration—user login plus API access.
- Thread count vs performance chart: Visualizes how latency and throughput change under load.
- Optimal thread score: Indicates the ideal thread count before latency spikes without improving throughput, expressed as throughput at that thread count.
How to Obtain Representative Benchmark Results
Why the first benchmark run may be slower
When running Nidam Benchmark multiple times on the same machine, it is expected that the first run may produce lower throughput and higher latency, especially at low to mid concurrency levels. This behavior is normal and is not caused by caching, I/O, or external dependencies.
Nidam is a pure CPU-bound benchmark:
- No disk I/O
- No network I/O
- No application-level caching
As a result, performance is dominated by JVM Just-In-Time (JIT) compilation and CPU microarchitectural warm-up effects.
CPU microarchitectural warm-up
In addition to JIT compilation, modern CPUs adapt dynamically to workload characteristics:
- Frequency scaling and sustained turbo states
- Instruction cache and µop cache population
- Branch predictor training
- Core scheduling and cache locality stabilization
After a full benchmark run:
- The CPU is already at steady operating frequency
- Instruction and branch prediction history is primed
- Thread placement is stable
This results in measurably higher efficiency in subsequent runs, even though no application-level state is preserved.
Recommended benchmarking practice
To obtain production-representative results:
- Treat the first run as a warm-up
- Perform multiple identical runs and use the average of subsequent runs
Production servers typically run for long periods, allowing the JVM and CPU to reach fully optimized steady state. Nidam Benchmark reflects this behavior when proper warm-up is applied.
Summary
- Variability between runs is expected and normal
- It is caused by JVM tiered JIT compilation and CPU warm-up
- No caching, I/O, or external dependencies influence results
- Steady-state measurements are the correct basis for comparison
Why it’s different from other benchmarks
| Synthetic benchmarks | Nidam Benchmark |
|---|---|
| Isolated CPU tests | Full production stack |
| Microbenchmarks | End-to-end workload |
| Short bursts | Sustained load |
| Unrealistic patterns | Real user flows |
| Single process | Multi-service, concurrent |
Nidam Benchmark doesn’t replace Cinebench or Geekbench — it complements them by showing what happens when hardware runs an actual backend workload for real users.
Notes
- Required Ports:
4001, 4002, 4003, 7080, 7081 - The result of the benchmark above of my machine: Ryzen 5800H with 32GB DDR4 RAM.