Quando estamos desenvolvendo é bom ter em mente o impacto do código que estamos escrevendo em termos de performance do banco de dados. A infraestrura de acesso a dados do Ax permite que o AOS faça o caching de registros pesquisados no banco de dados, diminuindo assim as idas e voltas no banco de dados.
Independente da opção de cache o AOS somente faz o cache do registro quando o select utiliza TODAS as chaves presentes na primary index da tabela e somente se o operador == for utilizado em todas elas, pois o AOS faz o cache de um registro por vez, isto significa que >, <, != não tem efeito nenhum sobre o cache.
Toda vez que o modificador forUpdate é utilizado, caso não tenha sido utilizado previamente na mesma transação, o AOS atualiza o cache.
Como o Ax trabalha com o cache depende da propriedade da tabela chamada CacheLookup. As seguintes opções estão definidas:
1. None - sem cache
2. Found
3. FoundAndEmpty
4. NotInTTS
5. EntireTable
Utilizando Found and FoundAndEmpty o cache é preservado depois do uso do ttsBegin, ttsCommit e ttsAbort.
A opção FoundAndEmpty contém mais um detalhe, caso um select não devolva nenhum resultado, isto é, o registro com aquela PK não existe no banco, aquela PK é marcada como cacheada todos os selects subsequentes são "lidos" do cache e o cache é atualizado somente quando forUpdate seja chamado.
Utilizando NotInTTS o cache é atualizado no primeiro select após o ttsBegin.
A opção EntireTable somente deve ser utilizada para tabelas que não são atualizadas com frequência, como tabelas de parametros, grupos, etc, pois o AOS faz um cache completo da tabela quando a tabela for lida pela primeira vez, o AOS então cacheia a tabela toda do servidor, quando um client le a tabela cacheada no AOS ele envia a linha cacheada para o client sem ir ao banco de dados.
O AOS faz um flush do cache toda vez que um update, delete ou insert é feito na tabela, ela volta a ser toda cacheada na próxima vez que for lida.
O join entre tabelas com esse tipo de cache com tabelas que não tem o tipo de cache EntireTable sempre força o AOS a atualizar o cache não importa o momento do select.
Procurem sempre utilizar os métodos Find e Exists das tabelas pois eles sempre são escritos utilziando a PK da tabelas e garantem o uso do cache para aquela tabela.
Utilizando essas poucas regras e tendo elas em mente quando estão desenvolvendo para seus clientes, sempre tentem verificar se o modo que estão acessando o banco de dados pode ou não afetar a performance geral da fucnionalidade que estão desenvolvendo.
Até a próxima.
domingo, 31 de maio de 2009
Single Record Cache
Postado por Matiazo às 19:22 0 comentários
Marcadores: Cache, Performance
segunda-feira, 4 de maio de 2009
AX6 sneak preview - SQL AOD
Preview de uma das grandes mudanças na proxima versão SQL AOD
THIS POST IS PROVIDED AS-IS; AND CONFERS NO RIGHTS.
Postado por Matiazo às 09:52 1 comentários
Marcadores: AX6
Assinar:
Postagens (Atom)