Méthode 1 : mettre en cache les données dans la méthode init() du servlet
Une fois que le serveur d'applications a initialisé l'instance de servlet et avant de répondre aux requêtes des clients, il appelle la méthode init() du servlet. Dans le cycle de vie d'une servlet, la méthode init() ne sera appelée qu'une seule fois. En mettant en cache certaines données statiques dans la méthode init() ou en effectuant certaines opérations fastidieuses qui ne doivent être effectuées qu'une seule fois, les performances du système peuvent être considérablement améliorées.
Par exemple, l'établissement d'un pool de connexions JDBC dans la méthode init() est le meilleur exemple. Supposons que nous utilisions l'interface DataSource de jdbc2.0 pour obtenir une connexion à la base de données. Dans des circonstances normales, nous devons obtenir des données spécifiques via la source JNDI. On peut imaginer que dans une application spécifique, si une requête JNDI est exécutée pour chaque requête SQL, les performances du système chuteront fortement. La solution est le code suivant, qui met en cache le DataSource afin qu'il puisse continuer à être utilisé lors du prochain appel SQL :
la classe publique ControllerServlet étend HttpServlet
{
privé javax.sql.DataSource testDS = null ;
public void init (configuration ServletConfig) lance ServletException
{
super.init(config);
Contexte ctx = nul ;
essayer
{
ctx = nouveau InitialContext();
testDS = (javax.sql.DataSource)ctx.lookup("jdbc/testDS";
}
catch(NamingException ne)
{
ne.printStackTrace();
}
attraper (Exception e)
{
e.printStackTrace();
}
}
public javax.sql.DataSource getTestDS()
{
retourner testDS ;
}
...
...
}
Méthode 2 : Désactiver le rechargement automatique des servlets et JSP (rechargement automatique)
Servlet/JSP fournit une technologie pratique, à savoir la technologie de rechargement automatique, qui offre aux développeurs un bon environnement de développement sans avoir à redémarrer le serveur d'applications lorsque vous changez de servlet et de pages JSP. Cependant, cette technologie représente une énorme perte de ressources système pendant la phase d'exécution du produit, car elle imposera une charge énorme au chargeur de classes du moteur JSP. Par conséquent, la désactivation de la fonction de rechargement automatique est d’une grande aide pour améliorer les performances du système.
Méthode 3 : N’abusez pas de HttpSession
Dans de nombreuses applications, notre programme doit maintenir l'état du client afin que les pages puissent communiquer entre elles. Mais malheureusement, comme HTTP est intrinsèquement sans état, il ne peut pas sauvegarder l'état du client. Par conséquent, les serveurs d'applications générales proposent des sessions pour sauvegarder l'état du client. Dans le serveur d'applications JSP, la fonction de session est implémentée via l'objet HttpSession, mais bien que cela soit pratique, cela apporte également beaucoup de charge au système. Car chaque fois que vous obtenez ou mettez à jour une session, l’opérateur système doit y effectuer de longues opérations de sérialisation. Vous pouvez améliorer les performances du système en gérant HttpSession des manières suivantes :
Si ce n'est pas nécessaire, vous devez désactiver le paramètre par défaut de HttpSession dans la page JSP : Si vous ne le spécifiez pas explicitement, chaque page JSP créera une HttpSession par défaut. Si vous n'avez pas besoin d'utiliser la session dans votre JSP, vous pouvez la désactiver via l'indicateur de page JSP suivant :
＜%@page session="false"%＞
Ne stockez pas d'objets de données volumineux dans HttpSession : si vous stockez des objets de données volumineux dans HttpSession, le serveur d'applications les sérialisera à chaque fois qu'ils seront lus ou écrits, ajoutant ainsi une charge supplémentaire au système. Plus l'objet de données que vous stockez dans HttpSession est volumineux, plus les performances du système diminueront rapidement.
Lorsque vous n'avez plus besoin de la HttpSession, libérez-la dès que possible : Lorsque vous n'avez plus besoin de la session, vous pouvez la libérer en appelant la méthode HttpSession.invalidate().
Essayez de définir le délai d'expiration de session aussi court que possible : Dans le serveur d'applications JSP, il existe un délai d'expiration de session par défaut. Lorsque le client n'effectue aucune opération après ce délai, le système libère automatiquement la session concernée de la mémoire. Plus le délai d'expiration est long, plus les performances du système seront faibles. Le meilleur moyen est donc d'essayer de maintenir sa valeur aussi basse que possible.
Méthode 4 : Compresser la sortie de la page
La compression est un bon moyen de résoudre la redondance des données, surtout aujourd'hui où la bande passante du réseau n'est pas suffisamment développée. Certains navigateurs prennent en charge gzip (GNU zip) pour compresser les fichiers HTML. Cette méthode peut réduire considérablement le temps de téléchargement des fichiers HTML. Par conséquent, si vous compressez la page HTML générée par un servlet ou une page JSP, l'utilisateur aura l'impression que la vitesse de navigation de la page sera très rapide. Malheureusement, tous les navigateurs ne prennent pas en charge la compression gzip, mais vous pouvez vérifier dans votre programme si le navigateur du client la prend en charge. Voici un extrait de code de la façon dont cette méthode est implémentée :
public void doGet (demande HttpServletRequest, réponse HttpServletResponse)
lance IOException, ServletException
{
SortieStream = null
Encodage de chaîne = request.getHeader("Accept-Encoding";
if (encoding != null && encoding.indexOf("gzip" != -1)
{
request.setHeader("Content-Encoding" , "gzip";
out = new GZIPoutputStream(request.getOutputStream());
}
sinon if (encoding != null && encoding.indexOf("comdivss" != -1)
{
request.setHeader("Content-Encoding" , "comdivss";
out = new ZIPOutputStream(request.getOutputStream());
}
autre
{
out = request.getOutputStream();
}
...
...
}
Méthode 5 : utiliser le pool de threads.
Le serveur d'applications crée un thread pour traiter chaque demande client différente par défaut et leur affecte la méthode service(). Lorsque l'appel de la méthode service() est terminé, le thread correspondant est également annulé. . Étant donné que la création et la destruction de threads consomment certaines ressources système, ce mode par défaut réduit les performances du système. Mais heureusement, nous pouvons changer cette situation en créant un pool de threads. De plus, nous devons également définir un nombre minimum de threads et un nombre maximum de threads pour ce pool de threads. Lorsque le serveur d'applications démarre, il crée un pool de threads avec un nombre égal au nombre minimum de threads. Lorsqu'un client a une demande, un thread est retiré du pool pour être traité. Une fois le traitement terminé, le thread est supprimé. remettre dans la piscine. S'il n'y a pas assez de threads dans le pool, le système augmentera automatiquement le nombre de threads dans le pool, mais le nombre total ne peut pas dépasser le nombre maximum de threads. En utilisant le pool de threads, lorsque les demandes des clients augmentent fortement, la charge du système affichera une courbe ascendante douce, améliorant ainsi l'évolutivité du système.
Méthode 6 : Choisissez le bon mécanisme d'inclusion de pages
Il existe deux manières d'inclure une autre page dans JSP : 1. Utilisez l'indicateur d'inclusion (<%@ includee file="test.jsp" %>). 2. Utilisez l'indicateur jsp (
Méthode 7 : Déterminer correctement le cycle de vie des javabeans
L'une des fonctionnalités puissantes de JSP est sa prise en charge des javabeans. En utilisant la balise
＜jsp:useBean id="name" scope="page|request|session|application" class=
"package.className" type="typeName"＞
＜/jsp:useBean＞
L'attribut scope indique le cycle de vie de ce bean. Le cycle de vie par défaut est page. Si vous ne choisissez pas correctement le cycle de vie du bean, cela affectera les performances du système.
Par exemple, si vous souhaitez utiliser un certain bean dans une seule requête, mais que vous définissez le cycle de vie du bean sur session, lorsque la requête se termine, le bean restera toujours en mémoire à moins que le délai d'expiration de la session ou que l'utilisateur ne ferme le navigateur. Cela consommera une certaine quantité de mémoire et augmentera inutilement la charge de travail du garbage collector JVM. Par conséquent, définir le cycle de vie correct des beans et les nettoyer dès que possible une fois leur mission terminée améliorera les performances du système.
d'autres méthodes
Essayez de ne pas utiliser l'opérateur "+" dans les opérations de concaténation de chaînes : en programmation Java, nous utilisons souvent l'opérateur "+" pour connecter plusieurs chaînes, mais vous n'avez peut-être jamais pensé que cela affecterait réellement les performances du système. Puisque les chaînes sont des constantes, la JVM générera des objets temporaires. Plus vous utilisez de « + », plus d'objets temporaires seront générés, ce qui aura également un certain impact sur les performances du système. La solution consiste à utiliser un objet StringBuffer au lieu de l'opérateur "+".
Évitez d'utiliser la méthode System.out.println() : puisque System.out.println() est un appel synchrone, c'est-à-dire que lors de son appel, l'opération d'E/S disque doit attendre qu'elle soit terminée, nous devrions donc essayer d'éviter l'utiliser. Mais c'est un outil indispensable et pratique lorsque l'on débogue le programme. Afin de résoudre cette contradiction, je vous suggère d'utiliser l'outil Log4j, qui peut faciliter le débogage sans générer la méthode System.out.println().
Compromis entre ServletOutputStream et PrintWriter : L'utilisation de PrintWriter peut entraîner une petite surcharge, car elle convertit toute la sortie brute en un flux de caractères pour la sortie, donc s'il est utilisé comme sortie de page, le système doit supporter un processus de conversion. Il n'y a aucun problème si vous utilisez ServletOutputStream comme sortie de page, mais la sortie est en binaire. Par conséquent, les avantages et les inconvénients des deux doivent être pesés dans leurs applications pratiques.
Résumer
Le but de cet article est d'améliorer considérablement les performances de votre application grâce à quelques techniques de réglage des servlets et JSP, et ainsi d'améliorer les performances de l'ensemble de l'application J2EE. Grâce à ces techniques de réglage, vous constaterez que ce n'est pas une certaine plate-forme technique (comme le différend entre J2EE et .NET) qui détermine les performances de votre application. Ce qui est important, c'est que vous ayez une compréhension plus approfondie de cette plate-forme, donc. Ce n'est qu'alors que vous pourrez optimiser fondamentalement votre application !