Antes de se propor à execução de performance tuning, certifique-se de que o problema a ser atacado realmente é performance, e não outra coisa qualquer. Cada cliente tem problemas próprios e, naturalmente, necessidades específicas de tuning. Às vezes, o consumo de memória em demasia por não ser necessariamente um problema para o órgão X, que conta com 500TB de memória em seus servidores, mas pode ser o calcanhar de aquiles para outra instituição, que sofre de carência de recursos computacionais. Descubra o que aflige seu cliente e ajude-o, com ou sem tuning.
(...)não necessariamente o melhor ganho esteja em ajustes do JBoss, mas na configuração da rede, no sistema operacional, no banco de dados ou na própria aplicação em cheque. Às vezes, uma única linha de código pode resolver todo o gargalo que tanto incomoda seu cliente.
No dia-a-dia, chamamos essas restrições de gargalos. Esses gargalos são os pontos que representam problemas no uso dos recursos computacionais disponíveis (pra mais ou pra menos). Na prática então, o que ocorre num trabalho de tuning é a busca incessante desses gargalos, a fim de eliminá-los. Mas, sempre que um gargalo é desfeito, outro é criado (essa é a teoria), e o desafio é decidirmos até que ponto essa busca vale a pena.
Num processo de tuning, mesmo antes de se saber ao certo o ponto exato do tuning, é preciso estabelecer alguma estratégia de varredura, que deve ser seguida à risca para que todos os potenciais pontos de gargalo sejam avaliados. A não obediência do padrão pré-estabelecido de pesquisa abre lacunas colaboradoras ao fracasso de todo esforço empreendido.
Dentro do processo de tuning em si, é essencial a busca incessante do menor esforço que gerará o maior benefício (Pareto). Em primeira instância, deve-se avaliar a curva de custo/benefício da contratação. Por exemplo, se o problema relatado pelo cliente é “o servidor cai por OutOfMemoryError sempre que o sistema atinge 400 usuários simultâneos”, pode sair mais barata a aquisição de mais pentes de memória do que a execução de um processo de tuning para investigação de memory leaks na aplicação ou o reajsute de parâmetros de inicialização do servidor.
No papel de consultoria externa tida como a salvação da pátria, qualquer passo em falso pode desencadear conflitos capazes de inviabilizar todo o trabalho.
Assim, sempre sob a luz do ROI, é essencial conhecer quais fatores cujo alinhamento contribuem para o problema em questão, para que só então se tome a decisão certa sobre o próximo passo do tuning, de preferência, a que apresentar o melhor custo/benefício.
Num processo de tuning, não existe o cara do banco, o cara do JBoss e o desenvolvedor da aplicação, mas sim a equipe responsável por resolver o problema em pauta, seja ele qual for. Neste modelo, ao invés de ficar cada um no seu quadrado, todos circulam além das fronteiras de sua especialidade, abraçando a mesma causa e colaborando um com ou outro para o sucesso global da iniciativa.
Não existe receita de bolo para tuning. Se existisse, todo servidor JBoss já viria tunado de fábrica.
E, por definição, o processo de tuning é lento, empírico e gradual, que exige muita concentração e perseverança.