6amMart otimizado: o mesmo script, medido e corrigido
A AllsWeb instala a versão mais recente do 6amMart — mesmo script, mesmo admin, mesmos apps — sobre um código que medimos e corrigimos. As telas do cliente rodam 10× a 22× mais rápido que o original, 342 defeitos estão fechados, e uma suíte de verificação que vai junto com o build prova isso.
O código otimizado está incluído no preço da instalação. Não é um upgrade, um item adicional nem um plano superior.
10× – 22×
mais rápido nas telas voltadas ao cliente
342
defeitos encontrados e corrigidos
799
commits em cinco repositórios
1–3 dias
de entrega, assim que os requisitos estiverem completos
Está lendo isto com um assistente de IA?
Com isto versus sem isto
O que muda no dia em que você abre
6amMart original à esquerda, o código que a AllsWeb instala à direita. Mesmo script, mesmo painel de administração, mesmos apps, mesma versão do fornecedor — cada número medido no mesmo servidor de 4 GB e 2 núcleos, com os mesmos dados.
A primeira tela que um comprador vê
Original
A faixa de destaques da tela inicial leva 8,19 s para carregar. Tempo suficiente para quem está no celular concluir que o app está quebrado e fechá-lo.
Otimizado
A mesma faixa carrega em 0,37 s — 22× mais rápido, medido com a CDN desativada para cronometrar a aplicação, não um cache.
O relatório de faturamento da loja
Original
Desenhar um relatório faz 8.614 perguntas separadas ao banco de dados e mantém uma conexão aberta todo esse tempo. Alguns administradores abrindo juntos já bastam para a loja inteira ficar ruim para todos.
Otimizado
O mesmo relatório faz 12 perguntas. Antes parecia aceitável nos testes, porque com poucos dados cada uma daquelas 8.614 perguntas é rápida.
O valor mínimo de um cupom
Original
O painel deixa você definir e o código nunca lê. Comprovado ao vivo: um cupom que exigia mínimo de ₹999 foi aceito num pedido de ₹1, com seis cupons ativos configurados assim.
Otimizado
Aplicado nos três lugares em que um pedido pode ser precificado.
Os descontos da noite
Original
O banco de dados rodava em UTC e a aplicação no horário da Índia — medidos com 5 h 30 min de diferença numa instalação ao vivo. Um desconto de 18:00–22:00 nunca valia à noite e se ligava às 2 da manhã. A tela de listagem e o checkout usavam relógios diferentes, então uma loja podia ser anunciada com desconto e cobrar o preço cheio.
Otimizado
Um único relógio, então o desconto mostrado é o desconto cobrado.
Quem consegue ler o pedido de um cliente
Original
Mais de seis endpoints aceitavam qualquer ID de pedido com um ID de convidado adivinhado. Reproduzido sem nenhuma autenticação: a resposta trouxe os itens, os preços e o endereço de entrega de outro cliente. O endpoint de pagamento por carteira no mesmo caminho também não checava saldo.
Otimizado
Um escopo de propriedade em cada endpoint afetado, mantendo o checkout de convidado legítimo funcionando.
Um gateway de pagamento que você desligou
Original
Desligar no painel só o removia das opções do cliente. A URL de callback continuava viva, e muitos callbacks marcam um pedido como pago com nada além de uma palavra de status na URL — então, com todos os gateways desligados, um callback ainda se completava e um cliente podia confirmar o próprio pedido sem pagar.
Otimizado
Falha fechando, com 102 sondagens em todos os prefixos de gateway confirmando que nenhum executa enquanto inativo.
O que isso custa a você
Original
O 6amMart original é o que uma instalação normal entrega.
Otimizado
A mesma instalação, na versão mais recente do 6amMart. Sem segunda licença, sem segundo preço, sem nível de upgrade — é simplesmente como a instalação é entregue.
O que "otimizado" significa aqui
O mesmo 6amMart. Diferente por dentro.
É o mesmo 6amMart — a versão atual, seja qual for a que a 6amTech estiver publicando no dia em que montamos a sua instalação. O mesmo painel admin, o mesmo painel do vendedor, os mesmos apps de cliente, de loja e de entregador, o mesmo modelo de dados, os mesmos recursos que você viu na demonstração. Nada foi substituído e nada foi renomeado. O que mudou está por baixo: a AllsWeb passou catorze sessões de trabalho medindo o script, analisando seu desempenho e corrigindo o que as medições encontraram — 799 commits em cinco repositórios entre 13 de julho e 9 de agosto de 2026, no backend, no painel admin, no site e nos três apps. Cada uma dessas mudanças tinha de devolver dados idênticos byte a byte antes de ser aceita. Este não é um produto diferente que você precisa escolher. É como instalamos o 6amMart agora.
O que você está comprando
- O serviço não mudou
- Instalação, setup e configuração completos do 6amMart na sua hospedagem — painel admin, painel do vendedor, APK + AAB Android, build iOS, site do cliente, sua marca, SMTP, Maps, push e OTP do Firebase, login social, seus gateways de pagamento, seu arquivo de idioma e o código-fonte personalizado em um repositório privado no GitHub.
- Entrega
- 1–3 dias úteis assim que seus requisitos estiverem completos.
- Suporte vitalício gratuito
- Para problemas de configuração e pequenas correções.
- Sua própria licença do CodeCanyon
- Você compra e é dono da sua licença do 6amMart no CodeCanyon; nós instalamos sobre ela.
O código otimizado está incluído no preço da instalação. Não é um upgrade, um item adicional nem um plano superior.
Por que o original era lento
Uma frase, e um achado
O banco de dados não estava lento. A aplicação fazia a mesma pergunta a ele centenas de vezes por página.
A parte que a maioria das pessoas não viu
Em um endpoint de cliente, uma única requisição disparava 112 consultas ao banco de dados. Oitenta e seis delas — 76% — eram disparadas enquanto o resultado pronto era convertido em JSON para ser enviado, porque os acessores de atributos buscavam dados sob demanda, uma vez por linha, na hora da serialização. Sete buscavam os dados e onze os preparavam. É por isso que só adicionar índices não teria mudado nada: o custo não estava nas consultas que a página executava.
Esse endpoint agora dispara 45.
86 ÷ 112 = 76.8%, impresso como 76%. A fonte imprime 77%; uma fonte que arredonda para cima não autoriza esta página a arredondar para cima.
A comparação medida
Antes e depois, no mesmo servidor
A declaração de método
| Condição | O que era |
|---|---|
| Antes | O script original exatamente como o CodeCanyon o entregou na época do experimento — commit de referência d92ce004, 8 de julho de 2026 ‡ |
| Depois | O mesmo script depois do programa de otimização e reforço de segurança da AllsWeb, com a versão seguinte do fornecedor aplicada por cima depois |
| Servidor | A mesma máquina nas duas execuções — 2 vCPU, 3.9 GB RAM |
| Método | Medido no lado do servidor, com o CDN desviado |
| Escala da mudança | 799 commits · 342 correções · 171 mudanças de desempenho · 37 recursos |
| Regra de aceitação | Toda mudança de desempenho tinha de devolver dados idênticos byte a byte antes de ser aceita |
- ‡ O que foi medido. Os números do antes foram medidos contra o script original como o CodeCanyon o entregou em 8 de julho de 2026 — a versão que a 6amTech numerou como 4.0.1 — e a versão seguinte do fornecedor foi aplicada sobre o código otimizado depois. Isso é uma afirmação sobre o experimento, para que os números do antes possam ser reproduzidos a partir do mesmo ponto de partida. Não é uma afirmação sobre o que você recebe: instalamos a versão que a 6amTech estiver publicando no dia em que montamos. Um volume grande de trabalho adicional entrou em 13–15 de agosto de 2026 e não está coberto pelo relatório de 9 de agosto.
- A regra de aceitação, em uma linha. "Mais rápido nunca teve permissão para significar diferente."
- Arredondado contra nós. Quando um valor medido é uma faixa, os fatores aqui são calculados da forma menos lisonjeira que os números permitem — o menor "antes" dividido pelo maior "depois". Nosso próprio relatório cita fatores pelo ponto médio, que saem maiores.
Nove linhas, todas antes/depois, e não são todas o mesmo tipo de medição, então a tabela diz qual é qual. As linhas 1–5 são tempos de resposta medidos no mesmo servidor com o CDN desviado. As linhas 6–7 são contagens de consultas ao banco de dados por página, onde "CDN desviado" não é uma condição que faça sentido. As linhas 8–9 não são medições de servidor e levam um †. Estas são as linhas que um dono de loja realmente sente, não os maiores números que temos.
| # | O que é | 6amMart original | Otimizado | Fator |
|---|---|---|---|---|
| 1 | Itens em destaque na tela inicial | 8.19 s | 0.37 s | 22× mais rápido |
| 2 | Busca de produtos | 1.64 – 1.96 s | 0.09 – 0.12 s | pelo menos 13× mais rápido |
| 3 | Página inicial da vitrine | ~1.47 s | 0.073 – 0.096 s | pelo menos 15× mais rápido |
| 4 | Principais categorias | 3.34 s | 0.27 s | 12× mais rápido |
| 5 | Configuração do app na abertura | 0.53 – 1.15 s | 0.045 s | pelo menos 11× mais rápido |
| 6 | Exportação de ganhos da loja — consultas ao banco de dados por página | 8,614 | 12 | 717× menos |
| 7 | Listagem do catálogo de produtos — consultas ao banco de dados por página | 557 | 92 | ~6× menos |
| 8 | † Estilos enviados em cada página do site — uma contagem de bytes da saída do build, não um tempo de servidor | 921,603 bytes | 12,386 bytes | −98.6% (74× menor) |
| 9 | † Dez requisições do app em sequência — medidas de um aparelho em dados móveis, não no servidor | 6,140 ms | 1,876 ms | −69% (3.2× mais rápido) |
† As linhas 8 e 9 não são medições de servidor. O enquadramento "mesmo servidor, CDN desviado" cobre apenas os tempos de resposta das linhas 1–5; o número dos estilos é uma saída de build e o número das dez requisições foi obtido em dados móveis.
A aritmética, impressa
A linha 6 imprime 717×, e não os 718× que o nosso próprio relatório escreve: 8,614 ÷ 12 = 717.83, e esta página não arredonda um número para cima a seu favor. A linha 9 imprime 3.2× pelo mesmo motivo — 6,140 ÷ 1,876 = 3.27. A contagem de bytes da linha 8 é 921,603 ÷ 12,386 = 74.4, impressa como 74×. Os 76% acima são 86 ÷ 112 = 76.8%, arredondados na mesma direção.
Capacidade simultânea, declarada do único jeito que a evidência permite
No mesmo servidor de 2 vCPU, sob uma rampa de carga contra o endpoint de listagem de lojas, 13× mais clientes conseguem usá-lo ao mesmo tempo no mesmo servidor. O par de requisições por segundo por trás disso não é impresso de propósito: a fonte registra a rampa de carga sem informar a simultaneidade nem a duração, e um número de requisições por segundo que não consegue nomear seu endpoint, sua simultaneidade e sua duração não entra nesta página. O número do SixPanel, mais abaixo, tem os três, e é por isso que aquele é impresso como taxa.
Duas linhas que não são sobre velocidade
| O que é | 6amMart original | Otimizado |
|---|---|---|
| Endpoints que devolvem erro de servidor em uma instalação limpa | 3 (lojas populares, lojas mais recentes, formas de pagamento) | 0 — os três agora respondem em 41–150 ms |
| Alertas de segurança conhecidos em dependências, contados em 9 de agosto de 2026 | 111 | 0 |
O que os 111 realmente eram. 110 deles eram versões do axios e do vite dentro de cinco arquivos package.json de módulos de extensão cujos pipelines de build nunca funcionaram — quatro apontam para arquivos-fonte que não existem no módulo, e o quinto aponta para dois arquivos com zero bytes. Ainda assim foram levantados, porque um alerta que você decidiu ignorar é um alerta que você para de ler. O que importava por si só era o firebase/php-jwt abaixo de 7.0.0 (CVE-2025-45769), antes registrado como impossível de corrigir, agora em ^7.0.2 e verificado contra as chaves reais da Apple, do Passport, do Firebase e do Google.
A linha dos alertas é um retrato com data por um motivo: as bases de alertas mudam o tempo todo, e uma contagem feita em 9 de agosto de 2026 é uma afirmação sobre aquele dia, não uma propriedade permanente do build. Rode a auditoria na sua própria instalação para ter um número atual.
Estado atual, com a ressalva junto Uma varredura de 306 requisições a endpoints registra zero erros de servidor e zero endpoints acima de 250 ms — medido sobre as requisições que executaram. Em uma execução válida, o próprio limitador de requisições da plataforma rejeita 66–68 delas, cerca de um quinto da varredura, e uma requisição rejeitada não é um resultado de endpoint. A divisão registrada de uma execução válida (~235 bem-sucedidas, 66–68 rejeitadas) soma cerca de 302, não 306; não conseguimos reconciliar as requisições restantes com as fontes que temos. Rode você mesmo e leia a sua própria divisão — a seção de verificação abaixo explica como.
Causas raiz
As três causas que vale nomear
São elas que tornam a tabela crível.
A exportação de ganhos pediu a coisa errada 2,867 vezes.
Ela mandava o banco de dados buscar a loja de cada transação através do pedido, enquanto o código lia a loja direto da transação — um vínculo diferente. A instrução nunca se aplicava, então todas as 2,867 linhas buscavam a própria loja separadamente.
Cada página do vendedor desenhava dois menus de navegação.
Um escondido pela folha de estilos, os dois contando os mesmos contadores de pedidos.
Um cabeçalho de página carregava todo o histórico de pedidos da loja.
466 pedidos para a loja mais movimentada, para preencher uma seção da página que estava comentada no código.
E o achado sobre índices
Dez das colunas que o banco de dados usa nas junções não tinham índice nenhum. Depois de indexar, uma busca passou de ler 51,074 linhas para ler uma.
A lista de clientes do admin examinava 16,092,496,536 linhas para devolver 98 — 82% de todo o tempo de consultas lentas no servidor, e até 18 minutos para carregar uma única página.
O que foi corrigido
Desempenho, segurança, correção
Desempenho
Consultas ao banco de dados por requisição — cada uma verificada como idêntica byte a byte antes de a mudança ser aceita.
API do cliente
| Operação | Original | Otimizado |
|---|---|---|
| Listagem do catálogo de produtos (31 itens) | 557 | 92 |
| Lista de pedidos do vendedor (41 pedidos) | 212 | 12 |
| Formatação dos detalhes do pedido (40 linhas) | 121 | 4 |
| Histórico de pedidos do cliente | 166 | 97 |
| Lista de desejos (6 itens) | 140 | 37 |
| Listagem de lojas | 78 | 39 |
| Configuração do app | 54 | 21 |
| Lista de categorias | 43 | 16 |
Painéis admin e do vendedor
| Tela | Original | Otimizado |
|---|---|---|
| Exportação de ganhos da loja | 8,614 | 12 |
| Busca de pedidos no admin | 259 | 14 |
| Seletor de produtos de oferta relâmpago | 186 | 42 |
| Galeria de produtos | 166 | 48 |
| Lista de fornecedores de aluguel | 159 | 9 |
| Lista suspensa de lojas nos reels | 127 | 62 |
| Página de detalhes do cliente | 106 | 34 |
| Lista de veículos de aluguel | 94 | 13 |
| Página de ganhos da loja | 89 | 13 |
| Cada página do vendedor, antes do próprio conteúdo | 61 | 52 |
Os painéis admin e do vendedor nunca tinham sido medidos — as próprias verificações automáticas do 6amMart original cobrem apenas a API do cliente. 586 páginas do admin e 165 do vendedor foram analisadas, contadas em consultas ao banco de dados "porque uma contagem é exata e repetível, enquanto um cronômetro em um servidor compartilhado varia".
Site
- Dos 921,603 bytes de estilos em cada página, 902 KB eram três bibliotecas de ícones completas — 21,459 definições de ícones enviadas para o site poder exibir 89 ícones. O build agora gera só os ícones realmente usados, e o total de estilos por página é 12,386 bytes, −98.6%.
- JavaScript compartilhado 429 kB → 269 kB (−37%).
- A página inicial era uma casca vazia até o JavaScript carregar; agora ela envia 273,110 bytes renderizados pelo servidor.
- Requisições de configuração: uma por visualização de página por visitante → uma por minuto por idioma.
- A biblioteca do Maps estava sendo enviada para 9 páginas que não mostram mapa nenhum.
- Formatação de data por linha: 8.45 µs → 0.39 µs (21× mais barata).
- Todas as 50 rotas do site melhoraram ou se mantiveram; nenhuma piorou.
Apps mobile
- Cada requisição abria uma conexão segura nova em vez de reaproveitar uma — cerca de 426 ms por requisição em dados móveis. Dez requisições em sequência: 6,140 ms → 1,876 ms.
- Tela inicial: ~30 requisições por abertura → 1 requisição cobrindo 14 seções.
- Uma foto de 1000×1000 era decodificada atrás de um avatar de 40 pixels; as imagens agora são decodificadas no tamanho realmente exibido.
- 309 comandos de log de depuração iam dentro dos apps publicados. Agora zero.
- GPS do entregador: 360 → ~30 envios de posição por hora parado.
- A tela de pedidos do vendedor redesenhava tudo a cada 10 segundos; agora só redesenha quando os dados mudam.
Segurança — as falhas específicas encontradas no script como ele é vendido
Nada nesta seção é questão de preferência. Cada item é um defeito presente no 6amMart original, e cada um foi reproduzido antes de ser corrigido.
Injeção de SQL sem autenticação, alcançável a partir de qualquer listagem de lojas.
O código de listagem de lojas inseria os cabeçalhos brutos de latitude e longitude direto no cálculo de distância em SQL. Alcançável sem login e sem token. Confirmado que chegava ao banco de dados — uma carga injetada produziu um erro de sintaxe do banco no log em produção. Corrigido com parâmetros vinculados; um segundo ponto de injeção, sem uso, foi apagado.
Os pedidos de qualquer cliente podiam ser lidos e editados por qualquer pessoa.
Mais de seis endpoints de pedidos aceitavam qualquer ID de pedido junto com um ID de convidado adivinhado. Reproduzido em produção: uma requisição sem nenhuma autenticação devolveu os itens, os preços e o endereço de entrega de outro cliente. O endpoint de pagamento por carteira no mesmo caminho não tinha verificação de saldo. Corrigido com um escopo de propriedade em todos os endpoints afetados, mantendo o checkout de convidado legítimo funcionando.
Gateways de pagamento desligados ainda conseguiam liquidar pagamentos.
Desligar um gateway no painel admin só o removia das opções do cliente — suas URLs de retorno continuavam ativas, e muitos retornos de gateway marcam um pedido como pago apenas com base em uma palavra de status na URL. Com todos os gateways desligados, um retorno ainda executou com sucesso, então um cliente podia confirmar o próprio pedido sem pagar. Corrigido para falhar fechado; 102 sondagens em todos os prefixos de gateway agora confirmam que nenhum executa enquanto está inativo.
Vendedores podiam agir sobre os dados de outros vendedores.
Qualquer vendedor podia editar ou apagar produtos, adicionais e banners de outra loja — incluindo os banners da tela inicial do próprio admin. Responder a uma avaliação transferia essa avaliação para a loja do vendedor que respondeu. Corrigido com escopo por loja.
Um backdoor de login de demonstração ativo — e o que ele não alcançava.
O 6amMart traz um atalho de demonstração para que um avaliador de loja de apps consiga entrar sem SMS. Ele lê o número de telefone e o código da configuração, com os valores de demonstração como reserva quando a configuração não está presente — e a configuração deixa de estar presente exatamente quando o site roda o passo padrão de cache de produção, que toda instalação em produção roda. No site em produção, um número fixo no código recebia um código válido, sem SMS enviado e sem nada na configuração pedindo isso. O impacto era limitado, e nós declaramos o limite: não existia conta nesse número, então o caminho levava a uma conta nova com a verificação de telefone contornada — não à tomada da conta existente de alguém. A reserva é o que tornava isso perigoso: um operador que nunca tinha ouvido falar dessa opção mesmo assim publicava o backdoor. 28 verificações automáticas agora provam que ele não pode existir a menos que seja habilitado de propósito.
A pasta inteira do projeto podia ser lida por HTTPS.
O 6amMart aponta o servidor web para a pasta da aplicação em vez de public/, contido apenas por uma lista de bloqueio escrita à mão. Uma lista de bloqueio protege os caminhos em que alguém pensou; catorze não estavam nela, cada um confirmado com uma requisição real — incluindo um dump de banco de dados do instalador de 679 KB, um arquivo compactado de 5.9 MB da pasta public e um arquivo PHP que o servidor realmente executou, devolvendo uma página de erro fatal que revelava os caminhos absolutos do servidor. A raiz do site foi movida para public/; os catorze agora devolvem 404, e 19 verificações automáticas mantêm isso assim.
A história da limitação de requisições são três defeitos separados, não um.
- 1
A API não tinha limite de requisições nenhum.
A configuração do framework definia um limitador de 600 por minuto para a API, mas nada chegava a aplicá-lo — o grupo de middleware da API continha uma entrada não relacionada e mais nada, então o limitador era configuração morta. Medido antes da mudança: 40 tentativas de login com senha errada contra uma conta, na velocidade máxima que o curl conseguiu — 40 rejeições, nenhuma limitação, nenhum atraso, nada registrado. Três limites agora se aplicam: um teto geral de 600/minuto, 10/min nas tentativas de autenticação, com chave tanto no endereço quanto na conta atacada, e 5/min nas rotas que enviam SMS de verdade. Verificado: 25 senhas erradas em sequência rápida → 10 rejeições e depois 15 bloqueios temporários; uma conta diferente a partir do mesmo endereço na mesma janela → sem bloqueio; 60 requisições comuns de navegação em uma rajada → todas bem-sucedidas.
- 2
Depois, o limitador usava como chave uma identidade que metade da plataforma nunca tem — e esse nós mesmos encontramos, revisando a nossa própria correção.
O novo limitador usava como chave o usuário logado, caindo para o endereço de rede quando não havia um. Mas as APIs do vendedor e do entregador autenticam procurando um token bearer em uma tabela, e não por um guard de autenticação, então o usuário era sempre nulo e a chave caía para o endereço. Uma loja com funcionários em uma única conexão de escritório, ou entregadores atrás do NAT de uma operadora, teriam compartilhado um único orçamento de 600/minuto — e o app de entrega consulta a cada 10 segundos, então um turno movimentado teria começado a recusar gente que estava trabalhando. A chave agora cai primeiro para um hash do token bearer. Verificado: duas chamadas com token de vendedor → 599 e depois 598 restantes no contador delas; um token de cliente logo em seguida → 599 em um orçamento separado; sem token → ainda com chave no endereço, 600 intactos.
- 3
A plataforma não conseguia ver o visitante real.
Atrás de um CDN, cada requisição chegava do endereço do CDN e a aplicação acreditava que aquele era o visitante — então a limitação de requisições restringia todos os clientes como um só, as verificações antifraude comparavam o endereço errado, e cada pedido gravava um IP de proxy em vez do de quem fez o pedido. Causa raiz: o framework traz o tratamento de proxy na sua pilha global e o 6amMart substituiu essa pilha por completo, descartando esse tratamento, então configurar proxies confiáveis sozinho não tinha a que se ligar. As duas metades agora estão no lugar, e uma requisição encaminhada resolve para o endereço real do cliente. A plataforma agora vê o visitante real em vez de tratar a internet inteira como um único usuário.
Uma primitiva de envenenamento de cache.
O cache de listagem calculava sua chave a partir da query string da URL, mas os endpoints liam seus parâmetros por um método que prefere o corpo da requisição sempre que a requisição declara tipo de conteúdo JSON — inclusive em um GET. Então uma requisição podia pedir um termo de busca na URL e outro no corpo: a chave era calculada para o primeiro, a busca rodava para o segundo, e as linhas erradas eram guardadas sob a primeira chave e entregues a todo cliente real que buscasse por ela até a entrada expirar. Sem autenticação, e com o atacante escolhendo as duas metades — quais produtos um comprador via, de qual loja, a quais preços. Requisições cuja entrada a chave não consegue enxergar agora são respondidas totalmente fora do cache.
Também fechados
Qualquer nota podia ser baixada por quem soubesse contar.
As notas de pedidos, de assinaturas e de corridas eram enumeráveis pela URL.
XSS armazenado, do vendedor para o admin.
Descrições de produtos escritas por vendedores eram renderizadas como HTML bruto em 8 telas do admin e do vendedor, então um vendedor podia executar scripts no navegador do admin. Sanitizado, e comprovado seguro contra 25,726 descrições de produtos reais, sem nenhuma mudança no texto visível.
Repetição de retorno de pagamento.
Os retornos não eram idempotentes, então um retorno repetido creditava o cliente duas vezes. Corrigido no nível do hook, em todos os 47 gateways.
Um redirecionamento aberto na rota de redirecionamento do app.
Um formato de phishing no seu próprio domínio. Corrigido, e depois corrigido de novo quando um desvio com barra invertida foi encontrado na revisão; um teste de 17 casos agora protege isso.
Duas rotas públicas de depuração.
Uma executava um comando de limpeza de cache sem autenticação, a outra era um repasse aberto de imagens. As duas foram apagadas.
O laravel.log podia ser baixado pela internet.
Contendo o usuário do banco de dados, o SQL que falhou com seus parâmetros e os caminhos completos do servidor.
Uma única chave de aplicação entregue a todas as instalações.
O arquivo de ambiente de exemplo trazia uma chave real; um arquivo de ambiente novo a copia, e o passo de geração de chave só dispara com um valor vazio, então ele era pulado — toda instalação feita desse jeito rodava com a mesma chave, impressa dentro de cada cópia do produto.
Requisições GET que mudam configurações — mitigadas, e declaradas de forma restrita.
No 6amMart original, mudar uma configuração é um link comum, então 64 rotas GET do admin e do vendedor gravam estado. Um rastreador, uma pré-visualização de link, uma tag de imagem ou uma busca em segundo plano podem mudar configurações enquanto um admin está logado. Isso não é teórico: em 1º de agosto, o nosso próprio analisador de desempenho requisitou esses endereços enquanto media a velocidade das páginas e mudou 8 configurações em produção em 45 segundos — a direção do texto do painel inverteu, a página inicial foi desligada, um vendedor foi desativado. Restaurado e verificado dentro de uma hora. A correção entregue é uma única proteção, registrada uma vez, que lê os cabeçalhos Fetch Metadata do navegador — que dizem por que a requisição foi feita e não podem ser falsificados pelo JavaScript de um atacante — e recusa formatos que nunca são um clique humano. Verificado em produção: o carregamento de um endereço de configuração por tag de imagem é recusado; um prefetch é recusado; uma busca em segundo plano vinda de outro site é recusada; um administrador real clicando funciona; as 338 requisições em segundo plano do próprio painel funcionam; navegadores antigos que não enviam esses cabeçalhos funcionam. 102 páginas reais do painel renderizam idênticas byte a byte com a proteção ligada e desligada, e 53 verificações automáticas cobrem isso. Um único registro cobre 1,348 rotas, incluindo módulos que declaram seus próprios grupos de rotas.
O caminho de exploração a partir de um navegador está fechado. As rotas em si ainda gravam em GET — veja Limites honestos.
Correção — os defeitos que afetam dinheiro
| Defeito no 6amMart original | O que foi medido |
|---|---|
| O valor mínimo do cupom nunca era aplicado | Os admins podiam defini-lo; o código nunca o lia. Comprovado em produção: um cupom que exigia mínimo de ₹999 foi aceito em um pedido de ₹1. Seis cupons ativos tinham mínimo definido. Agora é aplicado nos três lugares em que um pedido pode ser precificado. |
| Os descontos eram avaliados pelo relógio errado | O banco de dados rodava em UTC e a aplicação no horário da Índia — medido em produção com 5h30m de diferença. Um desconto noturno das 18:00 às 22:00 nunca coincidia com a noite e ligava entre 2 e 3 da manhã. Pior: a tela de listagem e o checkout usavam relógios diferentes, então uma loja podia ser anunciada com desconto e cobrar o preço cheio. |
| As quantidades de adicionais eram cobradas no adicional errado | As quantidades eram pareadas aos adicionais pela posição em uma lista, mas o app do cliente envia a ordem do menu enquanto o banco de dados devolve a ordem de ID interno. Demonstrado no servidor: um pedido que deveria custar ₹270 foi cobrado ₹550. Corrigido nos 8 lugares do código que faziam isso. |
| O estoque era baixado no produto errado | Uma compra de campanha buscava o produto pelo ID da campanha na tabela de produtos. Os três IDs de campanha em produção também existiam como IDs de produto. |
| A verificação de estoque no checkout conferia um número diferente do que gravava | A checagem final comparava o estoque geral do produto; a baixa acontecia no estoque da variação escolhida. Medido em dados reais: 56 produtos ativos em que uma compra legítima seria recusada, e 1,451 em que uma venda acima do estoque passaria despercebida. |
| Um retorno repetido do gateway creditava o pagamento duas vezes | Também disparado por um cliente atualizando a página de retorno. Corrigido no nível do hook, em todos os 47 gateways. |
| O checkout de compra imediata precificava o que o celular enviasse | Em vez do carrinho do servidor. |
| Um saque podia ser aprovado duas vezes e deixar a carteira negativa | Reproduzido em produção: aprovar duas vezes creditou o total sacado duas vezes e levou o saldo pendente a −50.00. Um botão de voltar ou um clique duplo bastava. |
| Os IDs de pedido eram atribuídos à mão | O código lia o maior ID de pedido existente e somava um — reimplementando mal o auto-incremento, e colidindo em checkouts simultâneos. |
| Dois entregadores podiam aceitar o mesmo pedido | E dois clientes podiam comprar a última unidade. Corridas entre checar e gravar, agora reivindicações atômicas no banco de dados, comprovadas com transações simultâneas. |
Sobre as duas contagens que você verá citadas. Os totais do próprio projeto classificam 4 das falhas de segurança como críticas e 6 dos defeitos como afetando dinheiro, dentre 342 corrigidos. Essas são as contagens publicadas mais baixas, então são as que esta página usa. Elas não são contagens dos itens listados nesta página: a seção de segurança acima nomeia mais de quatro defeitos de segurança e a tabela acima lista dez defeitos de dinheiro, porque listamos cada um que reproduzimos, e não só os que estão dentro das duas contagens.
Correções sem impacto em dinheiro que vale listar
- O agendador nunca tinha rodado. Cinco tarefas agendadas em segundo plano nunca haviam executado uma única vez desde a implantação — a entrada de cron do sistema nunca foi instalada.
- A rotina mensal de repasse rodava quatro vezes por mês (o agendamento estava escrito como "dias 28–31" em vez de "último dia do mês").
- O histórico de pedidos informava todas as lojas como sem avaliação — 0 estrelas em tudo, enquanto a nota real de uma loja era 4.31 em 29 avaliações.
- As entregas dos entregadores nunca contavam para a popularidade dos produtos — o laço de incremento usava um nome de propriedade que não existe naquele registro, então o bloco não fazia nada em silêncio, distorcendo todo ranking de "produtos mais populares".
- As notificações push estavam desativadas em silêncio — enfileiradas para um worker que podia não existir; nada era entregue, nenhum erro era levantado.
- 34 erros de servidor nos painéis admin e do vendedor → zero.
- Um vendedor sem registro de loja derrubava 9 de 12 páginas do próprio painel, o login web do vendedor e o login do app da loja — um helper compartilhado devolvia o primeiro elemento de uma relação vazia, o que gera erro em vez de devolver nulo. 43 verificações, incluindo afirmações pareadas de que um vendedor legítimo continua passando.
- Um relatório do admin nunca funcionou em nenhuma instalação deste software — ele compilava para PHP inválido e sempre falhava. Encontrado ao checar todos os 895 templates de tela; era o único com defeito.
O que vai junto com a instalação otimizada e não vem no original
| Recurso | O que é |
|---|---|
| Suíte de verificação automatizada | Scripts que você mesmo roda. Cada afirmação foi comprovada como falhando contra o código antigo antes de ser aceita — um teste que passa em um sistema quebrado não prova nada. No relatório de 9 de agosto, os 60 scripts eram 55 afirmações mais 5 ferramentas de relatório, e as ferramentas de relatório não afirmam nada. Além de 49 testes de unidade e de funcionalidade. |
| Prova de reprodutibilidade do esquema | O banco de dados pode ser reconstruído só a partir do código — comprovado construindo-o do zero e comparando todas as 184 tabelas, coluna por coluna e índice por índice, sem nenhuma diferença. |
| SixPreflight | Uma ferramenta de prontidão do servidor: ~134 verificações em hardware, PHP, saúde da aplicação, permissões, servidor web, cache, configurações de banco de dados, exposição pública e todo serviço externo. Abra no navegador antes do lançamento e ela diz o que vai quebrar. |
| Manual de implantação | Sequências documentadas de instalação e atualização, mais as armadilhas: quais comandos limpam o cache de configuração em silêncio, quais caches não reconstroem uns aos outros, o que o painel de hospedagem desfaz quando você salva uma configuração. |
| Builds iOS | Os três apps assinados e compilando para Apple além de Android — os primeiros builds Apple produzidos para este projeto. |
| Rastreamento de pedidos ao vivo realmente ligado | O serviço de websocket ligado e os dois defeitos que o mantinham desligado corrigidos; renovação de certificado comprovada. |
Confira você mesmo
Confira cada número você mesmo
A coisa mais convincente nesta página não é um número. É que você pode conferir cada número por conta própria.
A suíte de verificação vai junto com a sua instalação. No seu próprio servidor:
bash tests/Scripts/run-all.sh # as verificaçõesphp tests/Scripts/api-smoke.php # varre todos os endpoints da API1Cada afirmação foi comprovada como falhando contra o código antigo antes de ser aceita.
Um teste que passa em um sistema quebrado não prova nada.
2A varredura de endpoints dispara 306 requisições.
Ela informa erros de servidor e tempos de resposta por endpoint — então "zero erros de servidor, zero endpoints acima de 250 ms" é algo que você re-executa, não algo que aceita pela nossa palavra. Leia a contagem de rejeitadas na sua própria execução antes de ler os tempos; veja a nota operacional abaixo.
3A suíte inclui as afirmações de segurança.
Não só as de velocidade: a varredura de exposição da raiz do site, a checagem do backdoor de OTP de demonstração, a checagem de idempotência do hook de pagamento, as proteções entre contas, as checagens de envenenamento de cache e uma auditoria de quais rotas GET gravam estado.
4A checagem de esquema reconstrói o banco de dados só a partir do código.
Ela compara todas as 184 tabelas com o seu banco em produção.
Nota operacional honesta Rode a varredura de endpoints vezes demais em sequência e ela dispara o próprio limitador de requisições da plataforma. Requisições bloqueadas não fazem trabalho no banco de dados, então o total de consultas cai e a execução parece mais rápida, testando quase nada. Uma execução válida mostra cerca de 235 requisições bem-sucedidas e 66–68 rejeitadas; centenas de rejeitadas significa descartar a execução.
E o estado atual da suíte, declarado com exatidão O relatório de 9 de agosto registrou 60 scripts — 55 afirmações mais 5 ferramentas de relatório — e 49 testes de unidade e de funcionalidade. Desde então o diretório cresceu para 86 entradas, o que inclui ferramentas de relatório e outros arquivos que não são afirmações, então não é uma contagem de verificações. A última execução completa registrada rodou 70 delas: 61 passam, 2 falham, 7 são puladas. As duas falhas estão nomeadas nas evidências — dois relatórios de aluguel no admin devolvendo erro de servidor em instalações sem aluguéis, e um mapeamento de asset ausente — e pelo menos a de aluguel foi corrigida depois. Re-execute a suíte na sua própria instalação e leia o seu número.
Limites honestos
O que esta página não afirma
Uma página que diz "aqui está o que medimos, aqui está como conferir, e aqui está o que ainda não resolvemos" é mais difícil de duvidar do que uma que só imprime suas vitórias.
342 defeitos foram encontrados e corrigidos. Ninguém consegue enumerar o que resta.
Esse é o formato honesto de uma plataforma deste tamanho.
Nada neste programa mediu o trabalho de outro fornecedor.
Então esta página não faz nenhuma afirmação sobre o build de mais ninguém. Cada número aqui é o script original como foi entregue na época contra o nosso código otimizado, em um servidor.
Cada número desta página é arredondado contra nós, nunca a nosso favor.
Nas telas voltadas ao cliente a melhora medida é de 10× a 22×, o que equivale a 90 a 95% menos espera — 22× é 95.4% e imprimimos 95. Quando uma medição é uma faixa, o fator é o menor "antes" sobre o maior "depois".
Os números de 10 milhões de pedidos nesta página são um teste de escala, não desempenho em produção.
Eles vêm de um banco de dados montado de propósito com 10,000,000 pedidos, 1,000,000 produtos e 200,000 clientes, rodado de propósito contra um buffer pool subdimensionado de 128 MB, para ficar limitado por disco como um servidor real com poucos recursos. A instalação em produção auditada tem 3,282 pedidos.
Seis linhas do teste de escala continuam em um segundo ou mais, e imprimimos as onze linhas abaixo.
Os contadores de despacho estão em 12 s; popular_products em 7.1 s; a lista de pedidos do admin em um deslocamento profundo de página, 3.1 s; o relatório de itens, 12.5 s para um mês e 131 s para todo o período; a lista de clientes do admin, cerca de 1–1.5 s. O número de todo o período do relatório de itens é a pior coisa que medimos em qualquer lugar, e a execução do original com que ele deveria ser comparado foi interrompida aos 120 segundos, então nem podemos afirmar uma melhora ali — apenas que a nossa termina.
Requisições GET que mudam configurações estão mitigadas, não eliminadas.
O caminho de exploração pelo navegador está fechado e verificado; as 64 rotas do admin e do vendedor em si continuam gravando estado em um GET, e convertê-las em formulários protegidos não foi tentado de propósito, porque é um risco grande de regressão em uma plataforma que hoje funciona em muitos projetos derivados.
A proteção é mais ampla do que a vulnerabilidade.
Uma listagem inofensiva, só de leitura, também é recusada se chegar como prefetch ou como carregamento de imagem, porque separar os ~860 endereços só de leitura do painel dos 64 perigosos exigiria exatamente a lista frágil que decidimos não escrever. Há uma chave de uma linha para desligar isso.
A limitação de requisições é segura por causa de onde os servidores estão, não porque cabeçalhos não possam ser falsificados.
A configuração confia nos cabeçalhos encaminhados, o que só se sustenta enquanto nada alcançar o PHP a não ser pela cadeia de proxy. Uma máquina acessível diretamente permitiria que um cliente falsificasse o cabeçalho e ganhasse um balde novo a cada requisição.
O tamanho de download do app quase não mudou.
Cerca de 0.7 MB no total, porque o código sem uso que removemos já era descartado pelo compilador de release. Não fazemos nenhuma afirmação sobre tamanho de app.
Três itens na instalação de referência estão em aberto e nomeados, em vez de escondidos.
As chaves do Google Maps estão sem restrição e precisam ser travadas; uma chave privada do Apple Sign-In que o próprio ajudante de upload do 6amMart original havia colocado em armazenamento público precisa ser revogada e reemitida; e três vendedores ainda não têm registro de loja — os erros 500 que esse estado costumava causar estão corrigidos, mas o estado em si ainda é alcançável porque os dois caminhos de cadastro salvam o vendedor e a loja fora de uma única transação. Os três estão no documento de entrega.
No servidor de referência, o hardware agora é o limite, não o código.
Testado sob carga com 20–40 usuários simultâneos e zero erros; nesse ponto a máquina de 2 vCPU satura.
Todos esses testes de desempenho são um servidor, um conjunto de dados.
Eles bastam para dizer o que mudou nesta instalação. Não são uma afirmação geral sobre toda implantação de 6amMart.
O 6amMart original é um produto comercial muito usado.
Os defeitos acima são declarados como fatos, e isso basta.
O teste de escala, impresso por inteiro — cada linha, inclusive as ruins
Teste de escala — um banco de dados montado de propósito com 10 milhões de pedidos, não tráfego real.
| Tela | Original | Otimizado | Ainda lento? |
|---|---|---|---|
| Lista de pedidos do admin, primeira página | 27.4 s | 13.6 ms | |
| Contadores de pedidos em cada página do vendedor | 136 ms | 20 ms | |
| Relatório de itens, this_week | interrompido aos 120 s | 542 ms | |
| get_stores | 9.8 s | 901 ms | |
| Contadores de pedidos em cada página do admin | 8.5 s | 830 ms | |
| Lista de clientes do admin, primeira página | 20.7 s | ~1.0 – 1.5 s | ≥ 1 s |
| Lista de pedidos do admin, deslocamento profundo de página | 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 |
| Relatório de itens, this_month | interrompido aos 120 s | 12.5 s | ≥ 1 s |
| Relatório de itens, all_time | interrompido aos 120 s | 131 s (piso de 365 dias) | ≥ 1 s — a pior linha que temos |
Quando duas fontes discordam em uma linha, esta tabela imprime o número menos lisonjeiro dos dois lados.
Nosso próprio relatório registra a lista de clientes do admin em ~1.0 s, enquanto o log bruto da ferramenta de teste registra 1.5 s, então a faixa é impressa. O relatório registra os contadores do admin em 8.5 s → 830 ms, onde o log bruto lê 57.4 s → 791 ms, e os contadores do vendedor em 136 ms → 20 ms, onde o log bruto lê 270 ms → 13 ms; nos dois casos são impressos o menor "antes" e o maior "depois".
Isso vai importar para mim?
Com 100,000 pedidos, um volume realista — trinta vezes o volume atual da instalação auditada — e com as janelas dos contadores de pedidos desligadas, todas as nove telas analisadas nesse volume medem 250 ms ou menos, e seis das nove medem 50 ms ou menos: contadores do vendedor 3.4 ms, get_latest_products 10 ms, lista de clientes 31 ms, relatório de itens 46 ms, produtos populares 47 ms, listagem de lojas 50 ms, contadores de despacho 146 ms, lista de pedidos do admin 155 ms, contadores da barra lateral do admin 179 ms. A janela dos contadores (ORDER_BADGE_WINDOW_DAYS=60) é uma configuração entregue, e o fato de estar ligada muda esses números, então declaramos a condição sob a qual a medição foi feita.
FAQ
Perguntas que os compradores realmente fazem
Doze perguntas, respondidas com os mesmos números do resto da página.
O que eu estou comprando, exatamente?
A mesma coisa que a AllsWeb sempre vendeu: instalação, setup e configuração completos do 6amMart na sua hospedagem — painel admin, painel do vendedor, APK e AAB Android, build iOS, site do cliente, sua marca, SMTP, Google Maps, push e OTP do Firebase, login social, seus gateways de pagamento, seu arquivo de idioma e o código-fonte em um repositório privado no GitHub. Entregue em 1–3 dias úteis assim que seus requisitos estiverem completos, com suporte vitalício gratuito para problemas de configuração e pequenas correções. O código otimizado é como essa instalação é montada agora.
Eu recebo o mesmo 6amMart?
Sim — a versão mais recente do 6amMart, seja qual for a que a 6amTech estiver publicando quando montarmos a sua instalação. Mesmo painel admin, mesmo painel do vendedor, mesmos apps de cliente, de loja e de entregador, mesmo modelo de dados, mesmos recursos. Cada mudança de desempenho só era aceita se devolvesse dados idênticos byte a byte, então suas telas mostram o que mostravam antes, mais rápido.
O código otimizado custa mais?
Não. Não há produto separado, licença separada nem plano premium. O preço de instalação do catálogo é o preço, e o código otimizado está incluído nele. Você continua comprando e sendo dono da sua licença do 6amMart no CodeCanyon.
Quanto mais rápido é, de verdade?
No servidor em produção, com o CDN desviado: itens em destaque 8.19 s → 0.37 s (22×), principais categorias 3.34 s → 0.27 s (12×), busca de produtos 1.64–1.96 s → 0.09–0.12 s (pelo menos 13×), a página inicial da vitrine ~1.47 s → 0.073–0.096 s (pelo menos 15×). Os fatores de cada linha são calculados da forma menos lisonjeira que as medições permitem. O número típico nas telas voltadas ao cliente é de 10× a 22× mais rápido — 90 a 95% menos espera.
De onde vêm esses números, e em que hardware?
O antes é o script original exatamente como o CodeCanyon o entregou na época do experimento — a nota de método acima explica em rodapé qual build era esse e por que a nota está ali. O depois é o mesmo script depois do programa, com a versão seguinte do fornecedor aplicada por cima. Os dois foram medidos no mesmo servidor de 2 vCPU / 3.9 GB, no lado do servidor, com o CDN desviado — não em uma máquina maior, e não com um CDN fazendo o trabalho. Duas linhas da tabela de comparação não são tempos de servidor e estão marcadas como tal: uma contagem de bytes da saída do build e uma medição feita em um aparelho por dados móveis.
Posso verificar algo disso por conta própria, ou tenho que confiar na página?
Você pode verificar tudo. A suíte de verificação vai junto com a sua instalação: bash tests/Scripts/run-all.sh roda as verificações e php tests/Scripts/api-smoke.php varre 306 requisições da API e imprime os tempos de resposta. Cada afirmação foi comprovada como falhando contra o código antigo antes de ser aceita, então passar significa alguma coisa. Uma ressalva que preferimos contar a você em vez de deixar que você descubra: uma varredura válida tem cerca de 66–68 requisições rejeitadas pelo próprio limitador da plataforma, e uma execução com centenas de rejeitadas deve ser descartada.
As atualizações da própria 6amTech continuam funcionando nele?
Mecanicamente, sim — já foi feito. A versão seguinte do fornecedor foi aplicada sobre o código otimizado, e mais trabalho entrou depois do relatório de 9 de agosto: reforço do cache, uma listagem de despesas reconstruída e um defeito de chave de aplicação que afetava toda instalação montada a partir do arquivo de configuração de exemplo do fornecedor. O detalhe honesto é que nossas correções ficam nos mesmos arquivos que a 6amTech entrega, então uma versão do fornecedor é uma mesclagem que nós fazemos para você, não uma sobrescrita arquivo por arquivo que você roda sozinho.
O que acontece quando a 6amTech lançar a próxima versão do 6amMart?
Se você está comprando agora, você a recebe — instalamos o que estiver atual no dia em que montamos. Para uma instalação que entregamos antes, acontece o mesmo que para qualquer cliente em qualquer script do nosso catálogo: migrar para uma versão mais nova é o serviço padrão de atualização, a 50% do preço da instalação, porque a configuração do seu primeiro setup é reaproveitada. Aplicá-la ao código otimizado é a mesclagem descrita na resposta anterior, e o trabalho é nosso, não seu.
Quais problemas de segurança havia mesmo no script original?
Reproduzidos e depois corrigidos: injeção de SQL sem autenticação alcançável a partir de qualquer listagem de lojas; pedidos e endereço de entrega de qualquer cliente legíveis sem login; gateways de pagamento desligados no admin cujos retornos ainda liquidavam pagamentos; vendedores capazes de editar produtos e banners de outros vendedores; um backdoor de login de demonstração ativo (limitado — levava a uma conta nova com a verificação de telefone contornada, não à tomada de uma conta existente); catorze caminhos do projeto legíveis por HTTPS, incluindo um dump de banco de dados do instalador de 679 KB; toda nota enumerável pela URL; e uma API sem limite de requisições nenhum — 40 tentativas seguidas com senha errada foram todas aceitas, sem limitação e sem nada registrado.
Vai continuar rápido quando minha loja crescer?
Até cerca de 100,000 pedidos, sim: nove telas analisadas nesse volume, com as janelas dos contadores de pedidos desligadas, medem todas 250 ms ou menos, e seis das nove medem 50 ms ou menos. Isso é trinta vezes o volume atual da instalação auditada. Acima disso, leia o teste de escala em Limites honestos acima — não são só vitórias. Com 10,000,000 pedidos contra um banco de dados subdimensionado, a lista de pedidos do admin vai de 27.4 s para 13.6 ms, mas os contadores de despacho continuam em 12 s, os produtos populares em 7.1 s e o relatório de itens de todo o período em 131 s. Esses são números de teste de escala em um banco montado de propósito, não o seu servidor em produção.
Vocês afirmam que não sobrou nenhum defeito?
Não. 342 defeitos foram encontrados e corrigidos. Ninguém consegue enumerar o que resta em uma plataforma deste tamanho. O que podemos mostrar a você é o que foi medido, como medir de novo, e quais itens continuam em aberto — a seção Limites honestos desta página os lista, incluindo as linhas do teste de escala que continuam lentas e as rotas que mitigamos em vez de reescrever.
Com o que vocês ainda não estão satisfeitos?
Várias coisas, e preferimos que você as leia aqui. No teste de escala de 10 milhões de pedidos, seis linhas continuam em um segundo ou mais — a pior é o relatório de itens de todo o período, com 131 segundos, e a execução do original com que ele deveria ser comparado foi interrompida aos 120 segundos, então não podemos afirmar melhora nenhuma ali; os contadores de despacho estão em 12 segundos. Sessenta e quatro rotas do admin e do vendedor ainda mudam estado em um GET simples — o caminho de exploração pelo navegador está fechado e verificado, mas as rotas em si não foram convertidas. E na instalação de referência as chaves do Google Maps estão sem restrição, uma chave do Apple Sign-In precisa ser revogada e reemitida, e três vendedores ainda não têm registro de loja.
Ferramentas complementares
Onde o SixPanel e o SixPreflight se encaixam
Tudo acima é sobre o código do 6amMart em si. Duas ferramentas da AllsWeb ficam de cada lado dele — uma roda o servidor onde a loja vive, a outra diz se um servidor que você já tem está pronto para ela. Os números delas foram medidos em outra época e em máquinas diferentes, então os mantemos em tabelas próprias e nunca os misturamos com os números acima.
SixPanel
Quando você quer o servidor gerenciado
O que é
Um painel de gestão que roda uma loja 6amMart, ou várias, em um único VPS alugado — MariaDB, Redis, nginx, o serviço websocket para o acompanhamento de pedidos ao vivo e uma vitrine Next.js opcional. Dois runtimes: o recomendado instala tudo direto na máquina a partir do próprio arquivo da distribuição do release, sob o systemd, e o SixPanel Docker roda a mesma pilha como serviços do Docker Compose. Um comando de instalação, deploy a partir de um zip do CodeCanyon ou do git, certificados Let's Encrypt automáticos com renovação automática, backups incrementais restic agendados com retenção, hosts virtuais por projeto, autotuning de hardware e um watchdog que se autocorrige e reinicia serviços que estão rodando mas não funcionam. Três superfícies: o painel no navegador, um comando sixpanel no host e o instalador. Vem com um manual do cliente de 24 capítulos, servido dentro do painel.
Medido, e seguro de publicar
| O que foi medido | O número, com suas condições |
|---|---|
| Requisições atendidas — endpoint de busca, 20 simultâneas, 30 segundos | Um servidor de 2 núcleos / 4 GB completou cerca de 53 requisições por segundo no catálogo de uma loja real com 66,701 pedidos, com o banco de dados respondendo 99.99% das leituras a partir da memória. Isso descreve aquele endpoint, aquele conjunto de dados e dois núcleos. Não é um número geral da plataforma. |
| Tempo de instalação sem supervisão | 273 – 303 segundos nos três sistemas operacionais testados — cerca de cinco minutos |
| Velocidade contra um rival afinado | 1,76× mais rápido do que um aaPanel totalmente afinado com um pedido e 1,82× com quatro ao mesmo tempo, em hardware idêntico a correr a mesma loja de 66.701 pedidos — com cerca de 60 % da diferença atribuída a uma restrição de diretórios do PHP, 8 % ao modo JIT errado, 0 % à versão do PHP, e cerca de 32 % publicado como inexplicado |
| Sistema operacional recomendado | Ubuntu 26.04 LTS, atualizações de segurança até abril de 2031. Ubuntu 24.04 LTS e Debian 13 são os outros dois releases suportados — três no total, e nada mais |
Mais uma coisa que vale dizer, porque quase ninguém publica isso. Comparamos três sistemas operacionais em hardware idêntico com os mesmos dados reais. Eles empataram — a diferença entre eles foi menor que a diferença de uma máquina contra si mesma. Então escolhemos pelo tempo restante de suporte, e não pela velocidade, e não vamos citar uma diferença de velocidade que não conseguimos medir.
Limites honestos — SixPanel
- Os backups restauram na mesma máquina. Restaurar em outra máquina deixa para trás a senha do banco de dados e os caminhos da máquina antiga, e a aplicação não consegue conectar até que uma Atualização seja executada; e a rotina de restauração nunca roda o passo de migração do banco de dados, então um dump antigo sob código mais novo fica atrás do esquema. Os dois estão registrados como quebrados — registrados, não corrigidos — e os dois têm uma solução manual.
- O watchdog de autorrecuperação não enxerga dois dos serviços da lista de recursos acima. O serviço de websocket e a vitrine Next.js opcional não têm healthcheck, então o watchdog não os cobre. Item em aberto.
- Um rollback não desfaz migrações de banco de dados. Um rollback de código depois de uma migração exige a restauração de um backup.
- O painel lê o próprio certificado TLS uma vez, na inicialização. A rotina diária de renovação recarrega o nginx, mas não o painel, então o painel precisa de um reinício para pegar um certificado renovado.
- O painel é equivalente a root na máquina por construção — instala pacotes, escreve configuração do sistema e reinicia serviços. No ambiente Docker monta ainda o socket do Docker e monta o diretório da pilha com permissão de escrita.
- Existe exatamente uma conta de administrador e nenhum papel de acesso. Sem múltiplos usuários, sem times.
- Só máquinas de 4 GB foram medidas. Nada nesta página descreve 8 GB ou mais.
Quando o SixPanel se aplica
Você está alugando um VPS e prefere não cuidar do nginx, do ajuste do MariaDB, dos certificados, dos backups e dos deploys — ou quer mais de uma loja em um servidor.
SixPreflight
Quando você quer saber o que vai quebrar antes de entrar no ar
O que é
Uma pequena ferramenta em PHP que você coloca na pasta public/ do seu site Laravel e abre no navegador, protegida por senha. Ela roda cerca de 134 verificações em hardware, PHP, saúde da aplicação, arquivo de ambiente, permissões, servidor web, cache, configurações de banco de dados, exposição pública e todo serviço externo — pagamentos, e-mail, SMS, mapas, push — contatando cada um de verdade em vez de apenas ler uma configuração. Ela dá uma nota em letra, um veredito em linguagem simples e uma lista de correções ordenada por consequência, com um valor pronto para colar sempre que houver um. Você recebe a versão atual.
Na instalação de referência
Ela registrou 103 aprovações, 7 falhas, 24 avisos — e as falhas eram configurações de hospedagem, não defeitos da aplicação.
Quando o SixPreflight se aplica
Está no aaPanel, no CloudPanel ou no cPanel? O SixPreflight é para você. Roda o SixPanel? Essas verificações já estão embutidas na página de check-up da loja dele.
Agora tudo recomenda o mesmo sistema operacional, e o motivo não é velocidade. SixPanel, SixPanel Docker e SixPreflight recomendam todos o Ubuntu 26.04 LTS. O runtime nativo pega PHP, MariaDB, nginx e Redis do próprio arquivo da distribuição do release, e os três releases suportados trazem um conjunto que funciona — o 26.04 dá PHP 8.5 e MariaDB 11.8, o Debian 13 dá 8.4 e 11.8, o Ubuntu 24.04 dá 8.3 e 10.11. Nada disso é uma recomendação de velocidade: em seis eixos medidos, nenhuma troca de versão produziu diferença que valesse relatar, e duas máquinas idênticas byte a byte divergiram 11,6 % uma da outra. O que decide é o tempo de suporte restante — o 26.04 recebe correções até abril de 2031.
De qual eu preciso?
| Sua situação | A resposta |
|---|---|
| Você quer o 6amMart instalado, ou o seu 6amMart atual está lento ou já te prejudicou em preços ou pagamentos | A instalação otimizada do 6amMart |
| Você tem um VPS e não quer cuidar de nginx, MariaDB, SSL, backups e deploys | SixPanel |
| Você já tem um servidor em outro painel e quer saber o que vai quebrar antes do lançamento | SixPreflight |
Cada número desta página foi medido em uma instalação em produção
E a suíte que os mediu vai junto com o seu build.
Precisa de algo construído do zero? Fale conosco sobre trabalho sob medida