Método 1: Armazenar dados em cache no método init() do servlet
Depois que o servidor de aplicativos inicializar a instância do servlet e antes de atender às solicitações do cliente, ele chama o método init() do servlet. No ciclo de vida de um servlet, o método init() será chamado apenas uma vez. Armazenando em cache alguns dados estáticos no método init() ou concluindo algumas operações demoradas que só precisam ser executadas uma vez, o desempenho do sistema pode ser bastante melhorado.
Por exemplo, estabelecer um pool de conexões JDBC no método init() é o melhor exemplo. Suponha que usemos a interface DataSource do jdbc2.0 para obter uma conexão de banco de dados. Em circunstâncias normais, precisamos obter dados específicos por meio da fonte JNDI. Podemos imaginar que em uma aplicação específica, se uma consulta JNDI for executada para cada solicitação SQL, o desempenho do sistema cairá drasticamente. A solução é o código a seguir, que armazena em cache o DataSource para que ele ainda possa ser usado durante a próxima chamada SQL:
A seguir está um fragmento de referência:
classe pública ControllerServlet estende HttpServlet{
private javax.sql.DataSource testDS = null;
public void init (configuração ServletConfig) lança ServletException {
super.init(config);
Contexto ctx = nulo;
tentar{
ctx = new InitialContext();
testDS = (javax.sql.DataSource)ctx.lookup("jdbc/testDS");
}catch(NamingException ne){ne.printStackTrace();}
}catch(Exceção e){e.printStackTrace();}
}
público javax.sql.DataSource getTestDS(){
retornar testeDS;
}
...
...
}
Método 2: Desativar recarregamento automático de servlet e JSP (recarregamento automático)
Servlet/JSP fornece uma tecnologia prática, ou seja, tecnologia de recarregamento automático, que fornece aos desenvolvedores um bom ambiente de desenvolvimento quando você altera páginas de servlet e JSP sem precisar reiniciar o servidor de aplicativos. No entanto, esta tecnologia representa uma enorme perda de recursos do sistema durante a fase de execução do produto, pois trará uma enorme carga para o carregador de classes do mecanismo JSP. Portanto, desligar a função de recarga automática é uma grande ajuda para melhorar o desempenho do sistema.
Método 3: Não abuse do HttpSession
Em muitos aplicativos, nosso programa precisa manter o estado do cliente para que as páginas possam se comunicar entre si. Mas, infelizmente, como o HTTP é inerentemente sem estado, ele não pode salvar o estado do cliente. Portanto, os servidores de aplicativos gerais fornecem sessões para salvar o estado do cliente. No servidor de aplicativos JSP, a função de sessão é implementada por meio do objeto HttpSession, mas embora seja conveniente, também traz muita carga para o sistema. Porque toda vez que você obtém ou atualiza uma sessão, o operador do sistema precisa realizar operações de serialização demoradas nela. Você pode melhorar o desempenho do sistema por meio dos seguintes métodos de processamento para HttpSession.
Caso não seja necessário, as configurações padrão de HttpSession na página JSP deverão ser desativadas. Cada página JSP criará uma HttpSession por padrão se você não especificá-la explicitamente. Se você não precisa usar sessão em seu JSP, você pode desabilitá-la através do seguinte indicador de página JSP:
A seguir está um fragmento de referência:
＜%@ sessão da página="false"%＞
Não armazene objetos de dados grandes em HttpSession: Se você armazenar objetos de dados grandes em HttpSession, o servidor de aplicativos os serializará sempre que forem lidos ou gravados, adicionando carga extra ao sistema. Quanto maior o objeto de dados armazenado em HttpSession, mais rápido o desempenho do sistema diminuirá.
Quando você não precisar mais da HttpSession, libere-a o mais rápido possível: Quando não precisar mais da sessão, você pode liberá-la chamando o método HttpSession.invalidate(). Tente definir o tempo limite da sessão o mais curto possível: No servidor de aplicativos JSP, há um tempo limite de sessão padrão. Quando o cliente não realizar nenhuma operação após esse período, o sistema liberará automaticamente a sessão relevante da memória. Quanto maior for o tempo limite definido, menor será o desempenho do sistema, portanto a melhor forma é tentar manter seu valor o mais baixo possível.
Método 4: compactar a saída da página
é uma boa maneira de resolver a redundância de dados, especialmente hoje em dia, quando a largura de banda da rede não está desenvolvida o suficiente. Alguns navegadores suportam gzip (GNU zip) para compactar arquivos HTML. Este método pode reduzir drasticamente o tempo de download de arquivos HTML. Portanto, se você compactar a página HTML gerada por um servlet ou página JSP, o usuário sentirá que a velocidade de navegação da página será muito rápida. Infelizmente, nem todos os navegadores suportam compactação gzip, mas você pode verificar em seu programa se o navegador do cliente oferece suporte. A seguir está um trecho de código sobre a implementação deste método:
A seguir está um trecho de cotação:
public void doGet (solicitação HttpServletRequest, resposta HttpServletResponse)
lança IOException, ServletException {
OutputStream out = null;
Codificação de string = request.getHeader("Accept-Encoding");
if (encoding != null && encoding.indexOf("gzip") != -1){
request.setHeader("Codificação de conteúdo", "gzip");
saída = novo GZIPOutputStream(request.getOutputStream());
}
senão if (encoding != null && encoding.indexOf("comdivss") != -1){
request.setHeader("Content-Encoding", "comdivss");
saída = novo ZIPOutputStream(request.getOutputStream());
}outro{
saída = request.getOutputStream();
}
...
...
}
Método 5: Use o pool de threads.
O servidor de aplicativos cria um thread para processar cada solicitação de cliente diferente por padrão e atribui o método service() a eles. Quando a chamada do método service() é concluída, o thread correspondente também é cancelado. . Como a criação e destruição de threads consome determinados recursos do sistema, esse modo padrão reduz o desempenho do sistema. Mas felizmente podemos mudar esta situação criando um pool de threads.
Além disso, também precisamos definir um número mínimo de threads e um número máximo de threads para este pool de threads. Quando o servidor de aplicativos for iniciado, ele criará um pool de threads com um número igual ao número mínimo de threads. Quando um cliente faz uma solicitação, um thread é retirado do pool para processamento. coloque de volta no meio da piscina. Se não houver threads suficientes no pool, o sistema aumentará automaticamente o número de threads no pool, mas o número total não pode exceder o número máximo de threads. Ao usar o pool de threads, quando as solicitações do cliente aumentam acentuadamente, a carga do sistema mostrará uma curva ascendente suave, melhorando assim a escalabilidade do sistema.
Método 6: Escolha o mecanismo de inclusão de página correto
Existem dois métodos em JSP que podem ser usados para incluir outra página:
1. Use a diretiva include
A seguir está um fragmento de referência:
＜%@ arquivo incluído=”test.jsp”%＞
2. Use o indicador jsp
A seguir está um fragmento de referência:
Na prática, verifica-se que se o primeiro método for utilizado, o desempenho do sistema pode ser superior.
Método 7: Determinar corretamente o ciclo de vida dos javabeans
Um dos aspectos poderosos do JSP é o suporte para javabeans. JavaBeans pode ser inserido diretamente em uma página JSP usando a tag jsp:useBean na página JSP. Veja como usá-lo:
Aqui está um trecho de citação:
＜/jsp:useBean＞
O atributo scope aponta o ciclo de vida deste bean. O ciclo de vida padrão é página. Se você não escolher o ciclo de vida do bean corretamente, isso afetará o desempenho do sistema.
Por exemplo, se você quiser usar apenas um determinado bean em uma solicitação, mas definir o ciclo de vida do bean como sessão, quando a solicitação terminar, o bean ainda permanecerá na memória, a menos que o tempo limite da sessão ou o usuário feche o navegador. Isso consumirá uma certa quantidade de memória e aumentará desnecessariamente a carga de trabalho do coletor de lixo da JVM. Portanto, definir o ciclo de vida correto para os beans e limpá-los o mais rápido possível após o término de sua missão melhorará o desempenho do sistema.
Alguns outros métodos úteis
1. Tente não usar o operador "+" em operações de conexão de string: Na programação Java, costumamos usar o operador "+" para conectar várias strings, mas você pode nunca ter pensado nisso. desempenho do sistema? Como as strings são constantes, a JVM gerará alguns objetos temporários. Quanto mais "+" você usar, mais objetos temporários serão gerados, o que também terá algum impacto no desempenho do sistema. A solução é usar um objeto StringBuffer em vez do operador “+”.
2. Evite usar o método System.out.println(): Como System.out.println() é uma chamada síncrona, ou seja, ao chamá-la, a operação de E/S do disco deve aguardar sua conclusão, então devemos tentar para evitar usá-lo. Mas é uma ferramenta indispensável e conveniente quando depuramos o programa. Para resolver esta contradição, sugiro que você use a ferramenta Log4j ( http://Jakarta.apache.org ), que pode facilitar a depuração sem métodos como System.out. .println() será gerado.
3. Compensação entre ServletOutputStream e PrintWriter: O uso de PrintWriter pode trazer uma pequena sobrecarga, porque converte toda a saída original em um fluxo de caracteres para saída, portanto, se for usado como saída de página, o sistema terá que suportar um processo de conversão. Não há problema se você usar ServletOutputStream como saída de página, mas a saída é binária. Portanto, os prós e os contras de ambos devem ser avaliados em aplicações práticas.
Resumo
O objetivo deste artigo é melhorar significativamente o desempenho da sua aplicação através de algumas técnicas de ajuste para servlets e JSP e, portanto, melhorar o desempenho de toda a aplicação J2EE. Através dessas técnicas de ajuste, você pode descobrir que não é uma determinada plataforma técnica (como a disputa entre J2EE e .NET) que determina o desempenho da sua aplicação. Só então você poderá otimizar fundamentalmente seu aplicativo.