Optimiser temps de réponse de serveur avec Java [Résolu/Fermé]

Signaler
Messages postés
58
Date d'inscription
dimanche 25 août 2013
Statut
Membre
Dernière intervention
11 juillet 2016
-
Messages postés
58
Date d'inscription
dimanche 25 août 2013
Statut
Membre
Dernière intervention
11 juillet 2016
-
Bonjour ,
J'ai le problème suivant , j'ai une application qui fait plusieurs appel au serveur (des request get ,plus que 11 000 request ) et ceci a rendu l'application trés trés lente , malgré que j'utilise des jobs qui s'executent en parallél .
Alors , dans tel cas qu'elle est la meilleure solution pour résoudre ce problème .
Merci d'avance pour toute aide .

2 réponses

Messages postés
16040
Date d'inscription
samedi 31 mai 2008
Statut
Modérateur
Dernière intervention
25 septembre 2020
2 679
Bonjour,

Il faudrait en savoir "un peu" plus pour t'aider.

Tes 11000 requêtes ont été soumises sur quel intervalle de temps ? Toutes en même temps ? Étalées sur 1 jour ?
Que fais chaque job que tu fais à la réception de la requête et combien de temps dure une requête ?
Est-ce que ton application traite uniquement ce type de requêtes ou elle fait autre chose à côté ? Les activités annexes ont aussi été ralenties ?
Quel serveur tu utilises, avec quelles technologies Java dessus ?

Bref, plus ta question sera précise, plus la réponse sera pertinente.
1
Merci

Quelques mots de remerciements seront grandement appréciés. Ajouter un commentaire

CCM 60769 internautes nous ont dit merci ce mois-ci

Messages postés
58
Date d'inscription
dimanche 25 août 2013
Statut
Membre
Dernière intervention
11 juillet 2016

Bonjour ,
je te remercie pour ta réponse tout d'abord ,en effet , mes 11 000 requêtes sont tous lancées en meme temps vu que j'utilise des jobs qui se lance en parallèle pour les appeler .
Chaque job lance la requête get pour retourner une string contenant les xml (réponse de ma requête get et pour remarque ces xml sont volumineux ).
Oui mon application fait autre chose ,en fait il y a d'autre job qui se lance comme réponse à la réaction de l'utilsiateur vis à vis le graphique(exemple appui d'un bouton mais ces jobs ne sont pas gourmands et leur exécution ne dure pas longtemps)
Côté serveur ,on utilise mule esb .
J'espère que j'ai mieux expliqué :)
Messages postés
16040
Date d'inscription
samedi 31 mai 2008
Statut
Modérateur
Dernière intervention
25 septembre 2020
2 679
Il y a encore quelques points obscurs.

Comment fonctionne la requête ? Tu retournes une String mais comment est obtenue sa valeur ? Est-ce que tu vas chercher des infos en base de données ? Ou tu fais des traitements longs derrière ?

Quel genre de jobs lancent 11000 requêtes en parallèle ? C'est depuis une page web ? Un client lourd ? Tu as 11000 clients qui envoient 1 requêtes ou chaque job en envoie plusieurs ?

Je ne connais pas Mule mais clairement un ESB n'as pas pour vocation a traiter lui même les requêtes, il est surtout là pour faire tampon et router les messages vers les bonnes applications.
En gros c'est le facteur qui transporte du courrier, mais ce n'est pas à lui d'écrire ou lire les lettres.
Donc dans ton application j'ai l'impression qu'il manque un vrai serveur dédié au traitement de ces requêtes...
Messages postés
58
Date d'inscription
dimanche 25 août 2013
Statut
Membre
Dernière intervention
11 juillet 2016

Rebonjour ,
Les Strings sont obtenus depuis une base de données .
j'ai 11 000 jobs et chaque job fait appel à une requête get (ces jobs s'exécutent en parallel).
Mule a pour objet d'accéder à la base de donnée et rendre ces données accessible depuis les url que je les appelle avec les reqëtes get .
Merci
Messages postés
16040
Date d'inscription
samedi 31 mai 2008
Statut
Modérateur
Dernière intervention
25 septembre 2020
2 679
Voici le schéma de fonctionnement d'un ESB :

Les customers se sont tes 11000 jobs, mais au vue de tes explications, tu n'as pas de producer, c'est ton ESB qui fait tout et c'est là le problème.

Normalement l'ESB fait tampon, c'est à dire qu'il a des files de messages (JMS) de sorte qu'il puisse accumuler 11000 requêtes sans problème dans une file d'attente, le temps que un ou plusieurs producers viennent les consommer un à un (ou plusieurs à la fois) pour interroger la base de données dans ton cas et créer le xml de retour, qui est renvoyé dans l'autre sens via l'ESB qui le soumet au customer d'origine.

Donc en gros ton ESB ne devrait avoir que 2 tâches : la réception des requêtes des customers et la réception des réponses des producers.

Les 11000 threads de traitement, c'est au producer de les gérer, et il ne le fera pas 11000 en une seule fois, il aura par exemple 10 threads qui viendront récupérer chacun 1 requête, pendant que les 10990 autres requêtes attendent d'être traitées dans l'ESB.

Après, on peut sûrement également optimiser l'interrogation de la base de données, pour ne pas faire 11000 requêtes en base, mais mutualiser les appels, par exemple pour récupérer toutes les données de 100 requêtes d'un coup, au sein d'un seul thread.
Messages postés
58
Date d'inscription
dimanche 25 août 2013
Statut
Membre
Dernière intervention
11 juillet 2016

Parfait , très bonne explication .
Grand merci KX pour ton énorme aide .(Je vais essayer alors de changer coté mule )
Messages postés
532
Date d'inscription
mercredi 9 mars 2016
Statut
Membre
Dernière intervention
8 mars 2018
86
Mise en cache, compression des données, laisser les connexions ouvertes si possibles
Messages postés
58
Date d'inscription
dimanche 25 août 2013
Statut
Membre
Dernière intervention
11 juillet 2016

Bonjour Rocailleux ,
Merci pour ta réponse , concernant la mise en cache y a t il une librairie java ou api dont tu recommandes son utilisation ?
Merci
Messages postés
16040
Date d'inscription
samedi 31 mai 2008
Statut
Modérateur
Dernière intervention
25 septembre 2020
2 679
Pour la mise en cache, cela dépend sur quels types de données tu travailles.
Le but est d'éviter d'aller chercher plusieurs fois les mêmes informations en base de données. Mais sur le principe une Map suffit.

Exemple simpliste :

public String getString(int id) {
    String value = getStringInCache(id);
    if (value == null) { // pas en cache
        value = getStringInDatabase(id);
        putStringInCache(id, value);
    }
    return value;
}

private Map<Integer, String> cache = new HashMap<Integer, String>();

private String getStringInCache(int id) {
    return cache.get(id);
}

private void putStringInCache(int id, String value) {
    cache.put(id, value);
}

Pour aller plus loin on peut utiliser des architectures plus complexes comme Hazelcast par exemple, ce qui est notamment utile pour partager des données entre plusieurs producers, définir des délais de rétention, etc.
Messages postés
532
Date d'inscription
mercredi 9 mars 2016
Statut
Membre
Dernière intervention
8 mars 2018
86
À la limite, charger tout la bdd en ram (collection/table de hachage) si elle n'est pas trop lourde
Messages postés
58
Date d'inscription
dimanche 25 août 2013
Statut
Membre
Dernière intervention
11 juillet 2016

Merci encore une fois pour vous deux :) .