Plusieurs accès à la base de données ou un accès massif?


25

Quelle est la meilleure approche en matière de performances et d'utilisation optimale des ressources: accéder à une base de données plusieurs fois via AJAX pour obtenir uniquement les informations exactes nécessaires lorsque cela est nécessaire, ou effectuer un accès pour récupérer un objet qui contient toutes les informations qui pourraient être nécessaires , avec une forte probabilité que tout ne soit pas réellement nécessaire?

Je sais comment comparer les requêtes réelles, mais je ne sais pas comment tester ce qui est le mieux en matière de performances de base de données lorsque des milliers d'utilisateurs accèdent à la base de données simultanément et comment le regroupement de connexions entre en jeu.


Quelle plate-forme utilisez-vous.? if LAMP u cud use memcaching
ravi404

Comme pour toute autre optimisation des performances, vous la mesurez.
Telastyn

2
@Telastyn: Je fais des choix de conception fondamentaux et je n'ai pas de serveur de transfert. Tous mes appels db sont vers une base de données qui réside sur la même machine où le php est exécuté. J'espérais apprendre de l'expérience des autres à cet égard, avant de réaliser que la route que j'ai décidé d'emprunter était excellente quand tout était local, mais sous-optimale lorsqu'elle était prise en direct.
DudeOnRock

1
@DudeOnRock - hocher la tête en général, cela dépend de vos modèles d'utilisation et de la façon dont les données changent. Si une requête fournit 80% de ce dont les gens ont besoin et que les données ne changent pas souvent, alors allez-y. Facile à mettre en cache, facile à optimiser. Si une requête renvoie 5% de ce dont les utilisateurs ont généralement besoin, alors peut-être pas. Je tendrais vers plus de requêtes que moins. Vous pouvez toujours les couper sur le serveur avant qu'il n'atteigne la base de données. Il est plus difficile d'annuler «tout fait une seule requête».
Telastyn

@ravz: ça a l'air intéressant!
DudeOnRock

Réponses:


27

Il n'y a pas de bonne réponse à cela; comme toute optimisation, cela dépend fortement du contexte / de l'utilisation.

Cependant, considérez ce qui suit en règle générale:

x
+: Data is stable / static
-: Data is dynamic / volatile

y
+: Data is frequently used
-: Data is infrequently used

++: fetch large chunks in the fewest number of fetches 
    and persist the data as long as possible within tolerances for staleness.

+-: do what is expedient to the logic & usage; if it is convenient to 
    fetch / calc as needed do so, if it is convenient to pre-fetch and 
    persist then do so. Seek to optimize only if absolutely necessary.

-+: fetch / calc as needed; but if optimization is required consider 
    pre-fetching or pre-calculating if possible, or negotiate a tolerance 
    for less than real time accuracy to reduce volatility.

--: fetch / calc as needed and don't worry about it further unless a 
    specific case is unacceptably expensive; if so see -+.

24

Rappelez-vous la première règle d'optimisation: mesurer, ne pas deviner . Essayez les deux, instrumentez-les avec une sorte de code chronomètre et voyez ce qui prend plus de temps.

Et gardez également à l'esprit la vieille plaisanterie selon laquelle "il n'y a que deux problèmes difficiles en informatique: l'invalidation du cache et bien nommer les choses". Si vous extrayez tout de la base de données à la fois et le gardez en mémoire, vous avez un cache. Et maintenant, vous avez un nouveau problème: chaque fois que quelque chose change n'importe où dans le système , il doit faire le même changement à deux endroits: la base de données et le cache. Si plusieurs serveurs parlent à la base de données ou plusieurs API pour que le serveur modifie les données, cela peut devenir très délicat très rapidement.


Et assurez- vous de ce que vous mesurez. Par exemple, les résultats peuvent varier en fonction de la bande passante et de la latence de la connexion à la base de données.
SpaceTrucker

4

Il n'y a PAS de solution miracle à cette question. Je suppose que vous devez ESSAYER les compromis possibles et régler votre ou vos serveurs pour en tirer le meilleur parti.

Premier point: avant de commencer à apporter les améliorations dont vous avez besoin pour définir votre référence de performance actuelle , la mesurer et la prendre comme référence en comparaison des solutions possibles pour l'améliorer.

La deuxième chose est que l' utilisation des applications doit être suivie. La façon dont l'application est utilisée par les utilisateurs finaux. La réduction des nombres bruts de données retournées qui ne sont pas nécessaires aux utilisateurs finaux peut vous faire économiser de précieuses ressources de serveur . Par exemple: il est inutile de renvoyer 5000 enregistrements alors que les utilisateurs sont intéressés par les 50 premiers.

Troisième point: vous devez comprendre la fréquence des appels et les implications possibles. Par exemple: si la plupart des appels sont des requêtes de table de valeurs de recherche, vous pouvez probablement créer une infrastructure pour mettre en cache ces appels . En d'autres termes, si vos données ne changent pas fréquemment, envisagez l'option de mise en cache. Et bien sûr, minimiser le nombre d'appels devrait toujours aider à améliorer les performances.


2

Tout obtenir en même temps vous donnera de meilleures performances, à moins que «tout» comprenne des éléments tels que des BLOB ou des objets de données de taille similaire. La surcharge de performances pour tout sérialiser, le déplacer sur le câble, puis le désérialiser à l'autre extrémité est assez importante, la latence du réseau en étant un gros morceau. La mémoire est moins chère que la bande passante du réseau et le restera probablement encore un certain temps. Votre seule vraie réponse viendra d'un point de repère, mais si vous essayez simplement d'évaluer l'un sur l'autre, c'est de cette façon que je me pencherais.


Selon les commentaires, il s'agit d'une base de données locale, il n'y a donc pas de latence "over the wire" ici.
Mason Wheeler

1
Selon les commentaires, il recherchait des stratégies qui ne seraient pas "géniales quand tout était local, mais sous-optimales quand elles étaient prises en direct".
TMN

1

Si vous prenez une décision architecturale, alors REST est une option. Avec REST, vous demandez toujours une ressource plusieurs fois, c'est-à-dire que vous n'envoyez pas de demande pour obtenir 2 objets car chaque objet a sa propre URL. Le problème de performances avec ce style sera probablement résolu lorsque HTTP / 2.0 sortira. Sinon, vous optimisez simplement pour le rendre aussi rapide que possible. Beaucoup d'entreprises le font de cette façon.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.