SixPanel vs SixPanel Docker vs aaPanel

Three servers were rented together, set up identically, and given the same shop's data — 66,701 real orders. The only difference between them was the panel running the machine. This page is what came back.

If you only want the answer: SixPanel served 6amMart's API 1.76× faster than a fully tuned aaPanel at one request, and 1.82× faster with four arriving at once. Everything below is how that was measured, where the difference comes from, and the third of it we cannot explain.

The setup

Two things were wrong with the benchmark itself and were fixed before any number was trusted.

The application rate-limits at 600 requests a minute, on top of the web server's own limit. A blocked request is answered in microseconds, so a rate-limited run reports a better number than the truth. Every reported row now mints a distinct token per request and records zero blocked responses.

Cold reads were passing as warm ones. One admin report read 6,260 ms cold against 1,201 ms warm — a five-fold error, in the direction that invents a crisis. Every sweep now discards a warm-up.

Every endpoint

Median milliseconds: one request / four at once. Lower is better.

Two of those rows are not a fair race and are shown anyway rather than quietly dropped. On the admin entry SixPanel redirects in 430 bytes while aaPanel renders 352 KB. On the storefront home, aaPanel's number is a proxy-cache hit, not a page being rendered. The /api/v1/config endpoint is left out entirely: SixPanel answers it from the web server in 0.6 ms and never sends it to PHP at all, which would flatter us for doing different work.

The rival was tuned, and the gap did not close

Beating a competitor on its default settings proves nothing. So the aaPanel box was set up the way a competent administrator would set it up, and every number was taken again:

• PHP's compiled-code cache raised from 128 MB to 256 MB, with timestamp validation switched off
• Database buffer pool raised from 256 MB to 1152 MB — four and a half times larger
• Database log file raised from 128 MB to 320 MB; query cache switched off
• PHP workers corrected from an over-committed 50 to a sized 14
• Path cache quadrupled; web-server buffers doubled

Its PHP 8.4 and its JIT compiler were deliberately left switched on. Those are its advantages, and removing them would have rigged the test.

Against the stock box SixPanel was 1.65× / 1.80× faster. Against the tuned box it is 1.76× / 1.82×. The gap moved slightly the other way.

The one row that shifted is fully accounted for by switching the query cache off — a correction, not a handicap. MariaDB ships it off, it takes a global lock on every query, and with it on the box was reporting database timings faster than the connection floor, which is impossible.

The database battery did not move at all. A buffer pool four and a half times larger changed nothing, because these reports are processor-bound work over rows already in memory. The internals did improve — cache hit rate 99.856% to 99.930%, temporary tables spilling to disk 47.3% down to 22.1% — and the response times did not follow.

Where the difference actually comes from

Measured on the five endpoints that reach PHP on both machines, one variable at a time:

So: a PHP directory restriction ≈60% · the wrong JIT mode ≈8% · PHP version 0% · about 32% unexplained.

The directory restriction — a fixed 16 to 26 ms on every request

aaPanel restricts which directories PHP may touch. That is a genuine security feature, so it earned a real measurement instead of being dismissed.

Three alternating pairs, with the "off" arm writing an empty settings file so the per-directory scan happens in both arms:

Arm-to-arm spread on these machines is 1–13%; these effects are 17–46%; and the control moved by nothing at all. That last row is what makes this a result rather than a coincidence.

The mechanism was then counted three separate ways. 5,862 filesystem lookups per request with the restriction on, 214 with it off, and 217 on SixPanel. With it on, 400 path resolutions add zero entries to PHP's path cache; with it off they add 509. The cache is simply disabled — which is why aaPanel's own tuned cache-size setting bought it nothing.

Confirmed in the other direction on a second machine: switching the same restriction on for SixPanel reproduced 17 to 23 ms of extra time per request, with filesystem lookups up 19- to 33-fold.

The JIT mode — a four-digit number, not a switch

PHP's JIT setting takes a code, and the two named modes are different things: function is 1205, tracing is 1254. A tuning script that only asks "is JIT enabled?" will leave the wrong one in place and report the job done.

aaPanel ships 1205. SixPanel ships tracing. Three alternating pairs put tracing ahead on 9 of 9 endpoints at one request and 9 of 9 at four at once — geometric mean 5.1% and 6.2%. Any single one of those differences sits inside the machines' own noise; eighteen out of eighteen falling the same way does not.

For a Laravel application this is the expected direction. Function JIT targets tight numeric loops, which a web request does not run.

The PHP version — worth nothing

On the bench box SixPanel was running PHP 8.3, because that is what Ubuntu 24.04's archive ships and SixPanel takes every component from the release's own archive — so security updates arrive with no third-party repository in the serving path. (On the releases supported now that means 8.5 on Ubuntu 26.04 and 8.4 on Debian 13; the version follows the release, and this section is why that is a free choice.) The obvious objection is that 8.4 must be faster.

