Com tanta performance bruta, a optimização ainda fará sentido?

A Red Gate publica uma newsletter chamada Simple Talk, que no geral, tal como as ferramentas da Red Gate, versam temas ligados à administração e utilização de bases de dados em SQL Server e ao profiling the aplicações .NET

Na última newsletter recebida esta semana, um tópico chamou a minha atenção…

A título de minha introdução e comentário à minha provocação no título deste post, numa altura em que o armazenamento ‘físico’, a memória RAM, a capacidade de processamento e o desempenho das redes deixaram de ser consideradas limitações, na fase de preparação e de desenvolvimento propriamente dito de soluções tendemos a esquecer-nos da optimização de processos. Há pouco tempo um amigo ligado a uma importante empresa portuguesa ligada ao desenvolvimento de software de gestão comentava que uma funcionalidade recentemente acrescentada ao software demorava demasiado tempo a ser executada nos seus clientes. Quando questionado o programador que a implementou, o comentário foi que nos testes que tinha feito, ‘aquilo’ era rápido, mas depressa se chegou à conclusão que o volume de informação testado era muito inferior ao volume que alguns clientes tinham nas suas bases de dados. O processo, muito intensivo em termos de operações de bases de dados provavelmente não teria sido optimizado, lembremo-nos que há pessoas que ainda não usam a preparação de comandos SQL com parâmetros quando têm de repetir a mesma acção um nº variável de vezes com valores diferentes. Na nossa empresa, seja por razões de performance na preparação de comandos, segurança para evitar SQL injection e confiança no tratamento de valores numéricos e datas, usamos sempre comandos com parâmetros, não embebemos os valores na string do .CommandText (a excepção é quando precisamos de utilizar o operador IN (…) ).

O tal tópico não tem a ver com a performance na óptica mencionada no ponto anterior, mas na óptica da execução de cada instrução SQL, mais precisamente explica detalhadamente o que é o Exectution Plan do SQL Server, como obtê-lo, formas de apresentação do mesmo e como o interpretar, para a partir dessa informação testar diferentes variantes de um comando e diferentes opções em termos da estrutura da base de dados em si, como índices, de modo a medir e determinar o melhor compromisso para a sua execução.

Fica o link directo para o artigo, que é o primeiro capítulo do mais recente livro do autor, dedicado às questões do Execution Plan:

Execution Plan Basics
Simple-talk: Grant Fritchey

http://www.simple-talk.com/sql/performance/execution-plan-basics/

Uma ressalva, apesar de eu geralmente apenas falar sobre questões ligadas ao desenvolvimento para a .NET Compact Framework e o SQL Server Compact, o artigo mencionado refere-se ao SQL Server para servidores, cujo ‘query processor’ difere daquele que encontramos no SQL Server Compact, pelo que o artigo sendo útil não é aplicável na sua totalidade a esta versão

One thought on “Com tanta performance bruta, a optimização ainda fará sentido?”

  1. A temática levantada dava para uma bela discussão. É uma realidade que, hoje em dia, a programar (no meu caso) em máquinas com processadores core 2 duo com 2 ou 3 Gb de RAM, tendemos a esquecer-nos de que ainda existem Pentium IV e que esses não são assim tão poucos…

    Outro problema com que me tenho deparado é a quantidade de informação que é enviada através da rede. Estas tendem a aumentar de velocidade e desenvolvem aplicações web muito giras mas que, frequentemente, debitam páginas acima dos 5Mb o que, para certas ligações, é muito tempo de espera até a página ser renderizada pelo navegador…

    http://www.revolucaodigital.net

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>