Bug #2037
fermé
Gros problèmes de lenteur suite à migration
Description
Suite à une migration de Silverpeas 5.4.2 vers Silverpeas 5.6 avec JBoss 6 la navigation dans les espaces et dans les thèmes est très lentes.
Des exceptions apparaissent dans les logs (voir pièces jointes).
Fichiers
| server.log (175 ko) server.log | |||
| Sampler.png (104 ko) Sampler.png | |||
| PileAppel.png (63,8 ko) PileAppel.png |
Mis à jour par Sebastien Vuillet il y a presque 13 ans
J'ai un site web qui lui tourne très bien.
J'ai l'impression que c'est les requêtes AJAX dans Silverpeas qui sont lentes...
Mis à jour par Emmanuel Hugonnet il y a presque 13 ans
- Catégorie mis à Authentification
- Assigné à mis à Emmanuel Hugonnet
- Version cible mis à Version 5.7
Les exceptions sont dues à une mauvaise fermeture des connexions JDBC dans le domain silverpeas.
Cela a été corrigé dans ma branche killing_schemas qui est une réecriture complète du domaine utilisant JPA.
Mis à jour par Sebastien Vuillet il y a presque 13 ans
Ok. Est-ce que ces exceptions expliqueraient les lenteurs que je constate ?
Mis à jour par Sebastien Vuillet il y a presque 13 ans
L'exception suivant me parait bizarre :
2011-05-26 16:36:22,153 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/silverpeas].[AjaxServletSilverpeasV5]] (http-8000-11) "Servlet.service()" pour la servlet AjaxServletSilverpeasV5 a généré une exception: java.lang.NullPointerException
at com.silverpeas.lookV5.AjaxServletLookV5.doPost(AjaxServletLookV5.java:93) [:2.5.1]
at com.silverpeas.lookV5.AjaxServletLookV5.doGet(AjaxServletLookV5.java:81) [:2.5.1]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:734) [:1.0.0.Final]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [:1.0.0.Final]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:324) [:6.0.0.Final]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [:6.0.0.Final]
at com.silverpeas.whitePages.filters.ComponentRequestRouterFilter.doFilter(ComponentRequestRouterFilter.java:93) [:2.5.1]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:274) [:6.0.0.Final]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [:6.0.0.Final]
at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:88) [:3.0.5.RELEASE]
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76) [:3.0.5.RELEASE]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:274) [:6.0.0.Final]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242) [:6.0.0.Final]
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [:6.0.0.Final]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) [:6.0.0.Final]
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:181) [:6.0.0.Final]
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:501) [:6.0.0.Final]
at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.event(CatalinaContext.java:285) [:1.1.0.Final]
at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.invoke(CatalinaContext.java:261) [:1.1.0.Final]
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:88) [:6.0.0.Final]
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:100) [:6.0.0.Final]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) [:6.0.0.Final]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [:6.0.0.Final]
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158) [:6.0.0.Final]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [:6.0.0.Final]
at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.invoke(ActiveRequestResponseCacheValve.java:53) [:6.0.0.Final]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [:6.0.0.Final]
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [:6.0.0.Final]
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:654) [:6.0.0.Final]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) [:6.0.0.Final]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
Mis à jour par Nicolas Eysseric il y a presque 13 ans
- Catégorie
Authentificationsupprimé - Assigné à
Emmanuel Hugonnetsupprimé - Version cible
Version 5.7supprimé
L'intranoo fonctionne malgré le problème de non fermeture des connexions.
D'ailleurs l'intranoo ne présente pas de problèmes de lenteurs !
Mis à jour par Nicolas Eysseric il y a presque 13 ans
- Statut changé de New à Feedback
Pour la dernière exception, il s'agit d'un NPE qui survient lorsque la session s'est terminée automatiquement.
Il faudrait prévenir cette exception. Mais elle ne peut pas expliquer l'origine des lenteurs que tu constates...
Mis à jour par Sebastien Vuillet il y a presque 13 ans
J'ai l'impression que cela vient de l'environnement... Linux, postgresql, java sun hotspot 64 bits. Que ce soit avec jboss 6 ou 4 c'est parait...
Mis à jour par Sebastien Vuillet il y a presque 13 ans
Je pense que la migration n'est pas en cause. Avec une version silverpeas 5.6 et jboss 6 fraichement installée et sans données , les problèmes de lenteur sont présents...
Mis à jour par Ludovic Bertin il y a presque 13 ans
Je rencontre aussi des problèmes de lenteurs sur les requetes ajax chez nos chtis...
Mis à jour par Sebastien Vuillet il y a presque 13 ans
Par élimination, je dirais que cela ne vient pas de :
- Jboss : en version 4 ou 6 cela ne change rien
- Postgresql : en accès distant avec un autre poste et un autre Silverpeas il n'y a pas de pb
- Java : il n'y pas de problème avec les versions de Silverpeas antérieures à la 5.6
J'ai bien l'impression que c'est Silverpeas qui entre en concurrence avec autre chose, mais quoi ?
Ludo, tu rencontres le problème en local ou en remote ?
Mis à jour par Sebastien Vuillet il y a presque 13 ans
- Fichier Sampler.png Sampler.png ajouté
- Fichier PileAppel.png PileAppel.png ajouté
Après profiling avec VisualVM, une méthode semble prendre plus de temps que les autres : com.stratelia.webactiv.kmelia.control.KmeliaSessionController.getTopic()
Voici éléments en pièce jointe.
Mis à jour par Sebastien Vuillet il y a presque 13 ans
La méthode getTopic() est "synchronized". Y a-t-il une raison à cela ? ça cela est coûteux... Le problème vient peut être de là.
Mis à jour par Sebastien Vuillet il y a presque 13 ans
Le problème vient bien du fait que cette méthode est "synchronized" je viens de faire le test est retirant le mot clé synchronized et la différence de performance est flagrant (affichage quasi instantané).
J'ai remarqué qu'il y a beaucoup de méthodes synchronized dans cette classe, si ce n'est pas justifié, il serait préférable de les retirer pour des raisons de performances...
Mis à jour par Emmanuel Hugonnet il y a presque 13 ans
Dans certaines pages ou avec les portlets on a(vait) des appels concurrents. Il faut voir les impacts sous charge.
Mis à jour par Sebastien Vuillet il y a plus de 12 ans
Il semble que les portlets qui pourraient générer des accès concurrents sur un ejb statfull sont "Dernières publications" et "Mes fichiers réservés".
Mis à jour par David Lesimple il y a plus de 12 ans
- Navigateur changé de Firefox 4.x à Tous
- Votre version de Silverpeas changé de 5.6 à 5.7.2
Ce problème se produit aussi chez un important client de la région lyonnaise...
Sur le serveur de test, la suppression du synchronized accélère grandement les temps de réponse
sur une GED avec plus de 500 publis et plusieurs dizaines de thèmes.
pt commun: le serveur de test du client est en Linux Debian, 5.7.2
Mis à jour par Stéphanie Fariello il y a plus de 11 ans
Ce bug, déclaré en 5.6 puis en 5.7.2, est t'il toujours d'actualité ?
si non, peut on le clore ?
Mis à jour par Nicolas Eysseric il y a plus de 11 ans
- Statut changé de Feedback à Closed
- % réalisé changé de 90 à 100
Les problèmes de performance sont réglés.
La récupération à tort des traductions des dossiers (alors que l'i18n n'était pas activé) avait été corrigé notamment.