À medida que o Avance Network se torna uma fonte importante de tráfego e receita para os editores, os parceiros procuram mais recursos de rastreamento que os ajudem a determinar a quantidade de tráfego gerado pelo Avance Network e como esse tráfego é distribuído pelo site. Além disso, os editores desejam ver essas informações em sua ferramenta analítica de escolha (Omniture, GA, Webtrends etc.).
O Avance Network agora fornece parâmetros de rastreamento que podem ser anexados ao URL das recomendações.
Motivação
Um URL é construído em três partes: prefixo, URL e sufixo reais, onde o prefixo e o sufixo servem como meios para permitir que nossos parceiros adicionem recursos de rastreamento na forma de parâmetros dinâmicos (por exemplo: título, data de publicação e ID). Eventualmente, os parâmetros dinâmicos são adicionados como uma sequência de consultas (campo1 = valor1 e campo2 = valor2 e campo3 = valor3) ao URL da recomendação.
O código legado contrataria as três partes da URL e usaria String replace para adicionar os parâmetros dinâmicos. Essa implementação era difícil de manter (em situações em que queríamos oferecer suporte a parâmetros mais dinâmicos) e também difícil de usar, pois havia a necessidade de importar muito código para um projeto e depender de muitos módulos.
Ao revisitar o problema, entendemos que seria apropriado usar uma abordagem de Separação de Preocupações, separando o modelo do modelo e da própria lógica de transformação - um mecanismo de modelo parecia a escolha certa! Além disso, como parâmetros cada vez mais dinâmicos estavam sendo adicionados, usamos um padrão de construtor para obter um uso mais fácil e limpo para os clientes e uma manutenção mais fácil no futuro.
O problema - usar um mecanismo de modelo não garante melhor desempenho
Decidimos usar o StringTemplate como nosso mecanismo de modelo, pois estávamos familiarizados com ele e tivemos uma boa experiência com ele. O resultado do refator foi uma API mais limpa, mais curta e sustentável.
Infelizmente, quando implantamos as novas alterações na produção, notamos um aumento significativo no tempo de veiculação que era inaceitável em termos de experiência do usuário. Depois de investigar a causa raiz, descobrimos que o uso do StringTemplate era bastante caro. Mesmo que os modelos pudessem ser reutilizados, não foi possível reutilizá-los todos. Por exemplo, criamos um novo modelo para cada solicitação, pois ele foi construído com diferentes parâmetros dinâmicos. (A forma do URL, porém, era a mesma: prefixo, URL e sufixo reais).
Então, naquele momento, tínhamos uma solução limpa e elegante que não estava funcionando bem. Em seguida, procuramos algumas soluções alternativas para o StringTemplate que pudessem economizar o custo dispendioso da construção de um novo modelo para cada solicitação.
A solução - ferramenta certa para o trabalho
Eventualmente, encontramos um mecanismo de modelo leve, que nos permitiu continuar usando a abordagem de Separação de Preocupações e ainda alcançar um bom desempenho. Acabamos usando o Apache Commons Lang 3.0 StrSubstitutor - uma alternativa mais simples ao StringTemplate. Dessa vez, garantimos que ela superou nossa última implementação, realizando alguns micro-benchmarking e, de fato, os resultados foram muito melhores. A nova implementação executou mais de 4 vezes a operação por segundo.
Resultados do MicroBenchmarking
Usamos o Java Microbenchmark Harness para realizar nossas medições de desempenho.
Dados não tratados:
