Optimiser temps de réponse de serveur avec Java

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é :)

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...

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

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.

Parfait , très bonne explication .
Grand merci KX pour ton énorme aide .(Je vais essayer alors de changer coté mule )

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

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.

À la limite, charger tout la bdd en ram (collection/table de hachage) si elle n'est pas trop lourde

Merci encore une fois pour vous deux :) .