Obtenha e teste de desempenho no Google BigTables (e em outros bancos de dados integrados)

Quais são algumas maneiras eficazes de executar testes de desempenho programático em operações de banco de dados, especialmente em ambientes em que os próprios bancos de dados não oferecem ferramentas dedicadas?

Por exemplo, no Google App Engine, o carregamento de páginas inteiras é avaliado como uma operação que pode incluir operações específicas do banco de dados. Esse problema também provavelmente está presente no SQLite e em outros bancos de dados integrados. Como é difícil abstrair completamente as (equivalentes) seleções e inserções que precisam ser testadas, existem ferramentas de banco de dados recomendadas para realizar diagnósticos mais detalhados sobre esses tipos de consultas?

— Brian Ballsun-Stanton
fonte

Você tem acesso direto ao banco de dados em questão?

— Stingervz

Sim, sou eu quem está escrevendo o aplicativo. E embora o desempenho do aplicativo seja uma pergunta diferente, estou recebendo alguns resultados de desempenho bastante graves em uma consulta desagradável que escrevi.

— Brian Ballsun-Stanton

Às vezes, uma dúzia de pares de olhos é um melhor diagnóstico do que um analisador de consulta ... (ok não que muitas vezes)

— jcolebrand

@ Brian Acho que você faria melhor no Stackoverflow com esse tipo de pergunta, pois é mais uma questão de programação do que uma questão de DBA.

— IamIC

@IanC Drat. Estou tentando chegar ao ponto mais importante da mesa, e não ao desempenho como um todo. Mas vou excluir se as pessoas não acharem a pergunta adequada. (Eu também estou tentando garantir que o site não é oracle / sql-server / mysql o tempo todo)

— Brian Ballsun-Stanton

Respostas:

Parece-me que seu problema é que você está tentando testar métricas de desempenho que não são bem suportadas no banco de dados subjacente. Isso torna muito difícil comparar o desempenho entre os sistemas, porque as abordagens subjacentes são muito diferentes. Eu não acho que é possível fazer comparações maçãs com maçãs, assim como eu não acho que você possa fazer uma comparação maçãs com maçãs das abordagens do tipo ORDBMS às abordagens do tipo RDBMS. As preocupações com o desempenho são muito diferentes e, se a Stonebraker estiver certa, a otimização de um ORDBMS para testes TPC-C perde o objetivo; então, para sistemas que estão ainda mais distantes, isso será impossível. (Eu acho que ele está lá, apenas onde a funcionalidade do ORDBMS entra em jogo.)

Eu acho que o que você precisa para ser honesto é ver como você usaria cada sistema e criar uma ferramenta de benchmark com base na abordagem que você adotaria em cada um. Em seguida, você pode dizer, pelo menos para esse fluxo de trabalho, que o benchmark mostra algo específico. Não vejo como você pode generalizar no entanto. Você pode executá-lo ainda mais em um criador de perfil para obter informações adicionais sobre o tempo gasto no teste em vários mecanismos.

No entanto, é muito difícil obter benchmarking do banco de dados significativo nas melhores circunstâncias e, quando você está comparando sistemas diferentes, torna-se impossível generalizar.

— Chris Travers
fonte

O Appstats é a principal ferramenta para medir o desempenho no App Engine. Ele mostrará o tempo usado para cada RPC, incluindo solicitações de armazenamento de dados, memcache, busca de URL e correio em um gráfico gráfico. Normalmente, os pedidos aparecem como uma "escada" onde cada pedido começa no ponto em que a solicitação anterior terminou, na próxima linha abaixo.

Se você usar as solicitações assíncronas avançadas no ndb, poderá ver as solicitações acontecendo em paralelo.

Essa ferramenta foi uma ajuda imensa para mim, para ver onde o tempo está sendo gasto e como otimizar as consultas.

— Brent Washburne
fonte