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

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.

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

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.

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.

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.

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.