# SixPanel vs SixPanel Docker vs aaPanel

> Source: https://www.allsweb.com/compare/sixpanel-vs-aapanel-vs-docker
> Markdown for agents: https://www.allsweb.com/compare/sixpanel-vs-aapanel-vs-docker.md
> Publisher: AllsWeb (www.allsweb.com)

Part of: Comparisons

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

| What was held constant | On all three machines |
|---|---|
| Hardware | AMD EPYC 7713, 2 vCPU, 4 GB — the same class on all three |
| Operating system | Ubuntu 24.04 on all three — the bench needed one release held constant, not the one we recommend today ([which is 26.04](https://www.allsweb.com/compare/operating-systems)) |
| Application | **our optimised 6amMart fork**, not plain CodeCanyon code — identical on all three machines, verified byte for byte: identical dependency lockfile, identical hash across the application, routes, modules and configuration. What that means for a buyer running the vendor tree is [set out below](#what-code-this-was-measured-on-and-what-that-means-for-you) |
| Data | the same shop, row for row — 66,701 orders, 3,865 items, 85 stores, 17,534 customers |
| Method | each machine measures itself over loopback with its real hostname and certificate; 40 samples per cell after a discarded warm-up |
| Reported | medians of alternating paired passes — never a single run |

Provenance: round **M5, measured 21–22 August 2026**, written up as `docs/measurements/2026-08-m5.md` in the product repository, which names every harness script beside the figure it produced (`bench-http.js`, `m5-onbox.sh`, `m5-db-battery.sh`, `m5-median.js`). Every number on this page comes from that round and nothing has been re-measured since, so read it as three weeks old rather than as today's reading.

## What code this was measured on, and what that means for you

The three machines all ran **our optimised 6amMart fork**, not the untouched CodeCanyon download. That is worth stating plainly, because most people buying 6amMart run the vendor tree, and this page's headline ratio was not taken on it.

What we can and cannot claim from that:

- **The ratio has not been re-measured on untouched vendor code.** We are not going to restate 1.76× as if it had been. The same round timed both trees on one box for a different purpose and the vendor tree was several times slower in absolute terms — 54.4 to 56.2 ms against the fork's 19.1 to 19.6 ms on a shared endpoint battery — so the two are not interchangeable baselines and a ratio measured on one does not automatically carry to the other.
- **The causes are panel-side, and those do carry.** The directory restriction and the JIT mode are PHP settings applied by the panel to whatever code it serves. Nothing about either depends on which 6amMart tree is on disk, so a vendor-code shop on aaPanel is paying the same fixed per-request tax.
- **The unexplained third stays unexplained** on either codebase.

If you run vendor code and want a number rather than a mechanism, the honest answer is that we have not measured yours, and [SixPreflight](/sixpreflight) will read your own server's two settings back for free.

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.

:::note Single runs lie on machines this size
Run-to-run spread reaches 15–30% on a short row. One endpoint's apparent 17% regression turned out to be a single-run outlier that a second run put at parity. Treat any panel comparison quoting one run of each — including one of ours — as unproven.
:::

## Every endpoint

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

| Endpoint | SixPanel | SixPanel Docker | aaPanel, stock | aaPanel, tuned |
|---|---|---|---|---|
| `/api/v1/categories` | **29.1 / 46.9** | 34.5 / 70.9 | 52.0 / 103.6 | 56.1 / 99.9 |
| `/api/v1/stores/get-stores/all` | **17.9 / 33.3** | 24.5 / 45.0 | 37.8 / 76.4 | 38.0 / 84.2 |
| `/api/v1/items/search` | **18.0 / 35.9** | 25.1 / 43.2 | 44.3 / 68.3 | 40.9 / 71.1 |
| `/api/v1/items/popular` | **41.6 / 77.2** | 50.7 / 94.6 | 58.4 / 112.1 | 65.3 / 122.9 |
| `/api/v1/customer/order/list` | **102.1 / 191.8** | 123.3 / 242.3 | 139.6 / 245.8 | 152.7 / 288.9 |
| `/` admin entry | **59.6 / 102.7** | 63.5 / 156.3 | 76.7 / 144.5 | 84.8 / 171.2 |
| storefront home | **54.3 / 104.0** | 111.4 / 213.5 | ≈83 / — | — |
| `/_next/static` asset | 1.8 / 4.7 | 2.2 / 6.9 | **0.3 / 0.8** | — |
| websocket handshake | **2.3 / 5.8** | 4.2 / 11.6 | 2.6 / 6.3 | — |

Three 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. **And on the static asset row aaPanel is the fastest of the three** — 0.3 ms against our 1.8 — for the same reason: it is serving that file from a proxy cache while we serve it from the framework. It is the one row in the table we lose, and dropping it while keeping the two that flatter us would be dishonest. 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:

| Configuration | One request | Four at once |
|---|---|---|
| As the two boxes ship | **1.99×** | 1.91× |
| After switching off aaPanel's directory restriction | 1.32× | 1.29× |
| After also correcting its JIT compiler mode | ≈1.25× | ≈1.21× |

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:

| Endpoint | Restriction on | Restriction off | Change |
|---|---|---|---|
| `/api/v1/config` | 37.7 | 20.3 | **−46%** |
| `/api/v1/stores/get-stores/all` | 39.8 | 23.5 | −41% |
| `/api/v1/items/search` | 40.6 | 24.1 | −41% |
| `/api/v1/categories` | 55.4 | 33.7 | −39% |
| `/api/v1/items/popular` | 70.7 | 51.5 | −27% |
| `/` admin entry | 85.7 | 66.4 | −23% |
| `/api/v1/customer/order/list` | 154.9 | 128.9 | −17% |
| *static file — never reaches PHP* | *0.4* | *0.4* | ***0%*** |

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.

:::note If you administer a server, this is the part worth keeping
The setting was in a per-directory file that four other places did not show — not the main configuration, not the site's own configuration, not the worker pool, and not what the command line reports. The only reliable check is to read the value back through the process that actually serves requests.
:::

### 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.

:::warning About a third of the gap is unexplained
The leading untested candidate is that aaPanel compiles its own PHP while Ubuntu ships a package, followed by a difference in how many files each caches. Neither can be isolated on a single machine, so neither is claimed. That share is published as unexplained rather than credited to us.
:::

## 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. That 20.9-second admin report was only **1.17×** apart between the two machines — the panel barely matters once the application itself is the bottleneck.

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 **the aaPanel box we measured, in its default configuration**, every site ran as the same unix user with world-readable files, so the PHP-level restriction was the only barrier. That is what its installer sets up — a single `www` account the stack runs as — and it is a default rather than a ceiling: an aaPanel administrator can give a site its own pool user, and on a server configured that way this paragraph does not describe it. On SixPanel the separation is not a setting anyone has to find: 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 — with the kernel, not PHP, doing the refusing.

Where the two overlap they part company: **a private file another site had written into the shared temporary directory was readable on that aaPanel box** 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 in this round the worst — the day-wise transaction report — took **20.86 seconds**, of which 12.43 seconds was inside the database driver, with **one query running 122 times at 87.6 ms each**.

No server setting reached it. It was present on every machine tested and the full aaPanel tuning pass moved it from 20,925 ms to 20,470 ms — about 2%.

**It was then fixed in the application, which is the point.** In a later round (26 August 2026) that page went from 17,549 ms to **712 ms** on the same box, and a live check on 1 September 2026 read **509 ms** against the full 66,701-order dataset.

That fix lives in the application's code, not the panel's, so it applies to the optimised tree and not to an untouched CodeCanyon download — the N+1 query is still in the vendor code. What we will not do is put a number on it: the vendor tree in that verification held **no orders at all**, so its millisecond readings are the cost of an empty report and say nothing about how it behaves under a real shop's data. The unfixed query pattern is a fact; a vendor-code timing for it is not something we have measured.

That is 6amMart's own code either way. No control panel can fix it and none should claim to — it needs the application changed, which is what the [6amMart installation service](/6ammart-optimized) does.

## So which should you install?

**SixPanel**, if this server exists to run one 6amMart shop. It was the fastest of the three on every endpoint that reaches PHP — aaPanel's proxy cache beat it on the static-asset row — and it isolates projects at the kernel rather than inside the PHP process.

**SixPanel Docker is not on offer.** It was retired on 29 August 2026 — no further work, no install command, its release notes left published. It appears in the table above because it was in the measurement, and dropping a column from a published benchmark would be dishonest. It ran PHP 8.4 and `mariadb:10.11` as images, which made it independent of the host's package list, and that was its whole case. Once the native runtime started taking MariaDB from the release's own archive and [10.11 against 11.8 measured a wash](https://www.allsweb.com/compare/database-engines), there was nothing left in it. No server ever ran it in production, so retiring it stranded nobody.

**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, supports a wider range of releases than we do (Debian 11/12 and Ubuntu 22/24, per its own installer), 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](https://www.allsweb.com/compare/sixpanel-vs-aapanel) · [SixPanel vs CloudPanel](https://www.allsweb.com/compare/sixpanel-vs-cloudpanel) · [SixPanel vs a plain server](https://www.allsweb.com/compare/sixpanel-vs-plain-server) · [Which database](https://www.allsweb.com/compare/database-engines) · [Which operating system](https://www.allsweb.com/compare/operating-systems)