O documento discute as diferentes percepções sobre o desempenho de aplicações entre desenvolvedores e equipes de produção, e como ferramentas de APM (Application Performance Management) podem ajudar a alinhar essas visões e otimizar o uso de recursos.

1. A relatividade das percepções na Application Performance
Management(APM)
Cada indivíduo tem suas percepções e entendimentos baseados no seu ponto de vista de experiências vividas.
Na TI não é diferente.
Cada especialista defende veementemente o seu território intelectual baseado nas suas perspectivas de "causa
e efeito" sobre os eventos observados. Causas e efeitos se confundem. Eventos e componentes se misturam.
A conclusão é distorcida. A crescente e rápida demanda do crescimento tecnológico, dificulta identificá-los, e
muitas vezes, geram conflitos entre as áreas que produzem e testam as aplicações (os desenvolvedores) e as
de produção, que as processam e as entregam. Muitas vezes não resolvem eficientemente o "problema"
do cliente (aplicação) , que é quem sofre com a falta de clareza e a demora na solução
A necessidade de gerir os recursos utilizados pela também pelo já sabemos sobre ele, pois acumulo
aplicação na área de TI, vem cada vez mais se utilizando cultural adquirido interfere no julgamento dos fatos
sistematicamente de metodologias e disciplinas
abrangentes para otimização do uso de recursos Figura 1 APM O usuário como o centro das atenções
utilizados pela aplicação juntamente com ferramentas
voltadas a estas disciplinas. Muito embora as áreas de
monitoração e performance já dotem pragmaticamente
medidas melhorias há menos 3 décadas, a adoção da
S u po r te Desenvolvimento
APM, ou Application Performance Management
Técn ico
[GARTNER-5D] vem se intensificando como palavra de EUE* is
ordem para sistematizar, e ao mesmo tempo, disciplinar King
as áreas envolvidas com boas práticas tanto no
desenvolvimento como na execução de aplicativos, com
uma consciência auto-sustentável do uso dos recursos.
P r odu ção Homologação
No entanto, a crescente complexidade tecnológica,
inúmeras fontes de métricas (ferramentas) e a Baseado nesta relatividade, os ‘“mesmos” fatos podem
diversidade de pessoas e áreas envolvidas, tornam a ter conclusões diferentes e divergentes que levam a
adoção da APM uma tarefa árdua de difícil implantação, conflitos de opiniões na defesa veemente do território
dada a grande fragmentação da informação sobre o cultural que o evento parece ter.
comportamento real da aplicação com relação aos
recursos que ela utiliza ao longo do seu Ciclo de Vida. Veja o texto:
http://pt.wikipedia.org/wiki/Relatividade_da_simultaneidad
Durante o Ciclo de Vida da Aplicação, a APM sugere e
verificar o consumo de recursos da aplicação desde o
design, teste, homologação, e produção, ciclicamente. Veja o vídeo:
http://www.youtube.com/watch?v=njToAZrphko
Em função disso, as duas principais áreas envolvidas, ou
sejam, o Desenvolvimento e a Produção, atuam
distantemente do objetivo comum de otimização, O código do usuário como visto pelo desenvolvedor
favorecendo o uso ineficiente dos recursos ao mesmo (Figura 2), não revela os reais recursos necessários para
tempo em que negligenciam o usuário final: EUE is sua execução. Esta pode ser uma visão simplificada que
King[EUE-FEE], que está no vértice destas duas grandes leva a concluir que qualquer “outro” consumo não seja de
áreas. E ele sofre com isso. (Figura 1) responsabilidade de quem o gerou. Na verdade, muitos
serviços necessários para sua execução são solicitados
Cada área tem seus especialistas que usam a sua “implicitamente” pelo código da linguagem ou as APIs
própria experiência tanto na geração, execução e (Application Program Interface) que servem de
otimização da aplicação. O fato inerente, é que, cada um intermediárias aos subsistemas necessários á sua
pode julgar ou interpretar diferentemente os fatos ou execução. (Figura 3)
eventos técnicos sobre comportamento da aplicação.
Surpreendentemente muitas aplicações têm o Aos olhos das ferramentas tradicionais de monitoração
comportamento em produção muito diferente daquele disponíveis, que notadamente monitoram a
que foi desenvolvido e testado. Como conseqüência, as infraestrutura, nem sempre vêem estes recursos
divergências surgem pelas interpretações muitas vezes claramente, pois muitos deles têm escopo limitado para
equivocadas sobre causa e efeito, por estarem em este nível de detalhamento. E isto não é
pontos de vistas baseados em conhecimentos e necessariamente uma limitação, mas sua proposta e
experiências distintos, mas não necessariamente posicionamento.
errados.
A boa notícia é que as ferramentas de APM atuais,
Como sabemos, a interpretação de um fato pode ser atuam como o fiel da balança equilibrando as tanto as
influenciada pelo ponto de vista que em que estamos e visões dos Desenvolvedores como as das equipes de
1

