Optimiertes 6amMart: dasselbe Script, gemessen und repariert
AllsWeb installiert das neueste 6amMart-Release — dasselbe Script, dasselbe Admin-Panel, dieselben Apps — auf Code, den wir gemessen und repariert haben. Bildschirme, die Kunden sehen, laufen 10× bis 22× schneller als im Standard, 342 Defekte sind geschlossen, und eine Prüf-Suite, die mit dem Build ausgeliefert wird, belegt das.
Der optimierte Code ist im Installationspreis enthalten. Er ist kein Upgrade, kein Add-on und keine höhere Stufe.
10× – 22×
schneller auf Bildschirmen, die Kunden sehen
342
gefundene und behobene Defekte
799
Commits in fünf Repositories
1–3 Tage
Lieferung, sobald die Anforderungen vollständig sind
Lesen Sie diese Seite mit einem KI-Assistenten?
Mit versus ohne
Was sich am Tag der Eröffnung ändert
6amMart im Standard links, der Code, den AllsWeb installiert, rechts. Dasselbe Script, dasselbe Admin-Panel, dieselben Apps, dasselbe Release des Herstellers — jede Zahl gemessen auf demselben Server mit 4 GB und 2 Kernen, mit denselben Daten.
Der erste Bildschirm, den ein Käufer sieht
Standard
Die Empfehlungszeile auf dem Startbildschirm braucht 8,19 s, bis sie gefüllt ist. Lang genug, dass jemand am Handy die App für kaputt hält und sie schließt.
Optimiert
Dieselbe Zeile füllt sich in 0,37 s — 22× schneller, gemessen mit umgangenem CDN, damit die Anwendung und nicht ein Cache gemessen wird.
Der Umsatzbericht des Shops
Standard
Ein Bericht stellt der Datenbank 8.614 einzelne Fragen und hält die ganze Zeit eine Verbindung offen. Schon einige Admins, die ihn gleichzeitig öffnen, machen den Shop für alle schwerfällig.
Optimiert
Derselbe Bericht stellt 12 Fragen. Vorher wirkte er im Test akzeptabel, weil jede dieser 8.614 Fragen auf kleinen Datenmengen schnell ist.
Der Mindestbestellwert eines Coupons
Standard
Das Admin-Panel lässt Sie ihn setzen, und der Code liest ihn nie. Live nachgewiesen: ein Coupon mit ₹999 Mindestwert wurde auf einer Bestellung über ₹1 akzeptiert, bei sechs aktiven Coupons mit dieser Einstellung.
Optimiert
Wird an allen drei Stellen durchgesetzt, an denen eine Bestellung bepreist werden kann.
Rabatte am Abend
Standard
Die Datenbank lief auf UTC und die Anwendung auf indischer Zeit — live gemessen 5 h 30 min auseinander. Ein Abendrabatt von 18:00–22:00 galt daher nie am Abend und schaltete sich um 2 Uhr nachts ein. Listenansicht und Kasse benutzten unterschiedliche Uhren, ein Shop konnte also als rabattiert angezeigt werden und den vollen Preis abrechnen.
Optimiert
Eine Uhr, also ist der angezeigte Rabatt der abgerechnete Rabatt.
Wer die Bestellung eines Kunden lesen kann
Standard
Mehr als sechs Endpunkte akzeptierten jede Bestell-ID zusammen mit einer erratenen Gast-ID. Ganz ohne Authentifizierung reproduziert: die Antwort enthielt Artikel, Preise und Lieferadresse eines anderen Kunden. Der Wallet-Zahlungsendpunkt auf demselben Pfad prüfte auch das Guthaben nicht.
Optimiert
Ein Eigentums-Scope auf jedem betroffenen Endpunkt, während der legitime Gast-Checkout weiter funktioniert.
Ein Zahlungs-Gateway, das Sie abgeschaltet haben
Standard
Abschalten im Admin-Panel entfernte es nur aus der Auswahl des Kunden. Seine Callback-URL blieb aktiv, und viele Gateway-Callbacks markieren eine Bestellung schon aufgrund eines Statuswortes in der URL als bezahlt — mit allen abgeschalteten Gateways lief ein Callback also weiterhin durch, und ein Kunde konnte seine eigene Bestellung ohne Zahlung bestätigen.
Optimiert
Scheitert jetzt geschlossen, mit 102 Prüfungen über alle Gateway-Präfixe, die bestätigen, dass keines im inaktiven Zustand ausgeführt wird.
Was es Sie kostet
Standard
6amMart im Standard ist das, was eine normale Installation übergibt.
Optimiert
Dieselbe Installation, auf dem neuesten 6amMart-Release. Keine zweite Lizenz, kein zweiter Preis, keine Upgrade-Stufe — so wird die Installation einfach geliefert.
Was „optimiert“ hier bedeutet
Dasselbe 6amMart. Darunter anders.
Es ist dasselbe 6amMart — das aktuelle Release, was auch immer 6amTech an dem Tag ausliefert, an dem wir Ihre Installation bauen. Dasselbe Admin-Panel, dasselbe Händler-Panel, dieselben Kunden-, Store- und Fahrer-Apps, dasselbe Datenmodell, dieselben Funktionen, die Sie in der Demo gesehen haben. Nichts wurde ersetzt und nichts umbenannt. Geändert hat sich, was darunter liegt: AllsWeb hat in vierzehn Arbeitssitzungen das Script gemessen, profiliert und das repariert, was die Messungen gefunden haben — 799 Commits in fünf Repositories zwischen dem 13. Juli und dem 9. August 2026, am Backend, am Admin-Panel, an der Website und an den drei Apps. Jede einzelne dieser Änderungen musste byte-identische Daten zurückgeben, bevor sie akzeptiert wurde. Das ist kein anderes Produkt, für das Sie sich entscheiden müssen. So installieren wir 6amMart jetzt.
Was Sie kaufen
- Der Service ist unverändert
- Vollständige Installation, Einrichtung und Konfiguration von 6amMart auf Ihrem Hosting — Admin-Panel, Händler-Panel, Android APK + AAB, iOS-Build, Kunden-Website, Ihr Branding, SMTP, Maps, Firebase Push und OTP, Social Login, Ihre Payment-Gateways, Ihre Sprachdatei und der angepasste Quellcode in einem privaten GitHub-Repository.
- Lieferung
- 1–3 Werktage, sobald Ihre Anforderungen vollständig sind.
- Kostenloser lebenslanger Support
- Für Einrichtungsprobleme und kleine Korrekturen.
- Ihre eigene CodeCanyon-Lizenz
- Sie kaufen und besitzen Ihre eigene 6amMart-Lizenz bei CodeCanyon; wir installieren darauf.
Der optimierte Code ist im Installationspreis enthalten. Er ist kein Upgrade, kein Add-on und keine höhere Stufe.
Warum der Standard langsam war
Ein Satz und ein Befund
Die Datenbank war nicht langsam. Die Anwendung hat ihr dieselbe Frage hunderte Male pro Seite gestellt.
Der Teil, den die meisten noch nicht gesehen haben
Auf einem Kunden-Endpunkt löste eine einzige Anfrage 112 Datenbankabfragen aus. Sechsundachtzig davon — 76% — entstanden erst beim Umwandeln des fertigen Ergebnisses in JSON für den Versand, weil Attribut-Accessoren beim Serialisieren nachluden, einmal pro Zeile. Sieben holten die Daten und elf bereiteten sie auf. Genau deshalb hätten Indizes allein nichts geändert: Die Kosten lagen nicht in den Abfragen, die die Seite ausführte.
Dieser Endpunkt löst jetzt 45 aus.
86 ÷ 112 = 76.8%, gedruckt als 76%. Die Quelle druckt 77%; dass eine Quelle aufrundet, erlaubt dieser Seite nicht, ebenfalls aufzurunden.
Der gemessene Vergleich
Vorher und nachher, auf demselben Server
Die Angaben zur Methode
| Bedingung | Wie sie war |
|---|---|
| Vorher | Das Standard-Script genau so, wie CodeCanyon es zum Zeitpunkt des Experiments ausgeliefert hat — Basis-Commit d92ce004, 8. Juli 2026 ‡ |
| Nachher | Dasselbe Script nach dem AllsWeb-Programm für Optimierung und Härtung, mit dem danach aufgesetzten nächsten Release des Herstellers |
| Server | Dieselbe Maschine für beide Durchläufe — 2 vCPU, 3.9 GB RAM |
| Methode | Serverseitig gemessen, unter Umgehung des CDN |
| Umfang der Änderung | 799 Commits · 342 Korrekturen · 171 Geschwindigkeitsänderungen · 37 Funktionen |
| Abnahmeregel | Jede Performance-Änderung musste byte-identische Daten zurückgeben, bevor sie akzeptiert wurde |
- ‡ Was gemessen wurde. Die Vorher-Zahlen wurden gegen das Standard-Script erhoben, so wie CodeCanyon es am 8. Juli 2026 ausgeliefert hat — das Release, das 6amTech mit 4.0.1 nummeriert hat — und das nächste Release des Herstellers wurde danach auf den optimierten Code aufgesetzt. Das ist eine Aussage über das Experiment, damit die Vorher-Zahlen gegen denselben Ausgangspunkt reproduziert werden können. Es ist keine Aussage darüber, was Sie bekommen: Wir installieren das Release, das 6amTech an dem Tag ausliefert, an dem wir bauen. Am 13.–15. August 2026 kam erhebliche weitere Arbeit hinzu, die der Bericht vom 9. August nicht abdeckt.
- Die Abnahmeregel, in einer Zeile. „Schneller durfte nie anders bedeuten.“
- Zu unseren Ungunsten gerundet. Wo ein Messwert ein Bereich ist, sind die Faktoren hier so berechnet, wie es die Zahlen am wenigsten schmeichelhaft zulassen — der niedrigste „Vorher“-Wert geteilt durch den höchsten „Nachher“-Wert. Unser eigener Bericht nennt Faktoren aus den Mittelwerten, und die fallen höher aus.
Neun Zeilen, alle vorher/nachher, und sie sind nicht alle dieselbe Art von Messung, deshalb sagt die Tabelle, welche welche ist. Die Zeilen 1–5 sind Antwortzeiten, gemessen auf demselben Server unter Umgehung des CDN. Die Zeilen 6–7 zählen Fragen an die Datenbank pro Seite, wo „CDN umgangen“ keine sinnvolle Bedingung ist. Die Zeilen 8–9 sind überhaupt keine Servermessungen und tragen ein †. Das sind die Zeilen, die ein Shop-Betreiber tatsächlich spürt, nicht die größten Zahlen, die wir haben.
| # | Worum es geht | Standard-6amMart | Optimiert | Faktor |
|---|---|---|---|---|
| 1 | Hervorgehobene Artikel auf dem Startbildschirm | 8.19 s | 0.37 s | 22× schneller |
| 2 | Produktsuche | 1.64 – 1.96 s | 0.09 – 0.12 s | mindestens 13× schneller |
| 3 | Startseite des Shops | ~1.47 s | 0.073 – 0.096 s | mindestens 15× schneller |
| 4 | Top-Kategorien | 3.34 s | 0.27 s | 12× schneller |
| 5 | App-Konfiguration beim Start | 0.53 – 1.15 s | 0.045 s | mindestens 11× schneller |
| 6 | Export der Store-Einnahmen — Fragen an die Datenbank pro Seite | 8,614 | 12 | 717× weniger |
| 7 | Produktkatalog-Liste — Fragen an die Datenbank pro Seite | 557 | 92 | ~6× weniger |
| 8 | † Styling, das auf jeder Website-Seite ausgeliefert wird — eine Byte-Zahl aus dem Build, keine Servermessung | 921,603 Bytes | 12,386 Bytes | −98.6% (74× kleiner) |
| 9 | † Zehn App-Anfragen nacheinander — auf einem Handy über Mobilfunk gemessen, nicht auf dem Server | 6,140 ms | 1,876 ms | −69% (3.2× schneller) |
† Die Zeilen 8 und 9 sind keine Servermessungen. Die Formulierung „derselbe Server, CDN umgangen“ deckt nur die Antwortzeiten in den Zeilen 1–5 ab; die Styling-Zahl ist eine Build-Ausgabe, und die Zahl zu den zehn Anfragen wurde über Mobilfunk erhoben.
Die Rechnung, ausgedruckt
Zeile 6 druckt 717×, nicht die 718×, die unser eigener Bericht schreibt: 8,614 ÷ 12 = 717.83, und diese Seite rundet keine Zahl zu ihren eigenen Gunsten auf. Zeile 9 druckt aus demselben Grund 3.2× — 6,140 ÷ 1,876 = 3.27. Die Byte-Zahl in Zeile 8 ist 921,603 ÷ 12,386 = 74.4, gedruckt als 74×. Die 76% weiter oben sind 86 ÷ 112 = 76.8%, in dieselbe Richtung gerundet.
Gleichzeitige Kapazität, formuliert auf die einzige Art, die die Belege zulassen
Auf demselben Server mit 2 vCPU können unter einer Lastrampe gegen den Store-Listing-Endpunkt 13× mehr Kunden ihn gleichzeitig nutzen, auf demselben Server. Das zugrunde liegende Zahlenpaar für Anfragen pro Sekunde wird bewusst nicht gedruckt: Die Quelle protokolliert die Lastrampe, ohne ihre Gleichzeitigkeit oder ihre Dauer zu nennen, und eine Zahl für Anfragen pro Sekunde, die ihren Endpunkt, ihre Gleichzeitigkeit und ihre Dauer nicht nennen kann, kommt nicht auf diese Seite. Die SixPanel-Zahl weiter unten hat alle drei, und deshalb wird jene als Rate gedruckt.
Zwei Zeilen, die keine Geschwindigkeitsgeschichte sind
| Worum es geht | Standard-6amMart | Optimiert |
|---|---|---|
| Endpunkte, die bei einer sauberen Installation einen Serverfehler zurückgeben | 3 (beliebte Stores, neueste Stores, Zahlungsmethoden) | 0 — alle drei antworten jetzt in 41–150 ms |
| Bekannte Sicherheitsmeldungen zu Abhängigkeiten, gezählt am 9. August 2026 | 111 | 0 |
Was die 111 tatsächlich waren. 110 davon waren axios- und vite-Versionen in fünf package.json-Dateien von Addon-Modulen, deren Build-Pipelines noch nie funktioniert haben — vier verweisen auf Quelldateien, die es im Modul nicht gibt, und die fünfte auf zwei Dateien, die null Bytes groß sind. Sie wurden trotzdem gemeldet, denn eine Warnung, die man zu ignorieren beschlossen hat, ist eine Warnung, die man nicht mehr liest. Die einzige, die für sich genommen zählte, war firebase/php-jwt unterhalb von 7.0.0 (CVE-2025-45769), früher als nicht behebbar vermerkt, jetzt auf ^7.0.2 und gegen die echten Apple-, Passport-, Firebase- und Google-Schlüssel verifiziert.
Die Zeile zu den Sicherheitsmeldungen ist aus gutem Grund eine Momentaufnahme mit Datum: Meldungs-Feeds ändern sich laufend, und eine Zählung vom 9. August 2026 ist eine Aussage über diesen Tag, keine dauerhafte Eigenschaft des Builds. Führen Sie die Prüfung auf Ihrer eigenen Installation erneut aus, um eine aktuelle Zahl zu bekommen.
Aktueller Stand, mit der zugehörigen Einschränkung Ein Durchlauf mit 306 Endpunkt-Anfragen meldet null Serverfehler und null Endpunkte über 250 ms — gemessen über die Anfragen, die ausgeführt wurden. In einem gültigen Durchlauf weist die plattformeigene Ratenbegrenzung 66–68 davon ab, ungefähr ein Fünftel des Durchlaufs, und eine abgewiesene Anfrage ist kein Endpunkt-Ergebnis. Die protokollierte Aufteilung eines gültigen Durchlaufs (~235 erfolgreich, 66–68 abgewiesen) ergibt etwa 302, nicht 306; die restlichen Anfragen können wir aus den vorliegenden Quellen nicht auflösen. Führen Sie ihn selbst aus und lesen Sie Ihre eigene Aufteilung — der Abschnitt zur Überprüfung weiter unten erklärt, wie.
Ursachen
Die drei Ursachen, die es zu nennen lohnt
Sie sind es, die die Tabelle glaubwürdig machen.
Der Einnahmen-Export hat 2,867 Mal das Falsche angefordert.
Er wies die Datenbank an, den Store jeder Transaktion über die Bestellung zu holen, während der Code den Store direkt aus der Transaktion las — eine andere Verknüpfung. Die Anweisung griff nie, also holten alle 2,867 Zeilen ihren Store einzeln.
Jede Händler-Seite zeichnete zwei Navigationsmenüs.
Eines vom Stylesheet ausgeblendet, beide zählten dieselben Bestell-Badges.
Ein Seitenkopf lud die gesamte Bestellhistorie des Stores.
466 Bestellungen für den meistfrequentierten Store, um einen Abschnitt der Seite zu füllen, der auskommentiert war.
Und der Befund zu den Indizes
Zehn der Spalten, über die die Datenbank verknüpft, hatten überhaupt keinen Index. Nach dem Indizieren las eine Abfrage statt 51,074 Zeilen nur noch eine.
Die Kundenliste im Admin-Panel durchsuchte 16,092,496,536 Zeilen, um 98 zurückzugeben — 82% der gesamten Zeit für langsame Abfragen auf dem Server und bis zu 18 Minuten für einen einzigen Seitenaufruf.
Was behoben wurde
Performance, Sicherheit, Korrektheit
Performance
Fragen an die Datenbank pro einzelner Anfrage — jede einzelne vor der Annahme der Änderung als byte-identisch verifiziert.
Kunden-API
| Vorgang | Standard | Optimiert |
|---|---|---|
| Produktkatalog-Liste (31 Artikel) | 557 | 92 |
| Händler-Bestellliste (41 Bestellungen) | 212 | 12 |
| Aufbereitung der Bestelldetails (40 Zeilen) | 121 | 4 |
| Bestellhistorie der Kunden | 166 | 97 |
| Wunschliste (6 Artikel) | 140 | 37 |
| Store-Liste | 78 | 39 |
| App-Konfiguration | 54 | 21 |
| Kategorienliste | 43 | 16 |
Admin- und Händler-Panel
| Bildschirm | Standard | Optimiert |
|---|---|---|
| Export der Store-Einnahmen | 8,614 | 12 |
| Bestellsuche im Admin-Panel | 259 | 14 |
| Produktauswahl für Flash-Sale | 186 | 42 |
| Produktgalerie | 166 | 48 |
| Liste der Mietanbieter | 159 | 9 |
| Store-Dropdown für Reels | 127 | 62 |
| Kundendetailseite | 106 | 34 |
| Liste der Mietfahrzeuge | 94 | 13 |
| Seite mit den Store-Einnahmen | 89 | 13 |
| Jede Händler-Seite, vor ihrem eigenen Inhalt | 61 | 52 |
Das Admin- und das Händler-Panel waren noch nie gemessen worden — die eigenen automatischen Prüfungen von Standard-6amMart decken nur die Kunden-API ab. 586 Admin- und 165 Händler-Seiten wurden profiliert, gezählt in Fragen an die Datenbank, „weil eine Zählung exakt und wiederholbar ist, während eine Stoppuhr auf einem geteilten Server driftet“.
Website
- Von den 921,603 Bytes Styling auf jeder Seite waren 902 KB drei komplette Icon-Bibliotheken — 21,459 Icon-Definitionen wurden ausgeliefert, damit die Website 89 Icons anzeigen konnte. Der Build gibt jetzt nur noch die tatsächlich verwendeten Icons aus, und das gesamte Styling pro Seite beträgt 12,386 Bytes, −98.6%.
- Gemeinsam genutztes JavaScript 429 kB → 269 kB (−37%).
- Die Landingpage war eine leere Hülle, bis JavaScript geladen war; jetzt liefert sie 273,110 Bytes aus, die der Server gerendert hat.
- Konfigurationsanfragen: eine pro Seitenaufruf pro Besucher → eine pro Minute pro Sprache.
- Die Maps-Bibliothek wurde an 9 Seiten ausgeliefert, die gar keine Karte zeigen.
- Datumsformatierung pro Zeile: 8.45 µs → 0.39 µs (21× günstiger).
- Alle 50 Website-Routen wurden besser oder blieben gleich; keine wurde langsamer.
Mobile Apps
- Jede Anfrage öffnete eine brandneue sichere Verbindung, statt eine bestehende weiterzuverwenden — rund 426 ms pro Anfrage im Mobilfunk. Zehn Anfragen nacheinander: 6,140 ms → 1,876 ms.
- Startbildschirm: ~30 Anfragen pro Start → 1 Anfrage, die 14 Abschnitte abdeckt.
- Ein Foto mit 1000×1000 wurde hinter einem 40 Pixel großen Avatar dekodiert; Bilder werden jetzt in der tatsächlich angezeigten Größe dekodiert.
- 309 Debug-Log-Anweisungen wurden in den veröffentlichten Apps mitgeliefert. Jetzt null.
- Fahrer-GPS: 360 → ~30 Positionsmeldungen pro Stunde im Stillstand.
- Der Bestellbildschirm der Händler zeichnete alle 10 Sekunden alles neu; jetzt zeichnet er nur neu, wenn sich Daten geändert haben.
Sicherheit — die konkreten Lücken im Script, so wie es verkauft wird
Nichts in diesem Abschnitt ist Geschmackssache. Jeder Punkt ist ein Defekt im Standard-6amMart, und jeder wurde reproduziert, bevor er behoben wurde.
Nicht authentifizierte SQL-Injection, erreichbar aus jeder Store-Liste.
Der Code für die Store-Liste setzte die rohen Header für Breiten- und Längengrad direkt in die SQL-Distanzberechnung ein. Erreichbar ohne Login und ohne Token. Bestätigt bis zur Datenbank — eine eingeschleuste Payload erzeugte einen SQL-Syntaxfehler im laufenden Log. Behoben mit gebundenen Parametern; ein zweiter, ungenutzter Injection-Punkt wurde gelöscht.
Die Bestellungen jedes Kunden waren für jeden lesbar und änderbar.
Mehr als sechs Bestell-Endpunkte akzeptierten jede beliebige Bestell-ID zusammen mit einer geratenen Gast-ID. Live reproduziert: Eine Anfrage ganz ohne Authentifizierung gab die Artikel, Preise und Lieferadresse eines anderen Kunden zurück. Der Endpunkt für Wallet-Zahlungen auf demselben Pfad hatte keine Guthabenprüfung. Behoben mit einer Eigentümerprüfung über jeden betroffenen Endpunkt, während der legitime Gast-Checkout weiter funktioniert.
Abgeschaltete Payment-Gateways konnten trotzdem Zahlungen abschließen.
Ein Gateway im Admin-Panel abzuschalten entfernte es nur aus der Auswahl des Kunden — seine Callback-URLs blieben aktiv, und viele Gateway-Callbacks markieren eine Bestellung allein aufgrund eines Statuswortes in der URL als bezahlt. Mit jedem abgeschalteten Gateway lief ein Callback trotzdem erfolgreich durch, sodass ein Kunde seine eigene Bestellung ohne Zahlung bestätigen konnte. Behoben nach dem Prinzip fail-closed; 102 Testanfragen über jeden Gateway-Präfix bestätigen jetzt, dass keines im inaktiven Zustand ausgeführt wird.
Händler konnten auf die Daten anderer Händler zugreifen.
Jeder Händler konnte Produkte, Add-ons und Banner eines anderen Stores bearbeiten oder löschen — einschließlich der Startbildschirm-Banner des Admins. Auf eine Bewertung zu antworten ordnete diese Bewertung dem Store des antwortenden Händlers zu. Behoben mit einer Store-Begrenzung.
Eine aktive Hintertür beim Demo-Login — und was sie nicht erreicht hat.
6amMart liefert eine Demo-Abkürzung mit, damit ein Prüfer im App-Store sich ohne SMS anmelden kann. Sie liest Telefonnummer und Code aus der Konfiguration, mit den Demo-Werten als Rückfallwert, wenn die Konfiguration fehlt — und die Konfiguration fehlt genau dann, wenn eine Website den üblichen Produktions-Caching-Schritt ausführt, was jede Live-Installation tut. Auf der Live-Website bekam eine fest einprogrammierte Nummer einen funktionierenden Code, ohne dass eine SMS versendet wurde und ohne dass die Konfiguration das verlangt hätte. Die Auswirkung war begrenzt, und wir nennen die Grenze: Zu dieser Nummer existierte kein Konto, also führte der Weg zu einem neuen Konto mit umgangener Telefonverifizierung — nicht zur Übernahme eines bestehenden Kontos. Gefährlich machte es der Rückfallwert: Ein Betreiber, der von der Einstellung nie gehört hatte, lieferte die Hintertür trotzdem aus. 28 automatische Prüfungen belegen jetzt, dass sie ohne bewusste Aktivierung nicht existieren kann.
Der gesamte Projektordner war über HTTPS lesbar.
6amMart richtet den Webserver auf den Anwendungsordner statt auf public/, gehalten nur von einer handgeschriebenen Sperrliste. Eine Sperrliste schützt die Pfade, an die jemand gedacht hat; vierzehn standen nicht darauf, jeder mit einer echten Anfrage bestätigt — darunter ein 679 KB großer Datenbank-Dump des Installers, ein 5.9 MB großes Archiv des public-Ordners und eine PHP-Datei, die der Server tatsächlich ausführte und die eine Fehlerseite mit den absoluten Serverpfaden zurückgab. Das Web-Root wurde auf public/ verlegt; alle vierzehn geben jetzt 404 zurück, und 19 automatische Prüfungen halten das so.
Die Geschichte der Ratenbegrenzung besteht aus drei getrennten Defekten, nicht aus einem.
- 1
Die API hatte überhaupt keine Ratenbegrenzung.
Die Framework-Konfiguration definierte einen API-Begrenzer mit 600 pro Minute, aber nichts wendete ihn je an — die Middleware-Gruppe der API enthielt einen einzigen, unbeteiligten Eintrag und sonst nichts, der Begrenzer war also tote Konfiguration. Vor der Änderung gemessen: 40 Anmeldeversuche mit falschem Passwort gegen ein Konto, so schnell wie curl es schaffte — 40 Ablehnungen, keine Drosselung, keine Verzögerung, nichts protokolliert. Jetzt gelten drei Grenzen: eine Rückfallgrenze von 600/Minute, 10/Min. für Anmeldeversuche, geschlüsselt sowohl auf die Adresse als auch auf das angegriffene Konto, und 5/Min. auf den Routen, die eine echte SMS versenden. Verifiziert: 25 schnelle Falschpasswörter → 10 Ablehnungen, dann 15 Drosselungen; ein anderes Konto von derselben Adresse im selben Zeitfenster → nicht gedrosselt; 60 normale Browsing-Anfragen in einem Schwall → alle erfolgreich.
- 2
Der Begrenzer schlüsselte dann auf eine Identität, die die halbe Plattform nie hat — und den Fehler haben wir selbst gefunden, bei der Prüfung unserer eigenen Korrektur.
Der neue Begrenzer schlüsselte auf den angemeldeten Benutzer und fiel auf die Netzwerkadresse zurück. Aber die APIs für Händler und Lieferfahrer authentifizieren, indem sie ein Bearer-Token in einer Tabelle nachschlagen, statt über einen Auth-Guard zu gehen, also war der Benutzer immer null und der Schlüssel fiel auf die Adresse zurück. Ein Store mit Personal an einem Büroanschluss oder Fahrer hinter einem Carrier-NAT hätten sich ein einziges Budget von 600/Minute geteilt — und die Liefer-App fragt alle 10 Sekunden ab, eine geschäftige Schicht hätte also angefangen, Leute abzuweisen, die gerade arbeiteten. Der Schlüssel fällt jetzt zuerst auf einen Hash des Bearer-Tokens zurück. Verifiziert: zwei Aufrufe mit Händler-Token → 599, dann 598 verbleibend auf ihrem eigenen Zähler; ein Kunden-Token unmittelbar danach → 599 auf einem separaten Budget; kein Token → weiterhin auf die Adresse geschlüsselt, 600 unangetastet.
- 3
Die Plattform konnte den echten Besucher nicht sehen.
Hinter einem CDN kam jede Anfrage von der Adresse des CDN, und die Anwendung hielt das für den Besucher — die Ratenbegrenzung drosselte also alle Kunden als einen, Betrugsprüfungen verglichen die falsche Adresse, und jede Bestellung speicherte eine Proxy-IP statt der Person, die sie aufgegeben hatte. Ursache: Das Framework liefert die Proxy-Behandlung in seinem globalen Stack mit, und 6amMart ersetzte diesen Stack komplett und ließ sie damit weg, sodass es für die Konfiguration vertrauenswürdiger Proxys allein nichts gab, woran sie andocken konnte. Beide Hälften sind jetzt vorhanden, und eine weitergeleitete Anfrage löst sich zur echten Client-Adresse auf. Die Plattform sieht jetzt den echten Besucher, statt das ganze Internet als einen Nutzer zu behandeln.
Ein Baustein für Cache Poisoning.
Der Cache für Listen berechnete seinen Schlüssel aus dem Query-String der URL, aber die Endpunkte lasen ihre Parameter über eine Methode, die den Request-Body bevorzugt, sobald die Anfrage einen JSON-Content-Type angibt — auch bei einem GET. Eine Anfrage konnte also in der URL nach einem Suchbegriff fragen und im Body nach einem anderen: Der Schlüssel wurde für den ersten berechnet, die Suche lief für den zweiten, und die falschen Zeilen wurden unter dem ersten Schlüssel gespeichert und an jeden echten Kunden ausgeliefert, der danach suchte, bis der Eintrag ablief. Nicht authentifiziert, und der Angreifer wählte beide Hälften — welche Produkte ein Käufer sah, aus welchem Store, zu welchen Preisen. Anfragen, deren Eingaben der Schlüssel nicht sehen kann, werden jetzt vollständig außerhalb des Caches beantwortet.
Ebenfalls geschlossen
Jede Rechnung war für jeden herunterladbar, der zählen kann.
Rechnungen zu Bestellungen, Abonnements und Fahrten waren über die URL durchnummerierbar.
Gespeichertes XSS vom Händler zum Admin.
Von Händlern geschriebene Produktbeschreibungen wurden in 8 Admin- und Händler-Bildschirmen als rohes HTML gerendert, ein Händler konnte also Skripte im Browser des Admins ausführen. Bereinigt und gegen 25,726 echte Produktbeschreibungen als sicher nachgewiesen, ohne dass sich ein einziger sichtbarer Text geändert hat.
Wiederholung von Zahlungs-Callbacks.
Callbacks waren nicht idempotent, ein wiederholter Callback schrieb dem Kunden also zweimal gut. Behoben auf Hook-Ebene über alle 47 Gateways.
Eine offene Weiterleitung auf der App-Redirect-Route.
Eine Phishing-Vorlage auf Ihrer eigenen Domain. Behoben, dann erneut behoben, als bei der Prüfung eine Umgehung über einen Backslash gefunden wurde; ein Test mit 17 Fällen sichert das jetzt ab.
Zwei öffentliche Debug-Routen.
Die eine führte ohne Authentifizierung einen Befehl zum Leeren des Caches aus, die andere war ein offenes Bild-Relay. Beide gelöscht.
laravel.log war aus dem Internet herunterladbar.
Mit dem Datenbank-Benutzernamen, fehlgeschlagenem SQL samt Bindings und vollständigen Serverpfaden.
Ein einziger Anwendungsschlüssel, ausgeliefert an jede Installation.
Die Beispiel-Umgebungsdatei enthielt einen echten Schlüssel; eine frische Umgebungsdatei kopiert ihn, und der Schritt zur Schlüsselerzeugung läuft nur bei einem leeren Wert, wurde also übersprungen — jede so gebaute Installation lief mit demselben Schlüssel, der in jeder Kopie des Produkts abgedruckt ist.
GET-Anfragen, die Einstellungen ändern — abgemildert, und eng formuliert.
Im Standard-6amMart ist das Ändern einer Einstellung ein gewöhnlicher Link, deshalb schreiben 64 GET-Routen im Admin- und Händler-Panel Zustand. Ein Crawler, eine Link-Vorschau, ein Bild-Tag oder ein Hintergrund-Abruf kann Einstellungen ändern, während ein Admin angemeldet ist. Das ist nicht theoretisch: Am 1. August hat unser eigener Performance-Profiler diese Adressen beim Messen der Seitengeschwindigkeit aufgerufen und in 45 Sekunden 8 aktive Einstellungen geändert — die Textrichtung des Panels kippte, die Landingpage wurde abgeschaltet, ein Händler deaktiviert. Innerhalb einer Stunde wiederhergestellt und überprüft. Die ausgelieferte Korrektur ist ein einzelner, einmal registrierter Wächter, der die Fetch-Metadata-Header des Browsers liest — die angeben, warum eine Anfrage gestellt wurde, und die das JavaScript eines Angreifers nicht fälschen kann — und der Formen ablehnt, die nie ein menschlicher Klick sind. Live verifiziert: Das Laden einer Einstellungsadresse per Bild-Tag wird abgelehnt; ein Prefetch wird abgelehnt; ein seitenübergreifender Hintergrund-Abruf wird abgelehnt; ein echter Administrator, der klickt, kommt durch; die 338 eigenen Hintergrundanfragen des Panels kommen durch; ältere Browser, die solche Header nicht senden, kommen durch. 102 echte Panel-Seiten rendern mit und ohne Wächter byte-identisch, und 53 automatische Prüfungen decken das ab. Eine Registrierung deckt 1,348 Routen ab, einschließlich Module, die eigene Routengruppen deklarieren.
Der Angriffsweg über den Browser ist geschlossen. Die Routen selbst schreiben weiterhin bei GET — siehe Ehrliche Grenzen.
Korrektheit — die Defekte, die Geld kosten
| Defekt im Standard-6amMart | Was gemessen wurde |
|---|---|
| Der Mindestbestellwert für Gutscheine wurde nie durchgesetzt | Admins konnten ihn setzen; der Code las ihn nie. Live nachgewiesen: Ein Gutschein mit einem Mindestwert von ₹999 wurde bei einer Bestellung über ₹1 akzeptiert. Sechs aktive Gutscheine hatten Mindestwerte gesetzt. Jetzt an allen drei Stellen durchgesetzt, an denen eine Bestellung bepreist werden kann. |
| Rabatte wurden nach der falschen Uhr beurteilt | Die Datenbank lief auf UTC und die Anwendung auf indischer Zeit — live mit 5h30m Abstand gemessen. Ein Abendrabatt von 18:00–22:00 traf abends nie zu und schaltete sich um 2–3 Uhr nachts ein. Schlimmer noch, Listenansicht und Checkout benutzten unterschiedliche Uhren, ein Store konnte also rabattiert beworben und zum vollen Preis abgerechnet werden. |
| Add-on-Mengen wurden dem falschen Add-on berechnet | Mengen wurden Add-ons über die Position in einer Liste zugeordnet, aber die App des Kunden sendet die Menü-Reihenfolge, während die Datenbank die Reihenfolge der internen IDs zurückgibt. Auf dem Server nachgewiesen: Eine Bestellung, die ₹270 kosten sollte, wurde mit ₹550 abgerechnet. An allen 8 Stellen im Code behoben, die das so machten. |
| Der Bestand wurde beim falschen Produkt verringert | Ein Kampagnenkauf schlug das Produkt anhand der Kampagnen-ID in der Produkttabelle nach. Alle drei aktiven Kampagnen-IDs existierten auch als Produkt-IDs. |
| Die Bestandsprüfung im Checkout prüfte eine andere Zahl, als sie schrieb | Die abschließende Prüfung verglich den Gesamtbestand des Produkts; verringert wurde der Bestand der gewählten Variante. An Live-Daten gemessen: 56 aktive Produkte, bei denen ein legitimer Kauf abgelehnt worden wäre, und 1,451, bei denen ein Überverkauf unbemerkt geblieben wäre. |
| Ein wiederholter Gateway-Callback buchte die Zahlung zweimal gut | Auch ausgelöst dadurch, dass ein Kunde die Rückkehrseite neu lud. Behoben auf Hook-Ebene über alle 47 Gateways. |
| Der Sofortkauf-Checkout bepreiste, was das Telefon sendete | Statt den Warenkorb des Servers zu verwenden. |
| Eine Auszahlung konnte zweimal genehmigt werden und ein Wallet ins Minus treiben | Live reproduziert: Zweimaliges Genehmigen schrieb den ausgezahlten Betrag zweimal gut und trieb den ausstehenden Saldo auf −50.00. Ein Klick auf Zurück oder ein Doppelklick reichte. |
| Bestell-IDs wurden von Hand vergeben | Der Code las die höchste bestehende Bestell-ID und zählte eins dazu — eine schlechte Nachbildung des Auto-Increments, die bei gleichzeitigem Checkout kollidierte. |
| Zwei Fahrer konnten dieselbe Bestellung annehmen | Und zwei Kunden konnten die letzte Einheit kaufen. Wettläufe zwischen Prüfen und Schreiben, jetzt atomare Ansprüche in der Datenbank, mit gleichzeitigen Transaktionen nachgewiesen. |
Zu den beiden Zahlen, die Sie zitiert sehen werden. Die projekteigenen Summen bewerten 4 der Sicherheitslücken als kritisch und 6 der Defekte als geldwirksam, von 342 behobenen. Das sind die niedrigeren, veröffentlichten Zählungen, deshalb sind es die, die diese Seite verwendet. Sie sind keine Zählungen der auf dieser Seite aufgeführten Punkte: Der Sicherheitsabschnitt oben nennt mehr als vier Sicherheitsdefekte, und die Tabelle oben listet zehn Defekte mit Geldwirkung, denn wir listen jeden auf, den wir reproduziert haben, nicht nur die innerhalb der beiden Summen.
Korrektheit ohne Geldwirkung, die eine Erwähnung wert ist
- Der Scheduler war noch nie gelaufen. Fünf geplante Hintergrundaufgaben waren seit dem Deployment kein einziges Mal ausgeführt worden — der Cron-Eintrag im System war nie eingerichtet worden.
- Der monatliche Auszahlungslauf lief viermal im Monat (der Zeitplan war als „Tage 28–31“ geschrieben statt als „letzter Tag des Monats“).
- Die Bestellhistorie meldete jeden Store als unbewertet — überall 0 Sterne, während die echte Bewertung für einen Store bei 4.31 aus 29 Bewertungen lag.
- Lieferungen durch Fahrer zählten nie zur Produktbeliebtheit — die Zählschleife benutzte einen Eigenschaftsnamen, den es auf diesem Datensatz nicht gibt, der Block tat also stillschweigend nichts und verzerrte jede Rangliste der „Top-Produkte“.
- Push-Benachrichtigungen waren stillschweigend abgeschaltet — sie wurden an einen Worker in die Warteschlange gestellt, den es möglicherweise gar nicht gab; nichts wurde zugestellt, kein Fehler gemeldet.
- 34 Serverfehler im Admin- und Händler-Panel → null.
- Ein Händler ohne Store-Datensatz legte 9 von 12 Seiten seines eigenen Panels lahm, dazu das Web-Login der Händler und das Login der Store-App — eine gemeinsam genutzte Hilfsfunktion gab das erste Element einer leeren Beziehung zurück, was einen Fehler auslöst, statt null zurückzugeben. 43 Prüfungen, darunter gepaarte Zusicherungen, dass ein legitimer Händler weiterhin durchkommt.
- Ein Admin-Bericht hat auf keiner Installation dieser Software je funktioniert — er kompilierte zu ungültigem PHP und schlug immer fehl. Gefunden durch die Prüfung aller 895 Bildschirmvorlagen; er war die einzige fehlerhafte.
Was mit der optimierten Installation mitgeliefert wird und im Standard fehlt
| Fähigkeit | Worum es geht |
|---|---|
| Automatisierte Prüf-Suite | Skripte, die Sie selbst ausführen. Jede Zusicherung musste gegen den alten Code nachweislich fehlschlagen, bevor sie akzeptiert wurde — ein Test, der auf einem kaputten System besteht, beweist nichts. Zum Bericht vom 9. August waren die 60 Skripte 55 Zusicherungen plus 5 Auswertungswerkzeuge, und die Auswertungswerkzeuge sichern nichts zu. Dazu 49 Unit- und Feature-Tests. |
| Nachweis der reproduzierbaren Schemastruktur | Die Datenbank lässt sich allein aus dem Code neu aufbauen — nachgewiesen, indem sie aus dem Nichts gebaut und alle 184 Tabellen Spalte für Spalte und Index für Index verglichen wurden, ohne Unterschiede. |
| SixPreflight | Ein Werkzeug für die Serverbereitschaft: ~134 Prüfungen über Hardware, PHP, Anwendungszustand, Berechtigungen, Webserver, Caching, Datenbankeinstellungen, öffentliche Erreichbarkeit und jeden externen Dienst. Vor dem Start im Browser öffnen, und es sagt Ihnen, was kaputtgehen wird. |
| Deployment-Handbuch | Dokumentierte Abläufe für Installation und Update plus die Fallstricke: welche Befehle den Konfigurations-Cache stillschweigend leeren, welche Caches sich nicht gegenseitig neu aufbauen, was das Hosting-Panel rückgängig macht, wenn Sie eine Einstellung speichern. |
| iOS-Builds | Alle drei Apps signiert und sowohl für Apple als auch für Android baubar — die ersten Apple-Builds, die für dieses Projekt erstellt wurden. |
| Live-Bestellverfolgung tatsächlich aktiv | Der Websocket-Dienst eingeschaltet und die zwei Defekte behoben, die ihn ausgeschaltet hielten; die Zertifikatserneuerung nachgewiesen. |
Prüfen Sie es selbst
Prüfen Sie jede Zahl selbst
Das Überzeugendste auf dieser Seite ist keine Zahl. Es ist, dass Sie jede Zahl selbst prüfen können.
Die Prüf-Suite wird mit Ihrer Installation ausgeliefert. Auf Ihrem eigenen Server:
bash tests/Scripts/run-all.sh # die Prüfungenphp tests/Scripts/api-smoke.php # geht jeden API-Endpunkt durch1Jede Zusicherung musste gegen den alten Code nachweislich fehlschlagen, bevor sie akzeptiert wurde.
Ein Test, der auf einem kaputten System besteht, beweist nichts.
2Der Endpunkt-Durchlauf feuert 306 Anfragen ab.
Er meldet Serverfehler und Antwortzeiten pro Endpunkt — „null Serverfehler, null Endpunkte über 250 ms“ ist also etwas, das Sie erneut ausführen, und nichts, das Sie uns glauben müssen. Lesen Sie in Ihrem eigenen Durchlauf zuerst die Zahl der abgewiesenen Anfragen und dann die Zeiten; siehe den Betriebshinweis unten.
3Die Suite enthält die Sicherheitszusicherungen.
Nicht nur die zur Geschwindigkeit: den Durchlauf zur Erreichbarkeit des Web-Roots, die Prüfung der Demo-OTP-Hintertür, die Prüfung der Idempotenz der Zahlungs-Hooks, die kontoübergreifenden Absicherungen, die Prüfungen auf Cache Poisoning und eine Aufstellung, welche GET-Routen Zustand schreiben.
4Die Schemaprüfung baut die Datenbank allein aus dem Code neu auf.
Sie vergleicht alle 184 Tabellen mit Ihrer laufenden Datenbank.
Ehrlicher Betriebshinweis Führen Sie den Endpunkt-Durchlauf zu oft hintereinander aus, löst er die plattformeigene Ratenbegrenzung aus. Gedrosselte Anfragen erzeugen keine Datenbankarbeit, die Gesamtzahl der Abfragen sinkt also und der Durchlauf wirkt schneller, während er fast nichts testet. Ein gültiger Durchlauf zeigt etwa 235 erfolgreiche und 66–68 abgewiesene Anfragen; hunderte abgewiesene bedeuten, den Durchlauf zu verwerfen.
Und der aktuelle Stand der Suite, exakt formuliert Der Bericht vom 9. August verzeichnete 60 Skripte — 55 Zusicherungen plus 5 Auswertungswerkzeuge — und 49 Unit- und Feature-Tests. Das Verzeichnis ist seitdem auf 86 Einträge gewachsen, was Auswertungswerkzeuge und andere Dateien ohne Zusicherung einschließt, es ist also keine Zählung der Prüfungen. Der zuletzt protokollierte vollständige Durchlauf führte 70 davon aus: 61 bestanden, 2 fehlgeschlagen, 7 übersprungen. Beide Fehlschläge sind in den Belegen benannt — zwei Miet-Berichte im Admin-Panel, die auf Installationen ohne Mietobjekte einen Serverfehler zurückgeben, und eine fehlende Asset-Zuordnung — und zumindest der Miet-Fehler wurde danach behoben. Führen Sie die Suite auf Ihrer eigenen Installation erneut aus und lesen Sie Ihre eigene Zahl.
Ehrliche Grenzen
Was diese Seite nicht behauptet
Eine Seite, die sagt „das haben wir gemessen, so können Sie es prüfen, und das haben wir nicht gelöst“, ist schwerer anzuzweifeln als eine, die nur ihre Erfolge druckt.
342 Defekte wurden gefunden und behoben. Niemand kann aufzählen, was übrig ist.
Das ist die ehrliche Form einer Plattform dieser Größe.
Nichts in diesem Programm hat die Arbeit eines anderen Anbieters gemessen.
Diese Seite behauptet also nichts über den Build von irgendjemandem sonst. Jede Zahl hier ist das Standard-Script, so wie es damals ausgeliefert wurde, gegen unseren optimierten Code, auf einem Server.
Jede Zahl auf dieser Seite ist zu unseren Ungunsten gerundet, nie zu unseren Gunsten.
Auf Bildschirmen, die Kunden sehen, beträgt die gemessene Verbesserung 10× bis 22×, also 90 bis 95% weniger Wartezeit — 22× sind 95.4% und wir drucken 95. Wo eine Messung ein Bereich ist, ist der Faktor der niedrigste „Vorher“-Wert über dem höchsten „Nachher“-Wert.
Die Zahlen zu 10 Millionen Bestellungen auf dieser Seite sind ein Skalierungstest, keine Live-Performance.
Sie stammen aus einer eigens gebauten Datenbank mit 10,000,000 Bestellungen, 1,000,000 Produkten und 200,000 Kunden, bewusst gegen einen unterdimensionierten Buffer-Pool von 128 MB gefahren, damit sie wie ein echter unterversorgter Server I/O-gebunden ist. Die geprüfte Produktionsinstallation enthält 3,282 Bestellungen.
Sechs Zeilen des Skalierungstests liegen weiterhin bei einer Sekunde oder darüber, und wir drucken unten alle elf Zeilen.
Dispatch-Badges liegen bei 12 s; popular_products bei 7.1 s; die Bestellliste im Admin-Panel bei einem tiefen Seitenversatz bei 3.1 s; der Artikelbericht bei 12.5 s für einen Monat und 131 s für den gesamten Zeitraum; die Kundenliste im Admin-Panel bei etwa 1–1.5 s. Der Gesamtzeitraum-Wert des Artikelberichts ist das Schlechteste, das wir irgendwo gemessen haben, und der Standard-Durchlauf, mit dem er verglichen werden müsste, wurde bei 120 Sekunden abgebrochen, wir können dort also nicht einmal eine Verbesserung behaupten — nur, dass unserer fertig wird.
GET-Anfragen, die Einstellungen ändern, sind abgemildert, nicht beseitigt.
Der Angriffsweg über den Browser ist geschlossen und überprüft; die 64 Routen im Admin- und Händler-Panel selbst schreiben weiterhin Zustand bei einem GET, und ihre Umstellung auf geschützte Formulare wurde bewusst nicht versucht, weil das ein großes Regressionsrisiko auf einer Plattform ist, die derzeit über viele abgeleitete Projekte hinweg funktioniert.
Der Wächter ist breiter als die Schwachstelle.
Auch eine harmlose, nur lesende Liste wird abgelehnt, wenn sie als Prefetch oder Bildaufruf ankommt, denn die rund 860 nur lesenden Adressen des Panels von den 64 gefährlichen zu trennen, bräuchte genau die fragile Liste, die wir nicht schreiben wollten. Es gibt einen Schalter aus einer Zeile, um ihn abzuschalten.
Die Ratenbegrenzung ist sicher, weil die Server so stehen, wie sie stehen, nicht weil Header nicht gefälscht werden können.
Die Konfiguration vertraut weitergeleiteten Headern, was nur so lange gilt, wie nichts anders als über die Proxy-Kette an PHP herankommt. Auf einer direkt erreichbaren Maschine könnte ein Client den Header fälschen und pro Anfrage einen frischen Zähler bekommen.
Die Downloadgröße der App hat sich kaum verändert.
Etwa 0.7 MB insgesamt, weil der ungenutzte Code, den wir entfernt haben, vom Release-Compiler ohnehin schon verworfen wurde. Wir behaupten nichts über die App-Größe.
Drei Punkte auf der Referenzinstallation sind offen und benannt statt versteckt.
Die Google-Maps-Schlüssel sind unbeschränkt und müssen eingeschränkt werden; ein privater Schlüssel für Apple Sign-In, den die eigene Upload-Hilfe von Standard-6amMart im öffentlichen Speicher abgelegt hatte, muss widerrufen und neu ausgestellt werden; und drei Händler haben weiterhin keinen Store-Datensatz — die 500er-Fehler, die dieser Zustand früher verursachte, sind behoben, aber der Zustand selbst ist weiterhin erreichbar, weil beide Registrierungswege Händler und Store außerhalb einer einzigen Transaktion speichern. Alle drei stehen im Übergabedokument.
Auf dem Referenzserver ist jetzt die Hardware die Grenze, nicht der Code.
Lasttest mit 20–40 gleichzeitigen Nutzern ohne Fehler; an diesem Punkt ist die Maschine mit 2 vCPU ausgelastet.
All diese Messungen stammen von einem Server, einem Datenbestand.
Sie reichen, um zu sagen, was sich auf dieser Installation geändert hat. Sie sind keine allgemeine Aussage über jedes 6amMart-Deployment.
Standard-6amMart ist ein weit verbreitetes kommerzielles Produkt.
Die Defekte oben sind als Tatsachen genannt, und das genügt.
Der Skalierungstest, vollständig gedruckt — jede Zeile, auch die schlechten
Skalierungstest — eine eigens gebaute Datenbank mit 10 Millionen Bestellungen, kein Live-Verkehr.
| Bildschirm | Standard | Optimiert | Weiterhin langsam? |
|---|---|---|---|
| Bestellliste im Admin-Panel, erste Seite | 27.4 s | 13.6 ms | |
| Bestellzähler-Badges auf jeder Händler-Seite | 136 ms | 20 ms | |
| Artikelbericht, this_week | bei 120 s abgebrochen | 542 ms | |
| get_stores | 9.8 s | 901 ms | |
| Bestellzähler-Badges auf jeder Admin-Seite | 8.5 s | 830 ms | |
| Kundenliste im Admin-Panel, erste Seite | 20.7 s | ~1.0 – 1.5 s | ≥ 1 s |
| Bestellliste im Admin-Panel, tiefer Seitenversatz | 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 |
| Artikelbericht, this_month | bei 120 s abgebrochen | 12.5 s | ≥ 1 s |
| Artikelbericht, all_time | bei 120 s abgebrochen | 131 s (Untergrenze 365 Tage) | ≥ 1 s — die schlechteste Zeile, die wir haben |
Wo zwei Quellen bei einer Zeile nicht übereinstimmen, druckt diese Tabelle auf beiden Seiten die weniger schmeichelhafte Zahl.
Unser eigener Bericht verzeichnet die Kundenliste im Admin-Panel mit ~1.0 s, während das Rohprotokoll des Testrahmens 1.5 s verzeichnet, deshalb ist der Bereich gedruckt. Der Bericht verzeichnet die Admin-Badges mit 8.5 s → 830 ms, wo das Rohprotokoll 57.4 s → 791 ms zeigt, und die Händler-Badges mit 136 ms → 20 ms, wo das Rohprotokoll 270 ms → 13 ms zeigt; in beiden Fällen sind der kleinere „Vorher“- und der größere „Nachher“-Wert gedruckt.
Wird mich das betreffen?
Bei realistischen 100,000 Bestellungen — dem Dreißigfachen des heutigen Volumens der geprüften Installation — und mit abgeschalteten Zeitfenstern für die Bestell-Badges messen alle neun bei diesem Volumen profilierten Bildschirme 250 ms oder weniger und sechs der neun 50 ms oder weniger: Händler-Badges 3.4 ms, get_latest_products 10 ms, Kundenliste 31 ms, Artikelbericht 46 ms, beliebte Produkte 47 ms, Store-Liste 50 ms, Dispatch-Badges 146 ms, Bestellliste im Admin-Panel 155 ms, Sidebar-Badges im Admin-Panel 179 ms. Das Badge-Zeitfenster (ORDER_BADGE_WINDOW_DAYS=60) ist eine mitgelieferte Einstellung, und ob es an ist, verändert diese Zahlen, deshalb nennen wir die Bedingung, unter der gemessen wurde.
FAQ
Fragen, die Käufer tatsächlich stellen
Zwölf Fragen, beantwortet mit denselben Zahlen wie der Rest der Seite.
Was kaufe ich hier eigentlich?
Dasselbe, was AllsWeb schon immer verkauft hat: vollständige Installation, Einrichtung und Konfiguration von 6amMart auf Ihrem Hosting — Admin-Panel, Händler-Panel, Android APK und AAB, iOS-Build, Kunden-Website, Ihr Branding, SMTP, Google Maps, Firebase Push und OTP, Social Login, Ihre Payment-Gateways, Ihre Sprachdatei und den Quellcode in einem privaten GitHub-Repository. Geliefert in 1–3 Werktagen, sobald Ihre Anforderungen vollständig sind, mit kostenlosem lebenslangem Support für Einrichtungsprobleme und kleine Korrekturen. Der optimierte Code ist die Art, wie diese Installation jetzt gebaut wird.
Bekomme ich dasselbe 6amMart?
Ja — das neueste 6amMart-Release, was auch immer 6amTech ausliefert, wenn wir Ihre Installation bauen. Dasselbe Admin-Panel, dasselbe Händler-Panel, dieselben Kunden-, Store- und Fahrer-Apps, dasselbe Datenmodell, dieselben Funktionen. Jede Performance-Änderung war daran gebunden, byte-identische Daten zurückzugeben, bevor sie akzeptiert wurde, Ihre Bildschirme zeigen also, was sie vorher gezeigt haben, nur schneller.
Kostet der optimierte Code extra?
Nein. Es gibt kein separates Produkt, keine separate Lizenz und keine Premium-Stufe. Der Installationspreis im Katalog ist der Preis, und der optimierte Code ist darin enthalten. Sie kaufen und besitzen weiterhin Ihre eigene 6amMart-Lizenz bei CodeCanyon.
Wie viel schneller ist es wirklich?
Auf dem Live-Server, unter Umgehung des CDN: hervorgehobene Artikel 8.19 s → 0.37 s (22×), Top-Kategorien 3.34 s → 0.27 s (12×), Produktsuche 1.64–1.96 s → 0.09–0.12 s (mindestens 13×), die Startseite des Shops ~1.47 s → 0.073–0.096 s (mindestens 15×). Die Faktoren pro Zeile sind so berechnet, wie es die Messungen am wenigsten schmeichelhaft zulassen. Der typische Wert über die Bildschirme, die Kunden sehen, ist 10× bis 22× schneller — 90 bis 95% weniger Wartezeit.
Woher kommen diese Zahlen, und auf welcher Hardware?
Vorher ist das Standard-Script genau so, wie CodeCanyon es zum Zeitpunkt des Experiments ausgeliefert hat — der Methodenhinweis oben erklärt in einer Fußnote, welcher Build das war und warum die Fußnote dort steht. Nachher ist dasselbe Script nach dem Programm, mit dem darauf aufgesetzten nächsten Release des Herstellers. Beides wurde auf demselben Server mit 2 vCPU / 3.9 GB gemessen, serverseitig, unter Umgehung des CDN — nicht auf einer größeren Maschine und nicht mit einem CDN, das die Arbeit übernimmt. Zwei Zeilen in der Vergleichstabelle sind keine Servermessungen und sind als solche markiert: eine Byte-Zahl aus dem Build und eine Messung auf einem Handy über Mobilfunk.
Kann ich davon irgendetwas selbst überprüfen, oder muss ich der Seite glauben?
Sie können alles überprüfen. Die Prüf-Suite wird mit Ihrer Installation ausgeliefert: bash tests/Scripts/run-all.sh führt die Prüfungen aus und php tests/Scripts/api-smoke.php geht 306 API-Anfragen durch und druckt die Antwortzeiten. Jede Zusicherung musste gegen den alten Code nachweislich fehlschlagen, bevor sie akzeptiert wurde, ein Bestehen bedeutet also etwas. Ein Vorbehalt, den wir Ihnen lieber sagen, als dass Sie ihn entdecken: In einem gültigen Durchlauf werden etwa 66–68 Anfragen von der plattformeigenen Ratenbegrenzung abgewiesen, und ein Durchlauf mit hunderten Abweisungen sollte verworfen werden.
Funktionieren die eigenen Updates von 6amTech darauf weiterhin?
Technisch ja — es ist bereits geschehen. Das nächste Release des Herstellers wurde auf den optimierten Code aufgesetzt, und nach dem Bericht vom 9. August kam weitere Arbeit hinzu: Cache-Härtung, eine neu gebaute Ausgabenliste und ein Defekt beim Anwendungsschlüssel, der jede aus der Beispielkonfiguration des Herstellers gebaute Installation betraf. Das ehrliche Detail ist, dass unsere Korrekturen in denselben Dateien liegen, die 6amTech ausliefert, ein Hersteller-Release ist also eine Zusammenführung, die wir für Sie durchführen, und kein Überschreiben Datei für Datei, das Sie selbst ausführen.
Was passiert, wenn 6amTech das nächste 6amMart-Release veröffentlicht?
Wenn Sie jetzt kaufen, bekommen Sie es — wir installieren, was am Tag des Builds aktuell ist. Für eine Installation, die wir früher geliefert haben, passiert dasselbe wie für jeden Kunden bei jedem unserer Katalog-Scripts: Der Wechsel auf ein neueres Release ist der übliche Update-Service zu 50% des Installationspreises, weil die Konfiguration aus Ihrer ersten Einrichtung wiederverwendet wird. Die Anwendung auf den optimierten Code ist die Zusammenführung aus der vorherigen Antwort, und das ist unsere Arbeit, nicht Ihre.
Welche Sicherheitsprobleme steckten tatsächlich im Standard-Script?
Reproduziert und dann behoben: nicht authentifizierte SQL-Injection, erreichbar aus jeder Store-Liste; die Bestellungen und die Lieferadresse jedes Kunden ohne Anmeldung lesbar; Payment-Gateways, die im Admin-Panel abgeschaltet waren, deren Callbacks aber weiterhin Zahlungen abschlossen; Händler, die Produkte und Banner anderer Händler bearbeiten konnten; eine aktive Hintertür beim Demo-Login (begrenzt — sie führte zu einem neuen Konto mit umgangener Telefonverifizierung, nicht zur Übernahme eines bestehenden); vierzehn Projektpfade über HTTPS lesbar, darunter ein 679 KB großer Datenbank-Dump des Installers; jede Rechnung über die URL durchnummerierbar; und eine API ganz ohne Ratenbegrenzung — 40 Versuche mit falschem Passwort hintereinander wurden alle angenommen, ohne Drosselung und ohne Protokolleintrag.
Bleibt es schnell, wenn mein Shop wächst?
Bis etwa 100,000 Bestellungen ja: neun bei diesem Volumen profilierte Bildschirme messen mit abgeschalteten Zeitfenstern für die Bestell-Badges alle 250 ms oder weniger und sechs der neun 50 ms oder weniger. Das ist das Dreißigfache des heutigen Volumens der geprüften Installation. Darüber hinaus lesen Sie den Skalierungstest unter Ehrliche Grenzen weiter oben — dort ist nicht alles ein Erfolg. Bei 10,000,000 Bestellungen gegen eine unterdimensionierte Datenbank geht die Bestellliste im Admin-Panel von 27.4 s auf 13.6 ms, aber Dispatch-Badges liegen weiterhin bei 12 s, beliebte Produkte bei 7.1 s und der Artikelbericht über den gesamten Zeitraum bei 131 s. Das sind Zahlen aus dem Skalierungstest auf einer eigens gebauten Datenbank, nicht von Ihrem Live-Server.
Behaupten Sie, es seien keine Defekte mehr übrig?
Nein. 342 Defekte wurden gefunden und behoben. Niemand kann aufzählen, was in einer Plattform dieser Größe übrig ist. Zeigen können wir Ihnen, was gemessen wurde, wie Sie es neu messen und welche Punkte noch offen sind — der Abschnitt Ehrliche Grenzen auf dieser Seite listet sie auf, einschließlich der Zeilen aus dem Skalierungstest, die weiterhin langsam sind, und der Routen, die wir abgemildert statt neu geschrieben haben.
Womit sind Sie noch nicht zufrieden?
Mit mehreren Dingen, und Sie sollen sie lieber hier lesen. Im Skalierungstest mit 10 Millionen Bestellungen liegen sechs Zeilen weiterhin bei einer Sekunde oder darüber — die schlechteste ist der Artikelbericht über den gesamten Zeitraum mit 131 Sekunden, und der Standard-Durchlauf, mit dem er verglichen werden müsste, wurde bei 120 Sekunden abgebrochen, wir können dort also überhaupt keine Verbesserung behaupten; Dispatch-Badges liegen bei 12 Sekunden. Vierundsechzig Routen im Admin- und Händler-Panel ändern weiterhin Zustand bei einem einfachen GET — der Angriffsweg über den Browser ist geschlossen und überprüft, aber die Routen selbst wurden nicht umgestellt. Und auf der Referenzinstallation sind die Google-Maps-Schlüssel unbeschränkt, ein Apple-Sign-In-Schlüssel muss widerrufen und neu ausgestellt werden, und drei Händler haben weiterhin keinen Store-Datensatz.
Begleitende Werkzeuge
Wo SixPanel und SixPreflight hineinpassen
Alles oben handelt vom 6amMart-Code selbst. Zwei AllsWeb-Werkzeuge stehen links und rechts davon — das eine betreibt den Server, auf dem der Shop lebt, das andere sagt Ihnen, ob ein Server, den Sie bereits haben, dafür bereit ist. Ihre Zahlen wurden zu einer anderen Zeit auf anderen Maschinen gemessen, deshalb halten wir sie in eigenen Tabellen und mischen sie nie mit den Zahlen oben.
SixPanel
Wenn der Server verwaltet werden soll
Worum es geht
Ein Verwaltungspanel, das einen 6amMart-Shop oder mehrere auf einem gemieteten VPS betreibt — MariaDB, Redis, nginx, den Websocket-Dienst für die Live-Bestellverfolgung und einen optionalen Next.js-Storefront. Zwei Laufzeitumgebungen: die empfohlene installiert alles direkt auf der Maschine aus dem eigenen Distributionsarchiv des Releases unter systemd, und SixPanel Docker betreibt denselben Stack als Docker-Compose-Dienste. Ein Installationsbefehl, Deploy aus einer CodeCanyon-ZIP oder aus git, automatische Let's-Encrypt-Zertifikate mit automatischer Erneuerung, geplante inkrementelle restic-Backups mit Aufbewahrung, virtuelle Hosts pro Projekt, Hardware-Autotuning und ein selbstheilender Watchdog, der Dienste neu startet, die laufen, aber nicht funktionieren. Drei Oberflächen: das Panel im Browser, ein sixpanel-Befehl auf dem Host und der Installer. Es liefert ein Kundenhandbuch mit 24 Kapiteln mit, direkt im Panel.
Gemessen und veröffentlichbar
| Was gemessen wurde | Die Zahl, mit ihren Bedingungen |
|---|---|
| Bediente Anfragen — Such-Endpunkt, 20 gleichzeitig, 30 Sekunden | Ein Server mit 2 Kernen / 4 GB schaffte etwa 53 Anfragen pro Sekunde auf dem Katalog eines echten Shops mit 66,701 Bestellungen, wobei die Datenbank 99.99% der Lesezugriffe aus dem Arbeitsspeicher beantwortete. Das beschreibt diesen Endpunkt, diesen Datenbestand und zwei Kerne. Es ist keine allgemeine Zahl für die Plattform. |
| Unbeaufsichtigte Installationszeit | 273 – 303 Sekunden über die drei getesteten Betriebssysteme — etwa fünf Minuten |
| Geschwindigkeit gegen einen optimierten Konkurrenten | 1,76× schneller als ein voll optimiertes aaPanel bei einer Anfrage und 1,82× bei vier gleichzeitig, auf identischer Hardware mit demselben Shop aus 66.701 Bestellungen — davon rund 60 % des Abstands einer PHP-Verzeichnisbeschränkung zugeordnet, 8 % dem falschen JIT-Modus, 0 % der PHP-Version und rund 32 % als unerklärt veröffentlicht |
| Empfohlenes Betriebssystem | Ubuntu 26.04 LTS, Sicherheitsupdates bis April 2031. Ubuntu 24.04 LTS und Debian 13 sind die beiden anderen unterstützten Releases — drei insgesamt, und nichts sonst |
Noch etwas, das erwähnenswert ist, weil es fast niemand veröffentlicht. Wir haben drei Betriebssysteme auf identischer Hardware mit denselben echten Daten gemessen. Sie lagen gleichauf — der Abstand zwischen ihnen war kleiner als der Abstand einer Maschine zu sich selbst. Also haben wir nach der Dauer des Supports entschieden statt nach Geschwindigkeit, und wir nennen keinen Geschwindigkeitsunterschied, den wir nicht messen konnten.
Ehrliche Grenzen — SixPanel
- Backups werden auf dieselbe Maschine zurückgespielt. Beim Zurückspielen auf eine andere Maschine bleiben das Datenbankpasswort und die Pfade der alten Maschine zurück, und die Anwendung kann sich erst verbinden, wenn ein Update ausgeführt wird; außerdem führt der Restore-Job den Schritt für die Datenbankmigration nie aus, ein älterer Dump unter neuerem Code bleibt also hinter dem Schema zurück. Beides ist als defekt vermerkt — vermerkt, nicht behoben — und für beides gibt es einen manuellen Weg.
- Der selbstheilende Watchdog sieht zwei der Dienste in der Funktionsliste oben nicht. Der Websocket-Dienst und der optionale Next.js-Storefront haben keinen Healthcheck, der Watchdog deckt sie also nicht ab. Offener Punkt.
- Ein Rollback macht Datenbankmigrationen nicht rückgängig. Ein Code-Rollback nach einer Migration braucht ein Zurückspielen aus dem Backup.
- Das Panel liest sein eigenes TLS-Zertifikat einmal beim Start. Der tägliche Erneuerungsjob lädt nginx neu, aber nicht das Panel, das Panel braucht also einen Neustart, um ein erneuertes Zertifikat zu übernehmen.
- Das Panel ist auf dem Host bauartbedingt root-gleichwertig — es installiert Pakete, schreibt Systemkonfiguration und startet Dienste neu. Auf der Docker-Laufzeit bindet es zusätzlich den Docker-Socket ein und hängt das Stack-Verzeichnis mit Schreibrecht ein.
- Es gibt genau ein Admin-Konto und keine Rollen. Kein Mehrbenutzerbetrieb, keine Teams.
- Es wurden nur Maschinen mit 4 GB gemessen. Nichts auf dieser Seite beschreibt 8 GB oder mehr.
Wann SixPanel passt
Sie mieten einen VPS und möchten nginx, MariaDB-Tuning, Zertifikate, Backups und Deployments lieber nicht selbst betreuen — oder Sie wollen mehr als einen Shop auf einem Server.
SixPreflight
Wenn Sie vor dem Start wissen wollen, was kaputtgehen wird
Worum es geht
Ein kleines PHP-Werkzeug, das Sie in den public/-Ordner Ihrer Laravel-Website legen und passwortgeschützt im Browser öffnen. Es führt rund 134 Prüfungen aus über Hardware, PHP, Anwendungszustand, Umgebungsdatei, Berechtigungen, Webserver, Caching, Datenbankeinstellungen, öffentliche Erreichbarkeit und jeden externen Dienst — Zahlungen, E-Mail, SMS, Karten, Push — und kontaktiert jeden davon tatsächlich, statt eine Einstellung zu lesen. Es gibt eine Note, ein klares Urteil und eine nach Folgen sortierte Liste der Korrekturen, jeweils mit einem einfügefertigen Wert, wo es einen gibt. Sie erhalten das aktuelle Release.
Auf der Referenzinstallation
Es meldete 103 bestanden, 7 fehlgeschlagen, 24 Warnungen — und die Fehlschläge waren Hosting-Einstellungen, keine Anwendungsfehler.
Wann SixPreflight passt
Auf aaPanel, CloudPanel oder cPanel? Dann ist SixPreflight für Sie. Sie betreiben SixPanel? Diese Prüfungen sind bereits in dessen Seite Shop-Check eingebaut.
Alles empfiehlt jetzt dasselbe Betriebssystem, und der Grund ist nicht Geschwindigkeit. SixPanel, SixPanel Docker und SixPreflight empfehlen alle Ubuntu 26.04 LTS. Die native Laufzeitumgebung nimmt PHP, MariaDB, nginx und Redis aus dem eigenen Distributionsarchiv des Releases, und alle drei unterstützten Releases bringen einen funktionierenden Satz mit — 26.04 liefert PHP 8.5 und MariaDB 11.8, Debian 13 liefert 8.4 und 11.8, Ubuntu 24.04 liefert 8.3 und 10.11. Nichts davon ist eine Geschwindigkeitsempfehlung: über sechs gemessene Achsen hat kein Versionswechsel einen berichtbaren Unterschied ergeben, und zwei bytegleiche Maschinen wichen um 11,6 % voneinander ab. Entscheidend ist die Support-Laufzeit — 26.04 wird bis April 2031 mit Patches versorgt.
Welches brauche ich?
| Ihre Situation | Die Antwort |
|---|---|
| Sie wollen 6amMart installiert haben, oder Ihr bestehendes 6amMart ist langsam oder hat Ihnen bei Preisen oder Zahlungen geschadet | Die optimierte 6amMart-Installation |
| Sie haben einen VPS und wollen nginx, MariaDB, SSL, Backups und Deployments nicht selbst betreuen | SixPanel |
| Sie haben bereits einen Server auf einem anderen Panel und wollen vor dem Start wissen, was kaputtgehen wird | SixPreflight |
Jede Zahl auf dieser Seite wurde auf einer laufenden Installation gemessen
Und die Suite, die sie gemessen hat, wird mit Ihrem Build ausgeliefert.
Brauchen Sie stattdessen etwas von Grund auf Neues? Sprechen Sie mit uns über Individualentwicklung