Por Techopedia Staff, 2 de novembro de 2016
Resumo: O anfitrião Eric Kavanagh discute o desempenho do aplicativo e como melhorar a eficiência com o Dr. Robin Bloor, Dez Blanchfield e Bill Ellis da IDERA.
No momento, você não está logado. Faça o login ou inscreva-se para ver o vídeo.
Eric Kavanagh: Senhoras e senhores, olá e bem-vindos de volta à Hot Technologies. Sim, de fato! Meu nome é Eric Kavanagh, serei o anfitrião de outro webcast hoje nesta série realmente divertida e emocionante que recebemos como elogio à nossa série Briefing Room. O título é "Aceleração de aplicativos: desempenho mais rápido para usuários finais". Vamos lá pessoal, quem não quer isso? Se eu sou o cara lá fora, ajudando seu aplicativo a correr mais rápido, acho que sou o cara que compra cervejas para mim no bar depois do trabalho. Tem que ser uma coisa bem legal entrar e acelerar a aplicação de qualquer pessoa.
Há realmente um slide sobre o seu, me escreva no Twitter, Eric_Kavanagh. Eu sempre tento seguir de volta e sempre re-tweet, se você me mencionar, então fique à vontade para me mencionar.
Todo o objetivo deste programa é focar em diferentes aspectos da tecnologia da empresa e realmente ajudar a definir determinadas disciplinas ou certas faces, se desejar. Muitas vezes, os fornecedores adotam certos termos de marketing e falam sobre como fazem isso ou aquilo ou alguma outra coisa. Esse programa foi realmente projetado para ajudar nosso público a entender o que uma ferramenta de software precisa ter para ser líder em seu espaço. O formato disso são dois analistas. Cada um vai primeiro, ao contrário da Sala de Briefing, onde o fornecedor vai primeiro. Cada um deles ensina o que eles acham importante para você saber sobre um tipo específico de tecnologia.
Hoje estamos falando sobre aceleração de aplicativos. Vamos ouvir notícias de Dez Blanchfield e também do doutor Robin Bloor - hoje em todo o mundo - e, em seguida, Bill Ellis está discando da área da grande Virgínia. Com isso, vou entregá-lo ao nosso primeiro apresentador, Dr. Bloor. Nós tweetamos a hashtag de #podcast por sinal, então fique à vontade para twittar. Leve embora.
Dr. Robin Bloor: Ok, obrigado por essa introdução. Desempenho de aplicativos e níveis de serviço - essa é uma espécie de área. Eu trabalhei bastante nessa área ao longo dos anos, no sentido em que realmente trabalhei bastante para monitorar o desempenho e trabalhar em um de uma forma ou de outra, como tentar calcular esses níveis. É preciso dizer que até - tínhamos essa época, há um tempo atrás, em que as pessoas construíam sistemas em silos. Basicamente, a quantidade de trabalho que eles realmente precisam fazer para que um sistema funcione razoavelmente bem se ele estivesse em um silo não era realmente muito difícil, porque havia muito pouca, muito pequena quantidade de variáveis que você precisava levar em consideração. Assim que entramos em rede corretamente, a orientação interativa e de serviço entrou na equação. Ficou um pouco difícil. O desempenho pode ser unidimensional. Se você apenas pensa em um aplicativo executando um caminho de código específico repetidamente, fazê-lo razoavelmente, em tempo hábil, parece algo unidimensional. Assim que você começa a falar sobre níveis de serviço, na verdade você está falando sobre várias coisas competindo pelos recursos do computador. Torna-se multidimensional muito rapidamente. Se você começar a falar sobre processos de negócios, eles poderão ser encadeados a partir de vários aplicativos. Se você está falando sobre arquitetura orientada a serviços, um determinado aplicativo pode realmente estar acessando os recursos de vários aplicativos. Então isso se torna uma coisa muito complicada.
Eu olhei - há muito tempo, desenhei esse diagrama. Este diagrama tem pelo menos 20 anos. Basicamente, eu chamo de Diagrama de Tudo, porque é uma maneira de ver tudo o que existe no ambiente de TI. Na verdade, são apenas quatro partes: usuários, dados, software e hardware. É claro que elas mudam com o tempo, mas você realmente percebe quando olha para isso que há uma explosão hierárquica de cada uma dessas peças. Um hardware sim, um hardware pode ser um servidor, mas um servidor consiste em possivelmente várias CPUs, tecnologia de rede e memória, e isso, meio que uma enorme quantidade de controladores, acontece. Se você realmente olhar para isso, tudo se divide em pedaços. Se você realmente pensa em tentar orquestrar tudo isso, em relação aos dados que mudam, o desempenho do software muda, porque o hardware muda, e assim por diante, na verdade você está olhando para uma situação multi-variável incrivelmente difícil. Essa é a curva de complexidade. É claro que é uma curva de complexidade para quase tudo, mas eu já vi isso repetidamente quando falamos de computadores. Basicamente, se você colocar nós em um eixo e as conexões importantes no outro eixo, terá uma curva de complexidade. Quase não importa quais são os nós e as conexões, e isso fará se você quiser uma representação do crescimento do volume na rede telefônica.
De fato, quando se fala de nós no ambiente de computadores, você está falando de coisas individuais que se importam umas com as outras. Complexidade, ao que parece, é uma questão de estrutura de variedade e as várias restrições que você está tentando obedecer. Além disso, os números. Quando os números aumentam, eles ficam loucos. Eu tive um bate-papo interessante ontem, estava conversando com alguém - não posso mencionar quem ele era, mas isso realmente não importa - eles estavam conversando sobre um site que tinha 40.000 - isso é quatro-zero, 40.000 - instâncias de bancos de dados no site. Basta pensar nisso - 40.000 bancos de dados diferentes. É claro que a única coisa que tínhamos - eles obviamente tinham muitos, muitos milhares de aplicativos. Estamos falando de uma organização muito grande, mas não sei o nome. Na verdade, você olha para isso e tenta, de uma maneira ou de outra, obter níveis de serviço adequados para vários usuários, com várias expectativas diferentes, se quiser. É uma situação complexa, e o que realmente estou dizendo é que isso é complexo. Os números sempre aumentam. As restrições são determinadas pelos processos e objetivos de negócios. Você deve ter notado que as expectativas mudam.
Lembro-me que, assim que o Gmail, Yahoo Mail e Hotmail, todos esses sistemas de correio surgissem, as pessoas começaram a ter uma expectativa de que seus sistemas internos de correio dentro da organização mereceriam os níveis de serviço dessas grandes operações com vastos farms de servidores fora a organização e começou a ser pressionada a fazer todo esse tipo de coisa acontecer. Na verdade, acordos de nível de serviço são uma coisa, mas a expectativa é outra e eles brigam entre si dentro de uma organização, uma coisa estranha. Aqui está apenas uma perspectiva de negócios. Em alguns sistemas, o tempo de resposta ideal é de um décimo de segundo do tempo de resposta humano. Um décimo de segundo é o tempo que uma cobra leva para morder você. Se você está na frente de uma cobra e decide mordê-lo, é tarde demais, porque você não pode responder em um décimo de segundo. Um décimo de segundo é o tempo que leva para a bola sair da mão do arremessador para alcançar o cara com o taco. Basicamente, quando ele vê a bola jogada, ele tem que responder exatamente naquele momento. Resposta humana, algo interessante. Software para software, obviamente, pode ter uma expectativa maior.
Então você entra em algumas situações que eu acho que são aquelas de mercado, onde ser o primeiro é onde está o valor do negócio. É como se você deseja vender uma ação específica no mercado de ações provavelmente é menor, por exemplo, porque você acha que está caindo e muitas outras pessoas pensam que está caindo, você obtém o melhor preço se chegar ao mercado primeiro. Existem muitas situações, veiculação de anúncios e coisas assim, situação muito semelhante. Você tem esse movimento em termos de expectativa de nível de serviço. Você tem uma coisa que é uma espécie de teto de vidro para a resposta humana. Uma vez que é software para software, se você tiver essa situação de teto, não haverá melhor nível de serviço. Mais rápido que todo mundo é o melhor.
Ok, acho que esse é o slide final que eu estava fazendo, mas isso é apenas para lhe dar uma visão geral da complexidade, uma vez que você realmente analisa os requisitos de uma organização, o serviço. Você tem, subindo o lado esquerdo aqui, você tem gerenciamento de sistema, que é um conjunto de software que serve ao gerenciamento de serviços, que está tentando gerenciar um nível de serviço. Acima disso, você tem gerenciamento de desempenho comercial. Então, se você olhar aqui embaixo, a área de automação de gerenciamento de serviços, terá serviços fragmentados que evoluem para serviços padronizados, se você realmente deseja investir nesse tipo de coisa, que evolui para serviços integrados, que evoluem para serviços otimizados . Principalmente o que as pessoas fizeram é apenas no canto inferior esquerdo disso. Talvez um pouco de gerenciamento de serviços. Gerenciamento de desempenho de negócios, muito raro. Fragmentado, quase tudo. Um mundo perfeito preencheria essa grade. Instrumentação - mencionei um problema de sub-otimização. Você pode otimizar partes de um sistema e isso não é bom para todo o sistema. Se você otimizar o coração, seu sangue poderá circular muito rápido pelos demais órgãos. Esse é um problema com grandes organizações e níveis de serviço. Claramente, nada será alcançado sem ferramentas sofisticadas, porque as variáveis acabaram de chegar - bem, existem muitas variáveis para tentar otimizar.
Dito isso, vou passar para Dez, que conversará sobre algo completamente diferente, espero.
Dez Blanchfield: Obrigado, Robin. Como o Dr. Robin Bloor, passei muitos anos pensando no desempenho de sistemas muito complexos em escala muito grande. Provavelmente não é exatamente a mesma escala que Robin, mas desempenho é um tópico diário e faz parte do nosso DNA desejar desempenho, para tirar o melhor proveito de tudo. Na verdade, eu usei um gráfico de uma das minhas coisas favoritas no mundo, as corridas de carros de Fórmula I, onde o planeta inteiro fica parado por um tempo e observa os carros girando em círculos muito rapidamente. Em todos os aspectos, não há nenhum aspecto da Fórmula I que não seja especificamente sobre obter desempenho. Muitas pessoas fazem cocô no esporte porque acham que é um desperdício de dinheiro. Acontece que o carro que dirigimos todos os dias para deixar as crianças no futebol nos fins de semana e na escola nos outros dias é derivado do desenvolvimento e da pesquisa com base no desempenho. É o tipo de vida das corridas de carros da Fórmula I. A tecnologia cotidiana, a ciência cotidiana, geralmente provém de algo que foi focado puramente no alto desempenho.
A realidade, porém, é que nosso novo mundo "sempre ativo", que exige 100% de tempo de atividade - como Robin mencionou anteriormente - com coisas como a introdução de webmail e outros serviços que consideramos garantidos no espaço contínuo, e agora esperamos que em nossa empresa e ambiente de trabalho. A realidade é que estar acordado nem sempre significa que você está cumprindo seu contrato de nível de serviço. Entendo que a necessidade de gerenciar o desempenho e a disponibilidade dos aplicativos, os contratos de nível de serviço sofreram uma mudança fundamental na última década. Não estamos mais tentando nos preocupar com o desempenho de um sistema. Quando o mundo era um pouco mais simples, podemos ter uma situação em que um único servidor executando vários serviços pode ser monitorado ao vivo e era relativamente simples oferecer suporte. Poderíamos - e aqui está o meu pequeno, sobre as coisas com as quais costumávamos nos preocupar quando eu era um administrador de sistemas, há muitos anos atrás - olharíamos em volta, o serviço normalmente está pronto e respondendo? Posso entrar em um terminal, por exemplo? O sistema operacional está respondendo e posso digitar comandos? Os aplicativos estão funcionando? Posso ver processos e memória ao fazer coisas e E / S na rede e assim por diante? Nos dias de mainframe, você podia ouvir fitas saindo zip-zip-zip e papel caindo delas.
Os aplicativos estão respondendo e podemos fazer login e fazer coisas neles? Os usuários conseguem se conectar a alguns desses servidores? Isso continua. Eles são bastante fundamentais, você sabe. Depois alguns engraçados - o suporte técnico é verde? Porque se não, tudo está indo bem, e quem vai conseguir os donuts? A vida era realmente simples naqueles dias. Mesmo naqueles dias, e então eu estou conversando com 20 a 30 anos atrás, a complexidade ainda era muito alta. Poderíamos, de maneira relativamente direta, gerenciar contratos de nível de serviço e ficar de olho no desempenho. Não podemos mais fazer isso manualmente, como Robin aludiu. O desafio é grande demais. O fato é que, quando alguns bons aplicativos, administradores, rede do sistema e banco de dados, os administradores podem monitorar e atender aos SLAs de desempenho. Os SLAs estão tão distantes agora que lutei ontem à noite, quando estava juntando minhas notas finais, para pensar no ano em que consegui olhar para um sistema de uma pilha muito complexa, compreendê-lo e até compreender o que era acontecendo sob o capô, e eu venho de uma formação profundamente técnica. Não consigo imaginar como é encarar isso no dia a dia agora de forma administrativa.
O que aconteceu? Bem, em 1996, aplicativos orientados a banco de dados foram transformados com o boom da Internet. Muitos de nós já passamos por isso. Mesmo que você não estivesse presente no boom da Internet, você pode facilmente olhar ao redor e perceber que, na vida cotidiana, conectamos tudo à Internet agora. Acredito que temos uma torradeira que aparentemente vem com a opção de acessar o Wi-Fi, o que é ridículo, porque não preciso da minha torradeira conectada à Internet. Na década de 2000, principalmente no início da década de 2000, tivemos que lidar com esse enorme crescimento da complexidade, oferecendo desempenho de serviço no boom das empresas pontocom. Em seguida, outra faísca estranha e ridícula na web 2.0, onde surgiram os smartphones e agora os aplicativos estavam em nossas mãos 24 horas por dia, 7 dias por semana e sempre ativos.
Agora é 2016, estamos diante de outro atoleiro na forma de nuvem, big data e mobilidade. Esses são sistemas tão grandes que geralmente são difíceis de compreender e colocar em inglês simples. Quando pensamos no fato de que alguns dos grandes unicórnios de que falamos têm dezenas de centenas de petabytes de dados. Este é um piso inteiro de espaço em disco e armazenamento apenas para armazenar seu email, imagens e mídias sociais. Ou, em alguns casos, na logística de transporte e remessa, é tudo no setor bancário, é onde está o seu dinheiro, ou onde está sua postagem ou onde você compra o que comprou no eBay. A próxima grande onda que estamos prestes a enfrentar é esse desafio muito pesado da Internet das coisas.
Se isso não bastasse, estamos prestes a criar inteligência artificial e computação cognitiva em praticamente tudo. Hoje falamos com os motores Siri e Google. Eu sei que a Amazon tem um próprio. O Baidu possui um desses dispositivos em que você pode falar, eles convertem em texto que entra em um sistema normal, o banco de dados faz uma consulta e volta e reverte o processo. Pense na complexidade que entra nisso. A realidade é que a complexidade da pilha de aplicativos padrão atual está muito além dos recursos humanos. Quando você pensa sobre tudo o que acontece quando você aperta um botão no seu smartphone ou tablet, fala com ele, converte isso em texto, executa todo o caminho da Internet para um sistema back-end, recebe um front-end isso, converte em uma consulta, executa a consulta através de uma pilha de aplicativos, passa por um banco de dados, bate no disco, volta e, no meio, há uma rede de operadora, um centro de status de rede local. A complexidade é louca.
Nós efetivamente afirmamos isso como hiperescala. A complexidade e a velocidade da hiperescala são apenas irritantes. Aplicativos e bancos de dados tornaram-se tão grandes e tão complexos que gerenciar o desempenho é de fato uma ciência em si. Muitos se referem a ele como uma ciência de foguetes. Temos tecnologia no local, temos tecnologia fora do local, temos uma variedade de opções de data center; físico e virtual. Temos servidores físicos e virtuais, temos nuvem, temos infraestrutura como serviço e plataforma como serviço e software como serviço é uma coisa que agora tomamos como garantida. Este último, software como serviço, tornou-se assustador há alguns anos atrás, quando os diretores financeiros e partes da organização perceberam que podiam pegar seu cartão de crédito e apenas comprar as coisas por conta própria e procurar o CIO e efetivamente chamamos isso de “sombra”. TI ”e os CIOs agora tentam recuperar esse controle e recuperar o controle.
Em infra-estrutura, temos redes definidas por software, virtualização de funções de rede, abaixo das quais temos, provavelmente acabamos, agora temos microsserviços e aplicativos de serviços ativos. Quando você clica em um URL, há um monte de lógica comercial que fica no final do URL que descreve o que ele realmente precisa para entregá-lo. Ele não necessariamente tem uma lógica pré-construída esperando por isso. Temos bancos de dados tradicionais de um lado que estão em escala muito, muito grande. Temos outros tipos de infraestrutura e ecossistemas do Hadoop em outro espectro tão grandes que, como eu disse, você sabe, as pessoas estão falando sobre centenas de petabytes de dados agora. Temos mobilidade complexa em dispositivos que transportam dispositivos móveis, laptops, telefones e tablets.
Temos BYOD em alguns ambientes fechados e cada vez mais agora, já que as pessoas experientes da geração Y estão trazendo seus próprios dispositivos. Apenas deixamos que eles conversem sobre interfaces da web. Pela Internet ou por Wi-Fi, temos acesso Wi-Fi gratuito no café no térreo, enquanto eles tomam café. Ou nosso Wi-Fi interno. Máquina a máquina está sempre presente agora. Isso não faz parte diretamente da Internet, mas também está relacionado. Internet of things é um jogo totalmente novo de uma complexidade que é incompreensível. Inteligência artificial, e se você acha que o que estamos jogando agora, com todos os Siri e outros dispositivos relacionados com os quais falamos, é complexo, espere até chegar a uma situação em que você vê algo chamado Olli, que é um 3D. ônibus impresso que leva cerca de seis pessoas e pode percorrer toda a cidade e você pode falar inglês simples e responderá a você. Se atingir o tráfego, decidirá virar à esquerda ou à direita na área principal onde há tráfego. Quando ele vira e você fica preocupado com o motivo de virar à esquerda ou à direita na estrada principal, ele diz: “Não se preocupe, estou prestes a virar à esquerda. Há tráfego pela frente e eu vou contorná-lo.
Gerenciar o desempenho de todos os sistemas existentes e toda a complexidade, rastrear para onde vão esses dados, se eles vão para o banco de dados, todas as interconexões e todos os bits relevantes é apenas incompreensível. A realidade é que gerenciar o desempenho e os SLAs na velocidade e escala de hoje exige ferramentas e sistemas e, por padrão, isso não é mais algo em que você acha que seria bom ter uma ferramenta - é um pré-requisito; é apenas absolutamente necessário. Aqui está algo como apenas um pequeno exemplo, uma lista dos diagramas de design de aplicativos de alto nível para a nuvem definida pelo software OpenStack, de código aberto. Este é apenas um grande pedaço. Isso não é apenas servidores e banco de dados. É aqui que cada pequena mancha azul representa aglomerados de coisas. Em alguns casos, arquivos e servidores ou centenas de bancos de dados ou, é claro, não mais que dezenas de milhares de pequenos pedaços de lógica de aplicativos em execução. Essa é uma versão pequena. É realmente incompreensível quando você começa a pensar na complexidade que surge nisso. Hoje, mesmo no espaço de big data, vou colocar algumas capturas de tela apenas das marcas. Quando você pensa em todas as peças que precisamos gerenciar aqui, não estamos falando necessariamente de uma marca necessariamente, todas elas são do cenário de big data e da marca de topo, e não apenas de pequenas marcas ou de código aberto. Você olha e acha que é um gráfico incompreensível.
Vamos dar uma olhada em algumas verticais. Vamos pegar o marketing, por exemplo. Aqui está um gráfico semelhante, mas a partir das pilhas de tecnologia disponíveis apenas na tecnologia de marketing. Este é o gráfico de 2011. Aqui está a versão 2016. Basta pensar: este é apenas o número de marcas de produtos que você pode executar para obter tecnologia em relação à tecnologia de marketing. Não é a complexidade dos sistemas lá dentro, nem o aplicativo e a web diferentes e o desenvolvimento e a rede e todos os outros. Apenas a marca. Há o antes, há cinco anos e aqui está hoje. Isso só vai piorar. Agora estamos agora onde a realidade é: os humanos simplesmente não podem garantir todos os acordos de nível de serviço. Não podemos mergulhar em detalhes suficientes, com rapidez suficiente e na escala de que precisamos. Aqui está um exemplo de como um console de monitoramento se parece agora. São quase vinte telas ímpares coladas fingindo ser uma tela grande e projetada, monitorando cada pedacinho. Agora é interessante aqui, não vou mencionar a marca, mas essa plataforma de monitoramento está monitorando um único aplicativo em um ambiente de logística e expedição. Apenas um aplicativo. Se você pensar sobre o que Robin estava falando, onde as organizações podem ter 40.000 bancos de dados agora em ambientes de produção. Você consegue visualizar como seriam 40.000 versões desta coleção de telas que monitoram um aplicativo? É um mundo muito corajoso em que vivemos. Como Robin disse e eu absolutamente, 100% ecoam que, sem as ferramentas certas, sem o apoio e o pessoal certos na mesa usando essas ferramentas, o desempenho do aplicativo é um jogo perdido para os humanos e isso deve ser feito por ferramentas e software.
Com isso, vou passar para os nossos amigos em IDERA.
Eric Kavanagh: Tudo bem, Bill.
Bill Ellis: Obrigado. Compartilhando minha tela aqui. Eu acho que alguém pode confirmar que você pode ver minha tela?
Dr. Robin Bloor: Sim.
Eric Kavanagh: Parece tudo bem.
Bill Ellis: Obrigado. A única coisa que ele se referiu foi que eu mal posso esperar pelo carro que dirigia. A única coisa que eu não tinha ouvido ninguém falar é: o que acontece quando neva? Eu meio que me pergunto se os engenheiros da Califórnia perceberam que em outras partes do país neva um pouco.
Dez Blanchfield: Eu gosto disso, vou lembrar disso.
Eric Kavanagh: Uma típica milha por hora.
Bill Ellis: Estamos aqui para falar sobre gerenciamento de desempenho de aplicativos em um ambiente complexo. Uma coisa que gosto de falar é: muitas pessoas, quando falam sobre desempenho, a natureza da reação é: ei, mais servidores, mais CPU, mais memória, etc. O outro lado dessa moeda é a eficiência do processamento. Realmente, são dois lados da mesma moeda e vamos dar uma olhada nos dois. O objetivo final é cumprir os acordos de nível de serviço para as transações comerciais. Por fim, toda essa tecnologia existe para os negócios. Falamos sobre ter um banco de dados de gerenciamento de desempenho pioneiro no setor. O ideal é ajustar-se ao molde ideal de desempenho e gerenciá-lo desde o início do ciclo de vida dos aplicativos.
Os tópicos realmente se resumem a quatro partes; um é o processo de gerenciar o desempenho. Conversamos com todo mundo, e todo mundo tem ferramentas. Se eles não possuem ferramentas, possuem scripts ou comandos, mas o que está faltando é o contexto. O contexto é simplesmente conectar os pontos nas pilhas de aplicativos. Esses aplicativos para - são baseados em navegador. Eles são muito bem acoplados de um nível para outro. Como as camadas interagem também é vital. Então, estamos falando sobre a transação comercial. Vamos fornecer a visibilidade não apenas para o pessoal técnico, mas também para os proprietários de aplicativos e os gerentes de operações.
Tenho alguns estudos de caso para compartilhar com você como os clientes os utilizaram. Esta é uma parte muito prática da apresentação aqui. Vamos dar uma olhada no que normalmente acontece. Eu gosto de fazer um diagrama - era como uma incrível colagem de tecnologias. O número de tecnologias no data center cresceu e cresceu e cresceu. Enquanto isso, um usuário final não se importa com isso e não sabe disso. Eles só querem exercitar a transação, que esteja disponível, que seja concluída rapidamente. O que normalmente acontece é que os profissionais de TI não sabem que os usuários finais ainda tiveram um problema, até se reportarem. Isso inicia um processo lento, demorado e muitas vezes frustrante. O que acontece é que as pessoas abrirão suas ferramentas e analisarão um subconjunto de sua pilha de aplicativos. Com esse subconjunto, fica muito difícil responder à pergunta mais simples. É normal você ter o problema? Que transação é essa? Onde na pilha de aplicativos está o gargalo? Ao passar todo esse tempo, procurando nível por nível, incapaz de responder a essas perguntas, você acaba gastando muito tempo e energia, muita equipe, fundos e tipo de energia descobrindo.
Para resolver isso, a fim de fornecer uma maneira melhor, o que o Precise faz é realmente levar a transação de rastreamento do usuário final, capturar metadados sobre ela, seguir a transação pela rede, no servidor da web, na camada de lógica de negócios e apoiamos .NET, ABAP, PeopleCode e E-Business Suite, em aplicativos de várias camadas que, em última análise, todas as transações vão interagir com o sistema de registro. Seja uma pesquisa de inventário, o tempo de relatório trabalhado, eles sempre interagem com o banco de dados. O banco de dados se torna a base do desempenho comercial. O banco de dados, por sua vez, depende do armazenamento. Quais são os metadados sobre as transações, quem, qual transação, onde na pilha de aplicativos e, em seguida, temos uma visibilidade profunda no nível do código para mostrar o que está sendo executado. Essas informações são capturadas continuamente, colocadas no banco de dados de gerenciamento de desempenho - que se torna uma única folha de música para todos verem o que está acontecendo. Existem diferentes pessoas e organizações que se preocupam com o que está acontecendo: os especialistas técnicos, os proprietários dos aplicativos e, finalmente, o próprio negócio. Quando surgir um problema, você deseja extrair informações sobre essa transação.
Antes de analisarmos a transação de investimento, quero mostrar como isso pode parecer para diferentes pessoas na organização. Em uma camada de gerenciamento, convém ter uma visão geral de vários aplicativos. Convém saber sobre a integridade calculada pela conformidade e disponibilidade do SLA. Que saúde não significa que tudo está 100% funcionando perfeitamente. Há espaço nesse caso. Você pode ver que a transação de investimento está no status de aviso. Agora, um pouco mais fundo, talvez na linha de negócios, você deseja obter alguns detalhes adicionais sobre transações individuais, quando violam SLAs, contagens de transações etc. A equipe de operações deseja ser notificada sobre isso por meio de um alerta de alguns ordenar. Temos alertas de desempenho integrados. Na verdade, medimos o desempenho no navegador do usuário final. Seja o Internet Explorer, Chrome, Firefox etc., somos capazes de detectar, isso responde à primeira pergunta: o usuário final está com algum problema?
Vamos nos aprofundar e ver o que mais podemos mostrar sobre isso. As pessoas interessadas em desempenho abririam o Precise. Eles avaliavam as transações. Eles examinavam a coluna SLA para identificar transações que não eram compatíveis com o SLA. Eles poderiam ver os usuários finais que foram impactados, bem como o que essa transação fez ao fluir pelo aplicativo. A maneira como você decifra esses hieróglifos é: este é o navegador, o URL, o U é o URL, esse é o ponto de entrada na JVM. Agora, essa JVM específica faz um servidor da Web chamar a segunda JVM que executa a instrução SQL. Esse é claramente um problema no banco de dados, porque essa instrução SQL foi responsável por 72% do tempo de resposta. Estamos focados no tempo. Tempo é a moeda do desempenho. É como os usuários finais experimentam se as coisas estão funcionando lentamente ou não, e é uma medida do consumo de recursos. É muito útil; é o tipo de métrica única mais importante para avaliar o desempenho. Quando esse problema é transferido para o DBA, não é apenas um problema de banco de dados, é esta instrução SQL. Este é o contexto que eu estava falando.
Agora armado com essas informações, sou capaz de analisar o que aconteceu. Eu posso ver em primeiro lugar, o eixo y é o tempo ao longo do dia. Com licença, o eixo y é o tempo de resposta, o eixo x é o tempo ao longo do dia. Percebo que há um problema no banco de dados, há duas ocorrências, retorne a esse fluxo, pegue a instrução SQL e entre na visualização de especialistas, onde o Precise é capaz de mostrar o que está acontecendo, seus controles e quanto tempo esse código leva para executar. Na camada do banco de dados, é o plano de execução. Você observará que o Precise selecionou o plano de execução real que foi usado no tempo de execução, que se distingue do plano estimado, que seria quando o plano fosse fornecido e não durante o tempo de execução. Pode ou não refletir que o banco de dados realmente o fez.
Agora, aqui embaixo, há uma análise do tempo de resposta para a instrução SQL. Noventa por cento do tempo gasto em armazenamento; 10% foram usados na CPU. Eu posso ver o texto da instrução SQL, bem como o relatório de descobertas. O texto da instrução SQL realmente começa a revelar alguns problemas de codificação. É uma estrela selecionada; que retorna todas as linhas - com licença, todas as colunas das linhas que foram retornadas. Estamos retornando colunas adicionais que o aplicativo pode ou não precisar. Essas colunas consomem espaço e recursos para processar. Se você executa o SAP, uma das grandes mudanças, porque o banco de dados do HANA é colunar, é basicamente reescrever o SAP para não escolher a estrela selecionada, para que possam reduzir bastante o consumo de recursos. Isso é basicamente algo que acontece muito tempo também em aplicativos locais, seja Java, .NET etc.
Essa tela mostra quem, o quê, quando, onde e por quê. O porquê, como a instrução SQL e o plano de execução que permite resolver problemas. Como o Precise é executado continuamente, é possível medir antes e depois, no nível da instrução SQL, no nível da transação, para que você possa medir por si mesmo, bem como pelos proprietários do aplicativo e pelo gerenciamento, que resolveu o problema . Essa documentação é realmente útil. Há muita complexidade nessa pilha de aplicativos. De muitas aplicações, na verdade, todas as pessoas com quem conversamos executam pelo menos uma parte da pilha de aplicativos no VMware. Nesse caso, eles estão analisando o aplicativo de serviço ao cliente, analisando o tempo da transação e correlacionando-o com a desaceleração é um evento de virtualização. O Precision rastreia todos os eventos de virtualização. Temos um plug-in para o vCenter para buscá-lo.
Também somos capazes de detectar contenção. A contenção é diferente da utilização. Na verdade, mostra quando talvez um vizinho barulhento esteja afetando sua VM convidada, no contexto do aplicativo do servidor do cliente. Agora, sou capaz de detalhar e obter informações e, na verdade, posso ver as duas VMs que disputam, neste caso, recursos da CPU. Isso me permite ter visibilidade para que eu possa ver a programação. Eu posso colocar uma VM convidada em um servidor físico diferente. Todos esses tipos de coisas que você pode responder e, além disso, posso analisar a eficiência do código para que ele use menos CPU. Acho que tenho um bom exemplo nesta apresentação de como alguém foi capaz de reduzir o consumo de CPU em ordens de magnitude.
Esse foi o VMware. Vamos entrar no próprio código, o código do aplicativo. O Precise poderá mostrar o que está acontecendo em Java, .NET, o código ABAP, E-Business, PeopleCode, etc. Esses são os pontos de entrada para, neste caso, o WebLogic. Aqui embaixo, há um relatório de descobertas que me diz que são esses EJBs que você precisa examinar e me diz que você também está travando nesse sistema. Mais uma vez, faça uma busca detalhada no nível da lógica de negócios, para mostrar o que está acontecendo. Nesse caso, estou analisando casos particulares; Eu também apoio cluster. Se houver várias JVMs em execução, é possível examinar o cluster como um todo ou verificar os gargalos na JVM individual.
Conforme você entra no bloqueio, posso entrar em exceções. Exceção é um pouco diferente de um problema de desempenho. Normalmente, as exceções são executadas muito rapidamente. Como existe um erro lógico e, quando você o atinge, ele termina. Conseguimos capturar um rastreamento de pilha no início de uma exceção. Isso poderia economizar muito tempo, pois ele tentava descobrir o que estava acontecendo. Você apenas tem o rastreamento de pilha, bem ali. Também podemos capturar vazamentos de memória. A solução também inclui a camada do banco de dados, posso entrar, posso avaliar a instância do banco de dados. Mais uma vez, o eixo y é onde o tempo foi gasto, o eixo x é o tempo ao longo do dia. Há um relatório de descobertas que apenas me diz automaticamente o que está acontecendo no sistema e o que eu deveria olhar.
Uma das coisas sobre o relatório de descobertas do Precise, ele não apenas analisa os logs ou o estado de espera - analisa todos os estados de execução, incluindo a CPU, além de retornar informações do armazenamento. O armazenamento é uma parte muito importante da pilha de aplicativos, especialmente com o advento do estado sólido. Ter informações nesse sentido pode ser muito útil. Para determinadas unidades de armazenamento, podemos detalhar e mostrar o que está acontecendo no nível do dispositivo individual. Esse tipo de informação - mais uma vez, é uma visibilidade profunda; seu escopo é amplo - para fornecer informações suficientes para que você possa aproveitar melhor como profissional de desempenho de aplicativos, para que você possa otimizar seus aplicativos de ponta a ponta para atender a essas transações comerciais.
Eu tenho alguns estudos de caso que gostaria de compartilhar com você. Navegamos muito rápido; Espero estar indo no ritmo certo. Falando em armazenamento, todo mundo muda o hardware com o tempo. Há uma garantia de hardware. Realmente entregou o que o fornecedor lhe disse? Você pode avaliar isso com o Precise. Você entra e, o que aconteceu aqui, eles basicamente colocaram uma nova unidade de armazenamento, mas quando os administradores de armazenamento examinaram apenas o nível da unidade de armazenamento, eles viram muita contenda e acharam que poderia haver um problema com essa nova unidade de armazenamento . Observando mais de uma perspectiva de ponta a ponta, precisamente para mostrar onde isso realmente aconteceria. Na verdade, eles passaram de uma taxa de transferência de cerca de 400 meg por segundo, onde o armazenamento foi responsável por 38% do tempo de resposta, portanto é bem alto. Com a nova unidade de armazenamento, aumentamos a taxa de transferência para seiscentos e setecentos megs por segundo, então basicamente o dobro, e podemos reduzir pela metade a contribuição da camada de armazenamento para o tempo de transação. Eu sou capaz de representar graficamente isso antes, esse é o período de transição e depois o seguinte.
Então, mais uma vez, a documentação para provar que o investimento em hardware valeu a pena e eles foram entregues como o fornecedor esperava. Há tudo, devido à complexidade, ao número de coisas, a todo tipo de coisas que podem acontecer. Nesse caso, eles realmente tiveram uma situação em que todo mundo estava culpando o DBA, o DBA era como “Bem, não tão rápido.” Aqui, na verdade, estamos olhando para um aplicativo SAP, acho que esse tipo de cenário é bastante comum . O que aconteceu foi que eles estavam desenvolvendo uma transação personalizada para um usuário. O usuário diz: "Isso é muito lento". O codificador ABAP - que é a linguagem de programação no SAP - disse: "Este é um problema de banco de dados". Eles acabaram abrindo o Precise; eles mediram esse usuário final em 60 segundos, mais de um minuto. Cinquenta e três segundos foram gastos no back-end. Eles analisaram o back-end e conseguiram revelar a instrução SQL apresentada em ordem decrescente.
Essa instrução SQL de topo, responsável por 25% do consumo de recursos, tem um tempo médio de execução de dois milissegundos. Você meio que não pode culpar o banco de dados. Você sabe, ei, não tão rápido, cara. A questão é: por que existem tantas execuções? Bem, eles retornaram para o ABAP, ele entrou, olhou para o aninhamento do loop, descobriu que eles estavam chamando o banco de dados no lugar errado, eles basicamente fizeram a alteração, testaram a alteração e agora o novo tempo de resposta é cinco segundos. Um pouco lento, mas eles poderiam viver com isso. Muito melhor que 60 segundos. Às vezes, apenas descobrindo, é o código do aplicativo, o banco de dados, o armazenamento? Essas são as áreas em que o Precise, ao ter o contexto das transações de ponta a ponta, é onde o Precise entra em cena. Você basicamente termina essas coisas.
Estou olhando para a hora, parece que ainda temos um pouco de tempo para passar por mais algumas delas. Estou transmitindo através deles. Este aplicativo estava em desenvolvimento há mais de um ano. Quando eles entraram no controle de qualidade, estavam vendo que os servidores da Web estavam no máximo 100% e parecia que o aplicativo não podia ser executado no VMware. A primeira coisa que todos disseram foi: “Coloque isso no físico; ele não pode ser executado no VMware. ”A Precise ofereceu a eles outras maneiras de resolver o problema. Examinamos as transações, vimos uma chamada de servidor da Web, que aparece como um ASMX no IIS.NET. Na verdade, revelou o código subjacente. Você vê isso para onde estou apontando? São 23 dias, 11 horas. Uau, como isso é possível? Bem, cada chamada leva 9, 4 segundos e isso é invocado 215.000 vezes. Para cada chamada, ele usa 6 segundos de CPU. Essa é a razão, esse código é a razão pela qual essa coisa nunca pode ser dimensionada. Na verdade, não podia escalar em termos físicos.
O que eles fizeram, voltaram para seus desenvolvedores e disseram: “Alguém pode fazer uma mudança?” Eles meio que fizeram um concurso, testaram as diferentes sugestões e apresentaram uma sugestão que era capaz de executar muito mais eficientemente. O novo completou um ponto, um pouco menos de dois segundos, com duzentos centésimos de segundo na CPU. Agora isso pode ser dimensionado e executado no farm VMware. Conseguimos documentar isso basicamente no nível do código e na transação. Esse é o tipo do antes e depois do depois. Agora que você pode ver aqui no gráfico de barras da pilha que mostra web, .NET e banco de dados, agora você está interagindo com o banco de dados. Este é um perfil que você esperaria ver para um aplicativo que estava sendo executado normalmente.
Tudo bem, estou escolhendo em termos de coisas adicionais que posso mostrar. Muitas pessoas gostam disso, porque isso impressiona muitas lojas. Se você não conseguir atender a um SLA comercial, e todo mundo está tipo: "Ajude-nos". Esta loja teve uma situação em que o SLA comercial está em pedidos recebidos até as 15h, é enviado naquele dia. É realmente vital que eles recebam os pedidos, e o armazém está muito ocupado. A tela de pedidos de vendas da JD Edwards estava congelando e você pode ter uma idéia muito boa de que este é um sistema de gerenciamento de estoque de varejo na hora certa. Prateleiras vazias são inaceitáveis no varejo. Tem que ter a mercadoria lá para vendê-la. O que fizemos foi mergulhar, neste caso, estamos olhando para o banco de dados do servidor SQL. A aparência é a mesma, seja SQL, Oracle, DB2 ou Sybase.
Identificamos o select em PS_PROD e conseguimos capturar a duração, o fato de eles executarem muito. O azul escuro combinava com a chave que dizia que eles não estavam aguardando algum estado de espera ou algum log ou mesmo armazenamento - isso é limitado pela CPU. Nós rastreamos a instrução SQL em 34301, portanto, toda vez que isso é executado, incrementamos nossos contadores para acompanhá-la. Isso significa que temos um histórico detalhado e posso acessá-lo clicando nesse botão de sintonia. Aqui está a guia do histórico. Essa tela aqui mostra a duração média versus as alterações. Quarta, quinta e sexta-feira, a duração média era de dois décimos de segundo. Muito poucos congelamentos de tela podem atender ao SLA comercial. Em 27 de fevereiro, algo muda e, de repente, o tempo de execução está disponível e é realmente lento o suficiente para causar tempos limite, o que resulta em congelamentos da tela. Preciso, mantendo um histórico detalhado, incluindo o plano de execução e alterações gerais nos índices da tabela, se esse SQL estiver em uso. Conseguimos entender que o plano de acesso mudou em 27 de fevereiro. Segunda a semana ruim de sexta-feira. Em 5 de março, o plano de acesso mudou novamente. Esta é uma boa semana. Esta estrela rosa nos diz o volume atualizado.
Você pode ver aqui o número de linhas nas tabelas subjacentes está aumentando e isso é típico para uma empresa. Você quer que suas mesas cresçam. O problema é que as instruções são analisadas, as instruções SQL entram, o otimizador precisa decidir o que fazer e escolher quando o plano de execução é rápido, escolher outro plano de execução quando estiver lento, causando o congelamento da tela. Em uma base tecnológica profunda, preciso saber qual é o plano de execução e o Precise o captura para mim completo com o carimbo de data e hora. Esse foi rápido e eficiente, lento e ineficiente. Essa junção de filtro simplesmente usa muito mais CPU para se reconciliar, para fazer essa instrução SQL específica. Eles ainda têm o mesmo efeito final, mas este basicamente possui uma receita mais lenta e menos eficiente para fornecer o conjunto de resultados. Então, nós avançamos. Ei, temos tempo para mais um par?
Eric Kavanagh: Sim, vá em frente.
Bill Ellis: Ok, eu vou pular adiante. Quero mencionar uma coisa: conversamos sobre hardware, conversamos sobre SAP, conversamos sobre .NET, conversamos sobre JD Edwards e o ambiente Java-SQL Server. Este é o SAP, aqui estamos vendo o PeopleSoft. A matriz de suporte da Precise é ampla e profunda. Se você tem um aplicativo, mais do que provável, podemos instrumentá-lo para fornecer esse nível de visibilidade. Uma das maiores mudanças que estão acontecendo agora é a mobilidade. A PeopleSoft introduziu a mobilidade com a interface do usuário do Fluid. A interface do usuário do Fluid usa um sistema de maneira muito diferente. Esta aplicação está evoluindo. A interface do usuário do Fluid - o que faz da perspectiva do gerenciamento é que permite que os usuários finais usem seus telefones e aumenta muito a produtividade. Se você tem centenas ou milhares ou mais funcionários, se pode aumentar a produtividade deles, 1 a 2%, pode ter um enorme impacto na folha de pagamento e em tudo o mais. O que aconteceu foi que essa loja em particular lançou a UI do PeopleSoft Fluid. Agora, falando sobre complexidade, esta é a pilha do PeopleSoft. Um aplicativo, no mínimo seis tecnologias, inúmeros usuários finais. Como você começa?
Mais uma vez, o Precise poderá seguir essas transações. O que estamos mostrando aqui é um gráfico de barras empilhadas mostrando cliente, servidor Web, Java, banco de dados Tuxedo, pilha de aplicativos PeopleSoft. O verde é mapeado para o J2EE, que é uma maneira elegante de dizer WebLogic. Esta é a transição. Os usuários finais começam a usar a interface do usuário do Fluid e o tempo de resposta varia de um a meio, dois segundos, até nove, dez segundos. O que essa tela não mostra é o número de pessoas que “não responderam”. Na verdade, elas congelaram a tela no aplicativo. Vamos dar uma olhada em algumas das visibilidades que a Precise pode oferecer a esse cliente.
Primeiro de tudo, quando olho para as transações da PeopleSoft, elas podem ver basicamente, vimos esse tipo de coisa em geral. Todas as transações foram impactadas, bem como todos os locais. Aliás, quando você olha para isso, pode ver locais em todo o mundo. Da Ásia-Pacífico, para a Europa e também para a América do Norte. O problema de desempenho não estava localizado em uma transação específica ou em uma localização geográfica específica, mas em todo o sistema. É uma maneira de dizer que a mudança ou a maneira como a interface do usuário do Fluid teve impacto global. Você pode ver aqui do ponto de vista da escalabilidade, as pessoas estão tentando fazer o mesmo tipo de atividade, mas o tempo de resposta basicamente é degradado e degradado. Você pode ver que as coisas não estão aumentando. As coisas estão indo muito, muito mal. Por aqui, quando olho para a contagem de eixos e as conexões simultâneas, você vê algo muito interessante em termos de contagem de acessos e conexões. Aqui estamos escalando apenas cerca de 5.000 e você está olhando para isso, chega a 100 conexões simultâneas. Isso é feito depois; isso é antes. Então, qual é minha demanda real no sistema, se essa coisa pode escalar, está na faixa de 300.000. Antigamente, com a interface do usuário clássica, você vê 30 conexões simultâneas.
Agora, o que isso está dizendo é que a interface do usuário do Fluid usa pelo menos 10x números de conexões simultâneas. Começamos a recuar o que está acontecendo nos bastidores do PeopleSoft, para que você possa começar a ver o impacto nos servidores da Web, o fato de que os SLAs estão começando a violar. Não vai entrar em tudo, mas o que acaba acontecendo é que eles dependem basicamente de mensagens. Eles basicamente exercitam o WebLogic e causam filas no Tuxedo. Na verdade, houve um problema de dependência de várias camadas que apareceu com a interface do usuário do Fluid, mas o Precise foi capaz de mostrar que, por um monte de coisas diferentes, podemos nos concentrar em qual era o problema. Acontece que também houve um problema no próprio banco de dados. Na verdade, existe um arquivo de log de mensagens e, devido a todos os usuários simultâneos, esse arquivo estava bloqueado. Basicamente, havia coisas para ajustar, em todas as camadas da pilha de aplicativos. Falando sobre complexidade, aqui está, na verdade, a camada Tuxedo, mostrando as filas e você também pode ver o desempenho diminuindo nessa camada. Eu pude ver os processos; Eu pude ver os domínios e os servidores. No Tuxedo, para as pessoas usarem isso, normalmente o que você faz é abrir filas, domínios e servidores adicionais, como no supermercado para aliviar o congestionamento e minimizar o tempo de espera na fila. Última e última opção, o Precise mostra muitas informações.
Como mencionei anteriormente, toda transação significativa interage com o sistema de registros. A visibilidade no banco de dados é fundamental. O Precise mostra o que está acontecendo no banco de dados, no WebLogic, no Java, .NET, no navegador, mas o lugar que o Precise realmente se destaca é no nível do banco de dados. Essa é a fraqueza de nossos concorrentes. Deixe-me mostrar uma das maneiras pelas quais o Precise pode ajudá-lo a passar por isso. Não vou dedicar tempo ao triângulo da otimização de banco de dados, mas estamos basicamente olhando para alterações de tipo de baixo custo, baixo risco e amplo escopo, alto risco e alto custo. Na verdade, tweetarei este slide depois se as pessoas quiserem dar uma olhada nele. Acho que é um grande guia para problemas de ajuste. Aqui está a visão de especialistas do Precise for Oracle. No topo do relatório de descobertas, o impacto de 60% é essa instrução SQL específica. Se você abrir esta tela de atividade, ela será exibida lá em cima. Eu posso olhar para esta instrução select, há um plano de execução. Toda execução leva um segundo - 48.000 execuções. Isso soma 48.000 horas a mais de execuções.
O azul escuro, mais uma vez, é a CPU. Essa coisa está ligada à CPU, não é um estado de espera, não é um log. Enfatizo que, porque alguns de nossos concorrentes analisam apenas os estados de espera e os eventos de registro, mas de um modo geral, a CPU é o estado de execução mais movimentado e oferece a maior recompra. Entrando nessa visão de especialista - e estou indo muito rapidamente -, o que fiz foi olhar para a mesa, 100.000 linhas, 37.000 blocos. Estamos fazendo uma tabela completa, mas temos seis índices sobre isso. O que está acontecendo aqui? Bem, quando olho para a cláusula where, o que esta cláusula where está fazendo é na verdade converter uma coluna para maiúscula e dizer onde é igual à maiúscula, encontre a variável. O que está acontecendo é que toda vez que isso é executado, o Oracle precisa converter essa coluna para maiúscula. Em vez de fazer isso quase cinquenta mil vezes, é muito mais eficiente criar esse índice em letras maiúsculas de um índice baseado em funções e está disponível não apenas na divisão corporativa da Oracle, mas também na divisão padrão. Quando você faz isso, o que você pode fazer é verificar o plano de execução que está emitindo esse novo usuário de índice em maiúsculas, isso foi exatamente o que eu fiz.
Então, a partir de uma medição antes e depois, você está olhando para o tempo de execução de um segundo, agrega até 9 horas e 54 minutos, com a mesma instrução SQL exata, mas tendo esse índice construído em maiúsculas para 58.000 execuções, a resposta o tempo cai para menos de milissegundos e, agregado, chega a sete segundos. Basicamente, economizei dez horas de CPU no meu servidor. Isso é imenso. Porque, se não devo atualizar o servidor, posso morar nesse servidor. Na verdade, diminuo o uso do servidor em 20% e você pode ver o antes e o depois. Esse é o tipo de visibilidade que o Precise pode fornecer. Há também algumas coisas adicionais que podemos considerar: por que você tem todos esses índices se eles não estão sendo usados? Eles podem acompanhar isso. Há arquitetura, e vou encerrá-la, já que estamos chegando ao topo da hora. Sou um verdadeiro crente nesta solução e queremos que você seja um verdadeiro crente. Na IDERA, acreditamos que uma avaliação faz um cliente; portanto, se você estiver interessado, poderemos fazer avaliações no seu site.
Com isso, vou passar o farol de volta.
Eric Kavanagh: Sim, isso foi um tremendo detalhe que você mostrou lá. É realmente muito fascinante. Acho que já mencionei a você no passado que - e eu sei que em alguns dos outros webcasts que fizemos com o IDERA, mencionei isso -, eu venho acompanhando o Precise desde antes de ser adquirido pelo IDERA, todo o caminho de volta a 2008, eu acho, ou 2009. Eu estava fascinado por isso naquela época. Estou curioso para saber quanto trabalho é necessário para acompanhar as novas versões de aplicativos. Você mencionou o SAP HANA, que eu acho bastante impressionante, pois você pode realmente explorar a arquitetura do HANA e solucionar alguns problemas lá. Quantas pessoas você tem? Quanto esforço você faz e quanto pode ser feito de maneira dinâmica, ou seja, quando a ferramenta é implantada, você começa a engatinhar e a ver coisas diferentes? Quanto disso pode ser dinamicamente determinado pela ferramenta, para que você possa ajudar as pessoas a solucionar problemas de ambientes complexos?
Bill Ellis: Você fez muitas perguntas lá.
Eric Kavanagh: Eu sei, desculpe.
Bill Ellis: Eu forneci muitos detalhes, porque para essas aplicações, olhando o código, o diabo está nos detalhes. Você precisa ter esse nível de detalhe para realmente ter algo que possa ser acionado. Sem métricas acionáveis, você apenas conhece os sintomas. Você não está realmente resolvendo problemas. O IDERA trata da resolução de problemas. Ficar por dentro dos novos lançamentos e outras coisas é um grande desafio. A questão do que é preciso para fazer isso é realmente para o gerenciamento de produtos. Não tenho muita visibilidade da equipe que basicamente nos mantém atualizados. Em termos de HANA, isso é realmente uma nova adição à linha de produtos IDERA; é muito emocionante. Uma das coisas com o HANA é: deixe-me falar sobre a tarefa por um segundo. Na tarefa, as lojas da SAP deveriam replicar o banco de dados para fins de relatório. Então, é preciso que as pessoas se reconciliem com o que é realmente atual. Você teria esses bancos de dados diferentes e eles ficariam fora de sincronia em diferentes níveis. Há muito tempo e esforço, além do hardware, do software e das pessoas para manter tudo isso.
A ideia do HANA de ter um banco de dados na memória altamente paralelo, para basicamente evitar a necessidade de bancos de dados duplicados. Temos um banco de dados, uma fonte de verdade, sempre atualizada, para evitar o necessário para fazer toda essa reconciliação. A importância do desempenho do banco de dados HANA aumenta - vou dizer 10x ou pelo menos mais valioso do que a soma de todos os outros bancos de dados, hardware e recursos que podem comprar. Sendo capaz de gerenciar o HANA, agora que esse componente está atualmente em teste beta no momento, é algo que será lançado em breve. Então, isso é muito empolgante para a IDERA e para basicamente oferecer suporte à plataforma SAP. Não tenho certeza de que outras partes da sua pergunta eu meio que alterei, mas -
Eric Kavanagh: Não, isso é tudo de bom lá. Eu joguei um monte inteiro em você de uma só vez, desculpe por isso. Estou realmente fascinado, sério, quero dizer, não é uma aplicação muito simples, certo? Você está se aprofundando nessas ferramentas e entendendo como elas estão interagindo umas com as outras e, a seu ponto, você precisa juntar a história em sua cabeça. Você precisa combinar pequenas informações para entender o que realmente está acontecendo e o que está causando o problema, para poder ir lá e resolver esses problemas.
Um participante está perguntando: quão difícil é implementar o Precise? Outra pessoa perguntou: quem são as pessoas - obviamente os DBAs -, mas quem são outras funções na organização que usariam essa ferramenta?
Bill Ellis: O Precise é um pouco mais complicado de implantar. Você precisa ter algum conhecimento do ambiente do aplicativo, em termos de, sabe, esse aplicativo é executado nesse banco de dados, precisa ou - nos servidores Web de camada intermediária, etc. Acho que, dada a complexidade de alguns desses aplicativos, é realmente relativamente fácil. Se eu posso instrumentar o servidor da Web até seu banco de dados, posso fazer isso de ponta a ponta. Você percebe que eu não disse nada sobre como instrumentar um cliente usuário final e é porque o que fazemos é que incluímos dinamicamente, para que você não precise alterar seu código ou qualquer outra coisa. Um JavaScript entra no quadro da página do aplicativo. Não importa onde o usuário esteja, no mundo, quando eles acessam o URL do seu aplicativo e acessam a página, ele vem instrumentado com o Precise. Isso nos permite escolher o ID do usuário, seu endereço IP e também o tempo de renderização do primeiro byte de cada tempo de execução do script dos componentes da página no navegador do usuário final.
Em termos de transações, você não precisa mapear as transações porque elas estão fortemente acopladas. Essa URL se torna um ponto de entrada para a JVM e, em seguida, invoca esta mensagem, resultando em uma JVC capturada no banco de dados. Basicamente, podemos capturar esses pontos de conexão naturais e apresentá-los a você na tela de transação que mostrei onde calculamos também quanto tempo ou a porcentagem de tempo gasto em cada etapa individual. Tudo isso é feito automaticamente. De um modo geral, alocamos 90 minutos para fazer - basicamente instalar o núcleo Precise e, então, começamos a implementar o aplicativo. Dependendo do conhecimento do aplicativo, pode levar algumas sessões adicionais para instrumentalizar todo o aplicativo. Muitas pessoas usam apenas o componente de banco de dados do Precise. Isso é bom. Você pode basicamente dividir isso, dividir nos componentes que você sente que o seu site precisa. Definitivamente, acreditamos que o contexto de instrumentar toda a pilha de aplicativos para que você possa ver que a dependência de camada a camada realmente amplia o valor de monitorar uma camada individual. Se alguém quiser explorar ainda mais a instrumentação de sua pilha de aplicativos, acesse nosso site - acho que é a maneira mais fácil de solicitar informações adicionais, e discutiremos um pouco mais.
Eric Kavanagh: Deixe-me fazer uma ou duas perguntas rápidas para você. Suponho que você esteja coletando e construindo um repositório ao longo do tempo, tanto para clientes individuais quanto como uma entidade corporativa em geral, de interações entre vários aplicativos e vários bancos de dados. Em outras palavras, acho que a modelagem de cenário é o que estou fazendo alusão. É esse o caso? Você realmente mantém uma espécie de repositório de cenários comuns, de modo que você pode fazer sugestões para os usuários finais quando certas coisas entram em jogo? Como esta versão do E-Business Suite, esta versão deste banco de dados etc. - você faz muito disso?
Bill Ellis: Bem, esse tipo de informação está embutido no relatório de descobertas. O relatório de descobertas indica quais são os gargalos de desempenho e se baseia no tempo de execução. Parte desse relatório de descobertas é aprender mais e o que você faz a seguir. As informações ou a experiência dos clientes e assim por diante são basicamente incorporadas a essa biblioteca de recomendações.
Eric Kavanagh: Ok, isso parece bom. Bem pessoal, apresentação fantástica hoje. Bill, adorei quantos detalhes você tinha lá. Eu apenas pensei que essas informações eram realmente fantásticas, granulosas e detalhadas, mostrando como tudo isso é feito. Em um certo ponto, é quase como magia negra, mas na verdade não é. É uma tecnologia muito específica que vocês montam para entender ambientes muito, muito complexos e fazer as pessoas felizes porque ninguém gosta quando os aplicativos são executados lentamente.
Bem pessoal, vamos arquivar este webcast. Você pode entrar on-line no Techopedia ou insideanalysis.com e uau, obrigado pelo seu tempo, nós o encontraremos na próxima vez. Tome cuidado, tchau-tchau.
