2013-02-14 5 views
0

Nous avons écrit des procédures stockées dans MYSQLprocédure stockée appelée Parellel résultats retour séquentielle

Si la procédure stockée est appelée d'un thread sa prise de 2,5 secondes pour retourner des résultats

Si la procédure stockée est appelée à partir de 3 thread son prendre environ 8,5 secondes pour retourner les résultats. chaque fil prend presque le même temps.

Nous utilisons MyISM, s'il vous plaît laissez-moi savoir si nous avons besoin de faire des réglages pour la procédure à exécuter de façon pareil. Nous récupérons uniquement (sélectionne) dans la procédure stockée aucune mise à jour/insertion effectuée

+0

même les requêtes simultanées sont commutées en contexte/processus. Tirer aussi des données de DB. que 1 seconde de plus est le surcoût du changement de contexte. – SparKot

+0

Utilisez plus de threads lorsque MySQL est inactif et que tous les threads existants sont occupés à traiter certaines données qu'ils ont extraites de MySQL. – SparKot

+0

il prend 8,5 secondes pour chaque thread lorsque 3 thread sont exécutés. -> total 8.5 * 3 – dsr301

Répondre

1

L'augmentation du nombre de threads pour extraire des données de MySQL n'augmente pas nécessairement le débit. Vous exécutez la même requête dans plusieurs threads, ce qui ajoute à la surcharge du changement de contexte. Pour tirer parti de l'enfilage, vous devez utiliser le temps d'inactivité (le temps d'inactivité réel), comme les retards d'entrée/de sortie/de réseau. Exemple:

  • Un thread extrait des données de MySQL et commence le traitement, par exemple en envoyant une notification via une interface. Si cette interface est synchrone, le thread est bloqué.
  • Obtenez plus de threads pour faire le travail pour vous, par exemple, extraire les données de la base de données (inactif) et les traiter.

sans de tels délais/threads de ralenti n'entraîne qu'une surcharge IMO.

Questions connexes