6amMart optimizado: el mismo script, medido y corregido
AllsWeb instala la última versión de 6amMart — el mismo script, el mismo admin, las mismas apps — sobre código que medimos y corregimos. Las pantallas del cliente van de 10× a 22× más rápido que las de fábrica, 342 defectos están cerrados, y una suite que viene con la instalación lo demuestra.
El código optimizado está incluido en el precio de la instalación. No es una mejora, ni un extra, ni un plan superior.
10× – 22×
más rápido en las pantallas que ve el cliente
342
defectos encontrados y corregidos
799
commits en cinco repositorios
1–3 días
de entrega una vez completados los requisitos
¿Estás leyendo esto con un asistente de IA?
Con esto frente a sin esto
Qué cambia el día que abres
6amMart de fábrica a la izquierda, el código que instala AllsWeb a la derecha. Mismo script, mismo panel de administración, mismas apps, misma versión del proveedor — cada cifra medida en el mismo servidor de 4 GB y 2 núcleos con los mismos datos.
La primera pantalla que ve un comprador
De fábrica
La fila de destacados de la pantalla de inicio tarda 8,19 s en cargarse. Suficiente para que alguien en un móvil decida que la app está rota y la cierre.
Optimizado
Esa misma fila carga en 0,37 s — 22× más rápido, medido sin CDN para cronometrar la aplicación y no una caché.
El informe de ingresos de la tienda
De fábrica
Dibujar un informe hace 8.614 consultas distintas a la base de datos y mantiene una conexión abierta todo ese tiempo. Con unos pocos administradores abriéndolo a la vez, la tienda entera se siente mal para todos.
Optimizado
El mismo informe hace 12 consultas. Antes parecía aceptable en pruebas, porque con pocos datos cada una de esas 8.614 consultas es rápida.
El mínimo de compra de un cupón
De fábrica
El panel te deja configurarlo y el código nunca lo lee. Probado en vivo: un cupón que exigía un mínimo de ₹999 se aceptó en un pedido de ₹1, con seis cupones activos configurados así.
Optimizado
Se aplica en los tres lugares donde se puede calcular el precio de un pedido.
Los descuentos de la tarde
De fábrica
La base de datos iba en UTC y la aplicación en hora de India — medidos con 5 h 30 min de diferencia en una instalación en vivo. Un descuento de 18:00–22:00 nunca se aplicaba por la tarde y se activaba a las 2 de la madrugada. El listado y el checkout usaban relojes distintos, así que una tienda podía anunciarse con descuento y cobrar el precio completo.
Optimizado
Un solo reloj, así que el descuento que se muestra es el descuento que se cobra.
Quién puede leer el pedido de un cliente
De fábrica
Más de seis endpoints aceptaban cualquier ID de pedido con un ID de invitado adivinado. Reproducido sin ninguna autenticación: la respuesta traía los artículos, los precios y la dirección de entrega de otro cliente. El endpoint de pago con monedero en la misma ruta tampoco comprobaba el saldo.
Optimizado
Un ámbito de propiedad en cada endpoint afectado, manteniendo el checkout de invitado legítimo en funcionamiento.
Una pasarela de pago que has desactivado
De fábrica
Desactivarla en el panel solo la quitaba de las opciones del cliente. Su URL de callback seguía viva, y muchos callbacks marcan un pedido como pagado con nada más que una palabra de estado en la URL — así que con todas las pasarelas desactivadas, un callback seguía completándose y un cliente podía confirmar su propio pedido sin pagar.
Optimizado
Falla en cerrado, con 102 sondas en todos los prefijos de pasarela confirmando que ninguna se ejecuta estando inactiva.
Lo que te cuesta
De fábrica
6amMart de fábrica es lo que te entrega una instalación normal.
Optimizado
La misma instalación, sobre la última versión de 6amMart. Sin segunda licencia, sin segundo precio, sin nivel de mejora — es simplemente cómo se entrega la instalación.
Qué significa "optimizado" aquí
El mismo 6amMart. Distinto por dentro.
Es el mismo 6amMart — la versión actual, la que 6amTech esté publicando el día que construimos tu instalación. El mismo panel de administración, el mismo panel de vendedor, las mismas apps de cliente, tienda y repartidor, el mismo modelo de datos, las mismas funciones que viste en la demo. No se reemplazó nada y no se renombró nada. Lo que cambió está por dentro: AllsWeb dedicó catorce sesiones de trabajo a medir el script, perfilarlo y corregir lo que las mediciones encontraron — 799 commits en cinco repositorios entre el 13 de julio y el 9 de agosto de 2026, en el backend, el panel de administración, el sitio web y las tres apps. Cada uno de esos cambios tenía que devolver datos idénticos byte a byte antes de ser aceptado. Esto no es un producto distinto que tengas que elegir. Es como instalamos 6amMart ahora.
Lo que estás comprando
- El servicio no cambia
- Instalación, configuración y puesta a punto completas de 6amMart en tu hosting — panel de administración, panel de vendedor, APK + AAB de Android, build de iOS, sitio web del cliente, tu marca, SMTP, Maps, push y OTP de Firebase, inicio de sesión social, tus pasarelas de pago, tu archivo de idioma, y el código personalizado en un repositorio privado de GitHub.
- Entrega
- 1–3 días hábiles una vez que tus requisitos estén completos.
- Soporte de por vida gratis
- Para problemas de configuración y correcciones pequeñas.
- Tu propia licencia de CodeCanyon
- Tú compras y eres dueño de tu licencia de 6amMart en CodeCanyon; nosotros instalamos sobre ella.
El código optimizado está incluido en el precio de instalación. No es una mejora, ni un extra, ni un plan superior.
Por qué el script de fábrica era lento
Una frase y un hallazgo
La base de datos no era lenta. La aplicación le hacía la misma consulta cientos de veces por página.
La parte que casi nadie ha visto
En un endpoint del cliente, una sola petición lanzaba 112 consultas a la base de datos. Ochenta y seis de ellas — el 76% — se lanzaban al convertir el resultado ya listo en JSON para enviarlo, porque los accesores de atributos cargaban de forma perezosa, una vez por fila, al momento de serializar. Siete traían los datos y once los preparaban. Por eso agregar índices por sí solo no habría cambiado nada: el costo no estaba en las consultas que ejecutaba la página.
Ese endpoint ahora lanza 45.
86 ÷ 112 = 76.8%, impreso como 76%. La fuente imprime 77%; que una fuente redondee hacia arriba no autoriza a esta página a redondear hacia arriba.
La comparación medida
Antes y después, en el mismo servidor
La declaración del método
| Condición | Qué era |
|---|---|
| Antes | El script de fábrica exactamente como lo entregó CodeCanyon en el momento del experimento — commit base d92ce004, 8 de julio de 2026 ‡ |
| Después | El mismo script después del programa de optimización y endurecimiento de AllsWeb, con la siguiente versión del proveedor aplicada encima |
| Servidor | La misma máquina en las dos corridas — 2 vCPU, 3.9 GB RAM |
| Método | Medido del lado del servidor, con el CDN evitado |
| Alcance del cambio | 799 commits · 342 correcciones · 171 cambios de velocidad · 37 funciones |
| Regla de aceptación | Cada cambio de rendimiento tenía que devolver datos idénticos byte a byte antes de ser aceptado |
- ‡ Qué se midió. Los números de "antes" se tomaron sobre el script de fábrica tal como CodeCanyon lo entregó el 8 de julio de 2026 — la versión que 6amTech numeró 4.0.1 — y la siguiente versión del proveedor se aplicó encima del código optimizado después. Eso es una afirmación sobre el experimento, para que los números de "antes" se puedan reproducir desde el mismo punto de partida. No es una afirmación sobre lo que recibes: instalamos la versión que 6amTech esté publicando el día que construimos. Entre el 13 y el 15 de agosto de 2026 entró trabajo adicional importante que el informe del 9 de agosto no cubre.
- La regla de aceptación, en una línea. "Más rápido nunca pudo significar distinto."
- Redondeado en nuestra contra. Cuando un valor medido es un rango, los múltiplos aquí se calculan de la forma menos favorable que permiten los números — el "antes" más bajo dividido por el "después" más alto. Nuestro propio informe cita múltiplos del punto medio, que salen más altos.
Nueve filas, todas de antes/después, y no todas son el mismo tipo de medición, así que la tabla dice cuál es cuál. Las filas 1–5 son tiempos de respuesta tomados en el mismo servidor con el CDN evitado. Las filas 6–7 son conteos de consultas a la base de datos por página, donde "CDN evitado" no es una condición con sentido. Las filas 8–9 no son mediciones de servidor y llevan un †. Estas son las filas que un dueño de tienda de verdad siente, no los números más grandes que tenemos.
| # | Qué es | 6amMart de fábrica | Optimizado | Múltiplo |
|---|---|---|---|---|
| 1 | Productos destacados en la pantalla de inicio | 8.19 s | 0.37 s | 22× más rápido |
| 2 | Búsqueda de productos | 1.64 – 1.96 s | 0.09 – 0.12 s | al menos 13× más rápido |
| 3 | Portada del sitio web | ~1.47 s | 0.073 – 0.096 s | al menos 15× más rápido |
| 4 | Categorías principales | 3.34 s | 0.27 s | 12× más rápido |
| 5 | Configuración de la app al iniciarla | 0.53 – 1.15 s | 0.045 s | al menos 11× más rápido |
| 6 | Exportación de ganancias de la tienda — consultas a la base de datos por página | 8,614 | 12 | 717× menos |
| 7 | Listado del catálogo de productos — consultas a la base de datos por página | 557 | 92 | ~6× menos |
| 8 | † Estilos enviados en cada página del sitio — un conteo de bytes de la salida de compilación, no un tiempo de servidor | 921,603 bytes | 12,386 bytes | −98.6% (74× más pequeño) |
| 9 | † Diez peticiones de la app en secuencia — medidas desde un teléfono con datos móviles, no en el servidor | 6,140 ms | 1,876 ms | −69% (3.2× más rápido) |
† Las filas 8 y 9 no son mediciones de servidor. El marco de "mismo servidor, CDN evitado" cubre solo los tiempos de respuesta de las filas 1–5; la cifra de estilos es una salida de compilación y la cifra de las diez peticiones se tomó con datos móviles.
La aritmética, impresa
La fila 6 imprime 717×, no los 718× que escribe nuestro propio informe: 8,614 ÷ 12 = 717.83, y esta página no redondea una cifra hacia arriba a su favor. La fila 9 imprime 3.2× por la misma razón — 6,140 ÷ 1,876 = 3.27. El conteo de bytes de la fila 8 es 921,603 ÷ 12,386 = 74.4, impreso como 74×. El 76% de arriba es 86 ÷ 112 = 76.8%, redondeado en la misma dirección.
Capacidad concurrente, dicha de la única forma que permite la evidencia
En el mismo servidor de 2 vCPU, bajo una rampa de carga contra el endpoint de listado de tiendas, 13× más clientes pueden usarlo a la vez en el mismo servidor. El par de peticiones por segundo que hay detrás no se imprime a propósito: la fuente registra la rampa de carga sin indicar su concurrencia ni su duración, y una cifra de peticiones por segundo que no puede nombrar su endpoint, su concurrencia y su duración no va en esta página. La cifra de SixPanel más abajo tiene las tres, y por eso esa sí se imprime como una tasa.
Dos filas que no son una historia de velocidad
| Qué es | 6amMart de fábrica | Optimizado |
|---|---|---|
| Endpoints que devuelven un error de servidor en una instalación limpia | 3 (tiendas populares, tiendas nuevas, métodos de pago) | 0 — los tres responden ahora en 41–150 ms |
| Avisos de seguridad conocidos en dependencias, contados el 9 de agosto de 2026 | 111 | 0 |
Qué eran realmente esos 111. 110 de ellos eran versiones de axios y vite dentro de cinco archivos package.json de módulos addon cuyos procesos de compilación nunca han funcionado — cuatro apuntan a archivos fuente que no existen en el módulo, y el quinto apunta a dos archivos de cero bytes. Aun así se actualizaron, porque una alerta que decidiste ignorar es una alerta que dejas de leer. El que importaba por sí solo era firebase/php-jwt por debajo de 7.0.0 (CVE-2025-45769), antes registrado como imposible de corregir, ahora en ^7.0.2 y verificado contra las claves reales de Apple, Passport, Firebase y Google.
La fila de avisos es una foto con fecha por una razón: los feeds de avisos se mueven todo el tiempo, y un conteo tomado el 9 de agosto de 2026 es una afirmación sobre ese día, no una propiedad permanente de la instalación. Vuelve a correr la auditoría en tu propia instalación para tener un número actual.
Estado actual, con su salvedad incluida Un barrido de 306 peticiones a endpoints reporta cero errores de servidor y cero endpoints por encima de 250 ms — medido sobre las peticiones que se ejecutaron. En una corrida válida, el propio limitador de peticiones de la plataforma rechaza 66–68 de ellas, alrededor de una quinta parte del barrido, y una petición rechazada no es un resultado de endpoint. El reparto registrado de una corrida válida (~235 exitosas, 66–68 rechazadas) suma unas 302, no 306; no podemos cuadrar las peticiones restantes con las fuentes que tenemos. Córrelo tú mismo y lee tu propio reparto — la sección de verificación de abajo explica cómo.
Causas raíz
Las tres causas que vale la pena nombrar
Son las que hacen creíble la tabla.
La exportación de ganancias pidió lo equivocado 2,867 veces.
Le decía a la base de datos que trajera la tienda de cada transacción a través del pedido, mientras que el código leía la tienda directamente desde la transacción — un vínculo distinto. La instrucción nunca aplicaba, así que las 2,867 filas traían su propia tienda por separado.
Cada página de vendedor dibujaba dos menús de navegación.
Uno oculto por la hoja de estilos, y los dos contando los mismos contadores de pedidos.
Un encabezado de página cargaba todo el historial de pedidos de la tienda.
466 pedidos para la tienda más activa, para llenar una sección de la página que estaba comentada.
Y el hallazgo sobre los índices
Diez de las columnas por las que la base de datos une tablas no tenían ningún índice. Después de indexarlas, una búsqueda pasó de leer 51,074 filas a leer una.
La lista de clientes del admin examinaba 16,092,496,536 filas para devolver 98 — el 82% de todo el tiempo de consultas lentas del servidor, y hasta 18 minutos para cargar una sola página.
Qué se corrigió
Rendimiento, seguridad, exactitud
Rendimiento
Consultas a la base de datos por cada petición — todas verificadas como idénticas byte a byte antes de aceptar el cambio.
API del cliente
| Operación | De fábrica | Optimizado |
|---|---|---|
| Listado del catálogo de productos (31 elementos) | 557 | 92 |
| Lista de pedidos del vendedor (41 pedidos) | 212 | 12 |
| Formato de detalles del pedido (40 filas) | 121 | 4 |
| Historial de pedidos del cliente | 166 | 97 |
| Lista de deseos (6 elementos) | 140 | 37 |
| Listado de tiendas | 78 | 39 |
| Configuración de la app | 54 | 21 |
| Lista de categorías | 43 | 16 |
Paneles de administración y de vendedor
| Pantalla | De fábrica | Optimizado |
|---|---|---|
| Exportación de ganancias de la tienda | 8,614 | 12 |
| Búsqueda de pedidos del admin | 259 | 14 |
| Selector de productos para oferta flash | 186 | 42 |
| Galería de productos | 166 | 48 |
| Lista de proveedores de alquiler | 159 | 9 |
| Desplegable de tiendas en Reels | 127 | 62 |
| Página de detalle del cliente | 106 | 34 |
| Lista de vehículos de alquiler | 94 | 13 |
| Página de ganancias de la tienda | 89 | 13 |
| Cada página de vendedor, antes de su propio contenido | 61 | 52 |
Los paneles de administración y de vendedor nunca se habían medido — las propias pruebas automáticas de 6amMart de fábrica solo cubren la API del cliente. Se perfilaron 586 páginas del admin y 165 del vendedor, contadas en consultas a la base de datos "porque un conteo es exacto y repetible, mientras que un cronómetro en un servidor compartido se desvía".
Sitio web
- De los 921,603 bytes de estilos en cada página, 902 KB eran tres librerías de iconos completas — 21,459 definiciones de iconos enviadas para que el sitio pudiera mostrar 89 iconos. La compilación ahora emite solo los iconos que realmente se usan, y el total de estilos por página es de 12,386 bytes, −98.6%.
- JavaScript compartido 429 kB → 269 kB (−37%).
- La página de inicio era un cascarón vacío hasta que cargaba JavaScript; ahora envía 273,110 bytes renderizados por el servidor.
- Peticiones de configuración: una por vista de página por visitante → una por minuto por idioma.
- La librería de Maps se enviaba a 9 páginas que no muestran ningún mapa.
- Formato de fecha por fila: 8.45 µs → 0.39 µs (21× más barato).
- Las 50 rutas del sitio web mejoraron o se mantuvieron; ninguna creció.
Apps móviles
- Cada petición abría una conexión segura nueva en lugar de reutilizar una — unos 426 ms por petición con datos móviles. Diez peticiones seguidas: 6,140 ms → 1,876 ms.
- Pantalla de inicio: ~30 peticiones por apertura → 1 petición que cubre 14 secciones.
- Una foto de 1000×1000 se decodificaba detrás de un avatar de 40 píxeles; ahora las imágenes se decodifican al tamaño que de verdad se muestra.
- 309 instrucciones de registro de depuración se enviaban dentro de las apps publicadas. Ahora cero.
- GPS del repartidor: 360 → ~30 reportes de posición por hora detenido.
- La pantalla de pedidos del vendedor redibujaba todo cada 10 segundos; ahora solo redibuja cuando los datos cambiaron.
Seguridad — los agujeros concretos encontrados en el script tal como se vende
Nada en esta sección es cuestión de preferencia. Cada punto es un defecto presente en 6amMart de fábrica, y cada uno se reprodujo antes de corregirlo.
Inyección SQL sin autenticación, alcanzable desde cualquier listado de tiendas.
El código del listado de tiendas insertaba las cabeceras de latitud y longitud de la petición, sin filtrar, directamente en el cálculo de distancia en SQL. Alcanzable sin iniciar sesión y sin token. Confirmado que llegaba a la base de datos — un payload inyectado produjo un error de sintaxis de base de datos en el log en vivo. Corregido con parámetros vinculados; se eliminó un segundo punto de inyección que no se usaba.
Los pedidos de cualquier cliente, legibles y editables por cualquiera.
Más de seis endpoints de pedidos aceptaban cualquier ID de pedido junto con un ID de invitado adivinado. Reproducido en vivo: una petición sin ninguna autenticación devolvió los productos, los precios y la dirección de entrega de otro cliente. El endpoint de pago con billetera en la misma ruta no verificaba el saldo. Corregido con un control de propiedad en todos los endpoints afectados, sin romper la compra legítima como invitado.
Pasarelas de pago apagadas que aun así podían liquidar pagos.
Apagar una pasarela en el panel de administración solo la quitaba de las opciones del cliente — sus URLs de callback seguían activas, y muchos callbacks de pasarelas marcan un pedido como pagado con nada más que una palabra de estado en la URL. Con todas las pasarelas apagadas, un callback igual se ejecutaba con éxito, así que un cliente podía confirmar su propio pedido sin pagar. Corregido para que falle cerrado; 102 sondeos sobre cada prefijo de pasarela confirman ahora que ninguna se ejecuta estando inactiva.
Los vendedores podían actuar sobre los datos de otros vendedores.
Cualquier vendedor podía editar o borrar los productos, complementos y banners de otra tienda — incluidos los banners de la pantalla de inicio del propio admin. Responder a una reseña reasignaba esa reseña a la tienda del vendedor que respondía. Corregido limitando cada acción a la tienda propia.
Una puerta trasera de inicio de sesión de demo, activa — y hasta dónde no llegaba.
6amMart trae un atajo de demo para que un revisor de la tienda de apps pueda entrar sin SMS. Lee el número de teléfono y el código desde la configuración, con los valores de demo como respaldo cuando esa configuración no está — y esa configuración deja de estar justo cuando un sitio ejecuta el paso estándar de caché para producción, que toda instalación en vivo hace. En el sitio en vivo, a un número escrito en el código se le entregaba un código válido, sin enviar ningún SMS y sin nada en la configuración que lo pidiera. El impacto tenía un límite, y lo decimos: no existía ninguna cuenta con ese número, así que el camino llevaba a una cuenta nueva con la verificación por teléfono saltada — no a tomar el control de la cuenta existente de nadie. Lo peligroso era el respaldo: un operador que nunca había oído hablar de ese ajuste igual publicaba la puerta trasera. Ahora 28 pruebas automáticas demuestran que no puede existir a menos que se active a propósito.
Toda la carpeta del proyecto se podía leer por HTTPS.
6amMart apunta el servidor web a la carpeta de la aplicación en lugar de a public/, y lo único que lo contiene es una lista de bloqueo escrita a mano. Una lista de bloqueo protege las rutas que a alguien se le ocurrieron; catorce no estaban en ella, cada una confirmada con una petición real — incluidos un volcado de base de datos del instalador de 679 KB, un archivo comprimido de 5.9 MB de la carpeta public, y un archivo PHP que el servidor sí ejecutó, devolviendo una página de error fatal que revelaba las rutas absolutas del servidor. La raíz web se movió a public/; las catorce devuelven ahora 404, y 19 pruebas automáticas lo mantienen así.
La historia del límite de peticiones son tres defectos distintos, no uno.
- 1
La API no tenía ningún límite de peticiones.
La configuración del framework definía un limitador de API de 600 por minuto, pero nada lo aplicaba nunca — el grupo de middleware de la API contenía una sola entrada sin relación y nada más, así que el limitador era configuración muerta. Medido antes del cambio: 40 intentos de inicio de sesión con contraseña incorrecta contra una cuenta, tan rápido como curl pudo hacerlo — 40 rechazos, sin freno, sin demora, nada registrado. Ahora aplican tres límites: un tope de 600/minuto, 10/min en los intentos de autenticación, con clave tanto en la dirección como en la cuenta atacada, y 5/min en las rutas que envían un SMS real. Verificado: 25 contraseñas incorrectas seguidas → 10 rechazos y luego 15 frenadas; una cuenta distinta desde la misma dirección en la misma ventana → sin frenar; 60 peticiones normales de navegación en una ráfaga → todas exitosas.
- 2
Después el limitador usó como clave una identidad que la mitad de la plataforma nunca tiene — y ese lo encontramos nosotros mismos, revisando nuestra propia corrección.
El nuevo limitador usaba como clave al usuario con sesión iniciada, y si no había, la dirección de red. Pero las APIs de vendedor y de repartidor autentican buscando un token bearer en una tabla en vez de usar un guard de autenticación, así que el usuario siempre era nulo y la clave caía en la dirección. Una tienda con personal en una sola conexión de oficina, o repartidores detrás del NAT de una operadora, habrían compartido un único presupuesto de 600/minuto — y la app de entregas consulta cada 10 segundos, así que un turno con mucho movimiento habría empezado a rechazar a gente que estaba trabajando. Ahora la clave cae primero en un hash del token bearer. Verificado: dos llamadas con token de vendedor → 599 y luego 598 restantes en su propio contador; un token de cliente justo después → 599 en un presupuesto aparte; sin token → sigue con clave en la dirección, 600 intacto.
- 3
La plataforma no podía ver al visitante real.
Detrás de un CDN, cada petición llegaba desde la dirección del CDN y la aplicación creía que ese era el visitante — así que el límite de peticiones frenaba a todos los clientes como si fueran uno, las verificaciones antifraude comparaban la dirección equivocada, y cada pedido guardaba una IP de proxy en lugar de la de la persona que lo hizo. Causa raíz: el framework trae el manejo de proxies en su pila global y 6amMart reemplazó esa pila entera, dejándolo fuera, así que configurar los proxies de confianza por sí solo no tenía a qué engancharse. Ahora están las dos mitades, y una petición reenviada se resuelve a la dirección real del cliente. La plataforma ahora ve al visitante real en lugar de tratar a todo internet como un solo usuario.
Una primitiva de envenenamiento de caché.
La caché del listado calculaba su clave a partir de la cadena de consulta de la URL, pero los endpoints leían sus parámetros con un método que prefiere el cuerpo de la petición siempre que la petición declara un tipo de contenido JSON — incluso en un GET. Así que una petición podía pedir un término de búsqueda en la URL y otro distinto en el cuerpo: la clave se calculaba con el primero, la búsqueda corría con el segundo, y las filas equivocadas quedaban guardadas bajo la primera clave y se entregaban a cada cliente real que buscara eso hasta que la entrada expirara. Sin autenticación, y el atacante elegía las dos mitades — qué productos veía un comprador, de qué tienda y a qué precios. Las peticiones cuya entrada la clave no puede ver ahora se responden completamente fuera de la caché.
También cerrados
Cualquiera que supiera contar podía descargar cualquier factura.
Las facturas de pedidos, suscripciones y viajes se podían enumerar por URL.
XSS almacenado, del vendedor al admin.
Las descripciones de producto escritas por vendedores se renderizaban como HTML sin filtrar en 8 pantallas del admin y del vendedor, así que un vendedor podía ejecutar scripts en el navegador del admin. Saneado, y probado contra 25,726 descripciones de producto reales sin ningún cambio en el texto visible.
Reenvío de callbacks de pago.
Los callbacks no eran idempotentes, así que un callback repetido acreditaba dos veces al cliente. Corregido a nivel de hook en las 47 pasarelas.
Una redirección abierta en la ruta de redirección a la app.
Una forma de phishing en tu propio dominio. Corregido, y corregido otra vez cuando en la revisión se encontró un bypass con barra invertida; ahora lo protege una prueba de 17 casos.
Dos rutas de depuración públicas.
Una ejecutaba un comando de borrado de caché sin autenticación, la otra era un relé de imágenes abierto. Las dos eliminadas.
laravel.log descargable desde internet.
Con el usuario de la base de datos, el SQL fallido con sus parámetros y las rutas completas del servidor.
Una misma clave de aplicación enviada a todas las instalaciones.
El archivo de entorno de ejemplo traía una clave real; un archivo de entorno nuevo la copia, y el paso de generación de clave solo se dispara con un valor vacío, así que se saltaba — cada instalación hecha así corría con la misma clave, impresa dentro de cada copia del producto.
Peticiones GET que cambian ajustes — mitigadas, y dicho con precisión.
En 6amMart de fábrica, cambiar un ajuste es un enlace común, así que 64 rutas GET del admin y del vendedor escriben estado. Un crawler, una vista previa de enlace, una etiqueta de imagen o una petición en segundo plano pueden cambiar ajustes mientras un admin tiene la sesión abierta. Esto no es teórico: el 1 de agosto nuestro propio perfilador de rendimiento pidió esas direcciones mientras medía la velocidad de las páginas y cambió 8 ajustes en vivo en 45 segundos — la dirección del texto del panel se invirtió, la página de inicio se apagó, un vendedor quedó deshabilitado. Restaurado y verificado dentro de la hora. La corrección que se entrega es un único guard registrado una sola vez que lee las cabeceras Fetch Metadata del navegador — que dicen por qué se hizo una petición y no las puede falsificar el JavaScript de un atacante — y rechaza las formas que nunca son un clic humano. Verificado en vivo: cargar una dirección de ajustes con una etiqueta de imagen se rechaza; una precarga se rechaza; una petición en segundo plano desde otro sitio se rechaza; un administrador real haciendo clic funciona; las 338 peticiones en segundo plano del propio panel funcionan; los navegadores viejos que no envían esas cabeceras funcionan. 102 páginas reales del panel se renderizan idénticas byte a byte con el guard encendido y apagado, y 53 pruebas automáticas lo cubren. Un solo registro cubre 1,348 rutas, incluidos los módulos que declaran sus propios grupos de rutas.
El camino de explotación desde un navegador está cerrado. Las rutas en sí siguen escribiendo con GET — ver Límites honestos.
Exactitud — los defectos que cuestan dinero
| Defecto en 6amMart de fábrica | Qué se midió |
|---|---|
| El monto mínimo del cupón nunca se aplicaba | Los admins podían configurarlo; el código nunca lo leía. Probado en vivo: un cupón que exigía un mínimo de ₹999 se aceptó en un pedido de ₹1. Seis cupones activos tenían mínimos configurados. Ahora se aplica en los tres lugares donde se puede calcular el precio de un pedido. |
| Los descuentos se juzgaban con el reloj equivocado | La base de datos corría en UTC y la aplicación en hora de India — medidos en vivo con 5h30m de diferencia. Un descuento de noche de 18:00–22:00 nunca coincidía durante la noche y se activaba a las 2–3 de la madrugada. Peor aún, la pantalla de listado y el checkout usaban relojes distintos, así que una tienda podía anunciarse con descuento y cobrar el precio completo. |
| Las cantidades de complementos se cobraban al complemento equivocado | Las cantidades se emparejaban con los complementos por su posición en una lista, pero la app del cliente envía el orden del menú mientras que la base de datos devuelve el orden por ID interno. Demostrado en el servidor: un pedido pensado en ₹270 se cobró en ₹550. Corregido en los 8 lugares del código que hacían esto. |
| El inventario se descontaba del producto equivocado | Una compra de campaña buscaba el producto por el ID de campaña en la tabla de productos. Los tres IDs de campaña activos también existían como IDs de producto. |
| La verificación de inventario en el checkout revisaba un número distinto del que escribía | La verificación final comparaba el inventario general del producto; el descuento ocurría sobre el inventario de la variación elegida. Medido con datos reales: 56 productos activos donde se rechazaría una compra legítima, y 1,451 donde una sobreventa pasaría sin detectarse. |
| Un callback repetido de la pasarela acreditaba el pago dos veces | También se disparaba si el cliente recargaba la página de retorno. Corregido a nivel de hook en las 47 pasarelas. |
| El checkout de compra inmediata cobraba lo que enviara el teléfono | En lugar del carrito del servidor. |
| Un retiro se podía aprobar dos veces y dejar la billetera en negativo | Reproducido en vivo: aprobar dos veces acreditaba el total retirado dos veces y llevaba el saldo pendiente a −50.00. Bastaba con el botón de atrás o un doble clic. |
| Los IDs de pedido se asignaban a mano | El código leía el ID de pedido más alto existente y le sumaba uno — reimplementando mal el auto-incremento, y chocando cuando había pagos simultáneos. |
| Dos repartidores podían aceptar el mismo pedido | Y dos clientes podían comprar la última unidad. Condiciones de carrera de verificar-y-después-escribir, ahora reclamos atómicos en la base de datos, probados con transacciones concurrentes. |
Sobre las dos cifras que verás citadas. Los totales del propio proyecto califican 4 de los agujeros de seguridad como críticos y 6 de los defectos como que afectan al dinero, de 342 corregidos. Esos son los conteos publicados más bajos, así que son los que usa esta página. No son conteos de los elementos listados en esta página: la sección de seguridad de arriba nombra más de cuatro defectos de seguridad y la tabla de arriba lista diez defectos de dinero, porque listamos cada uno que reprodujimos, no solo los que entran en esos dos conteos.
Fallas de exactitud sin dinero de por medio que vale la pena listar
- El programador de tareas nunca había corrido. Cinco tareas de fondo programadas nunca se habían ejecutado ni una vez desde el despliegue — la entrada de cron del sistema nunca se instaló.
- La tarea mensual de liquidación corría cuatro veces al mes (la programación estaba escrita como "días 28–31" en vez de "último día del mes").
- El historial de pedidos reportaba todas las tiendas como sin calificar — 0 estrellas en todas partes, mientras que la calificación real de una tienda era 4.31 con 29 reseñas.
- Las entregas de los repartidores nunca contaban para la popularidad de los productos — el bucle de incremento usaba un nombre de propiedad que no existe en ese registro, así que el bloque no hacía nada en silencio, distorsionando todos los rankings de "productos más populares".
- Las notificaciones push estaban desactivadas en silencio — encoladas a un worker que podía no existir; nada se entregaba, ningún error se levantaba.
- 34 errores de servidor en los paneles de administración y de vendedor → cero.
- Un vendedor sin fila de tienda tumbaba 9 de las 12 páginas de su propio panel, el inicio de sesión web del vendedor y el inicio de sesión de la app de tienda — un helper compartido devolvía el primer elemento de una relación vacía, lo que lanza un error en vez de devolver nulo. 43 comprobaciones, incluidas aserciones emparejadas de que un vendedor legítimo sigue pasando.
- Un informe del admin nunca ha funcionado en ninguna instalación de este software — compilaba a PHP inválido y siempre fallaba. Se encontró revisando las 895 plantillas de pantalla; era la única defectuosa.
Lo que trae la instalación optimizada y la de fábrica no
| Capacidad | Qué es |
|---|---|
| Suite de verificación automatizada | Scripts que corres tú mismo. Se demostró que cada aserción fallaba contra el código viejo antes de aceptarla — una prueba que pasa en un sistema roto no demuestra nada. En el informe del 9 de agosto, los 60 scripts eran 55 aserciones más 5 herramientas de reporte, y las herramientas de reporte no afirman nada. Más 49 pruebas unitarias y de funcionalidad. |
| Prueba de reproducibilidad del esquema | La base de datos se puede reconstruir solo desde el código — probado construyéndola desde cero y comparando las 184 tablas, columna por columna e índice por índice, sin diferencias. |
| SixPreflight | Una herramienta que revisa si el servidor está listo: ~134 comprobaciones sobre hardware, PHP, salud de la aplicación, permisos, servidor web, caché, ajustes de base de datos, exposición pública y cada servicio externo. Ábrela en un navegador antes de lanzar y te dice qué se va a romper. |
| Manual de despliegue | Secuencias de instalación y actualización documentadas, más las trampas: qué comandos borran la caché de configuración en silencio, qué cachés no se reconstruyen entre sí, qué deshace el panel de hosting cuando guardas un ajuste. |
| Builds de iOS | Las tres apps firmadas y compilando para Apple además de Android — las primeras builds de Apple producidas para este proyecto. |
| Seguimiento de pedidos en vivo realmente encendido | El servicio de websocket encendido y los dos defectos que lo mantenían apagado corregidos; renovación de certificado probada. |
Compruébalo tú mismo
Comprueba cada número tú mismo
Lo más convincente de esta página no es un número. Es que puedes comprobar cada número tú mismo.
La suite de verificación viene con tu instalación. En tu propio servidor:
bash tests/Scripts/run-all.sh # las comprobaciones de verificaciónphp tests/Scripts/api-smoke.php # barre todos los endpoints de la API1Se demostró que cada aserción fallaba contra el código viejo antes de aceptarla.
Una prueba que pasa en un sistema roto no demuestra nada.
2El barrido de endpoints lanza 306 peticiones.
Reporta errores de servidor y tiempos de respuesta por endpoint — así que "cero errores de servidor, cero endpoints por encima de 250 ms" es algo que vuelves a correr, no algo que nos tienes que creer. Lee el conteo de rechazadas en tu propia corrida antes de leer los tiempos; mira la nota de operación de abajo.
3La suite incluye las aserciones de seguridad.
No solo las de velocidad: el barrido de exposición de la raíz web, la comprobación de la puerta trasera del OTP de demo, la comprobación de idempotencia del hook de pagos, los controles entre cuentas, las comprobaciones de envenenamiento de caché, y una auditoría de qué rutas GET escriben estado.
4La comprobación del esquema reconstruye la base de datos solo desde el código.
Compara las 184 tablas contra la tuya en vivo.
Nota honesta de operación Si corres el barrido de endpoints demasiadas veces seguidas, activas el propio limitador de peticiones de la plataforma. Las peticiones frenadas no hacen trabajo de base de datos, así que el total de consultas baja y la corrida parece más rápida mientras casi no prueba nada. Una corrida válida muestra unas 235 peticiones exitosas y 66–68 rechazadas; cientos de rechazadas significa descartar la corrida.
Y el estado actual de la suite, dicho con exactitud El informe del 9 de agosto registró 60 scripts — 55 aserciones más 5 herramientas de reporte — y 49 pruebas unitarias y de funcionalidad. Desde entonces el directorio creció a 86 entradas, que incluyen herramientas de reporte y otros archivos que no son aserciones, así que no es un conteo de comprobaciones. La última corrida completa registrada ejecutó 70 de ellas: 61 pasan, 2 fallan, 7 se saltan. Los dos fallos están nombrados en la evidencia — dos informes de alquiler del admin que devuelven un error de servidor en instalaciones sin alquileres, y un mapeo de assets que falta — y al menos el de alquiler se corrigió después. Vuelve a correr la suite en tu propia instalación y lee tu propio número.
Límites honestos
Lo que esta página no afirma
Una página que dice "esto es lo que medimos, así se comprueba, y esto es lo que no hemos resuelto" es más difícil de no creer que una que solo imprime sus logros.
Se encontraron y corrigieron 342 defectos. Nadie puede enumerar lo que queda.
Esa es la forma honesta de una plataforma de este tamaño.
Nada en este programa midió el trabajo de ningún otro proveedor.
Así que esta página no afirma nada sobre la instalación de nadie más. Cada número aquí es el script de fábrica tal como se entregaba en ese momento contra nuestro código optimizado, en un solo servidor.
Cada cifra de esta página está redondeada en nuestra contra, nunca a nuestro favor.
En las pantallas que ve el cliente, la mejora medida es de 10× a 22×, que es de 90 a 95% menos espera — 22× es 95.4% y nosotros imprimimos 95. Cuando una medición es un rango, el múltiplo es el "antes" más bajo sobre el "después" más alto.
Las cifras de 10 millones de pedidos de esta página son una prueba de escala, no rendimiento en vivo.
Vienen de una base de datos creada a propósito con 10,000,000 de pedidos, 1,000,000 de productos y 200,000 clientes, corrida deliberadamente contra un buffer pool subdimensionado de 128 MB para que quede limitada por I/O como un servidor real con pocos recursos. La instalación de producción auditada tiene 3,282 pedidos.
Seis filas de la prueba de escala siguen en un segundo o más, y abajo imprimimos las once filas.
Los contadores de despacho están en 12 s; popular_products en 7.1 s; la lista de pedidos del admin en una página muy avanzada, 3.1 s; el informe de artículos, 12.5 s para un mes y 131 s para todo el histórico; la lista de clientes del admin, alrededor de 1–1.5 s. La cifra de todo el histórico del informe de artículos es lo peor que medimos en cualquier parte, y la corrida de fábrica con la que debería compararse se cortó a los 120 segundos, así que ahí ni siquiera podemos afirmar una mejora — solo que la nuestra termina.
Las peticiones GET que cambian ajustes están mitigadas, no eliminadas.
El camino de explotación desde el navegador está cerrado y verificado; las 64 rutas del admin y del vendedor en sí siguen escribiendo estado con un GET, y convertirlas en formularios protegidos no se intentó a propósito, porque es un riesgo grande de regresión en una plataforma que hoy funciona en muchos proyectos derivados.
El guard es más amplio que la vulnerabilidad.
Un listado inofensivo de solo lectura también se rechaza si llega como precarga o como carga de imagen, porque separar las ~860 direcciones de solo lectura del panel de las 64 peligrosas exige justamente esa lista frágil que decidimos no escribir. Hay un interruptor de una línea para apagarlo.
El límite de peticiones es seguro por dónde están los servidores, no porque las cabeceras no se puedan falsificar.
La configuración confía en las cabeceras reenviadas, lo que se sostiene solo mientras nada pueda llegar a PHP salvo por la cadena de proxies. Una máquina alcanzable de forma directa dejaría que un cliente falsificara la cabecera y obtuviera un cupo nuevo en cada petición.
El tamaño de descarga de la app casi no cambió.
Unos 0.7 MB en total, porque el código sin usar que quitamos ya lo descartaba el compilador de la versión final. No hacemos ninguna afirmación sobre el tamaño de la app.
Tres puntos de la instalación de referencia están abiertos y nombrados en vez de escondidos.
Las claves de Google Maps no tienen restricciones y hay que asegurarlas; una clave privada de Apple Sign-In que el propio ayudante de subida de 6amMart de fábrica había puesto en almacenamiento público hay que revocarla y volver a emitirla; y tres vendedores siguen sin fila de tienda — los errores 500 que ese estado causaba están corregidos, pero el estado en sí sigue siendo alcanzable porque los dos caminos de registro guardan el vendedor y la tienda fuera de una sola transacción. Los tres están en el documento de entrega.
En el servidor de referencia, ahora el límite es el hardware, no el código.
Probado con carga de 20–40 usuarios concurrentes sin ningún error; en ese punto la máquina de 2 vCPU se satura.
Todos estos benchmarks son un servidor y un conjunto de datos.
Alcanzan para decir qué cambió en esta instalación. No son una afirmación general sobre cada despliegue de 6amMart.
6amMart de fábrica es un producto comercial muy usado.
Los defectos de arriba se enuncian como hechos, y con eso basta.
La prueba de escala, impresa completa — todas las filas, incluidas las malas
Prueba de escala — una base de datos creada a propósito con 10 millones de pedidos, no tráfico real.
| Pantalla | De fábrica | Optimizado | ¿Sigue lento? |
|---|---|---|---|
| Lista de pedidos del admin, primera página | 27.4 s | 13.6 ms | |
| Contadores de pedidos en cada página de vendedor | 136 ms | 20 ms | |
| Informe de artículos, this_week | cortado a los 120 s | 542 ms | |
| get_stores | 9.8 s | 901 ms | |
| Contadores de pedidos en cada página del admin | 8.5 s | 830 ms | |
| Lista de clientes del admin, primera página | 20.7 s | ~1.0 – 1.5 s | ≥ 1 s |
| Lista de pedidos del admin, página muy avanzada | 100 s | 3.1 s | ≥ 1 s |
| popular_products | 12.8 s | 7.1 s | ≥ 1 s |
| Contadores de despacho | 29.8 s | 12 s | ≥ 1 s |
| Informe de artículos, this_month | cortado a los 120 s | 12.5 s | ≥ 1 s |
| Informe de artículos, all_time | cortado a los 120 s | 131 s (piso de 365 días) | ≥ 1 s — la peor fila que tenemos |
Cuando dos fuentes no coinciden en una fila, esta tabla imprime el número menos favorable de los dos lados.
Nuestro propio informe registra la lista de clientes del admin en ~1.0 s mientras que el log crudo del arnés de pruebas registra 1.5 s, así que se imprime el rango. El informe registra los contadores del admin en 8.5 s → 830 ms donde el log crudo dice 57.4 s → 791 ms, y los contadores del vendedor en 136 ms → 20 ms donde el log crudo dice 270 ms → 13 ms; en los dos casos se imprime el "antes" más chico y el "después" más grande.
¿Esto me va a importar a mí?
Con 100,000 pedidos, que es una cifra realista — treinta veces el volumen actual de la instalación auditada — y con las ventanas de los contadores de pedidos apagadas, las nueve pantallas perfiladas a ese volumen miden 250 ms o menos, y seis de las nueve 50 ms o menos: contadores del vendedor 3.4 ms, get_latest_products 10 ms, lista de clientes 31 ms, informe de artículos 46 ms, productos populares 47 ms, listado de tiendas 50 ms, contadores de despacho 146 ms, lista de pedidos del admin 155 ms, contadores de la barra lateral del admin 179 ms. La ventana de los contadores (ORDER_BADGE_WINDOW_DAYS=60) es un ajuste que viene incluido, y que esté encendida o no cambia estos números, así que decimos bajo qué condición se tomó la medición.
Preguntas frecuentes
Preguntas que los compradores hacen de verdad
Doce preguntas, respondidas con los mismos números que el resto de la página.
¿Qué estoy comprando en realidad?
Lo mismo que AllsWeb ha vendido siempre: instalación, configuración y puesta a punto completas de 6amMart en tu hosting — panel de administración, panel de vendedor, APK y AAB de Android, build de iOS, sitio web del cliente, tu marca, SMTP, Google Maps, push y OTP de Firebase, inicio de sesión social, tus pasarelas de pago, tu archivo de idioma, y el código en un repositorio privado de GitHub. Entregado en 1–3 días hábiles una vez que tus requisitos estén completos, con soporte de por vida gratis para problemas de configuración y correcciones pequeñas. El código optimizado es la forma en que se construye esa instalación ahora.
¿Recibo el mismo 6amMart?
Sí — la última versión de 6amMart, la que 6amTech esté publicando cuando construyamos tu instalación. El mismo panel de administración, el mismo panel de vendedor, las mismas apps de cliente, tienda y repartidor, el mismo modelo de datos, las mismas funciones. Cada cambio de rendimiento tenía que devolver datos idénticos byte a byte para ser aceptado, así que tus pantallas muestran lo mismo que mostraban antes, pero más rápido.
¿El código optimizado cuesta más?
No. No hay un producto aparte, ni una licencia aparte, ni un plan premium. El precio de instalación del catálogo es el precio, y el código optimizado está incluido en él. Tú sigues comprando y siendo dueño de tu licencia de 6amMart en CodeCanyon.
¿Cuánto más rápido es, de verdad?
En el servidor en vivo, con el CDN evitado: productos destacados 8.19 s → 0.37 s (22×), categorías principales 3.34 s → 0.27 s (12×), búsqueda de productos 1.64–1.96 s → 0.09–0.12 s (al menos 13×), la portada del sitio web ~1.47 s → 0.073–0.096 s (al menos 15×). Los múltiplos de cada fila se calculan de la forma menos favorable que permiten las mediciones. La cifra típica en las pantallas que ve el cliente es de 10× a 22× más rápido — de 90 a 95% menos espera.
¿De dónde salen esos números y en qué hardware?
El "antes" es el script de fábrica exactamente como lo entregó CodeCanyon en el momento del experimento — la nota de método de arriba indica al pie qué build era y por qué está esa nota. El "después" es el mismo script después del programa, con la siguiente versión del proveedor aplicada encima. Los dos se midieron en el mismo servidor de 2 vCPU / 3.9 GB, del lado del servidor, con el CDN evitado — no en una máquina más grande, y no con un CDN haciendo el trabajo. Dos filas de la tabla de comparación no son tiempos de servidor y están marcadas como tales: un conteo de bytes de la salida de compilación, y una medición desde un teléfono con datos móviles.
¿Puedo verificar algo de esto yo mismo, o tengo que confiar en la página?
Puedes verificarlo todo. La suite de verificación viene con tu instalación: bash tests/Scripts/run-all.sh corre las comprobaciones y php tests/Scripts/api-smoke.php barre 306 peticiones de la API e imprime los tiempos de respuesta. Se demostró que cada aserción fallaba contra el código viejo antes de aceptarla, así que que pase significa algo. Una salvedad que preferimos decirte a que la descubras: un barrido válido tiene unas 66–68 peticiones rechazadas por el propio limitador de peticiones de la plataforma, y una corrida con cientos de rechazadas hay que descartarla.
¿Las actualizaciones del propio 6amTech seguirán funcionando sobre esto?
Mecánicamente, sí — ya se hizo. La siguiente versión del proveedor se aplicó encima del código optimizado, y después del informe del 9 de agosto entró más trabajo: endurecimiento de la caché, un listado de gastos reconstruido, y un defecto de clave de aplicación que afectaba a toda instalación hecha desde la configuración de ejemplo del proveedor. El detalle honesto es que nuestras correcciones están en los mismos archivos que entrega 6amTech, así que una versión del proveedor es una fusión que hacemos nosotros por ti, no una sobrescritura archivo por archivo que corras tú.
¿Qué pasa cuando 6amTech publica la siguiente versión de 6amMart?
Si estás comprando ahora, la recibes — instalamos lo que sea actual el día que construimos. Para una instalación que entregamos antes, pasa lo mismo que con cualquier cliente en cualquiera de los scripts de nuestro catálogo: pasar a una versión más nueva es el servicio estándar de actualización al 50% del precio de instalación, porque se reutiliza la configuración de tu primera puesta a punto. Aplicarla al código optimizado es la fusión que se describe en la respuesta anterior, y es trabajo nuestro, no tuyo.
¿Qué problemas de seguridad había realmente en el script de fábrica?
Reproducidos y después corregidos: inyección SQL sin autenticación alcanzable desde cualquier listado de tiendas; los pedidos y la dirección de entrega de cualquier cliente legibles sin iniciar sesión; pasarelas de pago apagadas en el admin pero cuyos callbacks seguían liquidando pagos; vendedores capaces de editar los productos y banners de otros vendedores; una puerta trasera de inicio de sesión de demo activa (con un límite — llevaba a una cuenta nueva con la verificación por teléfono saltada, no a tomar el control de una existente); catorce rutas del proyecto legibles por HTTPS, incluido un volcado de base de datos del instalador de 679 KB; cada factura enumerable por URL; y una API sin ningún límite de peticiones — 40 intentos seguidos con contraseña incorrecta fueron todos aceptados, sin freno y sin nada registrado.
¿Seguirá siendo rápido cuando mi tienda crezca?
Hasta unos 100,000 pedidos, sí: nueve pantallas perfiladas a ese volumen, con las ventanas de los contadores de pedidos apagadas, todas miden 250 ms o menos y seis de las nueve 50 ms o menos. Eso es treinta veces el volumen actual de la instalación auditada. Más allá de eso, lee la prueba de escala en Límites honestos, arriba — no todo son victorias. Con 10,000,000 de pedidos contra una base de datos subdimensionada, la lista de pedidos del admin pasa de 27.4 s a 13.6 ms, pero los contadores de despacho siguen en 12 s, los productos populares en 7.1 s y el informe de artículos de todo el histórico en 131 s. Esos son números de prueba de escala en una base de datos creada a propósito, no tu servidor en vivo.
¿Afirman que no queda ningún defecto?
No. Se encontraron y corrigieron 342 defectos. Nadie puede enumerar lo que queda en una plataforma de este tamaño. Lo que sí podemos mostrarte es qué se midió, cómo volver a medirlo, y qué puntos siguen abiertos — la sección de Límites honestos de esta página los lista, incluidas las filas de la prueba de escala que siguen lentas y las rutas que mitigamos en vez de reescribir.
¿Con qué siguen sin estar conformes?
Con varias cosas, y preferimos que las leas aquí. En la prueba de escala de 10 millones de pedidos, seis filas siguen en un segundo o más — la peor es el informe de artículos de todo el histórico con 131 segundos, y la corrida de fábrica con la que debería compararse se cortó a los 120 segundos, así que ahí no podemos afirmar ninguna mejora; los contadores de despacho están en 12 segundos. Sesenta y cuatro rutas del admin y del vendedor siguen cambiando estado con un GET simple — el camino de explotación desde el navegador está cerrado y verificado, pero las rutas en sí no se han convertido. Y en la instalación de referencia las claves de Google Maps no tienen restricciones, una clave de Apple Sign-In hay que revocarla y volver a emitirla, y tres vendedores siguen sin fila de tienda.
Herramientas complementarias
Dónde encajan SixPanel y SixPreflight
Todo lo de arriba es sobre el código de 6amMart en sí. Dos herramientas de AllsWeb están a cada lado — una opera el servidor donde vive la tienda, la otra te dice si un servidor que ya tienes está listo para ella. Sus números se midieron en otro momento y en máquinas distintas, así que los mantenemos en sus propias tablas y nunca los mezclamos con los números de arriba.
SixPanel
Cuando quieres que alguien administre el servidor
Qué es
Un panel de gestión que corre una tienda 6amMart, o varias, en un VPS alquilado — MariaDB, Redis, nginx, el servicio websocket para el seguimiento de pedidos en vivo y un storefront Next.js opcional. Dos runtimes: el recomendado instala todo directamente en la máquina desde el propio archivo de la distribución del release bajo systemd, y SixPanel Docker corre el mismo stack como servicios de Docker Compose. Un comando de instalación, despliegue desde un zip de CodeCanyon o desde git, certificados Let's Encrypt automáticos con renovación automática, backups incrementales restic programados con retención, hosts virtuales por proyecto, autotuning del hardware y un watchdog que se autorrepara y reinicia los servicios que están corriendo pero no funcionan. Tres superficies: el panel en un navegador, un comando sixpanel en el host y el instalador. Incluye un manual de cliente de 24 capítulos, servido dentro del panel.
Medido, y seguro de publicar
| Qué se midió | La cifra, con sus condiciones |
|---|---|
| Peticiones atendidas — endpoint de búsqueda, 20 concurrentes, 30 segundos | Un servidor de 2 núcleos / 4 GB completó unas 53 peticiones por segundo sobre el catálogo real de una tienda con 66,701 pedidos, con la base de datos respondiendo el 99.99% de las lecturas desde memoria. Esto describe ese endpoint, ese conjunto de datos y dos núcleos. No es una cifra general de la plataforma. |
| Tiempo de instalación desatendida | 273 – 303 segundos en los tres sistemas operativos probados — unos cinco minutos |
| Velocidad frente a un rival ajustado | 1,76× más rápido que un aaPanel completamente ajustado con una petición y 1,82× con cuatro a la vez, en hardware idéntico ejecutando la misma tienda de 66.701 pedidos — con alrededor del 60 % de la diferencia atribuida a una restricción de directorios de PHP, un 8 % al modo JIT equivocado, un 0 % a la versión de PHP y alrededor del 32 % publicado como no explicado |
| Sistema operativo recomendado | Ubuntu 26.04 LTS, actualizaciones de seguridad hasta abril de 2031. Ubuntu 24.04 LTS y Debian 13 son los otros dos releases soportados — tres en total, y nada más |
Una cosa más que vale la pena decir, porque casi nadie la publica. Medimos tres sistemas operativos en hardware idéntico y con los mismos datos reales. Empataron — la diferencia entre ellos fue menor que la diferencia de una misma máquina consigo misma. Así que elegimos por el tiempo de soporte que le queda a cada uno y no por velocidad, y no vamos a citar una diferencia de velocidad que no pudimos medir.
Límites honestos — SixPanel
- Los respaldos se restauran en la misma máquina. Restaurar en una máquina distinta deja atrás la contraseña de base de datos y las rutas de la máquina vieja, y la aplicación no puede conectarse hasta correr un Update; y la tarea de restauración nunca ejecuta el paso de migración de la base de datos, así que un volcado viejo bajo código nuevo queda atrasado respecto del esquema. Los dos están registrados como rotos — registrados, no corregidos — y los dos tienen una solución manual.
- El watchdog de auto-reparación no puede ver dos de los servicios de la lista de funciones de arriba. El servicio de websocket y la tienda web opcional en Next.js no tienen healthcheck, así que el watchdog no los cubre. Punto abierto.
- Un rollback no revierte las migraciones de la base de datos. Un rollback de código después de una migración necesita restaurar un respaldo.
- El panel lee su propio certificado TLS una sola vez al arrancar. La tarea diaria de renovación recarga nginx pero no el panel, así que el panel necesita reiniciarse para tomar un certificado renovado.
- El panel es equivalente a root en la máquina por construcción — instala paquetes, escribe configuración del sistema y reinicia servicios. En el entorno Docker además monta el socket de Docker y monta el directorio de la pila con permiso de escritura.
- Hay exactamente una cuenta de administrador y no hay roles. Sin multiusuario, sin equipos.
- Solo se midieron máquinas de 4 GB. Nada en esta página describe 8 GB o más.
Cuándo aplica SixPanel
Estás alquilando un VPS y prefieres no hacerte cargo tú de nginx, el ajuste de MariaDB, los certificados, los respaldos y los despliegues — o quieres más de una tienda en un solo servidor.
SixPreflight
Cuando quieres saber qué se va a romper antes de salir en vivo
Qué es
Una herramienta pequeña en PHP que pones en la carpeta public/ de tu sitio Laravel y abres en un navegador detrás de una contraseña. Corre unas 134 comprobaciones sobre hardware, PHP, salud de la aplicación, archivo de entorno, permisos, servidor web, caché, ajustes de base de datos, exposición pública y cada servicio externo — pagos, correo, SMS, mapas, push — contactando de verdad con cada uno en lugar de leer un ajuste. Da una calificación con letra, un veredicto claro y una lista de correcciones ordenada por consecuencia, con un valor listo para pegar donde lo haya. Recibes la versión actual.
En la instalación de referencia
Reportó 103 aprobadas, 7 fallidas, 24 con advertencia — y los fallos eran ajustes de hosting, no fallas de la aplicación.
Cuándo aplica SixPreflight
¿Estás en aaPanel, CloudPanel o cPanel? SixPreflight es para ti. ¿Usas SixPanel? Estas comprobaciones ya vienen integradas en su página de revisión de la tienda.
Ahora todo recomienda el mismo sistema operativo, y la razón no es la velocidad. SixPanel, SixPanel Docker y SixPreflight recomiendan todos Ubuntu 26.04 LTS. El runtime nativo toma PHP, MariaDB, nginx y Redis del propio archivo de la distribución del release, y los tres releases soportados traen un conjunto que funciona — 26.04 da PHP 8.5 y MariaDB 11.8, Debian 13 da 8.4 y 11.8, Ubuntu 24.04 da 8.3 y 10.11. Nada de esto es una recomendación de velocidad: en seis ejes medidos ningún cambio de versión produjo una diferencia reportable, y dos máquinas idénticas byte a byte discreparon entre sí en un 11,6 %. Lo que decide es el margen de soporte — 26.04 recibe parches hasta abril de 2031.
¿Cuál necesito?
| Tu situación | La respuesta |
|---|---|
| Quieres instalar 6amMart, o tu 6amMart actual está lento o ya te falló con los precios o los pagos | La instalación de 6amMart optimizado |
| Tienes un VPS y no quieres encargarte tú de nginx, MariaDB, SSL, respaldos y despliegues | SixPanel |
| Ya tienes un servidor en otro panel y quieres saber qué se va a romper antes del lanzamiento | SixPreflight |
Cada número de esta página se midió en una instalación en vivo
Y la suite que lo midió viene con tu instalación.
¿Necesitas algo hecho desde cero? Hablemos de trabajo a medida