Thursday, January 05, 2006
A Arte da Performance
Performance
Como falar sobre performance? Por que eu sou um paranóico por ela? Etimologicamente, performance vem do Francês antigo: par + fournir, ou seja, enfeitar, decorar, fornecer, persistir em uma tarefa até que seja completa. Anos depois, ficou conhecida como dar show, apresentação em um palco, afinação, além disso, atualmente significa desempenho juntando todas as definições anteriores. Então, se seu código tem performance, ele literalmente dá show. É isso que os usuários esperam: que seu código seja um espetáculo.
Eu realmente penso muito no desempenho dos sistemas que desenvolvo. Isso determina o sucesso ou o fracasso deles. Não importa qual tecnologia, quantas camadas, linguagem de desenvolvimento ou banco de dados, se aplicativo, interface ou seja lá o que estiver fazendo, não executar de acordo ao que o negócio exige, estará fadado ao fracasso.
Quem determina o quão rápido o sistema deve ser é o negócio para qual ele será desenvolvido. Por exemplo, em uma aplicação bancária, onde o cliente vai sacar dinheiro, o tempo de operação deve ser menor que 10 segundos após o cliente confirmar a senha. Esse é o requisito para a operação. Entretanto, se o sistema é um fechamento contábil, a operação de fechamento talvez possa esperar 15 minutos por filial.
Certa ocasião, fui chamado para otimizar um sistema em uma concessionária de telecomunicações. O processo batch para bloqueio de terminais pré-pagos estava executando em uma janela de 6 horas. O cliente estava com problemas jurídicos, porque alguns terminais já pagos, eram desbloqueados somente após de 48 horas do pagamento do mesmo. Quando a tarefa do banco de dados foi atribuída a mim, procurei entender o que o processo estava fazendo. Encontrei mais ou menos como segue a tabela/gráfico abaixo:
Podemos notar um overhead de no mínimo 4 horas no processo – MÍNIMO – por que? Ora, se estou na mesma rede, mesma empresa, por que tenho que fazer FTP de um lado para outro? Por que tenho que fazer EXPORT de uma base e IMPORT na outra? Encontrei as respostas facilmente quando investiguei um pouco a origem do sistema. Nenhum analista de banco de dados do lado da nossa empresa, tampouco o DBA da concessionária fora consultado.
Tiradas essas conclusões, armei um plano para desenvolver uma pequena API usando DBLINK, evitando o EXPORT – FTP – IMPORT, ou seja, 4 horas somente em processos desnecessários. Entrei em contato com o DBA deles, acertamos o DBLINK e as permissões necessárias e depois reescrevi o código para desbloqueio a cada N horas conforme o operador determinava; deixei o sistema bastante flexível quanto à execução. Cada vez que o processo “acorda” executava em menos de um minuto e alimentava o MAINFRAME para designar o desbloqueio no mesmo dia. Na verdade, a grande sacada aqui foi: 75% do tempo era gasto em overhead. O que fiz? Me livrei dos processos. Negociei com o DBA para evitarmos esse desperdício. Isso nos rendeu um elegante e-mail de elogios.
Para Performance não existe uma receita de bolo, é preciso usar a criatividade encontrando alternativas. O que é certo é que seu sistema precisa dar SHOW! Precisa de performance SEMPRE.
Como falar sobre performance? Por que eu sou um paranóico por ela? Etimologicamente, performance vem do Francês antigo: par + fournir, ou seja, enfeitar, decorar, fornecer, persistir em uma tarefa até que seja completa. Anos depois, ficou conhecida como dar show, apresentação em um palco, afinação, além disso, atualmente significa desempenho juntando todas as definições anteriores. Então, se seu código tem performance, ele literalmente dá show. É isso que os usuários esperam: que seu código seja um espetáculo.
Eu realmente penso muito no desempenho dos sistemas que desenvolvo. Isso determina o sucesso ou o fracasso deles. Não importa qual tecnologia, quantas camadas, linguagem de desenvolvimento ou banco de dados, se aplicativo, interface ou seja lá o que estiver fazendo, não executar de acordo ao que o negócio exige, estará fadado ao fracasso.
Quem determina o quão rápido o sistema deve ser é o negócio para qual ele será desenvolvido. Por exemplo, em uma aplicação bancária, onde o cliente vai sacar dinheiro, o tempo de operação deve ser menor que 10 segundos após o cliente confirmar a senha. Esse é o requisito para a operação. Entretanto, se o sistema é um fechamento contábil, a operação de fechamento talvez possa esperar 15 minutos por filial.
Certa ocasião, fui chamado para otimizar um sistema em uma concessionária de telecomunicações. O processo batch para bloqueio de terminais pré-pagos estava executando em uma janela de 6 horas. O cliente estava com problemas jurídicos, porque alguns terminais já pagos, eram desbloqueados somente após de 48 horas do pagamento do mesmo. Quando a tarefa do banco de dados foi atribuída a mim, procurei entender o que o processo estava fazendo. Encontrei mais ou menos como segue a tabela/gráfico abaixo:
Podemos notar um overhead de no mínimo 4 horas no processo – MÍNIMO – por que? Ora, se estou na mesma rede, mesma empresa, por que tenho que fazer FTP de um lado para outro? Por que tenho que fazer EXPORT de uma base e IMPORT na outra? Encontrei as respostas facilmente quando investiguei um pouco a origem do sistema. Nenhum analista de banco de dados do lado da nossa empresa, tampouco o DBA da concessionária fora consultado.
Tiradas essas conclusões, armei um plano para desenvolver uma pequena API usando DBLINK, evitando o EXPORT – FTP – IMPORT, ou seja, 4 horas somente em processos desnecessários. Entrei em contato com o DBA deles, acertamos o DBLINK e as permissões necessárias e depois reescrevi o código para desbloqueio a cada N horas conforme o operador determinava; deixei o sistema bastante flexível quanto à execução. Cada vez que o processo “acorda” executava em menos de um minuto e alimentava o MAINFRAME para designar o desbloqueio no mesmo dia. Na verdade, a grande sacada aqui foi: 75% do tempo era gasto em overhead. O que fiz? Me livrei dos processos. Negociei com o DBA para evitarmos esse desperdício. Isso nos rendeu um elegante e-mail de elogios.
Para Performance não existe uma receita de bolo, é preciso usar a criatividade encontrando alternativas. O que é certo é que seu sistema precisa dar SHOW! Precisa de performance SEMPRE.
Labels: Training
Comments:
<< Home
Perfeito Márcio. Foi uma explanação sintética e perfeita.
Vou deixar meu depoimento, caso algum leitor acabe caindo por aqui.
Depois que eu comecei a ter contato com o Márcio (agora o trato como Tio) e outras feras, eu melhorei demais no desenvolvimento de aplicações. E realmente, pensar, e pensar bem pensado, o desenvolvimento de um processo é fundamental na performance. Não adianta sentar na frente do micro e escrever o código da primeira maneira que vier na cabeça. Tenho otimizado alguns códigos e o que me surpreende em muitas das vezes é o uso de operações desnecessarias, loops que poderiam ser resolvidos num único processo e falta de conhecimento das possibilidades que a versão da ferramenta na qual se está trabalhando oferece.
Vou deixar meu depoimento, caso algum leitor acabe caindo por aqui.
Depois que eu comecei a ter contato com o Márcio (agora o trato como Tio) e outras feras, eu melhorei demais no desenvolvimento de aplicações. E realmente, pensar, e pensar bem pensado, o desenvolvimento de um processo é fundamental na performance. Não adianta sentar na frente do micro e escrever o código da primeira maneira que vier na cabeça. Tenho otimizado alguns códigos e o que me surpreende em muitas das vezes é o uso de operações desnecessarias, loops que poderiam ser resolvidos num único processo e falta de conhecimento das possibilidades que a versão da ferramenta na qual se está trabalhando oferece.
# posted by 
: 11:28 AM
: 11:28 AM
é ronaldo, não foi só vc não ... nós melhoramos ... depois da explicação dele lá no hooters sobre cube, sempre que preciso, eu uso ... *rs
aquele abraço tio !
Post a Comment
aquele abraço tio !
# posted by : 2:18 PM
: 2:18 PM<< Home
