Método 1: armazenar dados em cache no método init() do servlet
Após 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 possa continuar a ser usado durante a próxima chamada SQL:
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 não)
{
ne.printStackTrace();
}
pegar(Exceção e)
{
e.printStackTrace();
}
}
public 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 recarga automática, que fornece aos desenvolvedores um bom ambiente de desenvolvimento sem a necessidade de reiniciar o servidor de aplicativos quando você altera as páginas do servlet e JSP. 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 muitas aplicações, 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 manipulando HttpSession das seguintes maneiras:
Se não for necessário, você deve desativar a configuração padrão de HttpSession na página JSP: Se você não especificar explicitamente, cada página JSP criará uma HttpSession por padrão. Caso não precise utilizar session em seu JSP, você pode desabilitá-la através do seguinte indicador de página JSP:
＜%@ 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 saída da página
A compactação é 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. Aqui está um trecho de código de como esse método é implementado:
public void doGet (solicitação HttpServletRequest, resposta HttpServletResponse)
lança IOException, ServletException
{
SaídaStream fora = nulo
Codificação de string = request.getHeader("Accept-Encoding";
if (codificação! = null && codificação.indexOf("gzip"! = -1)
{
request.setHeader("Codificação de conteúdo", "gzip";
saída = novo GZIPOutputStream(request.getOutputStream());
}
senão if (codificação! = null && codificação.indexOf ("comdivss"! = -1)
{
request.setHeader("Codificação de conteúdo", "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 correto de inclusão de página
Existem duas maneiras de incluir outra página em JSP: 1. Utilize o indicador de inclusão (<%@ includee file="test.jsp" %>). 2. Use o indicador jsp (<jsp:includee page="test.jsp" flush="true"/>). Na prática, descobri que se você usar o primeiro método, o desempenho do sistema pode ser maior.
Método 7: Determinar corretamente o ciclo de vida dos javabeans
Um dos recursos poderosos do JSP é o suporte para javabeans. Usando a tag <jsp:useBean> na página JSP, os javabeans podem ser inseridos diretamente em uma página JSP. Veja como usá-lo:
＜jsp:useBean id="name" scope="page|request|session|application" class=
"package.className" type="typeName"＞
＜/jsp:useBean＞
O atributo scope indica 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.
outros métodos
Tente não usar o operador "+" em operações de concatenação de strings: Na programação Java, costumamos usar o operador "+" para conectar várias strings, mas você pode nunca ter pensado que isso realmente afetaria o desempenho do sistema. Como as strings são constantes, a JVM irá 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 “+”.
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 evitar usando-o. Mas é uma ferramenta indispensável e conveniente quando depuramos o programa. Para resolver esta contradição, sugiro que você use a ferramenta Log4j, que pode facilitar a depuração sem gerar o método System.out.println().
Compensações entre ServletOutputStream e PrintWriter: Usar PrintWriter pode trazer uma pequena sobrecarga, porque converte toda a saída bruta 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.
Resumir
O objetivo deste artigo é melhorar bastante o desempenho da sua aplicação através de algumas técnicas de ajuste de servlets e JSP, e assim 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. que só então você poderá otimizar fundamentalmente seu aplicativo!