2009-03-03 8 views
2

Je travaille actuellement sur un système n-tier et sur des problèmes de performance de base de données. Un domaine que nous avons étudié est la latence entre le serveur de base de données et le serveur d'applications. Dans notre environnement de test, les temps de ping moyens entre les deux boîtes sont de l'ordre de 0.2ms mais sur le site du client, ils sont plutôt de l'ordre de 8.2ms. Est-ce que nous devrions nous inquiéter?Latence de réseau de base de données

Pour votre système moyen que pensez-vous les gars considèrent comme un temps d'attente et comment resonable iriez-vous sur les tests/mesure de la latence?

Karl

Répondre

4

En résumé: non!

Ce que vous devez surveiller est la performance globale de vos requêtes (transport à l'exécution DB + + le transport sur votre serveur)

Ce que vous pouvez faire est d'utiliser un compteur de performance pour surveiller le temps vos requêtes habituellement prendre pour exécuter. Vous verrez probablement vos résultats dépasser la milliseconde.

Il n'y a pas une telle chose comme « temps d'attente raisonnable ». Vous devriez plutôt considérer la "latence raisonnable pour votre projet", qui varie beaucoup en fonction de ce que vous travaillez. Les gens n'ont pas les mêmes attentes pour une plate-forme de négociation en temps réel et pour un site Web amateur en lecture seule.

+0

Il existe également une fonctionnalité intégrée dans SQL pour cela. Ne définissez pas un filtre de 1ms ou vous ne verrez pas les opérations exécutées plus rapidement. –

1

Sur un serveur basé sur Linux, vous pouvez tester l'effet de latence vous-même en utilisant la commande tc.

Par exemple, cette commande ajoute 10ms délai à tous les paquets passant par eth0

tc qdisc add dev eth0 root netem delay 10ms 

utiliser cette commande pour supprimer le délai

tc qdisc del dev eth0 root 

Plus de détails ici: http://devresources.linux-foundation.org/shemminger/netem/example.html

Toutes les applications seront différentes, mais j'ai certainement vu des situations où la latence de 10 ms a eu un impact significatif sur la performance nce du système.

1

L'une des têtes honchos à answers.com a été dit selon leurs études, 400 ms Temps d'attente pour une charge de page Web est sur le moment où ils commencent d'abord amener les gens l'annulation de la charge de la page et aller ailleurs. Mon conseil est de regarder l'ensemble du processus, de la demande originale du client à l'exécution et si vous vous y débrouillez bien, il n'y a pas besoin d'optimiser davantage. 8,2 ms vs 0,2 ms est exponentiellement plus grand dans un sens mathématique, mais d'un point de vue humain, personne ne peut vraiment percevoir une différence de 8,0 ms. Il est la raison pour laquelle ils ont des finitions de photo dans les courses;)

2

Désolé pour la réponse très prématurée, mais je suis tombé sur cette question quand je cherchais des mesures de ce réseau latences autres accomplissaient entre leur serveur d'applications et le serveur db. Quoi qu'il en soit, j'ai remarqué que les autres réponses

Quoi qu'il en soit, en bref: oui, la latence du réseau (mesurée par ping) peuvent faire une énorme différence.

Si votre réponse est la base de données .001ms alors vous verrez un impact énorme d'aller d'un 0.2ms à 8ms ping. J'ai entendu dire que les protocoles de base de données sont bavards, ce qui, si vrai, signifie qu'ils seraient plus affectés par la lenteur du réseau par rapport à http.

Et plus que probablement, si vous exécutez 1 requête, l'ajout de 8ms pour obtenir la réponse de la base de données n'aura aucune importance. Mais si vous faites 10 000 requêtes qui se produisent généralement avec un mauvais code ou une utilisation non optimisée d'un ORM, vous devrez attendre 80 secondes de plus pour un ping de 8ms, alors que pour un ping de 0.2ms, vous n'attendrez que 4 secondes.

Pour ma part, je ne laisse jamais les applications client contacter directement la base de données. Je demande que les applications client passent toujours par un serveur d'application (par exemple un service Web REST). De cette façon, si j'ai accidentellement un problème ORM "1 + N", alors ce n'est pas aussi percutant. Je voudrais toujours essayer de résoudre le problème sous-jacent ...

+0

Encore ressusciter un vieux fil, mais j'ai aussi trébuché sur ce sujet. Je suis d'accord qu'en raison de la bavardage de l'activité de la base de données, le suivi de la latence rtt de la base de données est important. L'outil fourni par mon entreprise (www.heimdalldata) a en plus de nombreuses autres fonctionnalités un mécanisme facile à utiliser qui ajoutera une latence spécifique à une requête, de sorte que l'impact sur l'application peut être mesuré. De plus, il aidera à repérer les requêtes redondantes et, grâce à des règles, à configurer la mise en cache au niveau de la requête ou de la table. Les requêtes rapides sont celles qui ne quittent jamais l'application! –