Par Techopedia Staff, 2 novembre 2016
À retenir: l' hôte Eric Kavanagh discute des performances des applications et de la façon d'améliorer l'efficacité avec le Dr Robin Bloor, Dez Blanchfield et l'IDERA's Bill Ellis.
Vous n'êtes actuellement pas connecté. Veuillez vous connecter ou vous inscrire pour voir la vidéo.
Eric Kavanagh: Mesdames et messieurs, bonjour et bienvenue à nouveau à Hot Technologies. Oui en effet! Je m'appelle Eric Kavanagh, je serai votre hôte pour une autre webdiffusion aujourd'hui dans cette série vraiment amusante et excitante que nous avons en complément de notre série Briefing Room. Le titre est «Accélération des applications: des performances plus rapides pour les utilisateurs finaux». Allez les amis, qui ne veut pas ça? Si je suis le gars qui aide votre application à fonctionner plus rapidement, je pense que je suis le gars qui achète des bières pour moi au bar après le travail. Ça doit être une chose assez cool de marcher et d'accélérer l'application de n'importe qui.
Il y a une diapositive sur la vôtre, contactez-moi sur Twitter @Eric_Kavanagh. J'essaie toujours de revenir en arrière et je re-tweete toujours si vous me mentionnez, alors n'hésitez pas à me mentionner.
Le but de ce spectacle est de se concentrer sur différents aspects de la technologie d'entreprise et vraiment aider à définir certaines disciplines ou certains visages, si vous voulez. La plupart du temps, les vendeurs reprendront certaines conditions de marketing et parleront de la façon dont ils font ceci ou cela ou autre chose. Ce spectacle a été vraiment conçu pour aider notre public à comprendre ce dont un outil logiciel a besoin pour être un leader dans son espace. Le format de ceci étant deux analystes. Chacun passe en premier, contrairement à la salle de briefing où le vendeur se rend en premier. Chacun donne son avis sur ce qu'il pense important pour vous de connaître un type particulier de technologie.
Aujourd'hui, nous parlons de l'accélération des applications. Nous allons entendre Dez Blanchfield et aussi le docteur Robin Bloor - nous sommes partout dans le monde aujourd'hui - puis Bill Ellis se connecte depuis la grande région de Virginie. Sur ce, je vais céder la parole à notre premier présentateur, le Dr Bloor. Soit dit en passant, nous avons tweeté le hashtag de #podcast, alors n'hésitez pas à tweeter. Emportez-le.
Dr Robin Bloor: D'accord, merci pour cette introduction. Performances des applications et niveaux de service - c'est une sorte de domaine, j'ai fait beaucoup de travail dans ce domaine au fil des ans, en ce sens que j'ai fait énormément de travail pour surveiller les performances et travailler dans un d'une manière ou d'une autre, comment essayer de calculer ces niveaux. Il faut dire que jusqu'à - nous avions cette époque, il y a quelque temps, où les gens construisaient des systèmes en silos. Fondamentalement, la quantité de travail qu'ils doivent réellement faire pour que le système fonctionne raisonnablement bien s'il était dans un silo n'était pas vraiment trop difficile, car il y a très peu, très peu de variables que vous avez dû prendre en considération. Dès que nous avons été correctement mis en réseau, l'interaction et l'orientation service sont entrées en jeu. C'est devenu un peu difficile. Les performances peuvent être unidimensionnelles. Si vous pensez simplement à une application qui exécute un chemin de code particulier à plusieurs reprises, le faire raisonnablement, en temps opportun, ressemble à une chose unidimensionnelle. Dès que vous commencez à parler des niveaux de service, vous parlez en fait de plusieurs choses en concurrence pour les ressources informatiques. Il devient très rapidement multidimensionnel. Si vous commencez à parler de processus métier, les processus métier peuvent être regroupés à partir de plusieurs applications. Si vous parlez d'architecture orientée services, une application donnée peut en fait accéder aux capacités de plusieurs applications. Cela devient alors une chose très compliquée.
J'ai regardé - il y a longtemps, j'ai dessiné ce diagramme. Ce diagramme a au moins 20 ans. Fondamentalement, je l'appelle le diagramme de tout, car c'est une façon de voir tout ce qui existe dans l'environnement informatique. Ce n'est vraiment que quatre éléments: les utilisateurs, les données, les logiciels et le matériel. Bien sûr, ils changent avec le temps, mais vous vous rendez compte en réalité qu'il y a une explosion hiérarchique de chacune de ces pièces. Un matériel oui, un matériel peut être un serveur mais un serveur se compose peut-être de plusieurs processeurs, de la technologie réseau et de la mémoire, et cela, en quelque sorte, beaucoup de contrôleurs, comme cela se produit. Si vous regardez cela, tout se décompose. Si vous pensez réellement à orchestrer tout cela, en ce qui concerne les données qui changent, les performances du logiciel changent, parce que le matériel change, et ainsi de suite, vous êtes en fait confronté à une situation multivariée incroyablement difficile. Ceci est la courbe de complexité. Bien sûr, c'est la courbe de complexité pour à peu près tout, mais je l'ai vu dessiné maintes et maintes fois en parlant d'ordinateurs. Fondamentalement, si vous placez des nœuds sur un axe et les connexions importantes sur l'autre axe, vous vous retrouvez avec une courbe de complexité. Peu importe ce que sont les nœuds et les connexions et cela fera l'affaire si vous voulez une représentation de la croissance du volume dans le réseau téléphonique.
En fait, lorsque vous parlez de nœuds dans l'environnement informatique, vous parlez de choses individuelles qui se soucient les unes des autres. Il s'avère que la complexité est une question de structure de variété et de contraintes diverses auxquelles vous essayez de vous conformer. Aussi, les chiffres. Lorsque les chiffres augmentent, ils deviennent fous. J'ai eu une conversation intéressante hier, je parlais à quelqu'un - je ne peux pas mentionner qui il était, mais cela n'a pas vraiment d'importance - ils parlaient d'un site qui avait 40 000 - c'est quatre zéro, 40 000 - instances de bases de données dans le site. Pensez-y, 40 000 bases de données différentes. Bien sûr, la seule chose que nous avions - ils avaient évidemment des milliers, des milliers d'applications. Nous parlons d'une très grande organisation, mais je ne peux pas le nommer. En fait, vous regardez cela, et vous essayez en fait, d'une manière ou d'une autre, d'obtenir des niveaux de service qui seront adéquats à tous les niveaux pour plusieurs utilisateurs, avec de multiples attentes différentes, si vous voulez. C'est une situation complexe, et tout ce que je dis, c'est que ce truc est complexe. Les nombres augmentent toujours. Les contraintes sont déterminées par les processus métier et les objectifs métier. Vous aurez remarqué que les attentes changent.
Je me souviens que dès que Gmail, Yahoo mail et Hotmail, tous ces systèmes de messagerie sont apparus, les gens ont commencé à s'attendre à ce que leurs systèmes de messagerie internes au sein de l'organisation méritent les niveaux de service de ces énormes opérations avec de vastes batteries de serveurs à l'extérieur l'organisation et a commencé à subir des pressions pour que tout ce genre de chose se produise. En fait, les accords de niveau de service sont une chose, mais les attentes en sont une autre et ils se combattent au sein d'une organisation, une chose maladroite. Voici juste une perspective commerciale. Dans certains systèmes, le temps de réponse optimal est un dixième de seconde du temps de réponse humain. Un dixième de seconde est le temps qu'il faut à un cobra pour vous mordre. Si vous vous tenez devant un cobra, et qu'il décide de vous mordre, c'est trop tard, ça va parce que vous ne pouvez pas répondre en un dixième de seconde. Un dixième de seconde est à peu près le temps qu'il faut au ballon pour quitter la main du lanceur pour atteindre le gars avec la batte. Fondamentalement, comme il voit la balle lancée, il doit répondre exactement à ce moment-là. Réponse humaine, une sorte de chose intéressante. De logiciel à logiciel, on peut évidemment avoir une attente plus élevée.
Ensuite, vous entrez dans des situations qui, je pense, sont des situations de marché, où le premier est la valeur commerciale. C'est comme si vous voulez vendre un titre particulier en bourse, c'est probablement moins, par exemple, parce que vous pensez qu'il baisse et que beaucoup d'autres pensent qu'il baisse, vous obtenez le meilleur prix si vous arrivez au marché en premier. Il y a beaucoup de situations, la diffusion d'annonces et des choses comme ça, une situation très similaire. Vous avez ce mouvement en termes d'attentes de niveau de service. Vous avez une chose qui est une sorte de plafond de verre pour la réponse humaine. Une fois que c'est logiciel à logiciel, si vous avez cette situation de plafond, il n'y a pas de meilleur niveau de service. Plus vite que tout le monde est le meilleur.
D'accord, c'est, je pense, la dernière diapositive que je faisais, mais c'est juste pour vous donner une vue d'ensemble de la complexité, une fois que vous avez réellement examiné les exigences d'une organisation, le service. Vous avez, en montant à gauche ici, vous avez la gestion du système, qui est un ensemble de logiciels qui sert à la gestion des services, qui essaie de gérer un niveau de service. Au-dessus, vous avez la gestion des performances de l'entreprise. Ensuite, si vous regardez en bas ici, le domaine de l'automatisation de la gestion des services, vous avez des services fragmentés qui évoluent en services standardisés, si vous souhaitez réellement investir dans ce genre de chose, qui évoluent en services intégrés, qui évoluent en services optimisés . La plupart du temps, ce que les gens ont fait, c'est seulement dans le coin inférieur gauche de cela. Peut-être un peu de gestion des services. Gestion de la performance commerciale, très rare. Fragmenté, presque tout. Un monde parfait remplirait cette grille. Instrumentation - J'ai mentionné un problème de sous-optimisation. Vous pouvez optimiser des parties d'un système et ce n'est pas bon pour l'ensemble du système. Si vous optimisez le cœur, votre sang pourrait circuler trop rapidement pour le reste de vos organes. C'est un problème avec les grandes organisations et les niveaux de service. De toute évidence, rien ne sera réalisé sans outils sophistiqués, car les variables viennent juste d’être obtenues - eh bien, il y a trop de variables à essayer et à optimiser.
Cela dit, je vais passer à Dez qui parlera de quelque chose d'autre, j'espère.
Dez Blanchfield: Merci, Robin. Comme le Dr Robin Bloor, j'ai passé beaucoup trop d'années à réfléchir aux performances de systèmes très complexes à très grande échelle. Probablement pas à la même échelle que Robin, mais la performance est un sujet quotidien et cela fait partie de notre ADN de vouloir la performance, de tirer le meilleur parti de tout. En fait, j'ai utilisé un graphique de l'une de mes choses préférées dans le monde, la course automobile de Formule I, où la planète entière reste immobile pendant un certain temps et regarde les voitures tourner en rond très rapidement. Chaque aspect, il n'y a aucun aspect de la Formule I qui ne concerne pas spécifiquement les performances. Beaucoup de gens font caca le sport parce qu'ils pensent que c'est un gaspillage d'argent. Il s'avère que la voiture que nous conduisons chaque jour pour déposer les enfants au football le week-end et à l'école les autres jours est issue du développement et de la recherche basés sur les performances. C'est un peu la vie de la course automobile de Formule I. La technologie de tous les jours, la science de tous les jours, vient souvent de quelque chose qui est axé uniquement sur la haute performance.
La réalité, cependant, est que notre nouveau monde "toujours actif", qui exige une disponibilité à 100% - comme Robin l'a mentionné plus tôt - avec des choses comme l'introduction du webmail et d'autres services que nous tenons pour acquis dans un espace continu, et nous nous attendons maintenant à ce que dans notre entreprise et notre environnement de travail. La réalité est qu'être en place ne signifie pas toujours que vous respectez votre accord de niveau de service. J'ai cette prise sur la nécessité de gérer les performances des applications et la disponibilité des accords de niveau de service a subi un changement fondamental au cours de la dernière décennie. Nous n'essayons plus seulement de nous soucier des performances d'un système. Lorsque le monde était un peu plus simple, nous pourrions avoir une situation où un seul serveur exécutant plusieurs services peut être surveillé en direct et il était relativement simple à prendre en charge. Nous pourrions - et voici mon petit, les choses dont nous nous inquiétions lorsque j'étais administrateur système par exemple, il y a de nombreuses années - nous regardions autour de nous, le service est-il généralement opérationnel et répond-il? Puis-je me connecter à un terminal par exemple? Le système d'exploitation répond-il et puis-je taper des commandes? Les applications sont-elles opérationnelles? Puis-je voir les processus et la mémoire dans les tâches et les E / S sur le réseau, etc.? Dans les jours de mainframe, vous pouviez entendre des bandes coulissant zip-zip-zip et du papier en tomber.
Les applications répondent-elles et pouvons-nous nous connecter et faire des choses sur elles? Les utilisateurs peuvent-ils se connecter à certains de ces serveurs? Ça continue. Ils sont assez fondamentaux, vous savez. Ensuite, quelques drôles - le service d'assistance est-il vert? Parce que sinon, tout va bien, et qui va obtenir les beignets? La vie était vraiment simple à cette époque. Même à l'époque, et je parle d'il y a 20 à 30 ans, la complexité était encore très élevée. Nous pourrions, d'une manière relativement simple, gérer les accords de niveau de service et garder un œil sur les performances. Nous ne pouvons plus le faire à la main, comme Robin l'a mentionné. Le défi est trop grand. Le fait est le moment où quelques bonnes applications, administrateurs, réseau système et base de données, les administrateurs peuvent surveiller et respecter les SLA de performance. Les SLA sont si loin maintenant que j'ai eu du mal hier soir quand je préparais mes notes finales pour même penser à l'année où j'ai réussi à regarder un système d'une pile très complexe, à le comprendre et même à comprendre ce qui était passe sous le capot, et je viens d'un milieu profondément technique. Je ne peux pas imaginer ce que c'est que de faire face à cela au jour le jour maintenant de façon administrative.
Qu'est-il arrivé? Eh bien, en 1996, les applications basées sur des bases de données ont été transformées avec le boom d'Internet. Beaucoup d'entre nous sont passés par là. Même si vous n'étiez pas dans le boom d'Internet, vous pouvez facilement regarder autour de vous et réaliser que dans la vie de tous les jours, nous connectons tout à Internet maintenant. Je crois que nous avons un grille-pain qui semble avoir la possibilité de se connecter au Wi-Fi, ce qui est ridicule, car je n'ai pas besoin que mon grille-pain soit connecté à Internet. Dans les années 2000, en particulier au début des années 2000, nous avons dû faire face à cette croissance massive du cycle de complexité pour fournir des performances de service dans le boom des dot-com. Ensuite, une autre étincelle ridicule et maladroite dans le Web 2.0, où les smartphones sont apparus et maintenant les applications étaient entre nos mains 24/7 et étaient toujours en mode actif.
Nous sommes en 2016 maintenant, nous sommes confrontés à un autre bourbier sous la forme de cloud et de big data et de mobilité. Ce sont des systèmes qui sont tellement volumineux qu'ils sont souvent difficiles à comprendre et à utiliser dans un anglais simple. Quand on pense au fait que certaines des grandes licornes dont nous parlons ont des dizaines de centaines de pétaoctets de données. Il s'agit d'un étage entier d'espace disque et de stockage juste pour contenir vos e-mails, vos images et vos réseaux sociaux. Ou dans certains cas, dans la logistique du transport et de l'expédition, tout est dans la banque, c'est là où se trouve votre argent, ou où se trouve votre poste, ou votre, où se trouve la chose que vous avez achetée sur eBay. La prochaine grande vague à laquelle nous allons faire face est ce très gros défi de l'Internet des objets.
Si cela ne suffisait pas, nous sommes sur le point d'intégrer l'intelligence artificielle et l'informatique cognitive à peu près tout. Nous parlons aux moteurs Siri et Google ces jours-ci. Je sais qu'Amazon en a un. Baidu possède l'un de ces appareils auquel vous pouvez parler, il le convertit en texte qui va dans un système normal, la base de données fait une requête et revient et inverse le processus. Pensez à la complexité de tout cela. La réalité est que la complexité de la pile d'applications standard d'aujourd'hui dépasse de loin les capacités humaines. Lorsque vous pensez à tout ce qui se passe lorsque vous appuyez sur un bouton de votre smartphone ou de votre tablette, vous lui parlez, le convertissez en texte, le transférez jusqu'à Internet vers un système principal, un frontal reçoit qui, le convertit en requête, exécute la requête via une pile d'applications, passe par une base de données, frappe le disque, revient, et au milieu il y a un réseau de transporteur, il y a un centre d'état du réseau local. La complexité est folle.
Nous affirmons effectivement cela comme hyperscale. La complexité et la vitesse de l'hyperscale ne font qu'arroser les yeux. Les applications et les bases de données sont devenues si grandes et si complexes que la gestion des performances est en fait une science en soi. Beaucoup se réfèrent à lui comme une science de fusée. Nous avons une technologie sur site, nous avons une technologie hors site, nous avons une gamme d'options de centre de données; physique et virtuel. Nous avons des serveurs physiques et virtuels, nous avons un cloud, nous avons une infrastructure en tant que service et une plate-forme en tant que service et un logiciel en tant que service est une chose que nous tenons maintenant pour acquise. Ce dernier, le logiciel en tant que service, est devenu effrayant il y a quelques années lorsque les directeurs financiers et des parties de l'organisation ont réalisé qu'ils pouvaient récupérer leur carte de crédit et simplement acheter des choses eux-mêmes et faire le tour du CIO et, en fait, nous avons appelé cela «l'ombre IT ”et les DSI essaient maintenant de remonter ce contrôle et de reprendre le contrôle.
Dans l'infrastructure, nous avons la mise en réseau définie par logiciel, la virtualisation des fonctions réseau, en dessous de celle que nous avons, probablement plus, maintenant nous avons des microservices et des applications de services actifs. Lorsque vous cliquez sur une URL, il y a un tas de logique métier à la fin de cette URL qui décrit ce dont elle a besoin pour la livrer. Il n'a pas nécessairement une logique pré-construite qui l'attend. Nous avons d'un côté des bases de données traditionnelles qui évoluent très, très grandes. Nous avons des infrastructures et des écosystèmes Hadoop sur l'autre spectre qui sont tellement vastes que, comme je l'ai dit, vous savez, les gens parlent de centaines de pétaoctets de données maintenant. Nous avons une mobilité complexe en ce qui concerne les appareils qui se déplacent, les ordinateurs portables, les téléphones et les tablettes.
Nous avons du BYOD dans certains environnements fermés et de plus en plus maintenant, car les personnes expérimentées de la génération Y apportent leurs propres appareils. Nous les laissons simplement leur parler des interfaces Web. Que ce soit sur Internet ou sur Wi-Fi, nous avons une connexion Wi-Fi gratuite dans le café en bas car ils prennent un café. Ou notre Wi-Fi interne. La machine à machine est toujours présente aujourd'hui. Cela ne fait pas directement partie de l'Internet des objets, mais c'est également lié. L'Internet des objets est un tout nouveau jeu d'une complexité époustouflante. L'intelligence artificielle, et si vous pensez que ce avec quoi nous jouons actuellement, avec tous les Siri et autres appareils connexes avec lesquels nous parlons est complexe, attendez que vous arriviez à une situation où vous voyez quelque chose appelé Olli qui est un 3-D bus imprimé qui prend environ six personnes et peut se déplacer en ville et vous pouvez lui parler un anglais simple, et il vous répondra. S'il atteint le trafic, il décidera de tourner à gauche ou à droite hors de la zone principale où il y a du trafic. Quand il tourne et que vous vous demandez pourquoi il a tourné à gauche ou à droite sur la route principale, il vous dira: «Ne vous inquiétez pas, je suis sur le point de tourner à gauche. Il y a du trafic devant moi et je vais le contourner. »
Gérer les performances de tous les systèmes qui s'y trouvent et toute la complexité, suivre où ces données vont, si elles vont dans la base de données, toutes les interconnexions et tous les bits pertinents est tout simplement époustouflant. La réalité est que la gestion des performances et des SLA à la vitesse et à l'échelle d'aujourd'hui nécessite des outils et des systèmes, et par défaut, ce n'est plus quelque chose où vous penseriez qu'il serait bien d'avoir un outil - c'est une condition préalable; c'est juste absolument nécessaire. Voici un exemple, une liste des diagrammes de conception d'applications de haut niveau pour OpenStack, cloud défini par logiciel open source. Ce n'est qu'un gros morceau. Ce ne sont pas seulement des serveurs et des bases de données. C'est là que chaque petite goutte bleue représente des grappes de choses. Dans certains cas, des fichiers et des serveurs ou des centaines de bases de données ou bien sûr pas plus de dizaines de milliers de petits morceaux de logique d'applications en cours d'exécution. Voilà une petite version. C'est vraiment ahurissant quand vous commencez à penser à la complexité qui en découle. Aujourd'hui, même dans l'espace Big Data, je vais juste mettre quelques captures d'écran des marques. Lorsque vous pensez à toutes les pièces que nous devons gérer ici, nous ne parlons pas nécessairement d'une seule marque, ce sont toutes les marques du paysage des mégadonnées et la meilleure marque, pas seulement toutes les petites ou open source. Vous regardez et vous pensez que c'est un tableau ahurissant.
Jetons un coup d'œil à quelques verticales. Prenons le marketing, par exemple. Voici un tableau similaire, mais à partir des piles technologiques disponibles uniquement dans la technologie marketing. Voici le graphique de 2011. Voici la version 2016. Pensez-y, ce n'est que le nombre de marques de produits que vous pouvez utiliser pour la technologie en ce qui concerne la technologie de marketing. Pas la complexité des systèmes à l'intérieur, pas les différentes applications et web et le développement et le réseau et tous les autres. Juste la marque. Il y a avant, il y a cinq ans et voici aujourd'hui. Cela ne fera qu'empirer. Nous en sommes maintenant au point où la réalité est, les humains ne peuvent tout simplement pas garantir tous les accords de niveau de service. Nous ne pouvons pas plonger dans suffisamment de détails, assez rapidement et à l'échelle dont nous avons besoin. Voici un exemple de ce à quoi ressemble une console de surveillance maintenant. C'est comme près d'une vingtaine d'écrans collés en faisant semblant d'être un seul grand écran projeté surveillant chaque petit morceau. Maintenant, c'est intéressant ici, je ne mentionnerai pas la marque, mais cette plate-forme de surveillance surveille une seule application dans un environnement logistique et d'expédition. Une seule application. Si vous pensez à ce dont parlait Robin, où les organisations peuvent maintenant avoir 40 000 bases de données dans des environnements de production. Pouvez-vous simplement visualiser à quoi pourraient ressembler 40 000 versions de cette collection d'écrans de surveillance d'une application? C'est un monde très courageux dans lequel nous vivons. Comme Robin l'a dit et je le ferai absolument, à 100 pour cent, je répète que, sans les bons outils, sans le bon support et les personnes sur la table utilisant ces outils, les performances des applications sont un jeu perdu pour les humains et cela doit être fait par des outils et des logiciels.
Sur ce, je passerai la parole à nos amis de l'IDERA.
Eric Kavanagh: Très bien, Bill.
Bill Ellis: Merci. Partager mon écran ici. Je suppose que quelqu'un peut confirmer que vous pouvez voir mon écran?
Dr Robin Bloor: Oui.
Eric Kavanagh: Ça semble bien.
Bill Ellis: Merci. La seule chose à laquelle il a fait référence était que je ne pouvais vraiment pas attendre était la voiture autonome. La seule chose dont je n'avais entendu personne parler, c'est ce qui se passe quand il neige? Je me demande en quelque sorte si les ingénieurs en Californie ont réalisé que dans d'autres parties du pays, il neige un peu.
Dez Blanchfield: J'aime ça, je vais m'en souvenir.
Eric Kavanagh: Un mile typique à l'heure.
Bill Ellis: Nous sommes ici pour parler de la gestion des performances des applications dans un environnement complexe. Une chose dont j'aime parler, c'est que beaucoup de gens, quand ils parlent de performances, la nature de la réaction est, hé plus de serveurs, plus de CPU, plus de mémoire, etc. L'autre côté de cette médaille est l'efficacité du traitement. Vraiment, c'est les deux faces d'une même médaille et nous allons jeter un coup d'œil aux deux. L'objectif ultime est de respecter les accords de niveau de service pour les transactions commerciales. En fin de compte, toute cette technologie existe pour l'entreprise. Nous avons parlé de disposer d'une première base de données de gestion des performances de l'industrie. L'idéal est de s'intégrer dans le moule idéal de performance et de le gérer dès le début du cycle de vie des applications.
Les sujets se résument vraiment à quatre éléments; l'un est le processus de gestion des performances. Nous avons parlé à tout le monde et tout le monde a des outils. S'ils n'ont pas d'outils, ils ont des scripts ou des commandes, mais ce qui leur manque, c'est le contexte. Le contexte consiste simplement à connecter les points entre les piles d'applications. Ces applications pour - sont basées sur un navigateur. Ils sont très étroitement couplés d'un niveau à l'autre. L'interaction des niveaux est également vitale. Ensuite, nous parlons de la transaction commerciale. Nous allons fournir la visibilité non seulement aux techniciens, mais aussi aux propriétaires d'applications et aux responsables des opérations.
J'ai quelques études de cas pour partager avec vous comment les clients les ont utilisées. Ceci est une partie très pratique de la présentation ici. Voyons ce qui se passe généralement. J'aime schématiser - c'était comme un incroyable collage de technologies. Le nombre de technologies dans le centre de données vient de croître, de croître et de croître. Pendant ce temps, un utilisateur final s'en fiche et en est inconscient. Ils veulent simplement exercer la transaction, la rendre disponible, la terminer rapidement. Ce qui se passe généralement, c'est que les professionnels de l'informatique ne savent pas que les utilisateurs finaux ont même eu un problème, jusqu'à ce qu'ils se déclarent eux-mêmes. Cela donne le coup d'envoi d'un processus long, lent et souvent frustrant. Ce qui se passe, c'est que les gens ouvrent leurs outils et regardent un sous-ensemble de leur pile d'applications. Avec ce sous-ensemble, il devient très difficile de répondre à la question la plus simple. Est-il habituel que vous ayez le problème? De quelle transaction s'agit-il? Où se trouve le goulot d'étranglement dans la pile d'applications? En passant tout ce temps, à regarder niveau par niveau, incapable de répondre à ces questions, vous finissez par dépenser beaucoup de temps et d'énergie, beaucoup de personnel, de fonds et d'énergie pour le découvrir.
Afin de résoudre ce problème, afin de fournir un meilleur moyen, Precise prend en fait la transaction de suivi de l'utilisateur final, capture les métadonnées à ce sujet, suit la transaction via le réseau, dans le serveur Web, dans le niveau logique métier et nous prenons en charge .NET et ABAP et PeopleCode et E-Business Suite, dans des applications à plusieurs niveaux qui, finalement, toutes les transactions vont interagir avec le système d'enregistrement. Qu'il s'agisse d'une recherche d'inventaire, du temps de rapport travaillé, ils interagissent toujours avec la base de données. La base de données devient le fondement de la performance commerciale. La base de données, quant à elle, repose sur le stockage. À quoi répondent les métadonnées sur les transactions, qui, quelle transaction, où dans la pile d'applications, puis nous avons une visibilité approfondie au niveau du code pour vous montrer ce qui est en cours d'exécution. Ces informations sont capturées en continu, placées dans la base de données de gestion des performances - qui devient une seule feuille de musique pour que tout le monde puisse voir ce qui se passe. Il existe différentes personnes et organisations qui se soucient de ce qui se passe: les experts techniques, les propriétaires d'applications, en fin de compte l'entreprise elle-même. Lorsqu'un problème survient, vous souhaitez pouvoir extraire des informations sur cette transaction.
Avant d'examiner la transaction d'investissement, je veux vous montrer comment cela peut apparaître à différentes personnes de l'organisation. Au niveau de la gestion, vous souhaiterez peut-être avoir une vue d'ensemble de plusieurs applications. Vous voudrez peut-être en savoir plus sur l'intégrité calculée par la conformité et la disponibilité des SLA. Cette santé ne signifie pas que tout fonctionne parfaitement à 100%. Il y a de la place dans ce cas, vous pouvez voir que la transaction d'investissement est en état d'avertissement. Maintenant, un peu plus profondément, peut-être dans le secteur d'activité, vous voulez avoir des détails supplémentaires sur les transactions individuelles, quand elles enfreignent les SLA, le nombre de transactions, etc. L'équipe des opérations voudra en être informée par une alerte de certains Trier. Nous avons intégré des alertes de performances. Nous mesurons en fait les performances dans le navigateur de l'utilisateur final. Qu'il s'agisse d'Internet Explorer, de Chrome, de Firefox, etc., que nous pouvons détecter, cela répond à la première question: un utilisateur final a-t-il un problème?
Plongeons-nous et voyons ce que nous pouvons montrer d'autre à ce sujet. Les personnes intéressées par la performance ouvriraient Precise. Ils évalueraient les transactions. Ils examineraient la colonne SLA pour identifier les transactions qui n'étaient pas conformes au SLA. Ils pourraient voir les utilisateurs finaux qui ont été touchés ainsi que ce que cette transaction a fait au fur et à mesure qu'elle circulait dans l'application. La façon dont vous déchiffrez ces hiéroglyphes est, c'est le navigateur, l'URL, le U est pour l'URL, c'est le point d'entrée dans la JVM. Maintenant, cette machine virtuelle Java particulière appelle un serveur Web vers la deuxième machine virtuelle Java qui exécute ensuite l'instruction SQL. Il s'agit clairement d'un problème de base de données car cette instruction SQL était responsable de 72% du temps de réponse. Nous nous concentrons sur le temps. Le temps est la devise de la performance. C'est la façon dont les utilisateurs finaux ressentent si les choses tournent lentement ou non, et c'est une mesure de la consommation des ressources. C'est très pratique; c'est une sorte de métrique unique qui est la plus importante pour évaluer les performances. Lorsque ce problème est transmis au DBA, ce n'est pas seulement un problème de base de données, c'est cette instruction SQL. C'est le contexte dont je parlais.
Maintenant armé de ces informations, je peux entrer et analyser ce qui s'est passé. Je peux voir tout d'abord, l'axe des y est le temps à travers la journée. Excusez-moi, l'axe des y est le temps de réponse, l'axe des x est le temps de la journée. Je peux voir qu'il y a un problème de base de données, il y a deux occurrences, revenir à ce flux, récupérer cette instruction SQL et aller dans la vue experte, où Precise est capable de vous montrer ce qui se passe, ses contrôles, combien de temps ce code prend exécuter. Au niveau de la base de données, c'est le plan d'exécution. Vous remarquerez que Precise a sélectionné le plan d'exécution réel qui a été utilisé au moment de l'exécution, qui se distingue du plan estimé, qui serait lorsque le plan a été donné et non pendant le temps d'exécution. Cela peut ou non refléter le fait que la base de données l'a effectivement fait.
Maintenant, voici une analyse du temps de réponse pour l'instruction SQL. 90% du temps passé en stockage; dix pour cent a été utilisé dans le CPU. Je peux voir le texte de l'instruction SQL ainsi que le rapport des résultats. Le texte de l'instruction SQL commence en fait à révéler certains problèmes de codage. C'est une étoile choisie; qui renvoie toutes les lignes - excusez-moi, toutes les colonnes des lignes qui ont été retournées. Nous retournons des colonnes supplémentaires dont l'application peut ou non avoir besoin. Ces colonnes consomment de l'espace et des ressources à traiter. Si vous exécutez SAP, l'un des grands changements, car la base de données HANA est en colonnes, est que, fondamentalement, réécrit SAP pour ne pas choisir de sélectionner une étoile afin de réduire considérablement la consommation de ressources. C'est essentiellement quelque chose qui se produit souvent dans les applications locales, que ce soit Java, .NET, etc.
Cet écran, cela vous montre qui, quoi, quand, où et pourquoi. Le pourquoi, comme l'instruction SQL et le plan d'exécution qui vous permet de résoudre les problèmes. Étant donné que Precise s'exécute en continu, vous pouvez réellement mesurer avant et après, au niveau de l'instruction SQL, au niveau de la transaction, afin que vous puissiez mesurer par vous-même, ainsi que par le biais des propriétaires d'application et pour la gestion, que vous avez résolu le problème. . Cette documentation est vraiment utile. Il y a beaucoup de complexité dans cette pile d'applications. De nombreuses applications, en fait, tous ceux à qui nous avons parlé, exécutent au moins une partie de la pile d'applications sous VMware. Dans ce cas, ils regardent l'application de service client, ils regardent le temps de transaction et le corrélent avec le ralentissement est un événement de virtualisation. Precise suit tous les événements de virtualisation. Nous avons un plug-in pour vCenter pour le récupérer.
Nous pouvons également détecter les conflits. La contention est différente de l'utilisation. En fait, montrer quand peut-être un voisin bruyant a un impact sur votre machine virtuelle invitée, dans le contexte de l'application du serveur client. Maintenant, je peux explorer et obtenir des informations et je peux réellement voir les deux machines virtuelles qui se disputent, dans ce cas, pour les ressources CPU. Cela me permet d'avoir une visibilité afin que je puisse regarder la planification. Je peux mettre une machine virtuelle invitée sur un autre serveur physique. Tous ces types de choses auxquelles vous pourriez répondre et, en plus de cela, je peux en fait regarder l'efficacité du code pour peut-être qu'il utilise moins de CPU. Je pense que j'ai un assez bon exemple dans cette présentation de la façon dont quelqu'un a pu réduire la consommation du processeur par des ordres de grandeur.
C'était VMware. Entrons dans le code lui-même, le code de l'application. Precise pourra vous montrer ce qui se passe dans Java, .NET, le code ABAP, E-Business, PeopleCode, etc. Ce sont les points d'entrée dans, dans ce cas, dans WebLogic. Ici-bas, il y a un rapport de constatations qui me dit que ce sont ces EJB que vous devez regarder, et me dira que vous avez également obtenu un verrouillage sur ce système. Encore une fois, explorez le niveau logique métier pour montrer ce qui se passe. Dans ce cas, je regarde des cas particuliers; Je soutiens également le clustering. Si plusieurs JVM sont en cours d'exécution, vous pouvez soit regarder le cluster dans son ensemble, soit regarder les goulots d'étranglement au sein de la JVM individuelle.
Lorsque vous entrez dans le verrouillage, je peux entrer dans des exceptions. L'exception est un peu différente d'un problème de performances. En règle générale, les exceptions sont exécutées très rapidement. Parce qu'il y a une erreur logique et une fois que vous avez atteint cette erreur logique, elle se termine. Nous avons pu capturer une trace de pile au premier d'une exception, cela pourrait gagner beaucoup de temps car elle essaie de comprendre ce qui se passe, vous avez juste la trace de pile, juste là. Nous sommes également en mesure de capturer les fuites de mémoire. La solution comprend également le niveau de base de données, je peux entrer, je peux évaluer l'instance de base de données. Encore une fois, l'axe des y est l'endroit où le temps a été passé, l'axe des x est le temps sur la journée. Il y a un rapport de constatations qui me dit automatiquement ce qui se passe dans le système et ce que je pourrais regarder.
L'une des choses à propos du rapport des résultats de Precise, il ne se contente pas de regarder les journaux ou l'état d'attente - il examine tous les états d'exécution, y compris le processeur, ainsi que le retour d'informations du stockage. Le stockage est une partie très importante de la pile d'applications, en particulier avec l'avènement de l'état solide. Avoir des informations dans ce sens peut être très utile. Pour certaines unités de stockage, nous pouvons réellement explorer et montrer ce qui se passe au niveau de chaque appareil. Ce type d'information - encore une fois, c'est une visibilité profonde; sa portée est large - pour vous donner juste assez d'informations pour avoir plus d'effet de levier en tant que professionnel de la performance des applications, afin que vous puissiez optimiser vos applications de bout en bout pour répondre à ces transactions commerciales.
J'ai quelques études de cas que je voulais partager avec vous. Nous naviguons assez rapidement; J'espère que je vais à un rythme correct. En parlant de stockage, tout le monde change de matériel au fil du temps. Il y a une garantie sur le matériel. At-il vraiment livré ce que le vendeur vous a dit? Vous pouvez évaluer cela avec Precise. Vous entrez et ce qui s'est passé ici, ils ont essentiellement installé une nouvelle unité de stockage, mais lorsque les administrateurs de stockage ont regardé uniquement le niveau de l'unité de stockage, ils ont vu beaucoup de conflits et ils ont pensé qu'il pourrait y avoir un problème avec cette nouvelle unité de stockage. . En regardant plus d'un point de vue de bout en bout, précisément pour montrer où cela se produirait réellement. En fait, ils sont passés d'un débit d'environ 400 mégaoctets par seconde, où le stockage était responsable de 38% du temps de réponse, il est donc assez élevé. Avec la nouvelle unité de stockage, nous avons augmenté le débit à six, sept cents mégaoctets par seconde, donc pratiquement le double, et nous sommes en mesure de réduire de moitié la contribution du niveau de stockage au temps de transaction. Je suis en mesure de représenter graphiquement cela avant, c'est la période de transition, puis l'après.
Encore une fois, une documentation prouvant que l'investissement en matériel en valait la peine et ils ont été livrés comme ce fournisseur l'avait prévu. Il y a tout, à cause de la complexité, du nombre de choses, il y a toutes sortes de choses qui peuvent arriver. Dans ce cas, ils avaient en fait une situation où tout le monde blâmait le DBA, le DBA était comme "Eh bien, pas si vite." Ici, nous examinons en fait une application SAP, je pense que ce type de scénario est assez courant . Ce qui s'est passé, c'est qu'ils développaient une transaction personnalisée pour un utilisateur. L'utilisateur dit: «C'est tellement lent.» Le codeur ABAP - c'est le langage de programmation dans SAP - a dit: «C'est un problème de base de données.» Ils ont fini par ouvrir Precise; ils ont mesuré cet utilisateur final 60 secondes, donc bien plus d'une minute. Cinquante-trois secondes ont été passées à l'arrière. Ils ont percé dans le back-end et ils ont pu révéler l'instruction SQL présentée dans l'ordre décroissant.
Cette instruction SQL supérieure qui est responsable de 25 pour cent de la consommation de ressources, son temps d'exécution moyen est de deux millisecondes. Vous ne pouvez pas blâmer la base de données. Tu sais, hé, pas si vite, mec. La question est, pourquoi y a-t-il tant d'exécutions? Eh bien, ils l'ont renvoyé à l'ABAP, il est entré, a examiné l'imbrication de la boucle, a découvert qu'ils appelaient la base de données au mauvais endroit, ils ont essentiellement fait le changement, testé le changement et maintenant le nouveau temps de réponse est cinq secondes. Un peu lent, mais ils pourraient vivre avec ça. Bien mieux que 60 secondes. Parfois, à la recherche, est-ce le code d'application, la base de données, le stockage? Ce sont les domaines où Precise, en ayant le contexte des transactions de bout en bout, c'est là que Precise entre en jeu. Vous mettez essentiellement fin à ces choses.
Je regarde l'heure, on dirait qu'il nous reste encore un peu de temps pour en passer quelques autres. Je les diffuse. Cette application était en cours de développement depuis plus d'un an. Quand ils sont entrés dans l'assurance qualité, ils voyaient que les serveurs Web étaient au maximum à 100% et il semblait que l'application ne pouvait pas fonctionner sous VMware. La première chose que tout le monde a dit était: «Mettez cela sur le plan physique; il ne peut pas fonctionner sous VMware. »Precise leur a en fait proposé des moyens supplémentaires pour résoudre le problème. Nous avons examiné les transactions, nous avons vu un appel de serveur Web, il se présente sous la forme d'un ASMX dans IIS.NET. Il a en fait révélé le code sous-jacent. Vous voyez cela où je pointe? C'est 23 jours, 11 heures. Wow, comment est-ce possible? Eh bien, chaque invocation prend 9, 4 secondes et cette chose est invoquée 215 000 fois. Pour chaque appel, il utilise 6 secondes de CPU. C'est la raison, ce code est la raison pour laquelle cette chose ne pourrait jamais évoluer. En fait, il ne pouvait pas évoluer physiquement.
Ce qu'ils ont fait, est-ce qu'ils sont retournés vers leurs développeurs et ils ont dit: «Quelqu'un peut-il faire un changement?» Ils ont en quelque sorte organisé un concours, et ils ont testé les différentes suggestions et ils ont proposé une suggestion qui a pu fonctionner beaucoup plus efficacement. Le nouveau a complété un point, un peu moins de deux secondes, avec deux centièmes de seconde de CPU. Maintenant, cela pourrait évoluer et s'exécuter sur la batterie VMware. Nous avons pu essentiellement documenter cela au niveau du code ainsi qu'au niveau de la transaction. C'est un peu l'avant, puis l'après. Maintenant que vous pouvez voir ici dans le graphique à barres de la pile qui montre le Web, .NET et la base de données, vous interagissez maintenant avec la base de données. Il s'agit d'un profil que vous vous attendez à voir pour une application qui s'exécutait plus normalement.
Très bien, je choisis et je choisis en termes de choses supplémentaires que je peux vous montrer. Beaucoup de gens aiment ça parce que cela éblouit de nombreux magasins. Si vous ne parvenez pas à respecter un SLA d'entreprise et que tout le monde se dit «Aidez-nous». Cette boutique avait une situation où le SLA d'entreprise est dans les commandes reçues avant 15 h, il est expédié ce jour-là. Il est vraiment vital qu'ils passent les commandes et l'entrepôt est très occupé. Cet écran de commande client de JD Edwards était gelé et vous pouvez avoir une très bonne idée qu'il s'agit d'un système de gestion des stocks au détail juste à temps. Les étagères vides sont inacceptables dans le commerce de détail. Je dois avoir la marchandise là-bas pour la vendre. Ce que nous avons fait, c'est que nous avons plongé, dans ce cas, nous examinons la base de données du serveur SQL. L'aspect et la convivialité sont les mêmes, que ce soit SQL, Oracle, DB2 ou Sybase.
Nous avons identifié la sélection de PS_PROD et nous sommes en mesure de capturer la durée, le fait qu'ils s'exécutent tellement. Le bleu foncé correspondait à la clé qui disait qu'ils n'attendaient pas un état d'attente ou une journalisation ou même un stockage - cette chose est liée par le CPU. Nous avons suivi l'instruction SQL par 34301, donc à chaque exécution, nous incrémentons nos compteurs pour en garder la trace. Cela signifie que nous avons un historique détaillé et je peux y accéder en cliquant sur ce bouton de réglage. Voici l'onglet historique. Cet écran montre ici la durée moyenne en fonction des changements. Mercredi, jeudi, vendredi, la durée moyenne était d'environ deux dixièmes de seconde. Très peu de blocages d'écran, ils sont capables de respecter le SLA de l'entreprise. Le 27 février, quelque chose change et tout à coup, le temps d'exécution est là, et c'est en fait assez lent pour provoquer des délais d'attente, ce qui entraîne un gel de l'écran. Précis, en conservant un historique détaillé, y compris le plan d'exécution et les modifications générales apportées aux index de la table si ce SQL est utilisé. Nous avons pu constater que le plan d'accès a changé le 27 février. Du lundi au vendredi, mauvaise semaine. Le 5 mars, le plan d'accès a encore changé. C'est une bonne semaine. Cette étoile rose nous indique le volume mis à jour.
Vous pouvez voir ici que le nombre de lignes dans les tables sous-jacentes augmente et cela est typique d'une entreprise. Vous voulez que vos tables grandissent. Le fait est que les instructions sont analysées, les instructions SQL entrent, l'optimiseur doit décider quoi faire et choisir quand le plan d'exécution est rapide, choisir un autre plan d'exécution quand il est lent, provoquant le gel de l'écran. Sur une base technologique approfondie, j'ai besoin de savoir quel est le plan d'exécution et Precise le capture pour moi avec l'horodatage. C'est celui qui était rapide et efficace, c'est celui qui était lent et inefficace. Cette jointure de filtre utilise simplement beaucoup plus de CPU pour se réconcilier, pour faire cette instruction SQL particulière. Ils ont toujours le même effet ultime, mais celui-ci a essentiellement une recette plus lente et moins efficace pour fournir l'ensemble de résultats. Donc, nous progressons. Hé, nous avons le temps pour un couple de plus?
Eric Kavanagh: Ouais, allez-y.
Bill Ellis: D'accord, je vais sauter. Une chose que je veux que vous preniez note, nous avons parlé de matériel, parlé de SAP, nous avons parlé de .NET, nous avons parlé de JD Edwards et de l'environnement Java-SQL Server. C'est SAP, ici nous regardons PeopleSoft. La matrice de support de Precise est large et profonde. Si vous avez une application, plus que probable, nous pouvons l'instrumenter pour fournir ce niveau de visibilité. L'un des plus grands changements qui se produit actuellement est la mobilité. PeopleSoft a introduit la mobilité avec son interface utilisateur fluide. L'interface utilisateur fluide utilise un système très différemment. Cette application évolue. L'interface utilisateur fluide - ce qu'elle fait du point de vue de la gestion, c'est qu'elle permet aux utilisateurs finaux d'utiliser leur téléphone et augmente considérablement la productivité. Si vous avez des centaines ou des milliers ou même plus d'employés, si vous pouvez augmenter leur productivité de 1 à 2%, vous pouvez avoir un impact énorme sur la paie et tout le reste. Ce qui s'est passé, c'est que cette boutique a déployé l'interface utilisateur PeopleSoft Fluid. Maintenant, en parlant de complexité, voici la pile PeopleSoft. Une application, un minimum de six technologies, de nombreux utilisateurs finaux. Comment commencez-vous?
Precise va de nouveau pouvoir suivre ces transactions. Ce que nous vous montrons ici est un graphique à barres empilées montrant le client, le serveur Web, Java, la base de données Tuxedo, la pile d'applications PeopleSoft. Le vert est mappé sur J2EE, ce qui est une sorte de façon élégante de dire WebLogic. Ceci est la transition. Les utilisateurs finaux commencent à utiliser l'interface utilisateur fluide et le temps de réponse peut aller d'une heure et demie, deux secondes, à environ neuf, dix secondes. Ce que cet écran ne montre pas, c'est le nombre de personnes qui «n'ont pas répondu». Jetons un coup d'œil à la visibilité que Precise est en mesure de fournir à ce client.
Tout d'abord, quand je regarde les transactions PeopleSoft, ils peuvent voir essentiellement, nous avons vu ce genre de chose à tous les niveaux. Toutes les transactions ont été impactées, ainsi que tous les sites. Soit dit en passant, lorsque vous regardez cela, vous pouvez réellement voir des endroits à travers le monde. De l'Asie-Pacifique à l'Europe et à l'Amérique du Nord. Le problème de performances n'a pas été localisé dans une transaction particulière, ou un emplacement géographique particulier, il concerne tout le système. C'est une sorte de façon de dire que le changement ou la façon dont l'interface utilisateur fluide a eu un impact mondial. Du point de vue de l'évolutivité, vous pouvez voir que les gens essaient de faire le même type d'activité, mais le temps de réponse est simplement dégradé et dégradé. Vous pouvez voir que les choses ne sont pas à l'échelle. Les choses vont très, très mal. Ici, lorsque je regarde le nombre d'axes et les connexions simultanées, vous voyez quelque chose de très intéressant en termes de nombre d'accès et de connexions. Ici, nous évoluons jusqu'à environ 5000 et vous regardez environ, cela dépasse 100 connexions simultanées. Cela se fait après; c'est avant. Donc, ce que ma vraie demande sur le système, si cette chose pouvait évoluer, est de l'ordre de 300 000. Dans l'ancien temps, avec l'interface utilisateur classique, vous regardez 30 connexions simultanées.
Maintenant, ce que cela vous dit, c'est que l'interface utilisateur fluide utilise au moins 10 fois le nombre de connexions simultanées. Nous commençons à retirer ce qui se passe sous les couvertures avec PeopleSoft afin que vous puissiez commencer à voir l'impact sur les serveurs Web, le fait que les SLA commencent à violer. Ne va pas entrer dans tout, mais ce qui finit par arriver, c'est qu'ils reposent essentiellement sur la messagerie. Ils exercent essentiellement WebLogic et provoquent la mise en file d'attente dans Tuxedo. Il y avait en fait un problème de dépendance à plusieurs niveaux qui est apparu avec l'interface utilisateur fluide, mais Precise a pu montrer que par tout un tas de choses différentes, nous pouvons nous concentrer sur quel était le problème. Il s'avère qu'il y avait également un problème dans la base de données elle-même. Il y a en fait un fichier journal de messagerie, et à cause de tous les utilisateurs simultanés, ce fichier journal se bloquait. Il avait essentiellement des choses à régler, à chaque niveau de la pile d'applications. Parlez de complexité, voici en fait le niveau Tuxedo vous montrant la mise en file d'attente et vous pouvez également voir les performances se dégrader au sein de ce niveau. Je pouvais voir les processus; Je pouvais voir les domaines et les serveurs. Dans Tuxedo, pour que les gens l'utilisent, vous ouvrez généralement des files d'attente, des domaines et des serveurs supplémentaires, tout comme au supermarché pour soulager la congestion, afin de minimiser le temps de mise en file d'attente. Dernière et dernière option, Precise affiche beaucoup d'informations.
Comme je l'avais mentionné précédemment, chaque transaction importante interagit avec le système d'enregistrement. La visibilité dans la base de données est primordiale. Precise montre ce qui se passe dans la base de données, dans WebLogic, dans Java, .NET, dans le navigateur, mais la place que Precise excelle vraiment est dans le niveau de la base de données. Cela se trouve être la faiblesse de nos concurrents. Permettez-moi de vous montrer l'une des façons dont Precise pourrait vous aider à traverser cela. Je ne vais pas passer du temps sur le triangle de l'optimisation de la base de données, mais nous examinons essentiellement les modifications de type à faible coût, à faible risque, à large portée, à haut risque et à coût élevé. En fait, je vais tweeter cette diapositive après si les gens veulent essayer de la regarder. C'est un assez gros guide, je pense, pour les problèmes de réglage. Voici la vue expert Précise pour Oracle. En haut du rapport des résultats, 60% d'impact est cette instruction SQL particulière. Si vous ouvrez cet écran d'activité, il s'affiche là-haut. Je peux regarder cette instruction select, il y a un plan d'exécution. Chaque exécution prend une seconde - 48 000 exécutions. Cela représente 48 000 heures d'exécutions supplémentaires.
Le bleu foncé, encore une fois, est CPU. Cette chose est liée au processeur, pas un état d'attente, pas un journal. Je souligne que parce que certains de nos concurrents ne regardent que les états d'attente et les événements de journalisation, mais en règle générale, le processeur est l'état d'exécution le plus chargé et offre le plus de rachat. Entrer dans cette vision experte - et je vais très vite - ce que j'ai fait, c'est que j'ai regardé la table, 100 000 lignes, 37 000 blocs. Nous faisons un tableau complet, mais nous avons six index sur cette chose. Que se passe t-il ici? Eh bien, quand je regarde la clause where, ce que fait cette clause where, c'est en fait de convertir une colonne en majuscules et de dire où elle est égale à majuscule, find variable. Ce qui se passe, c'est que chaque fois que cette chose s'exécute, Oracle doit convertir cette colonne en majuscules. Plutôt que de le faire près de cinquante mille fois, il est beaucoup plus efficace de créer cet index en majuscules d'un index basé sur les fonctions et il est disponible non seulement dans la division Oracle Enterprise, également dans la division standard. Lorsque vous faites cela, ce que vous pouvez ensuite faire est de vérifier le plan d'exécution émettant ce nouvel utilisateur d'index perm en majuscule, c'était juste un peu mon truc.
Ensuite, à partir d'une mesure avant et après, vous regardez le temps d'exécution d'une seconde, agrège jusqu'à 9 heures 54 minutes, avec la même instruction SQL exacte, mais ayant cet index construit en majuscules pour 58 000 exécutions, la réponse le temps passe en sous-millisecondes, agrégé ensemble, il monte à sept secondes. J'ai essentiellement économisé dix heures de CPU sur mon serveur. C'est énorme. Parce que si je ne suis pas due pour une actualisation du serveur, je peux vivre sur ce serveur. En fait, je baisse l'utilisation de ce serveur de 20% et vous pouvez réellement voir l'avant et l'après. C'est le type de visibilité que Precise peut offrir. Il y a aussi d'autres choses que nous pourrions examiner, pourquoi avez-vous tous ces index s'ils ne sont pas utilisés? Ils peuvent suivre cela. Il y a de l'architecture, et je vais conclure, car nous atteignons le sommet de l'heure. Je suis un vrai croyant en cette solution et nous voulons que vous soyez un vrai croyant. Chez IDERA, nous pensons qu'un essai fait un client, donc si vous êtes intéressé, nous sommes en mesure de faire des évaluations sur votre site.
Sur ce, je vais restituer la balise.
Eric Kavanagh: Oui, c'est un détail énorme que vous avez montré là-bas. C'est vraiment assez fascinant. Je pense que je vous ai peut-être mentionné dans le passé que - et je sais que dans certaines des autres webémissions que nous avons faites avec IDERA, je l'ai mentionné - j'ai en fait suivi Precise depuis avant qu'il ne soit acquis par IDERA, depuis 2008, je pense, ou 2009. J'étais fasciné par ça à l'époque. Je suis curieux de savoir combien de travail reste à faire pour rester au fait des nouvelles versions d'applications. Vous avez mentionné que SAP HANA, qui, je pense, était assez impressionnant que vous pouvez réellement creuser dans l'architecture HANA et y faire quelques dépannages. Combien de personnes avez-vous? Dans quelle mesure est-ce un effort de votre part et dans quelle mesure cela peut-il être fait de manière quelque peu dynamique, ce qui signifie que lorsque l'outil est déployé, vous commencez à ramper et à voir différentes choses? Dans quelle mesure cela peut-il être dynamiquement, en quelque sorte, vérifié par l'outil, afin que vous puissiez aider les gens à dépanner des environnements complexes?
Bill Ellis: Vous y avez posé beaucoup de questions.
Eric Kavanagh: Je sais, désolé.
Bill Ellis: J'ai fourni beaucoup de détails parce que pour ces applications, en regardant le code, le diable est dans les détails. Vous devez avoir ce niveau de détail pour vraiment avoir quelque chose de concret. Sans mesures exploitables, vous ne connaissez que les symptômes. Vous ne résolvez pas réellement des problèmes. L'IDERA consiste à résoudre des problèmes. Rester au top des nouvelles versions et des trucs est un gros défi. La question de ce qu'il faut pour cela, c'est vraiment pour la gestion des produits. Je n'ai pas beaucoup de visibilité sur l'équipe qui nous tient essentiellement au courant des choses. En termes de HANA, c'est en fait un nouvel ajout à la gamme de produits IDERA; c'est très excitant. L'une des choses avec HANA est - permettez-moi de parler de la tâche pendant une seconde. Dans la tâche, les boutiques SAP feraient qu'elles répliqueraient la base de données à des fins de génération de rapports. Ensuite, il faudrait que les gens se réconcilient avec ce qui est réellement actuel. Vous auriez ces différentes bases de données et elles seraient désynchronisées à différents niveaux. Il y a juste beaucoup de temps et d'efforts, plus le matériel, les logiciels et les gens pour maintenir tout cela.
L'idée de HANA d'avoir une base de données en mémoire hautement parallèle, pour éviter essentiellement le besoin de bases de données en double. Nous avons une base de données, une source de vérité, elle est toujours à jour, de cette façon vous évitez d'avoir à faire tout ce rapprochement. L'importance des performances de la base de données HANA augmente - je vais dire 10 fois ou au moins plus de valeur que la somme de toutes ces autres bases de données, matériel, ressources peuvent acheter. Être capable de gérer HANA, maintenant que ce composant est actuellement en phase de test bêta, c'est quelque chose qui va bientôt devenir GA. C'est donc très excitant pour IDERA et pour nous de soutenir la plate-forme SAP. Je ne sais pas quelles autres parties de votre question j'ai un peu ratées, mais -
Eric Kavanagh: Non, ce sont de bonnes choses là-dedans. Je vous ai jeté tout un tas à la fois, désolé pour ça. Je suis juste fasciné, vraiment, je veux dire que ce n'est pas une application très simple, non? Vous creusez profondément dans ces outils et comprenez comment ils interagissent les uns avec les autres et à votre point, vous devez en quelque sorte reconstituer l'histoire dans votre tête. Vous devez combiner des informations pour comprendre ce qui se passe réellement et ce qui vous cause des ennuis, afin que vous puissiez y aller et résoudre ces problèmes.
Un participant demande, dans quelle mesure est-il difficile de mettre en œuvre Precise? Une autre personne a demandé qui sont les personnes - évidemment les administrateurs de base de données - mais qui ont d'autres rôles dans l'organisation qui utiliseraient ces outils?
Bill Ellis: Precise est un peu plus compliqué à déployer. Vous devez avoir une certaine connaissance de l'environnement d'application, en termes de, vous savez, cette application s'exécute sur cette base de données, elle a besoin ou - des serveurs Web de niveau intermédiaire, etc. Je pense que compte tenu de la complexité de certaines de ces applications, c'est en fait relativement facile. Si je peux instrumenter le serveur Web jusqu'à votre base de données, je peux le faire de bout en bout. Vous remarquez que je n'ai rien dit sur l'instrumentation d'un client utilisateur final et c'est parce que ce que nous faisons est que nous incluons en fait de manière dynamique, vous n'avez donc pas à changer votre code ou quoi que ce soit d'autre. Un JavaScript va dans le cadre de la page d'application. Peu importe où l'utilisateur se trouve dans le monde, lorsqu'il accède à l'URL à partir de votre application et affiche cette page, elle est instrumentée avec Precise. Cela nous permet de choisir l'ID utilisateur, son adresse IP, ainsi que le temps de rendu du premier octet de chacun des temps d'exécution du script des composants de page dans le navigateur de l'utilisateur final.
En termes de transactions, vous n'avez pas à cartographier les transactions car elles sont étroitement liées. Cette URL devient un point d'entrée pour JVM, puis a invoqué ce message, ce qui a provoqué un JVC intercepté dans la base de données. Nous sommes en mesure de capturer ces points de connexion naturels, puis de vous les présenter dans cet écran de transaction où je vous ai montré où nous avons également calculé le temps ou le pourcentage de temps passé à chaque étape individuelle. Tout cela se fait automatiquement. De manière générale, nous allouons 90 minutes pour faire - pour installer le noyau Precise et ensuite nous commençons à implémenter l'application. Selon la connaissance de l'application, il peut nous falloir quelques sessions supplémentaires pour obtenir l'instrumentation complète de l'application. De nombreuses personnes utilisent uniquement le composant de base de données de Precise. C'est très bien. Vous pouvez essentiellement casser cela, le diviser en composants dont vous avez besoin selon votre site. Nous pensons sans aucun doute que le contexte de l'instrumentation de la pile complète d'applications vous permet de voir que la dépendance de niveau à niveau augmente réellement la valeur de la surveillance d'un niveau individuel. Si quelqu'un veut explorer davantage l'instrumentation de sa pile d'applications, veuillez consulter notre site Web - je suppose que c'est la façon la plus simple de demander des informations supplémentaires, et nous en discuterons un peu plus loin.
Eric Kavanagh: Permettez-moi de vous poser une ou deux brèves questions. Je suppose que vous collectez et créez un référentiel au fil du temps, à la fois pour les clients individuels et en tant qu'entité d'entreprise dans son ensemble, des interactions entre diverses applications et diverses bases de données. En d'autres termes, je suppose que c'est la modélisation de scénarios. Est-ce le cas? Conservez-vous réellement une sorte de référentiel de scénarios courants afin que vous puissiez faire des suggestions aux utilisateurs finaux lorsque certaines choses entrent en jeu? Comme cette version d'E-Business Suite, cette version de cette base de données, etc. - faites-vous beaucoup de cela?
Bill Ellis: Eh bien, ce type d'information est intégré dans le rapport des résultats. Le rapport des résultats indique quels sont les goulots d'étranglement des performances, et il est basé sur le temps d'exécution. Une partie de ce rapport sur les résultats consiste à en savoir plus et que faire ensuite. Les informations ou l'expérience des clients et ainsi de suite sont fondamentalement incorporées dans cette bibliothèque de recommandations.
Eric Kavanagh: D'accord, ça sonne bien. Eh bien les gens, présentation fantastique aujourd'hui. Bill, j'ai adoré la quantité de détails que tu avais là-dedans. Je pensais que c'était une information vraiment fantastique, granuleuse et granulaire, montrant comment tout cela se faisait. À un certain point, c'est presque comme de la magie noire, mais vraiment, ce n'est pas le cas. C'est une technologie très spécifique que vous avez conçue pour comprendre des environnements très, très complexes et rendre les gens heureux parce que personne n'aime quand les applications s'exécutent lentement.
Eh bien les amis, nous allons archiver cette webémission. Vous pouvez sauter en ligne sur Techopedia ou insideanalysis.com et wow, merci pour votre temps, nous vous rattraperons la prochaine fois. Faites attention, au revoir.
