6amMart optimisé : le même script, mesuré et corrigé
AllsWeb installe la dernière version de 6amMart — même script, même admin, mêmes apps — sur un code que nous avons mesuré et corrigé. Les écrans côté client sont 10× à 22× plus rapides que la version d'origine, 342 défauts sont corrigés, et une suite de vérifications livrée avec le build le prouve.
Le code optimisé est compris dans le prix de l'installation. Ce n'est ni une mise à niveau, ni une option, ni une formule supérieure.
10× – 22×
plus rapide sur les écrans vus par les clients
342
défauts trouvés et corrigés
799
commits sur cinq dépôts
1–3 jours
de délai une fois vos informations complètes
Vous lisez cette page avec un assistant IA ?
Avec versus sans
Ce qui change le jour de l’ouverture
6amMart d’origine à gauche, le code qu’AllsWeb installe à droite. Même script, même panneau d’administration, mêmes apps, même version de l’éditeur — chaque chiffre mesuré sur le même serveur 4 Go / 2 cœurs, avec les mêmes données.
Le premier écran que voit un client
D’origine
La rangée « en vedette » de l’écran d’accueil met 8,19 s à se remplir. Assez pour qu’un client sur mobile conclue que l’app est cassée et la ferme.
Optimisé
La même rangée se remplit en 0,37 s — 22× plus vite, mesuré avec le CDN contourné pour chronométrer l’application et non un cache.
Le rapport de revenus de la boutique
D’origine
Dessiner un rapport pose 8 614 questions distinctes à la base de données et garde une connexion ouverte pendant tout ce temps. Quelques administrateurs qui l’ouvrent ensemble suffisent à rendre la boutique pénible pour tout le monde.
Optimisé
Le même rapport pose 12 questions. Avant, il paraissait acceptable en test, parce que sur un petit jeu de données chacune de ces 8 614 questions est rapide.
Le minimum d’achat d’un coupon
D’origine
Le panneau vous laisse le définir et le code ne le lit jamais. Prouvé en production : un coupon exigeant un minimum de ₹999 a été accepté sur une commande de ₹1, avec six coupons actifs configurés ainsi.
Optimisé
Appliqué aux trois endroits où une commande peut être tarifée.
Les remises du soir
D’origine
La base de données tournait en UTC et l’application à l’heure de l’Inde — mesurés à 5 h 30 d’écart sur une installation réelle. Une remise du soir 18:00–22:00 ne s’appliquait donc jamais le soir et s’activait à 2 h du matin. L’écran de liste et le paiement utilisaient des horloges différentes : une boutique pouvait être annoncée en remise et facturer le prix plein.
Optimisé
Une seule horloge : la remise affichée est la remise facturée.
Qui peut lire la commande d’un client
D’origine
Plus de six points d’entrée acceptaient n’importe quel identifiant de commande avec un identifiant d’invité deviné. Reproduit sans aucune authentification : la réponse contenait les articles, les prix et l’adresse de livraison d’un autre client. Le point d’entrée de paiement par portefeuille sur le même chemin ne vérifiait pas le solde.
Optimisé
Un périmètre de propriété sur chaque point d’entrée concerné, le paiement invité légitime continuant de fonctionner.
Une passerelle de paiement que vous avez désactivée
D’origine
La désactiver dans le panneau la retirait seulement des choix du client. Son URL de rappel restait active, et beaucoup de rappels de passerelle marquent une commande payée sur un simple mot de statut dans l’URL — donc avec toutes les passerelles désactivées, un rappel aboutissait encore et un client pouvait confirmer sa propre commande sans payer.
Optimisé
Échoue en position fermée, avec 102 sondes sur tous les préfixes de passerelle confirmant qu’aucune ne s’exécute lorsqu’elle est inactive.
Ce que cela vous coûte
D’origine
Le 6amMart d’origine, c’est ce qu’une installation normale vous remet.
Optimisé
La même installation, sur la dernière version de 6amMart. Pas de seconde licence, pas de second prix, pas de palier supérieur — c'est simplement la façon dont l'installation est livrée.
Ce que « optimisé » veut dire ici
Le même 6amMart. Différent en dessous.
C'est le même 6amMart — la version en cours, celle que 6amTech livre le jour où nous construisons votre installation. Le même panneau admin, le même panneau vendeur, les mêmes apps client, boutique et livreur, le même modèle de données, les mêmes fonctionnalités que dans la démo. Rien n'a été remplacé et rien n'a été renommé. Ce qui a changé est en dessous : AllsWeb a passé quatorze sessions de travail à mesurer le script, à le profiler et à corriger ce que les mesures ont révélé — 799 commits sur cinq dépôts entre le 13 juillet et le 9 août 2026, sur le backend, le panneau admin, le site web et les trois apps. Chacun de ces changements devait renvoyer des données identiques octet pour octet avant d'être accepté. Ce n'est pas un autre produit entre lesquels choisir. C'est notre façon d'installer 6amMart aujourd'hui.
Ce que vous achetez
- Le service ne change pas
- Installation, mise en place et configuration complètes de 6amMart sur votre hébergement — panneau admin, panneau vendeur, APK + AAB Android, build iOS, site web client, votre identité visuelle, SMTP, Maps, notifications push et OTP Firebase, connexion sociale, vos passerelles de paiement, votre fichier de langue, et le code source personnalisé sur un dépôt GitHub privé.
- Livraison
- 1–3 jours ouvrés une fois vos informations complètes.
- Support à vie gratuit
- Pour les problèmes de mise en place et les petites corrections.
- Votre propre licence CodeCanyon
- Vous achetez et possédez votre propre licence 6amMart sur CodeCanyon ; nous installons par-dessus.
Le code optimisé est compris dans le prix de l'installation. Ce n'est ni une mise à niveau, ni une option, ni une formule supérieure.
Pourquoi la version d'origine était lente
Une phrase, et un constat
La base de données n'était pas lente. L'application lui posait la même question des centaines de fois par page.
La partie que la plupart des gens n'ont jamais vue
Sur un endpoint client, une seule requête déclenchait 112 requêtes en base. Quatre-vingt-six d'entre elles — 76% — étaient déclenchées pendant la conversion du résultat final en JSON pour l'envoyer, parce que les accesseurs d'attributs allaient chercher la donnée à la demande, une fois par ligne, au moment de la sérialisation. Sept servaient à récupérer les données et onze à les préparer. C'est pourquoi ajouter des index n'aurait rien changé à lui seul : le coût n'était pas dans les requêtes exécutées par la page.
Cet endpoint en déclenche maintenant 45.
86 ÷ 112 = 76.8%, affiché ici 76%. La source affiche 77% ; qu'une source arrondisse vers le haut n'autorise pas cette page à en faire autant.
La comparaison mesurée
Avant et après, sur le même serveur
Le protocole
| Condition | Ce que c'était |
|---|---|
| Avant | Le script d'origine exactement tel que CodeCanyon le livrait au moment de l'expérience — commit de référence d92ce004, 8 juillet 2026 ‡ |
| Après | Le même script après le programme d'optimisation et de durcissement AllsWeb, avec la version suivante de l'éditeur appliquée par-dessus |
| Serveur | La même machine pour les deux séries — 2 vCPU, 3.9 GB RAM |
| Méthode | Mesuré côté serveur, CDN contourné |
| Ampleur du changement | 799 commits · 342 corrections · 171 changements de performance · 37 fonctionnalités |
| Règle d'acceptation | Chaque changement de performance devait renvoyer des données identiques octet pour octet avant d'être accepté |
- ‡ Ce qui a été mesuré. Les chiffres « avant » ont été relevés sur le script d'origine tel que CodeCanyon le livrait le 8 juillet 2026 — la version numérotée 4.0.1 par 6amTech — et la version suivante de l'éditeur a été appliquée ensuite sur le code optimisé. C'est une affirmation sur l'expérience, pour que les chiffres « avant » puissent être reproduits depuis le même point de départ. Ce n'est pas une affirmation sur ce que vous recevez : nous installons la version que 6amTech livre le jour où nous construisons. Des travaux importants ont encore été livrés les 13–15 août 2026, que le rapport du 9 août ne couvre pas.
- La règle d'acceptation, en une ligne. « Plus rapide n'a jamais eu le droit de vouloir dire différent. »
- Arrondis en notre défaveur. Quand une valeur mesurée est une plage, les facteurs indiqués ici sont calculés de la façon la moins flatteuse que les chiffres permettent — le plus petit « avant » divisé par le plus grand « après ». Notre propre rapport cite des facteurs calculés sur les milieux de plage, qui sortent plus élevés.
Neuf lignes, toutes en avant/après, et elles ne sont pas toutes du même type de mesure, donc le tableau précise laquelle est laquelle. Les lignes 1–5 sont des temps de réponse relevés sur le même serveur avec le CDN contourné. Les lignes 6–7 sont des comptages de questions à la base de données par page, où « CDN contourné » n'est pas une condition qui a un sens. Les lignes 8–9 ne sont pas du tout des mesures serveur et portent un †. Ce sont les lignes qu'un commerçant ressent vraiment, pas nos plus gros chiffres.
| # | Ce que c'est | 6amMart d'origine | Optimisé | Facteur |
|---|---|---|---|---|
| 1 | Articles en vedette sur l'écran d'accueil | 8.19 s | 0.37 s | 22× plus rapide |
| 2 | Recherche de produits | 1.64 – 1.96 s | 0.09 – 0.12 s | au moins 13× plus rapide |
| 3 | Page d'accueil de la boutique | ~1.47 s | 0.073 – 0.096 s | au moins 15× plus rapide |
| 4 | Catégories principales | 3.34 s | 0.27 s | 12× plus rapide |
| 5 | Configuration de l'app au lancement | 0.53 – 1.15 s | 0.045 s | au moins 11× plus rapide |
| 6 | Export des revenus boutique — questions à la base par page | 8,614 | 12 | 717× moins |
| 7 | Liste du catalogue produits — questions à la base par page | 557 | 92 | ~6× moins |
| 8 | † Styles envoyés sur chaque page du site — un nombre d'octets en sortie de build, pas un temps serveur | 921,603 octets | 12,386 octets | −98.6% (74× plus petit) |
| 9 | † Dix requêtes de l'app à la suite — mesurées depuis un téléphone en données mobiles, pas sur le serveur | 6,140 ms | 1,876 ms | −69% (3.2× plus rapide) |
† Les lignes 8 et 9 ne sont pas des mesures serveur. La formule « même serveur, CDN contourné » ne couvre que les temps de réponse des lignes 1–5 ; le chiffre des styles est une sortie de build et celui des dix requêtes a été relevé en données mobiles.
L'arithmétique, écrite noir sur blanc
La ligne 6 affiche 717×, et non le 718× qu'écrit notre propre rapport : 8,614 ÷ 12 = 717.83, et cette page n'arrondit pas un chiffre vers le haut en sa faveur. La ligne 9 affiche 3.2× pour la même raison — 6,140 ÷ 1,876 = 3.27. Le compte d'octets de la ligne 8 donne 921,603 ÷ 12,386 = 74.4, affiché 74×. Le 76% ci-dessus vaut 86 ÷ 112 = 76.8%, arrondi dans le même sens.
Capacité simultanée, énoncée de la seule façon que les preuves permettent
Sur le même serveur 2 vCPU, sous une montée en charge contre l'endpoint de la liste des boutiques, 13× plus de clients peuvent l'utiliser en même temps sur le même serveur. Le couple de requêtes par seconde correspondant n'est délibérément pas publié : la source enregistre la montée en charge sans indiquer sa simultanéité ni sa durée, et un chiffre de requêtes par seconde qui ne peut pas nommer son endpoint, sa simultanéité et sa durée n'a pas sa place sur cette page. Le chiffre SixPanel plus bas dispose des trois, et c'est pourquoi celui-là est publié sous forme de débit.
Deux lignes qui ne parlent pas de vitesse
| Ce que c'est | 6amMart d'origine | Optimisé |
|---|---|---|
| Endpoints renvoyant une erreur serveur sur une installation neuve | 3 (boutiques populaires, boutiques récentes, moyens de paiement) | 0 — les trois répondent maintenant en 41–150 ms |
| Alertes de sécurité connues sur les dépendances, comptées le 9 août 2026 | 111 | 0 |
Ce qu'étaient réellement ces 111. 110 d'entre elles portaient sur des versions d'axios et de vite à l'intérieur de cinq fichiers package.json de modules complémentaires dont les chaînes de build n'ont jamais fonctionné — quatre pointent vers des fichiers source qui n'existent pas dans le module, et le cinquième vers deux fichiers de zéro octet. Elles ont quand même été traitées, parce qu'une alerte que l'on a décidé d'ignorer est une alerte qu'on cesse de lire. La seule qui comptait en elle-même était firebase/php-jwt en dessous de 7.0.0 (CVE-2025-45769), auparavant notée comme non corrigeable, aujourd'hui en ^7.0.2 et vérifiée avec les vraies clés Apple, Passport, Firebase et Google.
La ligne des alertes est un instantané daté, et ce n'est pas un hasard : les flux d'alertes évoluent en continu, et un comptage fait le 9 août 2026 dit quelque chose sur ce jour-là, pas une propriété permanente du build. Relancez l'audit sur votre propre installation pour obtenir un chiffre à jour.
État actuel, avec sa réserve attachée Un balayage de 306 requêtes sur les endpoints rapporte zéro erreur serveur et zéro endpoint au-dessus de 250 ms — mesuré sur les requêtes qui se sont exécutées. Dans une série valide, le limiteur de débit de la plateforme en rejette lui-même 66–68, environ un cinquième du balayage, et une requête rejetée n'est pas un résultat d'endpoint. La répartition enregistrée pour une série valide (~235 réussies, 66–68 rejetées) fait environ 302, pas 306 ; nous ne pouvons pas justifier les requêtes restantes avec les sources dont nous disposons. Lancez-le vous-même et lisez votre propre répartition — la section vérification ci-dessous explique comment.
Causes profondes
Les trois causes qui méritent d'être nommées
Ce sont elles qui rendent le tableau crédible.
L'export des revenus demandait la mauvaise chose 2,867 fois.
Il demandait à la base d'aller chercher la boutique de chaque transaction via la commande, alors que le code lisait la boutique directement sur la transaction — un lien différent. L'instruction ne s'appliquait donc jamais, et les 2,867 lignes allaient chercher leur boutique séparément.
Chaque page vendeur dessinait deux menus de navigation.
L'un masqué par la feuille de style, les deux comptant les mêmes badges de commandes.
Un en-tête de page chargeait tout l'historique des commandes de la boutique.
466 commandes pour la boutique la plus active, pour remplir une section de la page qui avait été mise en commentaire.
Et le constat sur les index
Dix des colonnes sur lesquelles la base fait ses jointures n'avaient aucun index. Après indexation, une recherche est passée de la lecture de 51,074 lignes à la lecture d'une seule.
La liste des clients côté admin examinait 16,092,496,536 lignes pour en renvoyer 98 — 82% de tout le temps de requêtes lentes du serveur, et jusqu'à 18 minutes pour un seul chargement de page.
Ce qui a été corrigé
Performance, sécurité, exactitude
Performance
Questions à la base de données pour une seule requête — chacune vérifiée identique octet pour octet avant que le changement ne soit accepté.
API client
| Opération | Origine | Optimisé |
|---|---|---|
| Liste du catalogue produits (31 articles) | 557 | 92 |
| Liste des commandes vendeur (41 commandes) | 212 | 12 |
| Mise en forme du détail de commande (40 lignes) | 121 | 4 |
| Historique des commandes client | 166 | 97 |
| Liste de souhaits (6 articles) | 140 | 37 |
| Liste des boutiques | 78 | 39 |
| Configuration de l'app | 54 | 21 |
| Liste des catégories | 43 | 16 |
Panneaux admin et vendeur
| Écran | Origine | Optimisé |
|---|---|---|
| Export des revenus boutique | 8,614 | 12 |
| Recherche de commandes (admin) | 259 | 14 |
| Sélecteur de produits pour vente flash | 186 | 42 |
| Galerie produits | 166 | 48 |
| Liste des loueurs | 159 | 9 |
| Menu déroulant des boutiques dans les Reels | 127 | 62 |
| Fiche client | 106 | 34 |
| Liste des véhicules de location | 94 | 13 |
| Page des revenus boutique | 89 | 13 |
| Chaque page vendeur, avant son propre contenu | 61 | 52 |
Les panneaux admin et vendeur n'avaient jamais été mesurés — les propres tests automatisés de 6amMart d'origine ne couvrent que l'API client. 586 pages admin et 165 pages vendeur ont été profilées, comptées en questions à la base de données « parce qu'un comptage est exact et reproductible alors qu'un chronomètre sur un serveur partagé dérive ».
Site web
- Sur les 921,603 octets de styles présents sur chaque page, 902 KB étaient trois bibliothèques d'icônes complètes — 21,459 définitions d'icônes livrées pour que le site puisse en afficher 89. Le build n'émet plus que les icônes réellement utilisées, et le total des styles par page est de 12,386 octets, −98.6%.
- JavaScript partagé 429 kB → 269 kB (−37%).
- La page d'accueil était une coquille vide tant que le JavaScript n'était pas chargé ; elle livre maintenant 273,110 octets rendus par le serveur.
- Requêtes de configuration : une par page vue et par visiteur → une par minute et par langue.
- La bibliothèque Maps était envoyée à 9 pages qui n'affichent aucune carte.
- Formatage des dates par ligne : 8.45 µs → 0.39 µs (21× moins cher).
- Les 50 routes du site se sont améliorées ou sont restées stables ; aucune n'a régressé.
Apps mobiles
- Chaque requête ouvrait une toute nouvelle connexion sécurisée au lieu d'en réutiliser une — environ 426 ms par requête en données mobiles. Dix requêtes à la suite : 6,140 ms → 1,876 ms.
- Écran d'accueil : ~30 requêtes par lancement → 1 requête couvrant 14 sections.
- Une photo de 1000×1000 était décodée derrière un avatar de 40 pixels ; les images sont maintenant décodées à la taille réellement affichée.
- 309 instructions de journalisation de débogage étaient livrées dans les apps publiées. Aujourd'hui zéro.
- GPS livreur : 360 → ~30 rapports de position par heure à l'arrêt.
- L'écran des commandes vendeur redessinait tout toutes les 10 secondes ; il ne redessine plus que quand les données ont changé.
Sécurité — les failles précises trouvées dans le script tel qu'il est vendu
Rien dans cette section n'est une question de préférence. Chaque point est un défaut présent dans 6amMart d'origine, et chacun a été reproduit avant d'être corrigé.
Injection SQL sans authentification, atteignable depuis chaque liste de boutiques.
Le code de la liste des boutiques insérait les en-têtes de latitude et de longitude bruts directement dans le calcul SQL de distance. Atteignable sans connexion et sans jeton. Confirmé jusqu'à la base de données — une charge injectée a produit une erreur de syntaxe SQL dans le journal en production. Corrigé avec des paramètres liés ; un second point d'injection, inutilisé, a été supprimé.
Les commandes de n'importe quel client lisibles et modifiables par n'importe qui.
Plus de six endpoints de commande acceptaient n'importe quel identifiant de commande accompagné d'un identifiant invité deviné. Reproduit en conditions réelles : une requête sans aucune authentification renvoyait les articles, les prix et l'adresse de livraison d'un autre client. L'endpoint de paiement par portefeuille sur le même chemin n'avait aucun contrôle de solde. Corrigé avec un contrôle de propriété sur tous les endpoints concernés, tout en gardant fonctionnelle la commande légitime en tant qu'invité.
Des passerelles de paiement désactivées pouvaient encore encaisser.
Désactiver une passerelle dans le panneau admin la retirait seulement des choix proposés au client — ses URL de rappel restaient actives, et beaucoup de rappels de passerelle marquent une commande payée sur la seule base d'un mot d'état dans l'URL. Avec toutes les passerelles désactivées, un rappel s'exécutait encore avec succès : un client pouvait donc confirmer sa propre commande sans payer. Corrigé en mode fail-closed ; 102 sondes sur chaque préfixe de passerelle confirment maintenant qu'aucune ne s'exécute quand elle est inactive.
Les vendeurs pouvaient agir sur les données d'autres vendeurs.
N'importe quel vendeur pouvait modifier ou supprimer les produits, les suppléments et les bannières d'une autre boutique — y compris les bannières d'accueil de l'admin. Répondre à un avis réattribuait cet avis à la boutique du vendeur qui répondait. Corrigé avec un cloisonnement par boutique.
Une porte dérobée de connexion démo active — et ce qu'elle n'atteignait pas.
6amMart livre un raccourci démo pour qu'un relecteur d'app store puisse se connecter sans SMS. Il lit le numéro de téléphone et le code dans la configuration, avec les valeurs de démo en repli quand la configuration est absente — et la configuration est justement absente dès qu'un site exécute l'étape standard de mise en cache en production, ce que fait toute installation en ligne. Sur le site en production, un numéro codé en dur se voyait remettre un code fonctionnel sans qu'aucun SMS ne soit envoyé et sans que rien dans la configuration ne le demande. L'impact était limité, et nous disons jusqu'où : aucun compte n'existait sur ce numéro, donc le chemin menait à un nouveau compte avec la vérification téléphonique contournée — pas à la prise de contrôle d'un compte existant. C'est le repli qui rendait la chose dangereuse : un exploitant qui n'avait jamais entendu parler du réglage livrait quand même la porte dérobée. 28 vérifications automatisées prouvent désormais qu'elle ne peut pas exister sans activation délibérée.
Tout le dossier du projet était lisible en HTTPS.
6amMart fait pointer le serveur web sur le dossier de l'application plutôt que sur public/, retenu seulement par une liste d'interdiction écrite à la main. Une liste d'interdiction protège les chemins auxquels quelqu'un a pensé ; quatorze n'y figuraient pas, chacun confirmé par une vraie requête — dont un export de base de données de l'installateur de 679 KB, une archive de 5.9 MB du dossier public, et un fichier PHP que le serveur a réellement exécuté, renvoyant une page d'erreur fatale qui divulguait les chemins absolus du serveur. La racine web a été déplacée vers public/ ; les quatorze renvoient maintenant 404, et 19 vérifications automatisées maintiennent cet état.
L'histoire de la limitation de débit, ce sont trois défauts distincts, pas un.
- 1
L'API n'avait aucune limite de débit.
La configuration du framework définissait un limiteur d'API à 600 par minute, mais rien ne l'appliquait jamais — le groupe de middlewares de l'API contenait une entrée sans rapport et rien d'autre, donc le limiteur était de la configuration morte. Mesuré avant le changement : 40 tentatives de connexion avec un mauvais mot de passe sur un même compte, aussi vite que curl le permettait — 40 refus, aucun ralentissement, aucun délai, rien de journalisé. Trois limites s'appliquent désormais : un filet de sécurité à 600/minute, 10/min sur les tentatives d'authentification indexées à la fois sur l'adresse et sur le compte attaqué, et 5/min sur les routes qui envoient un vrai SMS. Vérifié : 25 mauvais mots de passe rapides → 10 refus puis 15 ralentissements ; un compte différent depuis la même adresse dans la même fenêtre → pas ralenti ; 60 requêtes de navigation ordinaires d'un coup → toutes réussies.
- 2
Le limiteur s'indexait ensuite sur une identité que la moitié de la plateforme n'a jamais — et c'est nous qui l'avons trouvé, en relisant notre propre correctif.
Le nouveau limiteur s'indexait sur l'utilisateur connecté, avec repli sur l'adresse réseau. Mais les API vendeur et livreur s'authentifient en cherchant un jeton porteur dans une table plutôt qu'en passant par un garde d'authentification, donc l'utilisateur était toujours nul et la clé retombait sur l'adresse. Une boutique dont le personnel partage une connexion de bureau, ou des livreurs derrière un NAT opérateur, auraient partagé un unique budget de 600/minute — et l'app de livraison interroge le serveur toutes les 10 secondes, donc un service chargé aurait commencé à refuser des gens en plein travail. La clé retombe maintenant d'abord sur une empreinte du jeton porteur. Vérifié : deux appels avec un jeton vendeur → 599 puis 598 restants sur leur propre compteur ; un jeton client juste après → 599 sur un budget distinct ; sans jeton → toujours indexé sur l'adresse, 600 intacts.
- 3
La plateforme ne voyait pas le vrai visiteur.
Derrière un CDN, chaque requête arrivait depuis l'adresse du CDN et l'application croyait que c'était le visiteur — la limitation de débit traitait donc tous les clients comme un seul, les contrôles antifraude comparaient la mauvaise adresse, et chaque commande enregistrait une IP de proxy au lieu de celle de la personne qui l'avait passée. Cause profonde : le framework livre la gestion des proxys dans sa pile globale et 6amMart a remplacé cette pile en bloc, la supprimant au passage, si bien que configurer les proxys de confiance n'avait plus rien à quoi se rattacher. Les deux moitiés sont maintenant en place, et une requête relayée se résout à la vraie adresse client. La plateforme voit maintenant le vrai visiteur au lieu de traiter tout l'internet comme un seul utilisateur.
Une primitive d'empoisonnement de cache.
Le cache des listes calculait sa clé à partir de la chaîne de requête de l'URL, mais les endpoints lisaient leurs paramètres via une méthode qui privilégie le corps de la requête dès que celle-ci se déclare de type JSON — y compris sur un GET. Une requête pouvait donc demander un terme de recherche dans l'URL et un autre dans le corps : la clé était calculée pour le premier, la recherche s'exécutait pour le second, et les mauvaises lignes étaient stockées sous la première clé puis servies à tous les vrais clients qui recherchaient ce terme jusqu'à expiration de l'entrée. Sans authentification, et l'attaquant choisissait les deux moitiés — quels produits un acheteur voyait, de quelle boutique, à quels prix. Les requêtes dont la clé ne peut pas voir les données d'entrée sont désormais traitées entièrement hors cache.
Également corrigé
Chaque facture était téléchargeable par quiconque savait compter.
Les factures de commande, d'abonnement et de course étaient énumérables par URL.
XSS stocké du vendeur vers l'admin.
Les descriptions de produits écrites par les vendeurs étaient rendues en HTML brut sur 8 écrans admin et vendeur, ce qui permettait à un vendeur d'exécuter des scripts dans le navigateur de l'admin. Assaini, et prouvé sans risque sur 25,726 descriptions de produits réelles sans aucun changement de texte visible.
Rejeu des rappels de paiement.
Les rappels n'étaient pas idempotents, donc un rappel rejoué créditait le client deux fois. Corrigé au niveau du hook pour les 47 passerelles.
Une redirection ouverte sur la route de redirection vers l'app.
Une base de hameçonnage sur votre propre domaine. Corrigé, puis corrigé de nouveau quand un contournement par barre oblique inverse a été trouvé en relecture ; un test à 17 cas la protège désormais.
Deux routes de débogage publiques.
L'une exécutait une commande de vidage de cache sans aucune authentification, l'autre était un relais d'images ouvert. Les deux ont été supprimées.
laravel.log téléchargeable depuis internet.
Contenant le nom d'utilisateur de la base de données, les requêtes SQL en échec avec leurs paramètres, et les chemins serveur complets.
Une même clé d'application livrée à toutes les installations.
Le fichier d'environnement d'exemple contenait une vraie clé ; un nouveau fichier d'environnement la recopie, et l'étape de génération de clé ne se déclenche que sur une valeur vide, elle était donc sautée — toutes les installations construites ainsi tournaient sur la même clé, imprimée dans chaque copie du produit.
Des requêtes GET qui modifient des réglages — atténué, et énoncé de façon restreinte.
Dans 6amMart d'origine, modifier un réglage est un simple lien, si bien que 64 routes GET admin et vendeur écrivent un état. Un robot d'exploration, un aperçu de lien, une balise d'image ou une requête en arrière-plan peut modifier des réglages pendant qu'un admin est connecté. Ce n'est pas théorique : le 1er août, notre propre profileur de performance a appelé ces adresses en mesurant la vitesse des pages et a modifié 8 réglages en production en 45 secondes — le sens d'écriture du panneau a basculé, la page d'accueil a été désactivée, un vendeur a été désactivé. Rétabli et vérifié dans l'heure. Le correctif livré est un garde unique, enregistré une seule fois, qui lit les en-têtes Fetch Metadata du navigateur — lesquels indiquent pourquoi une requête a été faite et ne peuvent pas être falsifiés par le JavaScript d'un attaquant — et refuse les formes qui ne sont jamais un clic humain. Vérifié en conditions réelles : le chargement d'une adresse de réglage via une balise d'image est refusé ; un préchargement est refusé ; une requête d'arrière-plan intersites est refusée ; un vrai administrateur qui clique fonctionne ; les 338 requêtes d'arrière-plan du panneau lui-même fonctionnent ; les navigateurs plus anciens qui n'envoient pas ces en-têtes fonctionnent. 102 vraies pages du panneau s'affichent de façon identique octet pour octet avec le garde activé et désactivé, et 53 vérifications automatisées le couvrent. Un seul enregistrement couvre 1,348 routes, y compris les modules qui déclarent leurs propres groupes de routes.
Le chemin d'exploitation depuis un navigateur est fermé. Les routes elles-mêmes écrivent toujours sur un GET — voir Limites honnêtes.
Exactitude — les défauts qui touchent à l'argent
| Défaut dans 6amMart d'origine | Ce qui a été mesuré |
|---|---|
| Le montant minimum des coupons n'était jamais appliqué | Les admins pouvaient le définir ; le code ne le lisait jamais. Prouvé en production : un coupon exigeant un minimum de ₹999 a été accepté sur une commande de ₹1. Six coupons en production avaient un minimum défini. Désormais appliqué aux trois endroits où une commande peut être valorisée. |
| Les remises étaient jugées avec la mauvaise horloge | La base de données tournait en UTC et l'application à l'heure de l'Inde — mesuré en production à 5h30m d'écart. Une remise du soir de 18:00–22:00 ne s'appliquait jamais le soir et s'activait entre 2 et 3 heures du matin. Pire, l'écran de liste et la commande utilisaient des horloges différentes : une boutique pouvait donc être affichée en promotion et facturée plein tarif. |
| Les quantités de suppléments étaient facturées sur le mauvais supplément | Les quantités étaient associées aux suppléments par position dans une liste, mais l'app du client envoie l'ordre du menu tandis que la base renvoie l'ordre des identifiants internes. Démontré sur le serveur : une commande prévue à ₹270 a été facturée ₹550. Corrigé aux 8 endroits du code qui faisaient cela. |
| Le stock était décrémenté sur le mauvais produit | Un achat en campagne cherchait le produit par identifiant de campagne dans la table des produits. Les trois identifiants de campagne en production existaient aussi comme identifiants de produits. |
| Le contrôle de stock à la commande vérifiait un autre nombre que celui qu'il écrivait | Le contrôle final comparait le stock global du produit ; la décrémentation avait lieu sur le stock de la variante choisie. Mesuré sur des données réelles : 56 produits actifs pour lesquels un achat légitime aurait été refusé, et 1,451 pour lesquels une survente serait passée inaperçue. |
| Un rappel de passerelle répété créditait le paiement deux fois | Déclenché aussi par un client qui rafraîchit la page de retour. Corrigé au niveau du hook pour les 47 passerelles. |
| L'achat immédiat facturait ce que le téléphone envoyait | Plutôt que le panier du serveur. |
| Un retrait pouvait être approuvé deux fois et laisser un portefeuille négatif | Reproduit en production : approuver deux fois créditait le total retiré deux fois et faisait tomber le solde en attente à −50.00. Un bouton retour ou un double-clic suffisait. |
| Les identifiants de commande étaient attribués à la main | Le code lisait l'identifiant de commande le plus élevé et ajoutait un — réimplémentant mal l'auto-incrément, avec des collisions en cas de commandes simultanées. |
| Deux livreurs pouvaient accepter la même commande | Et deux clients pouvaient acheter la dernière unité. Des courses entre lecture et écriture, devenues des réservations atomiques en base, prouvées avec des transactions simultanées. |
Sur les deux comptages que vous verrez cités. Les totaux du projet lui-même classent 4 des failles de sécurité comme critiques et 6 des défauts comme touchant à l'argent, sur 342 corrigés. Ce sont les décomptes publiés, les plus bas, donc ce sont ceux que cette page utilise. Ce ne sont pas des comptages des éléments listés sur cette page : la section sécurité ci-dessus nomme plus de quatre défauts de sécurité et le tableau ci-dessus liste dix défauts touchant à l'argent, parce que nous listons tous ceux que nous avons reproduits, pas seulement ceux qui entrent dans les deux décomptes.
Défauts d'exactitude sans lien avec l'argent qui méritent d'être listés
- Le planificateur n'avait jamais tourné. Cinq tâches de fond planifiées ne s'étaient jamais exécutées depuis le déploiement — l'entrée cron système n'avait jamais été installée.
- Le versement mensuel s'exécutait quatre fois par mois (la planification était écrite « jours 28–31 » au lieu de « dernier jour du mois »).
- L'historique des commandes indiquait chaque boutique comme non notée — 0 étoile partout, alors que la vraie note d'une boutique était de 4.31 sur 29 avis.
- Les livraisons des livreurs ne comptaient jamais dans la popularité des produits — la boucle d'incrément utilisait un nom de propriété qui n'existe pas sur cet enregistrement, donc le bloc ne faisait silencieusement rien, faussant tous les classements « meilleurs produits ».
- Les notifications push étaient silencieusement désactivées — mises en file vers un worker qui pouvait ne pas exister ; rien n'était livré, aucune erreur remontée.
- 34 erreurs serveur dans les panneaux admin et vendeur → zéro.
- Un vendeur sans ligne de boutique faisait tomber 9 des 12 pages de son propre panneau, la connexion web vendeur et la connexion de l'app boutique — un helper partagé renvoyait le premier élément d'une relation vide, ce qui lève une erreur au lieu de renvoyer null. 43 vérifications, dont des assertions appariées confirmant qu'un vendeur légitime passe toujours.
- Un rapport admin n'a jamais fonctionné sur aucune installation de ce logiciel — il se compilait en PHP invalide et échouait toujours. Trouvé en vérifiant les 895 gabarits d'écran ; c'était le seul défectueux.
Ce qui est livré avec l'installation optimisée et que la version d'origine n'a pas
| Capacité | Ce que c'est |
|---|---|
| Suite de vérification automatisée | Des scripts que vous lancez vous-même. Chaque assertion a dû échouer sur l'ancien code avant d'être acceptée — un test qui passe sur un système cassé ne prouve rien. Au rapport du 9 août, les 60 scripts se répartissaient en 55 assertions plus 5 outils de rapport, et les outils de rapport n'affirment rien. Plus 49 tests unitaires et fonctionnels. |
| Preuve de reproductibilité du schéma | La base de données peut être reconstruite à partir du seul code — prouvé en la construisant depuis zéro et en comparant les 184 tables, colonne par colonne et index par index, sans aucune différence. |
| SixPreflight | Un outil de contrôle de préparation du serveur : ~134 vérifications sur le matériel, PHP, la santé de l'application, les permissions, le serveur web, la mise en cache, les réglages de la base de données, l'exposition publique et chaque service externe. Ouvrez-le dans un navigateur avant le lancement et il vous dit ce qui va casser. |
| Manuel de déploiement | Séquences d'installation et de mise à jour documentées, avec les pièges : quelles commandes vident silencieusement le cache de configuration, quels caches ne se reconstruisent pas entre eux, ce que le panneau d'hébergement défait quand vous enregistrez un réglage. |
| Builds iOS | Les trois apps signées et compilées pour Apple comme pour Android — les premiers builds Apple produits pour ce projet. |
| Suivi de commande en direct réellement activé | Le service websocket activé et les deux défauts qui l'empêchaient de fonctionner corrigés ; renouvellement du certificat prouvé. |
Vérifiez vous-même
Vérifiez chaque chiffre vous-même
Ce qu'il y a de plus convaincant sur cette page n'est pas un chiffre. C'est que vous pouvez vérifier chaque chiffre vous-même.
La suite de vérification est livrée avec votre installation. Sur votre propre serveur :
bash tests/Scripts/run-all.sh # les vérificationsphp tests/Scripts/api-smoke.php # parcourt tous les endpoints de l'API1Chaque assertion a dû échouer sur l'ancien code avant d'être acceptée.
Un test qui passe sur un système cassé ne prouve rien.
2Le balayage des endpoints envoie 306 requêtes.
Il rapporte les erreurs serveur et les temps de réponse par endpoint — donc « zéro erreur serveur, zéro endpoint au-dessus de 250 ms » est une chose que vous relancez, pas une chose que vous devez croire sur parole. Lisez le nombre de requêtes rejetées de votre propre série avant de lire les temps ; voir la note d'exploitation ci-dessous.
3La suite comprend les assertions de sécurité.
Pas seulement celles de vitesse : le balayage d'exposition de la racine web, le contrôle de la porte dérobée OTP de démo, le contrôle d'idempotence des hooks de paiement, les gardes entre comptes, les contrôles d'empoisonnement de cache, et un audit des routes GET qui écrivent un état.
4Le contrôle de schéma reconstruit la base de données à partir du seul code.
Il compare les 184 tables avec les vôtres en production.
Note d'exploitation honnête Lancez le balayage des endpoints trop souvent d'affilée et il déclenche le limiteur de débit de la plateforme. Les requêtes ralenties ne font aucun travail en base, donc le total de requêtes baisse et la série paraît plus rapide alors qu'elle ne teste presque rien. Une série valide montre environ 235 requêtes réussies et 66–68 rejetées ; des centaines de rejets veulent dire qu'il faut jeter la série.
Et l'état actuel de la suite, énoncé exactement Le rapport du 9 août faisait état de 60 scripts — 55 assertions plus 5 outils de rapport — et de 49 tests unitaires et fonctionnels. Le dossier est depuis passé à 86 entrées, ce qui inclut des outils de rapport et d'autres fichiers qui ne sont pas des assertions : ce n'est donc pas un décompte de vérifications. La dernière série complète enregistrée en a exécuté 70 : 61 réussies, 2 en échec, 7 ignorées. Les deux échecs sont nommés dans les preuves — deux rapports admin de location qui renvoient une erreur serveur sur des installations sans location, et une correspondance d'actifs manquante — et au moins celui des locations a été corrigé ensuite. Relancez la suite sur votre propre installation et lisez votre propre chiffre.
Limites honnêtes
Ce que cette page ne prétend pas
Une page qui dit « voici ce que nous avons mesuré, voici comment le vérifier, et voici ce que nous n'avons pas résolu » est plus difficile à mettre en doute qu'une page qui n'affiche que ses victoires.
342 défauts ont été trouvés et corrigés. Personne ne peut énumérer ce qui reste.
C'est la forme honnête d'une plateforme de cette taille.
Rien dans ce programme n'a mesuré le travail d'un autre prestataire.
Cette page ne prétend donc rien sur la réalisation de qui que ce soit d'autre. Chaque chiffre ici compare le script d'origine tel qu'il était livré à l'époque à notre code optimisé, sur un seul serveur.
Chaque chiffre de cette page est arrondi en notre défaveur, jamais en notre faveur.
Sur les écrans vus par les clients, l'amélioration mesurée est de 10× à 22×, soit 90 à 95% d'attente en moins — 22× vaut 95.4% et nous affichons 95. Quand une mesure est une plage, le facteur est le plus petit « avant » divisé par le plus grand « après ».
Les chiffres à 10 millions de commandes de cette page sont un test de charge, pas des performances en production.
Ils viennent d'une base de données créée pour l'occasion, chargée de 10,000,000 commandes, 1,000,000 produits et 200,000 clients, exécutée délibérément avec un buffer pool sous-dimensionné de 128 MB pour qu'elle soit limitée par les entrées/sorties comme un vrai serveur sous-dimensionné. L'installation en production auditée contient 3,282 commandes.
Six lignes du test de charge sont encore à une seconde ou plus, et nous publions les onze lignes ci-dessous.
Les badges de répartition sont à 12 s ; popular_products à 7.1 s ; la liste des commandes admin à une pagination profonde à 3.1 s ; le rapport articles à 12.5 s pour un mois et 131 s pour tout l'historique ; la liste des clients admin autour de 1–1.5 s. Le chiffre « tout l'historique » du rapport articles est la pire chose que nous ayons mesurée où que ce soit, et la série d'origine à laquelle il devrait être comparé a été arrêtée à 120 secondes : nous ne pouvons donc même pas revendiquer une amélioration là-dessus — seulement que la nôtre va au bout.
Les requêtes GET qui modifient des réglages sont atténuées, pas éliminées.
Le chemin d'exploitation via un navigateur est fermé et vérifié ; les 64 routes admin et vendeur elles-mêmes écrivent toujours un état sur un GET, et leur conversion en formulaires protégés n'a délibérément pas été tentée, parce que c'est un gros risque de régression sur une plateforme qui fonctionne aujourd'hui sur de nombreux projets dérivés.
Le garde est plus large que la vulnérabilité.
Une liste en lecture seule sans danger est elle aussi refusée si elle arrive sous forme de préchargement ou de chargement d'image, parce que séparer les ~860 adresses en lecture seule du panneau des 64 dangereuses demanderait exactement la liste fragile que nous avons choisi de ne pas écrire. Il existe un interrupteur d'une ligne pour le désactiver.
La limitation de débit est sûre à cause de l'endroit où sont les serveurs, pas parce que les en-têtes ne peuvent pas être falsifiés.
La configuration fait confiance aux en-têtes relayés, ce qui ne tient qu'aussi longtemps que rien ne peut atteindre PHP autrement que par la chaîne de proxys. Une machine joignable directement permettrait à un client de falsifier l'en-tête et d'obtenir un compteur neuf à chaque requête.
La taille de téléchargement des apps a à peine bougé.
Environ 0.7 MB au total, parce que le code inutilisé que nous avons retiré était déjà écarté par le compilateur de publication. Nous ne revendiquons rien sur la taille des apps.
Trois points de l'installation de référence sont ouverts et nommés plutôt que cachés.
Les clés Google Maps ne sont pas restreintes et doivent être verrouillées ; une clé privée Apple Sign-In que l'assistant d'envoi de 6amMart d'origine avait placée dans un stockage public doit être révoquée et réémise ; et trois vendeurs n'ont toujours pas de ligne de boutique — les erreurs 500 que cet état provoquait sont corrigées, mais l'état lui-même reste atteignable parce que les deux chemins d'inscription enregistrent le vendeur et la boutique en dehors d'une transaction unique. Les trois figurent dans le document de remise.
Sur le serveur de référence, la limite est maintenant le matériel, pas le code.
Testé en charge à 20–40 utilisateurs simultanés sans aucune erreur ; à ce niveau, la machine 2 vCPU sature.
Tous ces tests portent sur un seul serveur et un seul jeu de données.
Ils suffisent à dire ce qui a changé sur cette installation. Ce n'est pas une affirmation générale sur chaque déploiement de 6amMart.
6amMart d'origine est un produit commercial largement utilisé.
Les défauts ci-dessus sont énoncés comme des faits, et cela suffit.
Le test de charge, publié en entier — toutes les lignes, y compris les mauvaises
Test de charge — une base de données de 10 millions de commandes créée pour l'occasion, pas du trafic réel.
| Écran | Origine | Optimisé | Toujours lent ? |
|---|---|---|---|
| Liste des commandes admin, première page | 27.4 s | 13.6 ms | |
| Badges de nombre de commandes sur chaque page vendeur | 136 ms | 20 ms | |
| Rapport articles, this_week | arrêté à 120 s | 542 ms | |
| get_stores | 9.8 s | 901 ms | |
| Badges de nombre de commandes sur chaque page admin | 8.5 s | 830 ms | |
| Liste des clients admin, première page | 20.7 s | ~1.0 – 1.5 s | ≥ 1 s |
| Liste des commandes admin, pagination profonde | 100 s | 3.1 s | ≥ 1 s |
| popular_products | 12.8 s | 7.1 s | ≥ 1 s |
| Badges de répartition | 29.8 s | 12 s | ≥ 1 s |
| Rapport articles, this_month | arrêté à 120 s | 12.5 s | ≥ 1 s |
| Rapport articles, all_time | arrêté à 120 s | 131 s (plancher de 365 jours) | ≥ 1 s — notre pire ligne |
Quand deux sources ne s'accordent pas sur une ligne, ce tableau affiche le chiffre le moins flatteur des deux côtés.
Notre propre rapport enregistre la liste des clients admin à ~1.0 s alors que le journal brut du banc d'essai indique 1.5 s : la plage est donc affichée. Le rapport enregistre les badges admin à 8.5 s → 830 ms là où le journal brut lit 57.4 s → 791 ms, et les badges vendeur à 136 ms → 20 ms là où le journal brut lit 270 ms → 13 ms ; dans les deux cas, le plus petit « avant » et le plus grand « après » sont affichés.
Est-ce que cela va me concerner ?
À un volume réaliste de 100,000 commandes — trente fois le volume actuel de l'installation auditée — et avec les fenêtres des badges de commandes désactivées, les neuf écrans profilés à ce volume mesurent tous 250 ms ou moins, et six des neuf 50 ms ou moins : badges vendeur 3.4 ms, get_latest_products 10 ms, liste des clients 31 ms, rapport articles 46 ms, produits populaires 47 ms, liste des boutiques 50 ms, badges de répartition 146 ms, liste des commandes admin 155 ms, badges de la barre latérale admin 179 ms. La fenêtre des badges (ORDER_BADGE_WINDOW_DAYS=60) est un réglage livré, et son activation change ces chiffres : nous précisons donc la condition dans laquelle la mesure a été prise.
FAQ
Les questions que les acheteurs posent vraiment
Douze questions, répondues avec les mêmes chiffres que le reste de la page.
Qu'est-ce que j'achète exactement ?
La même chose qu'AllsWeb a toujours vendue : installation, mise en place et configuration complètes de 6amMart sur votre hébergement — panneau admin, panneau vendeur, APK et AAB Android, build iOS, site web client, votre identité visuelle, SMTP, Google Maps, notifications push et OTP Firebase, connexion sociale, vos passerelles de paiement, votre fichier de langue, et le code source sur un dépôt GitHub privé. Livré en 1–3 jours ouvrés une fois vos informations complètes, avec support à vie gratuit pour les problèmes de mise en place et les petites corrections. Le code optimisé est la façon dont cette installation est construite aujourd'hui.
Est-ce que j'obtiens le même 6amMart ?
Oui — la dernière version de 6amMart, celle que 6amTech livre au moment où nous construisons votre installation. Même panneau admin, même panneau vendeur, mêmes apps client, boutique et livreur, même modèle de données, mêmes fonctionnalités. Chaque changement de performance était conditionné au renvoi de données identiques octet pour octet avant d'être accepté : vos écrans affichent donc ce qu'ils affichaient avant, en plus rapide.
Le code optimisé coûte-t-il plus cher ?
Non. Il n'y a pas de produit séparé, pas de licence séparée et pas de formule premium. Le prix d'installation du catalogue est le prix, et le code optimisé y est compris. Vous achetez et possédez toujours votre propre licence 6amMart sur CodeCanyon.
À quel point est-ce plus rapide, vraiment ?
Sur le serveur en production, avec le CDN contourné : articles en vedette 8.19 s → 0.37 s (22×), catégories principales 3.34 s → 0.27 s (12×), recherche de produits 1.64–1.96 s → 0.09–0.12 s (au moins 13×), page d'accueil de la boutique ~1.47 s → 0.073–0.096 s (au moins 15×). Les facteurs par ligne sont calculés de la façon la moins flatteuse que les mesures permettent. Le chiffre typique sur les écrans vus par les clients est de 10× à 22× plus rapide — 90 à 95% d'attente en moins.
D'où viennent ces chiffres, et sur quel matériel ?
L'« avant » est le script d'origine exactement tel que CodeCanyon le livrait au moment de l'expérience — la note de méthode ci-dessus précise de quel build il s'agissait et pourquoi cette note existe. L'« après » est le même script après le programme, avec la version suivante de l'éditeur appliquée par-dessus. Les deux ont été mesurés sur le même serveur 2 vCPU / 3.9 GB, côté serveur, avec le CDN contourné — pas sur une machine plus grosse, et pas avec un CDN qui fait le travail. Deux lignes du tableau de comparaison ne sont pas des temps serveur et sont signalées comme telles : un nombre d'octets en sortie de build, et une mesure prise depuis un téléphone en données mobiles.
Puis-je vérifier tout cela moi-même, ou dois-je croire la page sur parole ?
Vous pouvez tout vérifier. La suite de vérification est livrée avec votre installation : bash tests/Scripts/run-all.sh lance les vérifications et php tests/Scripts/api-smoke.php parcourt 306 requêtes API et affiche les temps de réponse. Chaque assertion a dû échouer sur l'ancien code avant d'être acceptée, donc un test réussi veut dire quelque chose. Une réserve que nous préférons vous dire plutôt que vous laisser la découvrir : un balayage valide voit environ 66–68 requêtes rejetées par le limiteur de débit de la plateforme, et une série avec des centaines de rejets doit être jetée.
Les mises à jour de 6amTech fonctionneront-elles encore dessus ?
Mécaniquement, oui — cela a déjà été fait. La version suivante de l'éditeur a été appliquée sur le code optimisé, et d'autres travaux ont été livrés après le rapport du 9 août : durcissement du cache, une liste de dépenses reconstruite, et un défaut de clé d'application qui touchait chaque installation construite à partir de la configuration d'exemple de l'éditeur. Le détail honnête, c'est que nos correctifs se trouvent dans les mêmes fichiers que ceux livrés par 6amTech : une version de l'éditeur est donc une fusion que nous réalisons pour vous, pas un écrasement fichier par fichier que vous exécutez vous-même.
Que se passe-t-il quand 6amTech publie la prochaine version de 6amMart ?
Si vous achetez maintenant, vous l'avez — nous installons la version en cours le jour où nous construisons. Pour une installation livrée plus tôt, il se passe la même chose que pour n'importe quel client sur n'importe lequel de nos scripts au catalogue : passer à une version plus récente relève du service de mise à jour standard, à 50% du prix d'installation, parce que la configuration de votre première mise en place est réutilisée. L'appliquer au code optimisé, c'est la fusion décrite dans la réponse précédente, et c'est notre travail, pas le vôtre.
Quels problèmes de sécurité y avait-il réellement dans le script d'origine ?
Reproduits, puis corrigés : injection SQL sans authentification atteignable depuis chaque liste de boutiques ; commandes et adresse de livraison de n'importe quel client lisibles sans se connecter ; passerelles de paiement désactivées dans l'admin mais dont les rappels encaissaient encore ; vendeurs capables de modifier les produits et bannières d'autres vendeurs ; une porte dérobée de connexion démo active (limitée — elle menait à un nouveau compte avec la vérification téléphonique contournée, pas à la prise de contrôle d'un compte existant) ; quatorze chemins du projet lisibles en HTTPS, dont un export de base de données de l'installateur de 679 KB ; chaque facture énumérable par URL ; et une API sans aucune limite de débit — 40 tentatives d'affilée avec un mauvais mot de passe ont toutes été acceptées, sans ralentissement et sans rien de journalisé.
Est-ce que ce sera toujours rapide quand ma boutique grandira ?
Jusqu'à environ 100,000 commandes, oui : neuf écrans profilés à ce volume, fenêtres des badges de commandes désactivées, mesurent tous 250 ms ou moins et six des neuf 50 ms ou moins. C'est trente fois le volume actuel de l'installation auditée. Au-delà, lisez le test de charge dans Limites honnêtes ci-dessus — ce n'est pas que des victoires. À 10,000,000 commandes sur une base sous-dimensionnée, la liste des commandes admin passe de 27.4 s à 13.6 ms, mais les badges de répartition restent à 12 s, les produits populaires à 7.1 s et le rapport articles sur tout l'historique à 131 s. Ce sont des chiffres de test de charge sur une base créée pour l'occasion, pas votre serveur en production.
Affirmez-vous qu'il ne reste aucun défaut ?
Non. 342 défauts ont été trouvés et corrigés. Personne ne peut énumérer ce qui reste dans une plateforme de cette taille. Ce que nous pouvons vous montrer, c'est ce qui a été mesuré, comment le re-mesurer, et quels points restent ouverts — la section Limites honnêtes de cette page les liste, y compris les lignes du test de charge encore lentes et les routes que nous avons atténuées plutôt que réécrites.
Qu'est-ce qui ne vous satisfait toujours pas ?
Plusieurs choses, et nous préférons que vous les lisiez ici. Dans le test de charge à 10 millions de commandes, six lignes sont encore à une seconde ou plus — la pire est le rapport articles sur tout l'historique à 131 secondes, et la série d'origine à laquelle il devrait être comparé a été arrêtée à 120 secondes : nous ne pouvons donc revendiquer aucune amélioration là-dessus ; les badges de répartition sont à 12 secondes. Soixante-quatre routes admin et vendeur modifient toujours un état sur un simple GET — le chemin d'exploitation via un navigateur est fermé et vérifié, mais les routes elles-mêmes n'ont pas été converties. Et sur l'installation de référence, les clés Google Maps ne sont pas restreintes, une clé Apple Sign-In doit être révoquée et réémise, et trois vendeurs n'ont toujours pas de ligne de boutique.
Outils compagnons
Où se situent SixPanel et SixPreflight
Tout ce qui précède porte sur le code de 6amMart lui-même. Deux outils AllsWeb se placent de part et d'autre — l'un fait tourner le serveur sur lequel vit la boutique, l'autre vous dit si un serveur que vous avez déjà est prêt pour elle. Leurs chiffres ont été mesurés à un autre moment sur d'autres machines : nous les gardons donc dans leurs propres tableaux et ne les mélangeons jamais avec les chiffres ci-dessus.
SixPanel
Quand vous voulez que le serveur soit géré
Ce que c'est
Un panneau de gestion qui fait tourner une boutique 6amMart, ou plusieurs, sur un seul VPS loué — MariaDB, Redis, nginx, le service websocket pour le suivi des commandes en direct, et une vitrine Next.js facultative. Deux environnements d'exécution : celui qui est recommandé installe tout directement sur la machine depuis l'archive de distribution de la version elle-même, sous systemd, et SixPanel Docker fait tourner la même pile comme services Docker Compose. Une commande d'installation, un déploiement depuis un zip CodeCanyon ou depuis git, des certificats Let's Encrypt automatiques avec renouvellement automatique, des sauvegardes restic incrémentales planifiées avec rétention, des hôtes virtuels par projet, un réglage automatique du matériel, et un chien de garde auto-réparateur qui redémarre les services qui tournent mais ne fonctionnent pas. Trois surfaces : le panneau dans un navigateur, une commande sixpanel sur l'hôte, et l'installateur. Il est livré avec un manuel client de 24 chapitres, servi dans le panneau.
Mesuré, et publiable sans réserve
| Ce qui a été mesuré | Le chiffre, avec ses conditions |
|---|---|
| Requêtes servies — endpoint de recherche, 20 en simultané, 30 secondes | Un serveur 2 cœurs / 4 GB a traité environ 53 requêtes par seconde sur le catalogue d'une vraie boutique de 66,701 commandes, la base répondant à 99.99% des lectures depuis la mémoire. Cela décrit cet endpoint, ce jeu de données et deux cœurs. Ce n'est pas un chiffre général pour la plateforme. |
| Durée d'installation sans surveillance | 273 – 303 secondes sur les trois systèmes d'exploitation testés — environ cinq minutes |
| Vitesse face à un concurrent optimisé | 1,76× plus rapide qu'un aaPanel entièrement optimisé sur une requête et 1,82× avec quatre à la fois, sur un matériel identique faisant tourner la même boutique de 66 701 commandes — avec environ 60 % de l'écart attribué à une restriction de répertoires PHP, 8 % au mauvais mode JIT, 0 % à la version de PHP, et environ 32 % publié comme inexpliqué |
| Système d'exploitation recommandé | Ubuntu 26.04 LTS, mises à jour de sécurité jusqu'en avril 2031. Ubuntu 24.04 LTS et Debian 13 sont les deux autres versions prises en charge — trois au total, et rien d'autre |
Une chose de plus qui mérite d'être dite, parce que presque personne ne la publie. Nous avons testé trois systèmes d'exploitation sur du matériel identique avec les mêmes données réelles. Ils sont à égalité — l'écart entre eux était plus petit que l'écart d'une machine avec elle-même. Nous avons donc choisi sur la durée de support restante plutôt que sur la vitesse, et nous ne citerons pas une différence de vitesse que nous n'avons pas pu mesurer.
Limites honnêtes — SixPanel
- Les sauvegardes se restaurent sur la même machine. Restaurer sur une autre machine laisse en place le mot de passe de base de données et les chemins de l'ancienne machine, et l'application ne peut pas se connecter tant qu'une mise à jour n'est pas lancée ; de plus, la tâche de restauration n'exécute jamais l'étape de migration de la base, donc un export ancien sous du code plus récent reste en retard sur le schéma. Les deux sont notés comme cassés — notés, pas corrigés — et les deux ont une solution de contournement manuelle.
- Le chien de garde autoréparateur ne voit pas deux des services de la liste de fonctionnalités ci-dessus. Le service websocket et la boutique Next.js optionnelle n'ont pas de contrôle de santé, donc le chien de garde ne les couvre pas. Point ouvert.
- Un retour arrière n'annule pas les migrations de base de données. Un retour arrière du code après une migration nécessite une restauration de sauvegarde.
- Le panneau lit son propre certificat TLS une seule fois au démarrage. La tâche de renouvellement quotidienne recharge nginx mais pas le panneau, donc le panneau doit être redémarré pour prendre en compte un certificat renouvelé.
- Le panneau est équivalent à root sur la machine, par construction — il installe des paquets, écrit de la configuration système et redémarre des services. Sur l'environnement Docker, il monte en plus la socket Docker et monte le répertoire de la pile en écriture.
- Il y a exactement un compte administrateur et aucun rôle. Pas de multi-utilisateur, pas d'équipes.
- Seules des machines de 4 GB ont été mesurées. Rien sur cette page ne décrit 8 GB ou plus.
Quand SixPanel s'applique
Vous louez un VPS et vous préférez ne pas gérer vous-même nginx, le réglage de MariaDB, les certificats, les sauvegardes et les déploiements — ou vous voulez plus d'une boutique sur un seul serveur.
SixPreflight
Quand vous voulez savoir ce qui va casser avant la mise en ligne
Ce que c'est
Un petit outil PHP que vous déposez dans le dossier public/ de votre site Laravel et que vous ouvrez dans un navigateur derrière un mot de passe. Il exécute environ 134 vérifications sur le matériel, PHP, la santé de l'application, le fichier d'environnement, les permissions, le serveur web, la mise en cache, les réglages de la base de données, l'exposition publique et chaque service externe — paiements, e-mail, SMS, cartes, push — en contactant réellement chacun plutôt qu'en lisant un réglage. Il donne une note en lettre, un verdict en clair et une liste de corrections classée par conséquence, avec une valeur prête à coller partout où il y en a une. Vous recevez la version en cours.
Sur l'installation de référence
Il a rapporté 103 réussites, 7 échecs, 24 avertissements — et les échecs étaient des réglages d'hébergement, pas des défauts applicatifs.
Quand SixPreflight s'applique
Sur aaPanel, CloudPanel ou cPanel ? SixPreflight est fait pour vous. Vous utilisez SixPanel ? Ces vérifications sont déjà intégrées à sa page Bilan de la boutique.
Tout recommande désormais le même système d'exploitation, et la raison n'est pas la vitesse. SixPanel, SixPanel Docker et SixPreflight recommandent tous Ubuntu 26.04 LTS. L'environnement natif prend PHP, MariaDB, nginx et Redis dans l'archive de distribution de la version elle-même, et les trois versions prises en charge apportent un ensemble qui fonctionne — 26.04 donne PHP 8.5 et MariaDB 11.8, Debian 13 donne 8.4 et 11.8, Ubuntu 24.04 donne 8.3 et 10.11. Rien de tout cela n'est une recommandation de vitesse : sur six axes mesurés, aucun changement de version n'a produit d'écart digne d'être rapporté, et deux machines identiques au bit près ont divergé de 11,6 % l'une de l'autre. Ce qui décide, c'est la durée de support restante — 26.04 est corrigé jusqu'en avril 2031.
De quoi ai-je besoin ?
| Votre situation | La réponse |
|---|---|
| Vous voulez faire installer 6amMart, ou votre 6amMart actuel est lent ou vous a joué un mauvais tour sur les prix ou les paiements | L'installation optimisée de 6amMart |
| Vous avez un VPS et ne voulez pas gérer vous-même nginx, MariaDB, le SSL, les sauvegardes et les déploiements | SixPanel |
| Vous avez déjà un serveur sur un autre panneau et voulez savoir ce qui va casser avant le lancement | SixPreflight |
Chaque chiffre de cette page a été mesuré sur une installation en production
Et la suite qui l'a mesuré est livrée avec votre build.
Besoin de quelque chose construit sur mesure à la place ? Parlons de votre projet sur mesure