2. produção e seus monitores. Derrubam os mitos, tais
como I/O excessivo, uso eficiente dos índices em banco
de dados, ou ainda crescimento dos negócios - que nem
sempre crescem na mesma proporção que os recursos
[MIPS-Growth]. Quebram paradigmas, revelam verdades.
Figura 2
Aplicação: Evento visto pelo desenvolvedor
0100-INITIALIZATION.
00024200
00024300
MOVE MQOD-CURRENT-VERSION TO MQOD-VERSION IN
MQOD1
MOVE MQOD-CURRENT-VERSION TO MQOD-VERSION IN
MQOD2
SET MSG-CNTR TO 1
INITIALIZE WS-MISC
EXEC CICS IGNORE CONDITION SUPPRESSED
END-EXEC
.
* * * * * * * * * * * * * * * * * * * * * * * * * * * *
* * * * * 00026400
0200-SEND-INITIAL-SCREEN.
EXEC CICS SEND
FROM (TMAP1)
LENGTH (TMAP1A-LEN)
ERASE
END-EXEC
.
* * * * * * * * * * * * * * * * * * * * * * * * * * * *
* * * * * 00026400
CALL 'MQGET' USING WS-HCONN….
.
.
Figura 3
O recurso gerado pelo código implícito da aplicação
02468 0100-INITIALIZATION. 00024200
002469 00024300
002470 MOVE MQOD-CURRENT-VERSION TO MQOD-VERSION IN MQOD1 1223 266
228
002471 MOVE MQOD-CURRENT-VERSION TO MQOD-VERSION IN MQOD2 1223 341
303
002472 SET MSG-CNTR TO 1 166
002473 INITIALIZE WS-MISC 23
002474
002475 *EXEC CICS IGNORE CONDITION SUPPRESSED
002476 *END-EXEC
002477 Call 'DFHEI1' using by content x'020a000007480000000000000000 EXT
002478 - '0000000000000000f0f0f3f1f5404040' end-call
002479 .
002480 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 00026400
1PP 5668-958 IBM VS COBOL II Release 4.0 09/15/92 CCAADEME Date 10/05/07 Time 10:35:17 Page
47
LineID PL SL ----+-*A-1-B--+----2----+----3----+----4----+----5----+----6----+----7-|--+----8 Map and
Cross Reference
0 002481
002482 0200-SEND-INITIAL-SCREEN.
002483
002484 *EXEC CICS SEND
002485 * FROM (TMAP1)
002486 * LENGTH (TMAP1A-LEN)
002487 * ERASE
002488 *END-EXEC
002489 Call 'DFHEI1' using by content x'0404300007000000810000400000 EXT
002490 - '00f0f0f3f2f2404040' by content x'0000' by content x'0000' by
002491 reference TMAP1 by reference TMAP1A-LEN end-call 132 21
002492
002493
002494 .
002495 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 00026400
2

3. Visões distintas
Na efetivação da aplicação em tempo de execução
(produção) devido ao distanciamento das experiências,
cada observador das duas grandes áreas, vê a aplicação
com granularidade, ordem de grandeza e importância
diferentes.
Ao desenvolvedor, aplicação pode parece simples,
grande e importante. A mesma aplicação vista pela
monitoração parece complexa e obscura, ou apenas
mais um programa dentre tantos que executam ao
mesmo tempo.
Todos têm a mesma importância.
Em contrapartida, a “máquina” (sistema oprecional,
subsistemas, subrotinas etc) é complexa aos olhos do
desenvolvedor e esmagadoramente temível e inatingível.
Montando o quebra-cabeças
A ausência ou não adoção de ferramentas de APM,
acabam contribuindo pelo aumento dos choques de
opinião, pois as causas e efeitos se confundem e
eventos se misturam.
Devido a tradicional e paradoxal confusão de causa x
efeito, e a falta de clareza sobre o real fato consumidor
de recurso, chega-se ao paradoxo da capacidade
esgotada. Por não sabermos claramente se é “pouca
máquina ou excesso de carga”, hesitamos em decidir
pela otimização das aplicações.
Como a “energia flui pelo caminho mais fácil”, os
upgrades são, na maioria das vezes, a solução mais
adotada. Entretanto, muitas dessas vezes surtem efeito
por pouco tempo dada a demanda reprimida e ineficácia
em encontrar a real causa do consumo nas aplicações,
conforme o caso.
Num mundo ideal, as próprias ferramentas de APM
facilitam entendimento dos eventos, o engajamento de
todos numa sinergia, a conciliação como um fórum
comum gerador da motivação na ampla e sistemática
adoção pela TI da Gestão da Performance da Aplicação.
Referências:
[GARTNER-5D]Também referida como[] Application
Performance Monitoring e suas 5 dimensões pelo Gartner
Group: The Five Dimensions of 5D no texto “Magic Quadrant for
Application Performance Monitoring” de Will Capelli
[MIPS-Growth] MIPS consumption is growing steadily. The
10% average annual growth rate in MIPS usage is higher than
overall business growth (9%) and overall IT costs growth
(7%)”
– Computerworld White Paper “MIPS Management at
Mainframe
[EUE-FEE] The Five Essential Elements of Application
Performance Monitoring – Don Jones – Realtime publishers: http://
nexus.realtimepublishers.com
Elaborado por:
Gilberto Modollo
Solutions Consultant
Compuware Corporation
3