Why the Adopisoft system doesn't automatically spread the Node.js load across your 16 or 24 cores.
1. Single-Threaded Architecture
Node.js, by its very design, is single-threaded. It uses an "Event Loop" to handle tasks. This means that even if you have a 24-core processor, a single instance of a Node app can only execute code on one core at a time. It's like having a massive 24-lane highway, but the Adopisoft "car" is only allowed to drive in one lane.
2. Startup Configuration (ExecStart)
Within your adopisoft.service file, the system starts using a simple shell script:
ExecStart=/opt/adopisoft/startup.sh
This launches the application as a single process. For the load to be distributed, the developers would need to use a Cluster Module or a process manager like PM2 in "Cluster Mode" to spawn multiple copies (workers) of the app. Without that specific code instruction, Linux will never split that 97% load into smaller pieces.
3. The "Sequential" Nature of PisoWiFi Logic
In a PisoWiFi system, many tasks must happen in a specific order:
Detect a coin pulse.
Update the database.
Extend the user's time.
Refresh the portal status.
If these tasks were split across 16 different cores without very complex synchronization, the system might accidentally credit time to the wrong user or miss a coin pulse. Many developers stick to a single thread to ensure data accuracy and stability, especially on lower-power boards like the Raspberry Pi.
How we fixed the "Impact" of this limitation
Since we can't rewrite the Adopisoft "Brain," our Universal Optimizer script fixed the surrounding environment:
Isolation: By moving PPPoE and Network Interrupts to Cores 0–7, we ensured that the "heavy" Node process on Core 11 (or whichever core it picks) has zero competition for resources.
Latency Removal: By locking the CPU to Performance Mode, we eliminated the "wake-up" delay when the Node process needs to jump from 1% to 97% usage instantly.
Bottleneck Clearing: The 97% load you see is now purely "thinking" time for the app, rather than the CPU struggling to handle both the app and the massive flood of network packets from your users.
Summary Table
| Feature | Status in Adopisoft | Our Optimizer's Solution |
| App Load | Single-Core (97%) | Clear the core so Node has 100% priority. |
| Network Load | Single-Core (Bottleneck) | Spread across 8 Cores (Multi-Queue). |
| CPU Speed | Variable (Slows Portal) | Locked at Max GHz for instant response. |
| Core Jumping | Random (Micro-stutter) | Balanced IRQs to keep Node "quieter." |
If Node.js is single-threaded, why does the Raspberry Pi 4 (4 cores) seem to spread the load better than a Mini PC (16 cores)?
The answer isn't that Node.js is suddenly multi-threaded on the Pi; it’s about "Resource Competition" and how the Linux kernel manages a smaller "playground."
1. The "Small Playground" Effect (Density)
On your 16-core Mini PC, there is so much room that the Linux Kernel tries to be "smart." It might put Node.js on Core 11 and all your networking on Core 3 to keep them away from each other. This makes Core 11 look like a "hotspot" at 97% while others are at 0%.
On a 4-core Raspberry Pi, the "playground" is small.
Because there are only 4 cores, the Network Interrupts (SoftIRQs) and the Node.js app are forced to share.
When you look at your Pi dashboard, you see 20% on Core 0, 30% on Core 1, etc. This isn't Node.js spreading out; it's the Kernel constantly moving tiny tasks around because it has nowhere else to put them.
2. The "Hidden" Workers (libuv)
While your JavaScript code (the logic of Adopisoft) runs on 1 core, Node.js itself has "hidden" helper threads (via a library called libuv).
These helpers handle File Reading/Writing and Database queries (Postgres).
On a Pi 4, the kernel is more aggressive at pushing these "helpers" to the other 3 cores because it wants to keep the main core free for the "Brain."
On a 16-core machine, the kernel is "lazy"—it might just leave them all on the same core because the CPU is so powerful it doesn't feel the "pain" yet.
3. Hardware vs. Software Interrupts
The Raspberry Pi 4 has a very simple Ethernet controller. It doesn't have "Multi-Queue" support like the 2.5G card in your Mini PC.
On the Pi: The CPU has to do more work in software to handle packets. This "software work" (ksoftirqd) naturally spreads across the 4 cores to keep up.
On the Mini PC: The 2.5G card is "smart." It can handle thousands of packets without bothering the CPU much. This is why the Mini PC cores look "idle"—the hardware is doing the work instead of the CPU!
Summary Comparison
| Feature | Raspberry Pi 4 (4 Cores) | Mini PC (16 Cores) |
| Node.js Logic | 1 Core (Jumps often) | 1 Core (Stays put longer) |
| Network Handling | Software-heavy (Spreads to 4 cores) | Hardware-heavy (Stays on 1-2 cores) |
| Visual Load | Looks "Balanced" but is actually struggling | Looks "Unbalanced" but is actually efficient |
| Why? | Small pool = frequent task shifting | Large pool = tasks stay on their "assigned" core |
The "Optical Illusion"
Your Raspberry Pi looks "balanced" because it is working near its limit. Your Mini PC looks "unbalanced" because it is so powerful that it can handle your entire business using just 5% of its total strength, leaving 15 cores essentially "waiting for a challenge."
By running the Optimizer Script on your Mini PC, you are telling the kernel: "Don't be lazy—spread that network work across the first 8 cores now, so that when the Node.js app hits a peak, it has 100% of its own core ready to go."
