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 demandes 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 toujours être utilisé lors du prochain appel SQL :
Ce qui suit est un fragment de référence :
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();}
}catch(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 lorsque vous modifiez les pages de servlet et JSP sans avoir à redémarrer le serveur d'applications. 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 grâce aux méthodes de traitement suivantes pour HttpSession.
Si cela n'est pas nécessaire, les paramètres par défaut de HttpSession dans la page JSP doivent être désactivés. Chaque page JSP créera une HttpSession par défaut si vous ne la spécifiez pas explicitement. 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 :
Ce qui suit est un fragment de référence :
＜%@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 : La compression de la sortie des pages
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. Ce qui suit est un extrait de code sur l'implémentation de cette méthode :
Ce qui suit est un extrait de citation :
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 mécanisme d'inclusion de page approprié.
Il existe deux méthodes dans JSP qui peuvent être utilisées pour inclure une autre page :
1. Utilisez la directive include.
Ce qui suit est un fragment de référence :
＜%@includee file="test.jsp" %＞
2. Utilisez l'indicateur jsp.
Ce qui suit est un fragment de référence :
En pratique, on constate que si la première méthode est utilisée, les performances du système peuvent être plus élevées.
Méthode 7 : Déterminer correctement le cycle de vie des javabeans.
L'un des aspects puissants de JSP est sa prise en charge des javabeans. Les JavaBeans peuvent être insérés directement dans une page JSP en utilisant la balise jsp:useBean dans la page JSP. Voici comment l'utiliser :
Voici un extrait de citation :
＜/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.
Quelques autres méthodes utiles
1. Essayez de ne pas utiliser l'opérateur "+" dans les opérations de connexion de chaînes : dans la programmation Java, nous utilisons souvent l'opérateur "+" pour connecter plusieurs chaînes, mais vous n'y avez peut-être jamais pensé. performances du système ? Étant donné que 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 "+".
2. É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 sa fin, nous devrions donc essayer pour éviter de l'utiliser son appel. Mais c'est un outil indispensable et pratique lorsque nous déboguons le programme. Afin de résoudre cette contradiction, je vous suggère d'utiliser l'outil Log4j ( http://Jakarta.apache.org ), qui peut faciliter le débogage sans méthodes comme System.out. .println() sera généré.
3. Compromis entre ServletOutputStream et PrintWriter : l'utilisation de PrintWriter peut entraîner une petite surcharge, car elle convertit toute la sortie originale 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ésumé
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 donc 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.