Recevez-vous souvent des plaintes de clients concernant la vitesse de réponse lente des pages JSP ? Avez-vous déjà réfléchi à la manière dont votre application WEB peut résister au nombre croissant de visites lorsque le nombre de visites clients augmente considérablement ? Cet article décrit quelques méthodes très pratiques pour ajuster JSP et les servlets, qui peuvent rendre vos pages de servlet et JSP plus réactives et plus évolutives. De plus, à mesure que le nombre d’utilisateurs augmente, la charge du système affichera une tendance à la hausse douce. Dans cet article, j'utiliserai quelques exemples pratiques et méthodes de configuration pour améliorer les performances de votre application de manière inattendue. Certaines de ces techniques de réglage sont implémentées dans votre travail de programmation. D'autres technologies sont liées à la configuration du serveur d'applications. Dans cet article, nous décrirons en détail comment améliorer les performances globales de votre application en ajustant les servlets et les pages JSP. Avant de lire cet article, il est supposé que vous possédez des connaissances de base sur les servlets et JSP.
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 :
public class ControllerServlet extends 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 des 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 changez de servlet et de page JSP sans avoir à redémarrer l'application. serveur. 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 cela n'est pas nécessaire, vous devez désactiver les paramètres par défaut de HttpSession dans la page JSP : Si vous ne le spécifiez pas explicitement, chaque page JSP affichera par défaut Créer une session Http. . Si vous n'avez pas besoin d'utiliser une 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 avez un volume de données volumineux Si l'objet est stocké dans HttpSession, le serveur d'applications le sérialisera à chaque fois qu'il sera lu ou écrit, 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 : sur 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 pour l'implémentation de cette méthode :
public void doGet (requête 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("compress") != -1)
{
request.setHeader("Content-Encoding", "compresser");
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 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'un des aspects puissants de JSP est sa prise en charge des javabeans. En utilisant la balise
＜/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
: 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'y avez peut-être jamais pensé. Cela affectera en fait le système. performances, non ? 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 de évitez de l'utiliser pour appeler. 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é.
· 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é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 !