Descrição do projeto
TraduzidoExecutamos um catálogo online que vem crescendo há seis anos, e finalmente ele ultrapassou a máquina em que está hospedado. As páginas de categoria levam cerca de cinco segundos para abrir, a busca no catálogo é pior, e nas horas de pico o site inteiro parece travado. O banco de dados ainda está no servidor antigo, enquanto o novo já está pago e preparado. Estou procurando alguém que mova os dados com o mínimo de tempo de inatividade possível — por meio de um plano escrito, com um ensaio e uma janela de troca acordada, não simplesmente desligando tudo numa sexta-feira à noite e torcendo.
A segunda metade do trabalho é tão importante quanto, porque pagar por uma máquina mais rápida e manter as mesmas consultas lentas não faz sentido. Por favor, leia o registro de consultas lentas na íntegra, diga-nos honestamente o que realmente consome tempo, adicione os índices que estão faltando, reescreva os selects pesados e substitua as páginas que buscam a tabela inteira e a cortam no código com paginação real. O que as pessoas mais solicitam deve ser armazenado em cache, e o cache deve se atualizar em vez de servir os preços de ontem. Após a mudança, espero uma verificação completa de todo o site — seções, formulários, busca, contas de usuário — além de uma breve instrução em linguagem simples que nossos próprios administradores possam realmente seguir.
Medições de antes e depois fazem parte do trabalho, não um bônus: quero números, não impressões.
Condições que não vou flexibilizar:
— a migração é ensaiada em uma cópia, e o banco de dados de produção não é tocado até que essa cópia tenha sido verificada;
— cada alteração de esquema é precedida por um backup cujo restauro foi testado, não apenas criado;
— nada é alterado ao vivo durante horas de pico — todos os passos arriscados acontecem dentro da janela de silêncio acordada;
— cada índice e cada consulta reescrita vem com seu próprio tempo antes e depois;
— o relatório final diz o que foi alterado, por que foi alterado e como reverter.
A segunda metade do trabalho é tão importante quanto, porque pagar por uma máquina mais rápida e manter as mesmas consultas lentas não faz sentido. Por favor, leia o registro de consultas lentas na íntegra, diga-nos honestamente o que realmente consome tempo, adicione os índices que estão faltando, reescreva os selects pesados e substitua as páginas que buscam a tabela inteira e a cortam no código com paginação real. O que as pessoas mais solicitam deve ser armazenado em cache, e o cache deve se atualizar em vez de servir os preços de ontem. Após a mudança, espero uma verificação completa de todo o site — seções, formulários, busca, contas de usuário — além de uma breve instrução em linguagem simples que nossos próprios administradores possam realmente seguir.
Medições de antes e depois fazem parte do trabalho, não um bônus: quero números, não impressões.
Condições que não vou flexibilizar:
— a migração é ensaiada em uma cópia, e o banco de dados de produção não é tocado até que essa cópia tenha sido verificada;
— cada alteração de esquema é precedida por um backup cujo restauro foi testado, não apenas criado;
— nada é alterado ao vivo durante horas de pico — todos os passos arriscados acontecem dentro da janela de silêncio acordada;
— cada índice e cada consulta reescrita vem com seu próprio tempo antes e depois;
— o relatório final diz o que foi alterado, por que foi alterado e como reverter.
Desenvolvimento de software Dinheiro, Transferência bancária
