Projet

Général

Profil

Actions
Copier le lien

Bug #2037

fermé

Gros problèmes de lenteur suite à migration

Ajouté par Sebastien Vuillet il y a plus de 13 ans. Mis à jour il y a environ 12 ans.

Statut:
Closed
Priorité:
High
Assigné à:
-
Catégorie:
-
Version cible:
-
Début:
26/05/2011
Echéance:
% réalisé:

100%

Temps estimé:
Temps passé:
40.00 h
Navigateur:
Tous
Votre version de Silverpeas:
5.7.2
Système d'exploitation:
Linux
Votre base de données:
PostgreSQL
Livraison en TEST:
Livraison en PROD:

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

Télécharger tous les fichiers
server.log (175 ko) server.log Sebastien Vuillet, 26/05/2011 16:48
Sampler.png (104 ko) Sampler.png Sebastien Vuillet, 10/06/2011 10:35
PileAppel.png (63,8 ko) PileAppel.png Sebastien Vuillet, 10/06/2011 10:35
Actions
Copier le lien
 #1

Mis à jour par Sebastien Vuillet il y a plus de 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...

Actions
Copier le lien
 #2

Mis à jour par Emmanuel Hugonnet il y a plus de 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.

Actions
Copier le lien
 #3

Mis à jour par Emmanuel Hugonnet il y a plus de 13 ans

  • % réalisé changé de 0 à 90
Actions
Copier le lien
 #4

Mis à jour par Sebastien Vuillet il y a plus de 13 ans

Ok. Est-ce que ces exceptions expliqueraient les lenteurs que je constate ?

Actions
Copier le lien
 #5

Mis à jour par Sebastien Vuillet il y a plus de 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]

Actions
Copier le lien
 #6

Mis à jour par Nicolas Eysseric il y a plus de 13 ans

  • Catégorie Authentification supprimé
  • Assigné à Emmanuel Hugonnet supprimé
  • Version cible Version 5.7 supprimé

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 !

Actions
Copier le lien
 #7

Mis à jour par Nicolas Eysseric il y a plus de 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...

Actions
Copier le lien
 #8

Mis à jour par Sebastien Vuillet il y a plus de 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...

Actions
Copier le lien
 #9

Mis à jour par Sebastien Vuillet il y a plus de 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...

Actions
Copier le lien
 #10

Mis à jour par Ludovic Bertin il y a plus de 13 ans

Je rencontre aussi des problèmes de lenteurs sur les requetes ajax chez nos chtis...

Actions
Copier le lien
 #11

Mis à jour par Sebastien Vuillet il y a plus de 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 ?

Actions
Copier le lien Télécharger tous les fichiers
 #12

Mis à jour par Sebastien Vuillet il y a plus de 13 ans

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.

Actions
Copier le lien
 #13

Mis à jour par Sebastien Vuillet il y a plus de 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à.

Actions
Copier le lien
 #14

Mis à jour par Sebastien Vuillet il y a plus de 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...

Actions
Copier le lien
 #15

Mis à jour par Emmanuel Hugonnet il y a plus de 13 ans

Dans certaines pages ou avec les portlets on a(vait) des appels concurrents. Il faut voir les impacts sous charge.

Actions
Copier le lien
 #16

Mis à jour par Sebastien Vuillet il y a environ 13 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".

Actions
Copier le lien
 #17

Mis à jour par David Lesimple il y a environ 13 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

Actions
Copier le lien
 #18

Mis à jour par Stéphanie Fariello il y a environ 12 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 ?

Actions
Copier le lien
 #19

Mis à jour par Nicolas Eysseric il y a environ 12 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.

Actions
Copier le lien

Formats disponibles : Atom PDF