The aaPanel box has both installed, so it could answer this cleanly. The 8.3 pool was first given the entire 8.4 tuning — it had been left on defaults, which would have rigged the result — and every setting was verified from the running process rather than from a file.

Geometric mean 8.3 against 8.4: 0.9994. 8.3 was ahead on 3 rows of 7, and every difference was smaller than at least one arm's own spread. The slow admin report agreed.

What was ruled out

Each of these is a plausible explanation somebody could offer. Each was measured and is not the cause.

• The web server. Each endpoint timed over the wire and again inside a single PHP process, on both machines. Wire minus in-process is 0–7 ms on aaPanel and 3.5–5 ms on SixPanel, mostly the encryption handshake. aaPanel's is no larger, despite writing an access-log entry per request.
• The database. Query times effectively identical across all three configurations. Datasets within about 1% on every table.
• How PHP reaches the database. Both on the local socket, verified from the running process.
• The cache layer. Counted, not read from a configuration file: 17.1 cache commands per request on aaPanel, 18.1 on SixPanel. Neither is silently falling back to disk.
• PHP's compiled-code cache. Zero out-of-memory events, zero hash collisions, zero manual restarts on both.
• The hardware. Identical down to the processor model and the set of security mitigations enabled.

What the ratio means for a real shop

The tax is a fixed cost per request, so it dominates short work and disappears on long work. The same 20.9-second admin report is only 1.17× apart between the two machines.

If your shop is mostly heavy back-office reports, the difference will be small. If it is mostly phone-app API calls — which is what a food-delivery shop mostly is — it is the whole difference.

Isolation, since one panel is faster partly for not restricting PHP

"We are faster because we do not set that restriction" needed checking before it could be a claim. Every cross-project read below was actually attempted from inside a project's PHP, on both machines.

Every cross-project read failed on both. What differs is the kind of refusal. On aaPanel every site runs as the same unix user with world-readable files, so the PHP-level restriction is the only barrier. On SixPanel it is the kernel refusing a different user: a separate unix account per project, 0700 application folders, 0600 settings files, a separate database user with grants scoped to its own schema, and a worker pool of its own.

Where the two overlap they part company: a private file another site had written into the shared temporary directory was readable on aaPanel and refused on SixPanel.

What SixPanel did give up was read-only information disclosure with no secrets in it — the user list, the web server's configuration, other pools' names. That was closed with a kernel mount namespace, at a cost measured as identical to the system call: 217 filesystem lookups per request before, 217 after. It closed the shared temporary directory (57 visible entries to 0), the panel's own code, every project's site configuration, and the visible process list (138 to 6).

Two further proposals were rejected by measurement rather than shipped: hiding the web server's configuration closed nothing and broke the check-up tool, which reads it; and blocking the panel's directory wholesale would have taken the database administration tool down with it.

The slowest thing is none of the three

All 297 6amMart admin pages were timed on the real dataset. 290 answer in under 300 ms. Seven account for the whole problem, and the worst — the day-wise transaction report — takes 20.86 seconds, of which 12.43 seconds is inside the database driver, with one query running 122 times at 87.6 ms each.

It is present on every machine tested and moved by nothing: the full aaPanel tuning pass took it from 20,925 ms to 20,470 ms.

That is 6amMart's own code. No control panel can fix it and none should claim to — it needs the application changed, which is what the 6amMart installation service does.

So which should you install?

SixPanel, unless something specific rules it out. It is the fastest of the three on every endpoint measured, it isolates projects at the kernel, and it is the runtime that keeps being developed.

SixPanel Docker if you want the whole stack isolated in containers, or if you specifically want MariaDB 10.11 on a release whose own archive does not carry it. It runs PHP 8.4 and mariadb:10.11 as images on every host, so what the host's package list holds never affects it.

This used to be a wider recommendation: the native runtime took its database from MariaDB's own installer script, which refuses 10.11 on Ubuntu 26.04 and Debian 13, so the container was presented as the only route onto those releases. The native runtime now takes every component from the release's own archive, MariaDB included, and 10.11 against 11.8 measured a wash anyway — so both runtimes install on Ubuntu 26.04, Debian 13 and Ubuntu 24.04, and the container is a deployment preference rather than a workaround. The container runtime also still accepts Debian 12, which the native installer refuses; that is not a reason to start a shop there.

aaPanel if the server has to do more than run one 6amMart shop. It hosts unrelated sites side by side, runs mail, gives each site its own PHP version and its own user, and has years of forum answers behind every problem you will hit. None of that is what SixPanel is for, and SixPanel will not even install beside it. A speed ratio does not make a general-purpose panel the wrong tool for a general-purpose job.

Related

SixPanel vs aaPanel, feature by feature · SixPanel vs CloudPanel · SixPanel vs a plain server · Which database · Which operating system