Più accessi al database o un accesso massiccio?

Qual è un approccio migliore in termini di prestazioni e utilizzo ottimale delle risorse: accedere a un database più volte tramite AJAX per ottenere solo le informazioni esatte necessarie quando necessario o eseguire un accesso per recuperare un oggetto che contiene tutte le informazioni che potrebbero essere necessarie , con un'alta probabilità che non tutto sia effettivamente necessario?

So come confrontare le query effettive, ma non so come testare ciò che è meglio quando si tratta delle prestazioni del database quando migliaia di utenti accedono al database contemporaneamente e come entra in gioco il pool di connessioni.

Non esiste una risposta corretta a questo; come ogni ottimizzazione dipende fortemente dal contesto / utilizzo.

Tuttavia, considera quanto segue come regola empirica:

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

Ricorda la prima regola di ottimizzazione: misura, non indovinare . Prova entrambi, strumentali con una sorta di codice cronometro e vedi cosa richiede più tempo.

E ricorda anche la vecchia battuta secondo cui "ci sono solo due problemi difficili nell'informatica: invalidare la cache e nominare bene le cose". Se si estrae tutto immediatamente dal DB e lo si tiene in memoria, si dispone di una cache. E ora hai un nuovo problema: ogni volta che qualcosa cambia in qualsiasi parte del sistema , deve apportare la stessa modifica in due punti: il database e la cache. Se hai più di un server che comunica con il DB o più API per consentire al server di modificare i dati, questo può diventare molto complicato molto rapidamente.

Non esiste una soluzione di proiettile d'argento a questa domanda. Immagino che tu debba PROVARE i possibili compromessi e mettere a punto i tuoi server per ottenere il meglio da esso.

Primo punto: prima di iniziare a apportare miglioramenti è necessario IMPOSTARE il benchmark delle prestazioni corrente , misurarlo e prenderlo come base di riferimento rispetto alle possibili soluzioni per migliorarlo.

La seconda cosa è che è necessario tenere traccia dell'utilizzo dell'applicazione . Il modo in cui l'applicazione viene utilizzata dagli utenti finali. Ridurre i numeri grezzi di dati restituiti che non è necessario per gli utenti finali può farti risparmiare molte preziose risorse del server . Ad esempio: non ha senso restituire 5000 record mentre gli utenti sono interessati ai primi 50.

Terzo punto: devi capire la frequenza delle chiamate e le possibili implicazioni. Ad esempio: se la maggior parte delle chiamate sono query della tabella dei valori di ricerca, è possibile che si crei un'infrastruttura per memorizzare queste chiamate nella cache . In altre parole, se i tuoi dati non cambiano frequentemente, considera l'opzione di memorizzazione nella cache. E, naturalmente, ridurre al minimo il numero di chiamate dovrebbe sempre aiutare a migliorare le prestazioni.

Ottenere tutto in una volta ti darà prestazioni migliori, a meno che "tutto" non includa oggetti come BLOB o oggetti dati di dimensioni simili. L'overhead delle prestazioni per serializzare tutto, spostarlo sul cavo, quindi deserializzarlo sull'altra estremità è piuttosto significativo, con la latenza di rete che ne costituisce un grosso pezzo. La memoria è più economica della larghezza di banda della rete e probabilmente rimarrà tale ancora per un po '. La tua unica vera risposta verrà da un punto di riferimento, ma se stai solo cercando di valutare l'uno sull'altro, è il modo in cui mi appoggerei.

Se stai prendendo una decisione architettonica, REST è un'opzione. Con REST, richiedi sempre una risorsa più volte, ovvero non invii una richiesta per ottenere 2 oggetti perché ogni oggetto ha il suo url. La preoccupazione per le prestazioni nel farlo in questo stile sarà probabilmente risolta quando uscirà HTTP / 2.0. Altrimenti, ti basta ottimizzare per renderlo il più veloce possibile. Molte aziende lo stanno facendo in questo modo.