Optimized 6amMart: the same script, measured and fixed
AllsWeb installs the latest 6amMart release — same script, same admin, same apps — on code we measured and fixed. Customer screens run 10× to 22× faster than stock, 342 defects are closed, and a suite that ships with the build proves it.
The optimized code is included in the installation price. It is not an upgrade, an add-on or a tier.
10× – 22×
faster on customer-facing screens
342
defects found and fixed
799
commits across five repositories
1–3 days
delivery once requirements are complete
Reading this with an AI assistant?
With it versus without it
What changes on the day you open
Stock 6amMart on the left, the code AllsWeb installs on the right. Same script, same admin panel, same apps, same vendor release — every figure measured on the same 4 GB, 2-core server with the same data.
The first screen a shopper sees
Stock
The featured row on the home screen takes 8.19 s to fill. Long enough that a shopper on a phone decides the app is broken and closes it.
Optimized
The same row fills in 0.37 s — 22× faster, measured with the CDN bypassed so what is timed is the application.
The store earnings report
Stock
Drawing one report asks the database 8,614 separate questions, holding a connection open for the whole time. A few admins opening it together is enough to make the shop feel unwell for everyone.
Optimized
The same report asks 12 questions. It looked acceptable in testing before, because on a small dataset those 8,614 questions are each fast.
A coupon's minimum spend
Stock
The admin panel lets you set it and the code never reads it. Proven live: a coupon requiring a ₹999 minimum was accepted on a ₹1 order, with six live coupons configured that way.
Optimized
Enforced in all three places an order can be priced.
Evening discounts
Stock
The database ran on UTC and the application on India time — measured 5 h 30 m apart on a live install. An 18:00–22:00 evening discount never applied during the evening and switched itself on at 2 a.m. The listing screen and the checkout used different clocks, so a store could be advertised discounted and charge full price.
Optimized
One clock, so the discount a shopper is shown is the discount they are charged.
Who can read a customer's order
Stock
More than six endpoints accepted any order ID with a guessed guest ID. Reproduced with no authentication at all: the response carried another customer’s items, prices and delivery address. The wallet-payment endpoint on the same path had no balance check.
Optimized
An ownership scope on every affected endpoint, with legitimate guest checkout still working.
A payment gateway you switched off
Stock
Turning it off in the admin panel only removed it from the customer's list of choices. Its callback URL stayed live, and many gateway callbacks mark an order paid on nothing more than a status word in the URL — so with every gateway switched off, a callback still completed and a customer could confirm their own order without paying.
Optimized
Fails closed, with 102 probes across every gateway prefix confirming none executes while inactive.
What it costs you
Stock
Stock 6amMart is what a normal installation hands you.
Optimized
The same installation, on the latest 6amMart release. No second licence, no second price, no upgrade tier — this is simply how the installation is delivered.
What "optimized" means here
The same 6amMart. Different underneath.
It is the same 6amMart — the current release, whatever 6amTech is shipping on the day we build your install. The same admin panel, the same vendor panel, the same customer, store and rider apps, the same data model, the same features you saw in the demo. Nothing was replaced and nothing was renamed. What changed is underneath: AllsWeb spent fourteen working sessions measuring the script, profiling it, and fixing what the measurements found — 799 commits across five repositories between 13 July and 9 August 2026, on the backend, the admin panel, the website and the three apps. Every one of those changes had to return byte-identical data before it was accepted. This is not a different product you have to choose. It is how we install 6amMart now.
What you are buying
- The service is unchanged
- Complete installation, setup and configuration of 6amMart on your hosting — admin panel, vendor panel, Android APK + AAB, iOS build, customer website, your branding, SMTP, Maps, Firebase push and OTP, social login, your payment gateways, your language file, and the customized source on a private GitHub repository.
- Delivery
- 1–3 working days once your requirements are complete.
- Free lifetime support
- For setup issues and small fixes.
- Your own CodeCanyon license
- You buy and own your own 6amMart license from CodeCanyon; we install on top of it.
The optimized code is included in the installation price. It is not an upgrade, an add-on or a tier.
Why stock was slow
One sentence, and one finding
The database was not slow. The application was asking it the same question hundreds of times per page.
The part most people have not seen
On one customer endpoint, a single request issued 112 database queries. Eighty-six of them — 76% — were issued while converting the finished result into JSON to send it, because attribute accessors fetched lazily, once per row, at serialization time. Seven fetched the data and eleven prepared it. That is why adding indexes alone would have changed nothing: the cost was not in the queries the page ran.
That endpoint now issues 45.
86 ÷ 112 = 76.8%, printed as 76%. The source prints 77%; a source rounding up does not license this page to round up.
The measured comparison
Before and after, on the same server
The method statement
| Condition | What it was |
|---|---|
| Before | The stock script exactly as CodeCanyon shipped it at the time of the experiment — baseline commit d92ce004, 8 July 2026 ‡ |
| After | The same script after the AllsWeb optimization and hardening program, with the vendor's next release layered on afterwards |
| Server | The same machine for both runs — 2 vCPU, 3.9 GB RAM |
| Method | Measured server-side, with the CDN bypassed |
| Scale of change | 799 commits · 342 fixes · 171 speed changes · 37 features |
| Acceptance rule | Every performance change had to return byte-identical data before it was accepted |
- ‡ What was measured. The before-numbers were taken against the stock script as CodeCanyon shipped it on 8 July 2026 — the release 6amTech numbered 4.0.1 — and the vendor's next release was layered onto the optimized code afterwards. That is a statement about the experiment, so the before-numbers can be reproduced against the same starting point. It is not a statement about what you receive: we install whatever release 6amTech is shipping on the day we build. Substantial further work landed on 13–15 August 2026 that the 9 August report does not cover.
- The acceptance rule, in one line. "Faster was never allowed to mean different."
- Rounded against us. Where a measured value is a range, the multiples here are computed the least flattering way the numbers allow — the lowest "before" divided by the highest "after". Our own report quotes midpoint multiples, which come out higher.
Nine rows, all before/after, and they are not all the same kind of measurement, so the table says which is which. Rows 1–5 are response times taken on the same server with the CDN bypassed. Rows 6–7 are counts of database questions per page, where "CDN bypassed" is not a meaningful condition. Rows 8–9 are not server measurements at all and carry a †. These are the rows a shop owner actually feels, not the biggest numbers we have.
| # | What it is | Stock 6amMart | Optimized | Multiple |
|---|---|---|---|---|
| 1 | Featured items on the home screen | 8.19 s | 0.37 s | 22× faster |
| 2 | Product search | 1.64 – 1.96 s | 0.09 – 0.12 s | at least 13× faster |
| 3 | Storefront home page | ~1.47 s | 0.073 – 0.096 s | at least 15× faster |
| 4 | Top categories | 3.34 s | 0.27 s | 12× faster |
| 5 | App configuration on launch | 0.53 – 1.15 s | 0.045 s | at least 11× faster |
| 6 | Store earnings export — database questions per page | 8,614 | 12 | 717× fewer |
| 7 | Product catalog listing — database questions per page | 557 | 92 | ~6× fewer |
| 8 | † Styling shipped on every website page — a build-output byte count, not a server timing | 921,603 bytes | 12,386 bytes | −98.6% (74× smaller) |
| 9 | † Ten app requests in sequence — measured from a handset over mobile data, not on the server | 6,140 ms | 1,876 ms | −69% (3.2× faster) |
† Rows 8 and 9 are not server measurements. The "same server, CDN bypassed" framing covers the response times in rows 1–5 only; the styling figure is a build output and the ten-request figure was taken over mobile data.
The arithmetic, printed
Row 6 prints 717×, not the 718× our own report writes: 8,614 ÷ 12 = 717.83, and this page does not round a figure up in its own favor. Row 9 prints 3.2× for the same reason — 6,140 ÷ 1,876 = 3.27. Row 8's byte count is 921,603 ÷ 12,386 = 74.4, printed as 74×. The 76% above is 86 ÷ 112 = 76.8%, rounded the same direction.
Concurrent capacity, stated the only way the evidence allows
On the same 2 vCPU server, under a load ramp against the store-listing endpoint, 13× more customers can use it at once on the same server. The underlying requests-per-second pair is deliberately not printed: the source records the load ramp without stating its concurrency or its duration, and a requests-per-second figure that cannot name its endpoint, its concurrency and its duration does not go on this page. The SixPanel figure further down has all three, which is why that one is printed as a rate.
Two rows that are not a speed story
| What it is | Stock 6amMart | Optimized |
|---|---|---|
| Endpoints returning a server error on a clean install | 3 (popular stores, latest stores, payment methods) | 0 — all three now answer in 41–150 ms |
| Known dependency security advisories, counted 9 August 2026 | 111 | 0 |
What the 111 actually were. 110 of them were axios and vite versions inside five addon-module package.json files whose build pipelines have never worked — four point at source files that do not exist in the module, and the fifth points at two files that are zero bytes. They were raised anyway, because an alert you have decided to ignore is an alert you stop reading. The one that mattered on its own was firebase/php-jwt below 7.0.0 (CVE-2025-45769), previously recorded as unfixable, now on ^7.0.2 and verified against the real Apple, Passport, Firebase and Google keys.
The advisory row is a snapshot with a date on it for a reason: advisory feeds move continuously, and a count taken on 9 August 2026 is a statement about that day, not a standing property of the build. Re-run the audit on your own install for a current number.
Current state, with its qualifier attached A sweep of 306 endpoint requests reports zero server errors and zero endpoints over 250 ms — measured over the requests that executed. In a valid run the platform's own rate limiter rejects 66–68 of them, roughly a fifth of the sweep, and a rejected request is not an endpoint result. The recorded valid-run split (~235 successful, 66–68 rejected) adds to about 302, not 306; we cannot reconcile the remaining requests from the sources we have. Run it yourself and read your own split — the verification section below explains how.
Root causes
The three causes worth naming
They are what make the table believable.
The earnings export asked for the wrong thing 2,867 times.
It told the database to fetch each transaction's store through the order, while the code read the store directly from the transaction — a different link. The instruction never applied, so all 2,867 rows fetched their own store separately.
Every vendor page drew two navigation menus.
One hidden by the stylesheet, both counting the same order badges.
A page header loaded the store's entire order history.
466 orders for the busiest store, to fill a section of the page that had been commented out.
And the index finding
Ten of the columns the database joins on had no index at all. After indexing, one lookup went from reading 51,074 rows to reading one.
The admin customer list was examining 16,092,496,536 rows to return 98 — 82% of all slow-query time on the server, and up to 18 minutes for a single page load.
What was fixed
Performance, security, correctness
Performance
Database questions per single request — every one verified byte-identical before the change was accepted.
Customer API
| Operation | Stock | Optimized |
|---|---|---|
| Product catalog listing (31 items) | 557 | 92 |
| Vendor order list (41 orders) | 212 | 12 |
| Order details formatting (40 rows) | 121 | 4 |
| Customer order history | 166 | 97 |
| Wishlist (6 items) | 140 | 37 |
| Store listing | 78 | 39 |
| App configuration | 54 | 21 |
| Category list | 43 | 16 |
Admin and vendor panels
| Screen | Stock | Optimized |
|---|---|---|
| Store earnings export | 8,614 | 12 |
| Admin order search | 259 | 14 |
| Flash-sale product picker | 186 | 42 |
| Product gallery | 166 | 48 |
| Rental provider list | 159 | 9 |
| Reels store dropdown | 127 | 62 |
| Customer detail page | 106 | 34 |
| Rental vehicle list | 94 | 13 |
| Store earnings page | 89 | 13 |
| Every vendor page, before its own content | 61 | 52 |
The admin and vendor panels had never been measured — stock 6amMart's own automated checks only cover the customer API. 586 admin and 165 vendor pages were profiled, counted in database questions "because a count is exact and repeatable while a stopwatch on a shared server drifts".
Website
- Of the 921,603 bytes of styling on every page, 902 KB was three complete icon libraries — 21,459 icon definitions shipped so the site could display 89 icons. The build now emits only the icons actually referenced, and total styling per page is 12,386 bytes, −98.6%.
- Shared JavaScript 429 kB → 269 kB (−37%).
- The landing page was an empty shell until JavaScript loaded; it now ships 273,110 bytes rendered by the server.
- Configuration requests: one per page view per visitor → one per minute per language.
- The Maps library was being sent to 9 pages that show no map.
- Per-row date formatting: 8.45 µs → 0.39 µs (21× cheaper).
- All 50 website routes improved or held; none grew.
Mobile apps
- Every request was opening a brand-new secure connection instead of reusing one — roughly 426 ms per request on mobile data. Ten sequential requests: 6,140 ms → 1,876 ms.
- Home screen: ~30 requests per launch → 1 request covering 14 sections.
- A 1000×1000 photo was being decoded behind a 40-pixel avatar; images now decode at the size actually shown.
- 309 debug logging statements were shipping inside the released apps. Now zero.
- Rider GPS: 360 → ~30 position reports per stationary hour.
- The vendor order screen redrew everything every 10 seconds; it now redraws only when data changed.
Security — the specific holes found in the script as sold
Nothing in this section is a preference. Each is a defect present in stock 6amMart, and each was reproduced before it was fixed.
Unauthenticated SQL injection reachable from every store listing.
The store-listing code inserted the raw latitude and longitude request headers straight into the SQL distance calculation. Reachable with no login and no token. Confirmed reaching the database — an injected payload produced a database syntax error in the live log. Fixed with bound parameters; a second, unused injection point was deleted.
Any customer's orders readable and editable by anyone.
More than six order endpoints accepted any order ID together with a guessed guest ID. Reproduced live: a request with no authentication at all returned another customer's items, prices and delivery address. The wallet-payment endpoint on the same path had no balance check. Fixed with an ownership scope across every affected endpoint, while keeping legitimate guest checkout working.
Payment gateways switched off could still settle payments.
Turning a gateway off in the admin panel only removed it from the customer's choices — its callback URLs stayed live, and many gateway callbacks mark an order paid on nothing more than a status word in the URL. With every gateway switched off, a callback still executed successfully, so a customer could confirm their own order without paying. Fixed fail-closed; 102 probes across every gateway prefix now confirm that none executes while inactive.
Vendors could act on other vendors' data.
Any vendor could edit or delete another store's products, add-ons and banners — including the admin's own home-screen banners. Replying to a review reassigned that review to the replying vendor's store. Fixed with store scoping.
A live demo-login backdoor — and what it did not reach.
6amMart ships a demo shortcut so an app-store reviewer can sign in without an SMS. It reads the phone number and code from config, with the demo values as the fallback when config is absent — and config is absent exactly once a site runs the standard production caching step, which every live install does. On the live site, one hardcoded number was being handed a working code with no SMS sent and nothing in config asking for it. The impact was bounded, and we state the bound: no account existed on that number, so the path led to a new account with phone verification bypassed — not a takeover of anyone's existing account. The fallback is what made it dangerous: an operator who had never heard of the setting still shipped the backdoor. 28 automated checks now prove it cannot exist unless deliberately enabled.
The whole project folder was readable over HTTPS.
6amMart points the web server at the application folder rather than public/, held back only by a hand-written deny-list. A deny-list protects the paths somebody thought of; fourteen were not on it, each confirmed with a real request — including a 679 KB installer database dump, a 5.9 MB archive of the public folder, and one PHP file that the server actually executed, returning a fatal-error page that disclosed the server's absolute paths. The web root was moved to public/; all fourteen now return 404, and 19 automated checks hold it there.
The rate limiting story is three separate defects, not one.
- 1
The API had no rate limit at all.
The framework configuration defined a 600-per-minute API limiter, but nothing ever applied it — the API middleware group contained one unrelated entry and nothing else, so the limiter was dead configuration. Measured before the change: 40 wrong-password sign-in attempts against one account, as fast as curl could manage — 40 rejections, no throttle, no delay, nothing logged. Three limits now apply: a 600/minute backstop, 10/min on authentication attempts keyed on both the address and the account being attacked, and 5/min on the routes that send a real SMS. Verified: 25 rapid wrong passwords → 10 rejections then 15 throttles; a different account from the same address in the same window → not throttled; 60 ordinary browsing requests in one burst → all successful.
- 2
The limiter then keyed on an identity that half the platform never has — and we found that one ourselves, reviewing our own fix.
The new limiter keyed on the signed-in user, falling back to the network address. But the vendor and deliveryman APIs authenticate by looking a bearer token up in a table rather than through an auth guard, so the user was always null and the key fell back to the address. A store with staff on one office connection, or riders behind a carrier NAT, would have shared a single 600/minute budget — and the delivery app polls every 10 seconds, so a busy shift would have started refusing people who were working. The key now falls back to a hash of the bearer token first. Verified: two vendor-token calls → 599 then 598 remaining on their own counter; a customer token immediately after → 599 on a separate budget; no token → still keyed on the address, 600 intact.
- 3
The platform could not see the real visitor.
Behind a CDN, every request arrived from the CDN's address and the application believed that was the visitor — so rate limiting throttled all customers as one, fraud checks compared the wrong address, and every order stored a proxy IP instead of the person who placed it. Root cause: the framework ships proxy handling in its global stack and 6amMart replaced that stack wholesale, dropping it, so configuring trusted proxies alone had nothing to attach to. Both halves are now in place, and a forwarded request resolves to the real client address. The platform now sees the real visitor instead of treating the whole internet as one user.
A cache-poisoning primitive.
The listing cache computed its key from the URL query string, but the endpoints read their parameters through a method that prefers the request body whenever the request declares a JSON content type — including on a GET. So a request could ask for one search term in the URL and a different one in the body: the key was computed for the first, the search ran for the second, and the wrong rows were stored under the first key and handed to every real customer who searched it until the entry expired. Unauthenticated, and the attacker chose both halves — which products a shopper saw, from which store, at which prices. Requests whose input the key cannot see are now answered outside the cache entirely.
Also closed
Every invoice was downloadable by anyone who could count.
Order, subscription and trip invoices were enumerable by URL.
Stored XSS from vendor to admin.
Vendor-written product descriptions rendered as raw HTML in 8 admin and vendor screens, so a vendor could run scripts in the admin's browser. Sanitized, and proven safe against 25,726 live product descriptions with zero changed visible text.
Payment callback replay.
Callbacks were not idempotent, so a replayed callback credited the customer twice. Fixed at hook level across all 47 gateways.
An open redirect on the app-redirect route.
A phishing shape on your own domain. Fixed, then fixed again when a backslash bypass was found in review; a 17-case test now guards it.
Two public debug routes.
One ran a cache-wipe command with no authentication, the other was an open image relay. Both deleted.
laravel.log downloadable from the internet.
Containing the database username, failed SQL with its bindings, and full server paths.
One application key shipped to every install.
The example environment file carried a real key; a fresh environment file copies it, and the key-generation step only fires on an empty value, so it was skipped — every install built that way ran on the same key, printed inside every copy of the product.
GET requests that change settings — mitigated, and stated narrowly.
In stock 6amMart, changing a setting is an ordinary link, so 64 admin and vendor GET routes write state. A crawler, a link preview, an image tag or a background fetch can change settings while an admin is signed in. This is not theoretical: on 1 August our own performance profiler requested those addresses while measuring page speed and changed 8 live settings in 45 seconds — panel text direction flipped, the landing page switched off, a vendor disabled. Restored and verified within the hour. The shipped fix is a single guard registered once that reads the browser's Fetch Metadata headers — which state why a request was made and cannot be faked by an attacker's JavaScript — and refuses shapes that are never a human click. Verified live: an image-tag load of a settings address is refused; a prefetch is refused; a cross-site background fetch is refused; a real administrator clicking works; the panel's own 338 background requests work; older browsers that send no such headers work. 102 real panel pages render byte-identical with the guard on and off, and 53 automated checks cover it. One registration covers 1,348 routes, including modules that declare their own route groups.
The exploit path from a browser is closed. The routes themselves still write on GET — see Honest limits.
Correctness — the money defects
| Defect in stock 6amMart | What was measured |
|---|---|
| Coupon minimum spend was never enforced | Admins could set it; the code never read it. Proven live: a coupon requiring a ₹999 minimum was accepted on a ₹1 order. Six live coupons had minimums set. Now enforced in all three places an order can be priced. |
| Discounts were judged by the wrong clock | The database ran on UTC and the application on India time — measured live at 5h30m apart. An 18:00–22:00 evening discount never matched during the evening and switched on at 2–3 a.m. Worse, the listing screen and checkout used different clocks, so a store could be advertised discounted and charged full price. |
| Add-on quantities were charged against the wrong add-on | Quantities were paired to add-ons by position in a list, but the customer's app sends menu order while the database returns internal-ID order. Demonstrated on the server: an order intended at ₹270 was billed ₹550. Fixed in all 8 places in the code that did this. |
| Stock was decremented on the wrong product | A campaign purchase looked the product up by campaign ID against the products table. All three live campaign IDs also existed as product IDs. |
| The checkout stock guard checked a different number than it wrote | The final check compared the product's overall stock; the decrement happened on the chosen variation's stock. Measured on live data: 56 active products where a legitimate purchase would be refused, and 1,451 where an oversell would go undetected. |
| A repeated gateway callback credited the payment twice | Also triggered by a customer refreshing the return page. Fixed at hook level across all 47 gateways. |
| Buy-now checkout priced whatever the phone sent | Rather than the server's cart. |
| A withdrawal could be approved twice and leave a wallet negative | Reproduced live: approving twice credited the withdrawn total twice and drove the pending balance to −50.00. A back-button or a double-click was enough. |
| Order IDs were assigned by hand | The code read the highest existing order ID and added one — re-implementing auto-increment badly, and colliding under concurrent checkout. |
| Two riders could accept the same order | And two customers could buy the last unit. Check-then-write races, now atomic database claims, proven with concurrent transactions. |
On the two counts you will see quoted. The project's own totals rate 4 of the security holes critical and 6 of the defects money-affecting, out of 342 fixed. Those are the lower, published tallies, so they are the ones this page uses. They are not counts of the items listed on this page: the security section above names more than four security defects and the table above lists ten money defects, because we list every one we reproduced, not only those inside the two tallies.
Non-money correctness worth listing
- The scheduler had never run. Five scheduled background tasks had never executed once since deployment — the system cron entry was never installed.
- The monthly payout job ran four times a month (the schedule was written as "days 28–31" rather than "last day of the month").
- Order history reported every store as unrated — 0 stars everywhere, while the real rating for one store was 4.31 across 29 reviews.
- Rider deliveries never counted toward product popularity — the increment loop used a property name that does not exist on that record, so the block silently did nothing, skewing every "top products" ranking.
- Push notifications were silently disabled — queued to a worker that might not exist; nothing delivered, no error raised.
- 34 server errors across the admin and vendor panels → zero.
- A vendor with no store row took down 9 of 12 pages of its own panel, the vendor web login, and the store app's login — one shared helper returned the first element of an empty relation, which raises instead of returning null. 43 checks, including paired assertions that a legitimate vendor still passes.
- One admin report has never worked on any installation of this software — it compiled to invalid PHP and always failed. Found by checking all 895 screen templates; it was the only faulty one.
What ships with the optimized install that stock does not
| Capability | What it is |
|---|---|
| Automated verification suite | Scripts you run yourself. Each assertion was proven to fail against the old code before it was accepted — a test that passes on a broken system proves nothing. At the 9 August report the 60 scripts were 55 assertions plus 5 reporting tools, and the reporting tools assert nothing. Plus 49 unit and feature tests. |
| Schema reproducibility proof | The database can be rebuilt from the code alone — proven by building it from nothing and comparing all 184 tables, column by column and index by index, with no differences. |
| SixPreflight | A server-readiness tool: ~134 checks across hardware, PHP, application health, permissions, web server, caching, database settings, public exposure and every outside service. Open it in a browser before launch and it tells you what will break. |
| Deployment runbook | Documented install and update sequences plus the traps: which commands silently clear the config cache, which caches do not rebuild each other, what the hosting panel undoes when you save a setting. |
| iOS builds | All three apps signed and building for Apple as well as Android — the first Apple builds produced for this project. |
| Live order tracking actually on | The websocket service turned on and the two defects that kept it off fixed; certificate renewal proven. |
Check it yourself
Check every number yourself
The most persuasive thing on this page is not a number. It is that you can check every number yourself.
The verification suite ships with your install. On your own server:
bash tests/Scripts/run-all.sh # the verification checksphp tests/Scripts/api-smoke.php # sweeps every API endpoint1Each assertion was proven to fail against the old code before it was accepted.
A test that passes on a broken system proves nothing.
2The endpoint sweep fires 306 requests.
It reports server errors and response times per endpoint — so "zero server errors, zero endpoints over 250 ms" is a thing you re-run, not a thing you take our word for. Read the rejected count on your own run before you read the timings; see the operating note below.
3The suite includes the security assertions.
Not just the speed ones: the web-root exposure sweep, the demo-OTP backdoor check, the payment-hook idempotency check, the cross-account guards, the cache-poisoning checks, and an audit of which GET routes write state.
4The schema check rebuilds the database from the code alone.
It diffs all 184 tables against your live one.
Honest operating note Run the endpoint sweep too many times in a row and it trips the platform's own rate limiter. Throttled requests do no database work, so the query total falls and the run looks faster while testing almost nothing. A valid run shows about 235 successful and 66–68 rejected requests; hundreds rejected means discard the run.
And the current state of the suite, stated exactly The 9 August report recorded 60 scripts — 55 assertions plus 5 reporting tools — and 49 unit and feature tests. The directory has since grown to 86 entries, which includes reporting tools and other non-assertion files, so it is not a count of checks. The latest recorded full run executed 70 of them: 61 pass, 2 fail, 7 skip. Both failures are named in the evidence — two rental admin reports returning a server error on installs with no rentals, and a missing asset map-back — and at least the rental one was fixed afterwards. Re-run the suite on your own install and read your own number.
Honest limits
What this page does not claim
A page that says "here is what we measured, here is how to check it, and here is what we have not solved" is harder to disbelieve than one that only prints its wins.
342 defects were found and fixed. Nobody can enumerate what remains.
That is the honest shape of a platform this size.
Nothing in this program measured any other vendor's work.
So this page makes no claim about anyone else's build. Every number here is the stock script as it shipped at the time against our optimized code, on one server.
Every figure on this page is rounded against us, never towards us.
On customer-facing screens the measured improvement is 10× to 22×, which is 90 to 95% less waiting — 22× is 95.4% and we print 95. Where a measurement is a range, the multiple is the lowest "before" over the highest "after".
The 10-million-order figures on this page are a scale test, not live performance.
They come from a purpose-built database loaded with 10,000,000 orders, 1,000,000 products and 200,000 customers, deliberately run against an under-provisioned 128 MB buffer pool so it is I/O-bound like a real under-resourced server. The audited production install holds 3,282 orders.
Six scale-test rows are still at or above one second, and we print all eleven rows below.
Dispatch badges are 12 s; popular_products 7.1 s; the admin order list at a deep page offset 3.1 s; the item report 12.5 s for one month and 131 s for all time; the admin customer list about 1–1.5 s. The item report's all-time figure is the worst thing we measured anywhere, and the stock run it should be compared against was killed at 120 seconds, so we cannot even claim an improvement there — only that ours finishes.
GET requests that change settings are mitigated, not eliminated.
The browser-driven exploit path is closed and verified; the 64 admin and vendor routes themselves still write state on a GET, and converting them to protected forms was deliberately not attempted because it is a large regression risk on a platform that is currently working across many derived projects.
The guard is broader than the vulnerability.
A harmless read-only listing is also refused if it arrives as a prefetch or an image load, because separating the panel's ~860 read-only addresses from the 64 dangerous ones needs exactly the fragile list we chose not to write. There is a one-line switch to turn it off.
Rate limiting is safe because of where the servers sit, not because headers cannot be forged.
The configuration trusts forwarded headers, which holds only as long as nothing can reach PHP except through the proxy chain. A box reachable directly would let a client forge the header and get a fresh bucket per request.
App download size barely moved.
About 0.7 MB in total, because the unused code we removed was already being discarded by the release compiler. We make no app-size claim.
Three items on the reference install are open and named rather than hidden.
The Google Maps keys are unrestricted and need locking down; an Apple Sign-In private key that stock 6amMart's own upload helper had placed in public storage needs revoking and reissuing; and three vendors still have no store row — the 500s that state used to cause are fixed, but the state itself is still reachable because both registration paths save the vendor and the store outside a single transaction. All three are in the handover document.
On the reference server, the hardware is now the limit, not the code.
Load tested at 20–40 concurrent users with zero errors; at that point the 2 vCPU machine saturates.
All of these benchmarks are one server, one dataset.
They are enough to say what changed on this install. They are not a general statement about every 6amMart deployment.
Stock 6amMart is a widely used commercial product.
The defects above are stated as facts, which is enough.
The scale test, printed in full — every row, including the bad ones
Scale test — a purpose-built 10-million-order database, not live traffic.
| Screen | Stock | Optimized | Still slow? |
|---|---|---|---|
| Admin order list, first page | 27.4 s | 13.6 ms | |
| Order-count badges on every vendor page | 136 ms | 20 ms | |
| Item report, this_week | killed at 120 s | 542 ms | |
| get_stores | 9.8 s | 901 ms | |
| Order-count badges on every admin page | 8.5 s | 830 ms | |
| Admin customer list, first page | 20.7 s | ~1.0 – 1.5 s | ≥ 1 s |
| Admin order list, deep page offset | 100 s | 3.1 s | ≥ 1 s |
| popular_products | 12.8 s | 7.1 s | ≥ 1 s |
| Dispatch badges | 29.8 s | 12 s | ≥ 1 s |
| Item report, this_month | killed at 120 s | 12.5 s | ≥ 1 s |
| Item report, all_time | killed at 120 s | 131 s (365-day floor) | ≥ 1 s — the worst row we have |
Where two sources disagree on a row, this table prints the less flattering number on both sides.
Our own report records the admin customer list at ~1.0 s while the raw harness log records 1.5 s, so the range is printed. The report records the admin badges at 8.5 s → 830 ms where the raw log reads 57.4 s → 791 ms, and the vendor badges at 136 ms → 20 ms where the raw log reads 270 ms → 13 ms; in both cases the smaller "before" and the larger "after" are printed.
Will this matter to me?
At a realistic 100,000 orders — thirty times the audited install's current volume — and with the order-badge windows switched off, all nine screens profiled at that volume measure at or under 250 ms, and six of the nine at or under 50 ms: vendor badges 3.4 ms, get_latest_products 10 ms, customer list 31 ms, item report 46 ms, popular products 47 ms, store listing 50 ms, dispatch badges 146 ms, admin order list 155 ms, admin sidebar badges 179 ms. The badge window (ORDER_BADGE_WINDOW_DAYS=60) is a shipped setting, and whether it is on changes these numbers, so we state the condition the measurement was taken under.
FAQ
Questions buyers actually ask
Twelve questions, answered with the same numbers as the rest of the page.
What am I actually buying?
The same thing AllsWeb has always sold: complete installation, setup and configuration of 6amMart on your hosting — admin panel, vendor panel, Android APK and AAB, iOS build, customer website, your branding, SMTP, Google Maps, Firebase push and OTP, social login, your payment gateways, your language file, and the source on a private GitHub repository. Delivered in 1–3 working days once your requirements are complete, with free lifetime support for setup issues and small fixes. The optimized code is how that install is built now.
Do I get the same 6amMart?
Yes — the latest 6amMart release, whatever 6amTech is shipping when we build your install. Same admin panel, same vendor panel, same customer, store and rider apps, same data model, same features. Every performance change was gated on returning byte-identical data before it was accepted, so your screens show what they showed before, faster.
Does the optimized code cost extra?
No. There is no separate product, no separate license and no premium tier. The installation price in the catalog is the price, and the optimized code is included in it. You still buy and own your own 6amMart license from CodeCanyon.
How much faster is it, really?
On the live server, with the CDN bypassed: featured items 8.19 s → 0.37 s (22×), top categories 3.34 s → 0.27 s (12×), product search 1.64–1.96 s → 0.09–0.12 s (at least 13×), the storefront home page ~1.47 s → 0.073–0.096 s (at least 15×). Row multiples are computed the least flattering way the measurements allow. The typical figure across customer-facing screens is 10× to 22× faster — 90 to 95% less waiting.
Where do those numbers come from, and on what hardware?
Before is the stock script exactly as CodeCanyon shipped it at the time of the experiment — the method note above footnotes which build that was and why the footnote is there. After is the same script after the program, with the vendor's next release layered on. Both were measured on the same 2 vCPU / 3.9 GB server, server-side, with the CDN bypassed — not on a bigger machine, and not with a CDN doing the work. Two rows in the comparison table are not server timings and are marked as such: a build-output byte count, and a handset measurement over mobile data.
Can I verify any of this myself, or do I have to trust the page?
You can verify all of it. The verification suite ships with your install: bash tests/Scripts/run-all.sh runs the checks and php tests/Scripts/api-smoke.php sweeps 306 API requests and prints the response times. Each assertion was proven to fail against the old code before it was accepted, so a pass means something. One caveat we would rather tell you than have you discover: a valid sweep has about 66–68 requests rejected by the platform's own rate limiter, and a run with hundreds rejected should be discarded.
Will 6amTech's own updates still work on it?
Mechanically, yes — it has been done. The vendor's next release was layered onto the optimized code, and further work landed after the 9 August report: cache hardening, a rebuilt expense listing, and an application-key defect that affected every install built from the vendor's example configuration. The honest detail is that our fixes sit in the same files 6amTech ships, so a vendor release is a merge we perform for you, not a file-by-file overwrite you run yourself.
What happens when 6amTech ships the next 6amMart release?
If you are buying now, you get it — we install whatever is current on the day we build. For an install we delivered earlier, the same thing happens as for any customer on any of our catalog scripts: moving to a newer release is the standard update service at 50% of the installation price, because the configuration from your first setup is reused. Applying it to the optimized code is the merge described in the previous answer, and it is our work, not yours.
What security problems were actually in the stock script?
Reproduced, then fixed: unauthenticated SQL injection reachable from every store listing; any customer's orders and delivery address readable without signing in; payment gateways that were switched off in admin but whose callbacks still settled payments; vendors able to edit other vendors' products and banners; a live demo-login backdoor (bounded — it led to a new account with phone verification bypassed, not to taking over an existing one); fourteen project paths readable over HTTPS, including a 679 KB installer database dump; every invoice enumerable by URL; and an API with no rate limit at all — 40 wrong-password attempts in a row were all accepted with no throttling and nothing logged.
Will it still be fast when my shop grows?
Up to roughly 100,000 orders, yes: nine screens profiled at that volume, with the order-badge windows off, all measure at or under 250 ms and six of the nine at or under 50 ms. That is thirty times the audited install's current volume. Beyond that, read the scale test in Honest limits above — it is not all wins. At 10,000,000 orders against an under-provisioned database, the admin order list goes from 27.4 s to 13.6 ms, but dispatch badges are still 12 s, popular products 7.1 s and the all-time item report 131 s. Those are scale-test numbers on a purpose-built database, not your live server.
Do you claim there are no defects left?
No. 342 defects were found and fixed. Nobody can enumerate what remains in a platform this size. What we can show you is what was measured, how to re-measure it, and which items are still open — the Honest limits section on this page lists them, including the scale-test rows that are still slow and the routes we mitigated rather than rewrote.
What are you still not happy with?
Several things, and we would rather you read them here. In the 10-million-order scale test, six rows are still at or above one second — the worst is the all-time item report at 131 seconds, and the stock run it should be compared against was killed at 120 seconds, so we cannot claim an improvement there at all; dispatch badges are 12 seconds. Sixty-four admin and vendor routes still change state on a plain GET — the browser exploit path is closed and verified, but the routes themselves have not been converted. And on the reference install the Google Maps keys are unrestricted, an Apple Sign-In key needs revoking and reissuing, and three vendors still have no store row.
Companion tools
Where SixPanel and SixPreflight fit
Everything above is about the 6amMart code itself. Two AllsWeb tools sit either side of it — one runs the server the shop lives on, the other tells you whether a server you already have is ready for it. Their numbers were measured at a different time on different machines, so we keep them in their own tables and never mix them with the numbers above.
SixPanel
When you want the server managed
What it is
A management panel that runs one 6amMart shop, or several, on one rented VPS — MariaDB, Redis, nginx, the websocket service for live order tracking, and an optional Next.js storefront. Two runtimes: the recommended one installs everything directly on the machine from the release's own distribution archive under systemd, and SixPanel Docker runs the same stack as Docker Compose services. One install command, deploy from a CodeCanyon zip or from git, automatic Let's Encrypt certificates with automatic renewal, scheduled incremental restic backups with retention, per-project virtual hosts, hardware autotuning, and a self-healing watchdog that restarts services which are running but broken. Three surfaces: the panel in a browser, a sixpanel command on the host, and the installer. It ships a 24-chapter customer manual, served inside the panel.
Measured, and safe to publish
| What was measured | The figure, with its conditions |
|---|---|
| Requests served — search endpoint, 20 concurrent, 30 seconds | A 2-core / 4 GB server completed about 53 requests per second on a real shop's catalog of 66,701 orders, with the database answering 99.99% of reads from memory. This describes that endpoint, that dataset and two cores. It is not a general figure for the platform. |
| Unattended install time | 273 – 303 seconds across the three operating systems tested — about five minutes |
| Speed against a tuned rival | 1.76× faster than a fully tuned aaPanel at one request and 1.82× with four at once, on identical hardware running the same 66,701-order shop — with about 60% of the gap attributed to a PHP directory restriction, 8% to the wrong JIT mode, 0% to the PHP version, and about 32% published as unexplained |
| Recommended OS | Ubuntu 26.04 LTS, security updates until April 2031. Ubuntu 24.04 LTS and Debian 13 are the other two supported releases — three in total, and nothing else |
One more thing worth saying, because almost nobody publishes it. We benchmarked three operating systems on identical hardware with the same real data. They tied — the spread between them was smaller than the spread of one machine against itself. So we chose on support runway instead of speed, and we will not quote a speed difference we could not measure.
Honest limits — SixPanel
- Backups restore to the same box. Restoring onto a different machine leaves the old machine's database password and paths behind and the app cannot connect until an Update is run; and the restore job never runs the database migration step, so an older dump under newer code is left behind the schema. Both are recorded as broken — recorded, not fixed — and both have a manual workaround.
- The self-healing watchdog cannot see two of the services in the feature list above. The websocket service and the optional Next.js storefront carry no healthcheck, so the watchdog does not cover them. Open item.
- A rollback does not reverse database migrations. A code rollback after a migration needs a backup restore.
- The panel reads its own TLS certificate once at boot. The daily renewal job reloads nginx but not the panel, so the panel needs a restart to pick up a renewed certificate.
- The panel is root-equivalent on the host by construction — it installs packages, writes system configuration and restarts services. On the Docker runtime it additionally mounts the Docker socket and bind-mounts the stack directory read-write.
- There is exactly one admin account and no roles. No multi-user, no teams.
- Only 4 GB boxes were measured. Nothing on this page describes 8 GB or larger.
When SixPanel applies
You are renting a VPS and you would rather not own nginx, MariaDB tuning, certificates, backups and deploys yourself — or you want more than one shop on one server.
SixPreflight
When you want to know what will break before you go live
What it is
A small PHP tool you drop into your Laravel site's public/ folder and open in a browser behind a password. It runs roughly 134 checks across hardware, PHP, application health, environment file, permissions, web server, caching, database settings, public exposure, and every outside service — payments, email, SMS, maps, push — actually contacting each one rather than reading a setting. It gives a letter grade, a plain verdict, and a fix list ordered by consequence, with a paste-ready value wherever there is one. You get the current release.
On the reference install
It reported 103 pass, 7 fail, 24 warn — and the failures were hosting settings, not application faults.
When SixPreflight applies
On aaPanel, CloudPanel or cPanel? SixPreflight is for you. Running SixPanel? These checks are already built into its Shop check-up page.
All of it now recommends the same operating system, and the reason is not speed. SixPanel, SixPanel Docker and SixPreflight all recommend Ubuntu 26.04 LTS. The native runtime takes PHP, MariaDB, nginx and Redis from the release's own distribution archive, and all three supported releases carry a working set — 26.04 gives PHP 8.5 and MariaDB 11.8, Debian 13 gives 8.4 and 11.8, Ubuntu 24.04 gives 8.3 and 10.11. Nothing here is a speed recommendation: across six measured axes no version swap produced a reportable difference, and two byte-identical machines disagreed with each other by 11.6 %. The deciding input is support runway — 26.04 is patched until April 2031.
Which one do I need?
| Your situation | The answer |
|---|---|
| You want 6amMart installed, or your existing 6amMart is slow or has bitten you on pricing or payments | The optimized 6amMart install |
| You have a VPS and do not want to run nginx, MariaDB, SSL, backups and deploys yourself | SixPanel |
| You already have a server on some other panel and want to know what will break before launch | SixPreflight |
Every number on this page was measured on a live install
And the suite that measured it ships with your build.
Need something built from scratch instead? Talk to us about bespoke work