Vários acessos ao banco de dados ou um acesso massivo?

O que é uma abordagem melhor quando se trata de desempenho e utilização óptima dos recursos: acessando um múltiplo banco de dados vezes através de AJAX para só obter a informação exata necessária quando é necessário, ou executar um acesso para recuperar um objeto que contém todas as informações que possam ser necessárias , com uma alta probabilidade de que nem tudo seja realmente necessário?

Eu sei como comparar as consultas reais, mas não sei como testar o que é melhor quando se trata de desempenho do banco de dados quando milhares de usuários estão acessando o banco de dados simultaneamente e como o pool de conexões entra em jogo.

Não há uma resposta correta para isso; como qualquer otimização, depende muito do contexto / uso.

No entanto, considere o seguinte como regra geral:

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

Lembre-se da primeira regra de otimização: meça, não adivinhe . Experimente os dois, instrumente-os com algum tipo de código de cronômetro e veja o que leva mais tempo.

E também lembre-se da velha piada de que "existem apenas dois problemas difíceis na ciência da computação: invalidar cache e nomear bem as coisas". Se você extrair tudo do banco de dados de uma só vez e mantê-lo na memória, terá um cache. E agora você tem um novo problema: sempre que algo muda em qualquer lugar do sistema , ele precisa fazer a mesma alteração em dois locais: o banco de dados e o cache. Se você tiver mais de um servidor conversando com o banco de dados ou várias APIs para fazer o servidor modificar dados, isso pode se tornar muito complicado muito rapidamente.

Não há solução de bala de prata para esta pergunta. Eu acho que você precisa TENTAR as possíveis compensações e ajustar o (s) servidor (es) para obter o melhor dele.

Primeiro ponto: antes de começar a fazer melhorias, você precisa definir seu benchmark de desempenho atual , medi-lo e tomar uma linha de base na comparação de possíveis soluções para melhorá-lo.

A segunda coisa é que o uso do aplicativo precisa ser rastreado. A maneira como o aplicativo é utilizado pelos usuários finais. Reduzir os números brutos de dados retornados que não são necessários para o (s) usuário (s) final (is) pode economizar muito recursos preciosos do servidor . Por exemplo: não faz sentido retornar 5000 registros enquanto os usuários estão interessados ​​nos 50 primeiros.

Terceiro ponto: você precisa entender a frequência das chamadas e possíveis implicações. Por exemplo: se a maioria das chamadas são consultas de tabela de valores de pesquisa, você provavelmente criaria uma infraestrutura para armazenar em cache essas chamadas . Em outras palavras, se seus dados não estiverem sendo alterados com frequência, considere a opção de cache. E, é claro, minimizar o número de chamadas sempre deve ajudar a aumentar o desempenho.

Obter tudo de uma vez dará a você um melhor desempenho, a menos que "tudo" inclua itens como BLOBs ou objetos de dados igualmente grandes. A sobrecarga de desempenho para serializar tudo, movê-lo pela conexão e desserializar na outra extremidade é bastante significativa, com a latência da rede sendo uma grande parte dele. A memória é mais barata que a largura de banda da rede e provavelmente permanecerá assim por algum tempo ainda. Sua única resposta real virá de uma referência, mas se você está apenas tentando avaliar uma sobre a outra, é assim que eu me inclino.

Se você estiver tomando uma decisão arquitetônica, o REST é uma opção. Com o REST, você sempre solicita um recurso várias vezes, ou seja, não envia uma solicitação para obter 2 objetos porque cada objeto tem seu próprio URL. A preocupação com o desempenho desse estilo provavelmente será resolvida quando o HTTP / 2.0 for lançado. Caso contrário, você apenas otimiza para torná-lo o mais rápido possível. Muitas empresas estão fazendo dessa maneira.