Персоналом Техопедии, 2 ноября 2016 г.
Вывод: ведущий Эрик Кавана обсуждает производительность приложений и способы повышения эффективности с доктором Робином Блором, Дезом Бланчфилдом и Биллом Эллисом из IDERA.
Вы не вошли в систему. Пожалуйста, войдите или зарегистрируйтесь, чтобы увидеть видео.
Эрик Кавана: Дамы и господа, здравствуйте и еще раз добро пожаловать в Hot Technologies. Да, в самом деле! Меня зовут Эрик Кавана, я буду вашим организатором очередной веб-трансляции сегодня в этой действительно веселой, захватывающей серии, которую мы получили в качестве комплимента для нашей серии брифингов. Заголовок «Ускорение приложений: более высокая производительность для конечных пользователей». Ну, ребята, кто этого не хочет? Если я парень, который помогает вашему приложению работать быстрее, я думаю, что я парень, который покупает мне пиво в баре после работы. Это должно быть довольно крутая вещь, чтобы войти и ускорить чье-либо приложение.
На самом деле есть слайд о вас, напишите мне в Твиттере @Eric_Kavanagh. Я всегда стараюсь следовать назад, и я всегда пишу в Твиттере, если вы упоминаете меня, поэтому не стесняйтесь упоминать меня.
Вся цель этого шоу - сосредоточиться на различных аспектах корпоративных технологий и действительно помочь определить определенные дисциплины или определенные лица, если хотите. Часто поставщики выбирают определенные маркетинговые условия и рассказывают о том, как они делают ту или иную или какую-то другую вещь. Это шоу было действительно разработано, чтобы помочь нашей аудитории понять, что нужно иметь программному инструменту, чтобы быть лидером в своем пространстве. Формат этого двух аналитиков. Каждый идет первым, в отличие от комнаты для брифингов, где продавец идет первым. Каждый из них дает свое представление о том, что, по его мнению, важно знать о конкретной технологии.
Сегодня мы говорим об ускорении приложений. Мы собираемся услышать от Деза Бланчфилда, а также доктора Робина Блура - мы сегодня во всем мире - и затем Билл Эллис звонит из района Вирджинии. После этого я передам это нашему первому докладчику, доктору Блору. Кстати, мы написали в твиттере хештег #pcast, так что не стесняйтесь твитнуть. Унеси это.
Доктор Робин Блур: Хорошо, спасибо за это вступление. Производительность приложений и уровни обслуживания - это своего рода область, я проделал большую работу в этой области на протяжении многих лет, в том смысле, что на самом деле я проделал огромную работу по мониторингу производительности и работе в одной так или иначе, как попытаться рассчитать эти уровни. Надо сказать, что до … у нас была эта эра, некоторое время назад, когда люди строили системы в бункерах. В основном, объем работы, которую они фактически должны сделать, чтобы система работала достаточно хорошо, если бы она находилась в бункере, на самом деле не был слишком сложным, потому что есть очень небольшое, очень небольшое количество переменных, которые вы должны были принять во внимание. Как только мы правильно подключились к сети, в уравнение вступили интерактивная и сервисная ориентация. Это немного сложно. Производительность может быть одномерной. Если вы просто думаете о приложении, выполняющем определенный путь кода несколько раз, то при разумном и своевременном выполнении это выглядит как одномерная вещь. Как только вы начинаете говорить об уровнях обслуживания, вы на самом деле говорите о множестве вещей, конкурирующих за ресурсы компьютера. Это становится многомерным очень быстро. Если вы начнете говорить о бизнес-процессах, бизнес-процессы могут быть объединены в несколько приложений. Если вы говорите об сервисно-ориентированной архитектуре, то конкретное приложение может на самом деле получать доступ к возможностям нескольких приложений. Тогда это становится очень сложной вещью.
Я посмотрел - давно я нарисовал эту диаграмму. Этой диаграмме не менее 20 лет. По сути, я называю это Diagram of Everything, потому что это способ взглянуть на все, что существует в ИТ-среде. Это всего лишь четыре части: пользователи, данные, программное обеспечение и оборудование. Конечно, они меняются со временем, но вы на самом деле понимаете, что когда вы смотрите на это, происходит иерархический взрыв каждой из этих частей. Аппаратное обеспечение да, аппаратное обеспечение может быть сервером, но сервер может состоять из нескольких процессоров, сетевых технологий и памяти, и это, как оказалось, довольно много контроллеров. Если вы действительно посмотрите на это, все будет разбито на куски. Если вы на самом деле думаете о том, чтобы попытаться организовать все это в отношении данных, которые изменяются, производительность программного обеспечения меняется, потому что меняется оборудование, и так далее, и так далее, вы на самом деле смотрите на невероятно сложную многофакторную ситуацию. Это кривая сложности. Конечно, это кривая сложности практически для всего, но я видел, как он обращается снова и снова, говоря о компьютерах. По сути, если вы разместите узлы на одной оси, а важные соединения - на другой, вы получите кривую сложности. Почти не имеет значения, что такое узлы и соединения, и это будет делать, если вы хотите представить рост громкости в телефонной сети.
На самом деле, когда речь идет об узлах в компьютерной среде, вы говорите об отдельных вещах, которые заботятся друг о друге. Сложность, оказывается, зависит от структуры разнообразия и различных ограничений, которым вы пытаетесь подчиниться. Также цифры. Когда цифры растут, они сходят с ума. У меня вчера был интересный чат, я разговаривал с кем-то - я не могу упомянуть, кем он был, но это не имеет значения - они говорили о сайте, на котором было 40000 - это четыре нуля, 40000 - экземпляров баз данных на сайте. Подумайте об этом - 40000 различных баз данных. Конечно, единственное, что у нас было - у них, очевидно, было много, много тысяч заявок. Мы говорим об очень большой организации, но я не могу назвать ее. Вы на самом деле смотрите на это, и вы на самом деле пытаетесь, так или иначе, получить уровни обслуживания, которые будут достаточными для всех пользователей, с несколькими различными, если хотите, ожиданиями. Это сложная ситуация, и все, что я на самом деле говорю, это сложный материал. Числа всегда увеличиваются. Ограничения определяются бизнес-процессами и бизнес-целями. Вы заметили изменение ожиданий.
Я помню, как только Gmail, Yahoo mail и Hotmail, все эти почтовые системы появились, люди начали ожидать, что их внутренние почтовые системы внутри организации заслужат уровень обслуживания этих огромных операций с обширными фермами серверов за пределами. организации и начали оказывать давление, чтобы все это произошло. На самом деле, соглашения об уровне обслуживания - это одно, а ожидание - это другое, и они сражаются друг с другом в организации, что неловко. Вот только бизнес-перспектива. В некоторых системах оптимальное время отклика составляет одну десятую секунды времени отклика человека. Одна десятая секунды - это время, которое требуется кобре, чтобы укусить вас. Если вы стоите перед коброй, и она решает укусить вас, это слишком поздно, это происходит потому, что вы не можете ответить в одну десятую секунды. Одна десятая секунды - это время, которое требуется мячу, чтобы покинуть руку кувшина, чтобы добраться до парня с битой. По сути, когда он видит брошенный мяч, он должен ответить именно в этот момент. Человеческий ответ, довольно интересная вещь. Программное обеспечение к программному обеспечению, очевидно, может иметь более высокие ожидания.
Затем вы попадаете в некоторые ситуации, которые, на мой взгляд, являются теми рыночными ситуациями, когда быть первым - это то, где ценность для бизнеса. Это похоже на то, что если вы хотите продать определенную акцию на фондовом рынке, вероятно, меньше, например, потому что вы думаете, что она идет вниз, а многие другие думают, что она идет вниз, вы получите лучшую цену, если сначала доберетесь до рынка. Там много ситуаций, показ рекламы и тому подобное, очень похожая ситуация. У вас есть это движение с точки зрения ожидания уровня обслуживания. У вас есть одна вещь, это своего рода стеклянный потолок для человеческого ответа. Если это программное обеспечение, если вы достигли такой предельной ситуации, лучшего уровня обслуживания не существует. Быстрее всех остальных лучше.
Ладно, я думаю, это последний слайд, который я делал, но это просто для того, чтобы дать вам общее представление о сложности, как только вы действительно посмотрите на требования организации, сервис. Вы поднялись на левую сторону, у вас есть система управления, которая представляет собой набор программного обеспечения, который служит для управления сервисом, который пытается управлять уровнем сервиса. Кроме того, у вас есть управление эффективностью бизнеса. Затем, если вы посмотрите вниз, область автоматизации управления сервисами, у вас есть фрагментированные сервисы, которые превращаются в стандартизированные сервисы, если вы действительно хотите инвестировать в такие вещи, которые превращаются в интегрированные сервисы, которые превращаются в оптимизированные сервисы., В основном то, что сделали люди, это только в левом нижнем углу. Может быть, немного управления услугами. Управление эффективностью бизнеса, очень редко. Фрагментировано, почти все это. Идеальный мир заполнил бы эту сетку. Инструментарий - я упомянул проблему субоптимизации. Вы можете оптимизировать части системы, и это плохо для всей системы. Если вы сделаете сердце оптимальным, то ваша кровь может циркулировать слишком быстро для остальных органов. Это проблема крупных организаций и уровней обслуживания. Очевидно, что ничего не будет достигнуто без сложных инструментов, потому что переменные только что получили - ну, слишком много переменных, чтобы попытаться их оптимизировать.
Сказав это, я передам Дезу, который, надеюсь, расскажет о чем-то другом.
Дез Бланчфилд: Спасибо, Робин. Как и доктор Робин Блур, я провел слишком много лет, размышляя о производительности очень сложных систем в очень больших масштабах. Вероятно, не совсем в том же масштабе, что и Робин, но производительность - это ежедневная тема, и наша часть ДНК - стремление к производительности, чтобы извлечь максимальную выгоду из всего. На самом деле, я использовал изображение одной из моих любимых вещей в мире, гонок автомобилей Формулы I, когда вся планета некоторое время сидит неподвижно и очень быстро наблюдает, как машины кружатся. В каждом отдельном аспекте нет формулы Формулы I, которая не касается конкретно производительности. Многие люди обнюхивают спорт, потому что думают, что это пустая трата денег. Оказывается, машина, на которой мы ездим каждый день, чтобы по выходным бросать детей в футбол, а в другие дни в школу, основана на результатах и исследованиях, основанных на результатах. Это своего рода жизнь гонок Формулы I. Повседневная технология, повседневная наука часто исходит из того, что сфокусировано исключительно на высокой производительности.
Реальность, однако, заключается в том, что наш новый мир «всегда включен», который требует 100-процентной бесперебойной работы - как уже упоминал Робин - с такими вещами, как внедрение веб-почты и других услуг, которые мы считаем само собой разумеющимся в непрерывном пространстве, и теперь мы ожидаем, что в наше предприятие и рабочая среда. Реальность такова, что не всегда означает, что вы выполняете соглашение об уровне обслуживания. Я имею в виду необходимость управления производительностью приложений, а соглашения об уровне доступности услуг претерпели фундаментальные изменения за последнее десятилетие. Мы больше не пытаемся беспокоиться о производительности одной системы. Когда мир был немного проще, у нас могла возникнуть ситуация, когда один сервер, на котором запущено несколько служб, можно отслеживать в режиме реального времени, и его поддержка была относительно простой. Мы могли бы - и вот мое маленькое, то, о чем мы беспокоились, например, когда я был системным администратором много лет назад, - мы бы посмотрели вокруг, обычно ли служба работает и отвечает? Могу ли я войти в терминал, например? Операционная система отвечает и могу ли я вводить команды? Приложения запущены и работают? Могу ли я видеть процессы и память при выполнении операций, ввод-вывод по сети и т. Д.? В дни мэйнфреймов можно было услышать, как из кассет идут ленты, и из них выпадает бумага.
Отвечают ли приложения, и можем ли мы войти в систему и что-то с ними сделать? Могут ли пользователи подключаться к некоторым из этих серверов? Это продолжается. Вы знаете, они довольно фундаментальные. Тогда несколько забавных - справочная служба зеленая? Потому что, если нет, то все работает хорошо, а кто получит пончики? Жизнь была действительно простой в те дни. Даже в те дни, а потом я говорю 20–30 лет назад, сложность все еще была очень высокой. Мы могли бы относительно простым способом управлять соглашениями об уровне обслуживания и следить за производительностью. Мы уже не можем делать это вручную, как намекал Робин. Задача слишком велика. Дело в том, что несколько хороших приложений, администраторов, системной сети и баз данных, администраторы могут отслеживать и выполнять соглашения об уровне обслуживания. Соглашения об уровне обслуживания теперь так далеко, что я боролся вчера вечером, когда собирал свои последние заметки, чтобы вспомнить год, когда мне в последний раз удалось взглянуть на систему очень сложного стека, понять ее и даже понять, что было происходит под капотом, и я пришел из глубоко технического образования. Я не могу себе представить, каково это сталкиваться с этим изо дня в день в административном порядке.
Что произошло? Ну, в 1996 году приложения на основе баз данных были преобразованы с интернет-бумом. Многие из нас прошли через это. Даже если вы не были на пороге интернет-бума, вы легко можете просто осмотреться и понять, что в повседневной жизни мы подключаем все к Интернету сейчас. Я считаю, что у нас есть тостер, который, очевидно, поставляется с возможностью подключиться к Wi-Fi, что смешно, потому что мне не нужен мой тостер, подключенный к Интернету. В 2000-х, особенно в начале 2000-х, нам приходилось сталкиваться с этим огромным ростом сложности, заключающимся в обеспечении производительности услуг в условиях доткомовского бума. Затем появилась еще одна нелепая неловкая искорка в Web 2.0, когда появились смартфоны, и теперь приложения были в наших руках 24/7 и были всегда включены.
Сейчас 2016 год, мы столкнулись с еще одним трясиной в виде облаков, больших данных и мобильности. Это системы, которые настолько велики, что их часто сложно понять и выразить простым языком. Когда мы думаем о том, что некоторые из больших единорогов, о которых мы говорим, имеют десятки сотен петабайт данных. Это целый этаж дискового пространства и хранилища только для хранения вашей электронной почты, изображений и социальных сетей. Или, в некоторых случаях, в транспортной и транспортной логистике, все это в банковском деле, это где ваши деньги, или где ваша почта, или ваша, где то, что вы купили на eBay. Следующая большая волна, с которой мы столкнемся, - это очень сложная проблема интернета вещей.
Если это не было достаточно плохо, мы собираемся встроить искусственный интеллект и когнитивные вычисления практически во все. В эти дни мы общаемся с движками Siri и Google. Я знаю, что у Amazon есть свой собственный. У Baidu есть одно из этих устройств, с которым вы можете разговаривать, они преобразуют его в текст, который поступает в обычную систему, база данных выполняет запрос, возвращается и полностью изменяет процесс. Подумайте о сложности, которая входит в это. Реальность такова, что сложность сегодняшнего стандартного стека приложений намного превышает возможности человека. Когда вы думаете обо всем, что происходит, когда вы нажимаете кнопку на своем смартфоне или планшете, вы разговариваете с ней, преобразуете это в текст, запускаете всю дорогу в Интернет до серверной системы, интерфейс получает который преобразует его в запрос, выполняет запрос через стек приложений, проходит через базу данных, нажимает на диск, возвращается, и в середине находится сеть оператора связи, имеется центр состояния локальной сети. Сложность безумная.
Мы фактически утверждаем это как гипермасштаб. Сложность и скорость гипермасштаба просто сенсация. Приложения и базы данных стали настолько большими и настолько сложными, что управление производительностью фактически является наукой само по себе. Многие называют это ракетостроением. У нас есть локальная технология, у нас есть внешняя технология, у нас есть ряд вариантов центров обработки данных; физический и виртуальный. У нас есть физические и виртуальные серверы, у нас есть облако, у нас есть инфраструктура как услуга и платформа как услуга, а программное обеспечение как услуга - вещь, которую мы принимаем как должное. Последнее, программное обеспечение как услуга, несколько лет назад стало пугающим, когда финансовые директора и подразделения организации поняли, что могут взять свою кредитную карту и просто сами что-то купить и обойти ИТ-директора, и мы фактически назвали эту «тень» ИТ »и ИТ-директора теперь пытаются свернуть это и восстановить контроль.
В инфраструктуре у нас есть программно-определяемые сети, виртуализация сетевых функций, ниже, чем у нас, вероятно, больше, теперь у нас есть микросервисы и приложения активных сервисов. Когда вы нажимаете на URL-адрес, в конце этого URL-адреса появляется набор бизнес-логики, которая описывает, что именно нужно для ее доставки. Это не обязательно имеет заранее построенную логику, ожидающую этого. У нас есть традиционные базы данных с одной стороны, которые масштабируются очень, очень большие. У нас есть такие инфраструктуры и экосистемы Hadoop в другом спектре, которые настолько велики, что, как я уже сказал, вы знаете, люди сейчас говорят о сотнях петабайт данных. У нас есть мобильность сложности, когда речь идет об устройствах, которые носят с собой, ноутбуки, телефоны и планшеты.
У нас есть BYOD в некоторых закрытых средах, и все больше сейчас, так как опытные люди Gen Y приносят свои собственные устройства. Мы просто позволяем им поговорить с ними о веб-интерфейсах. Либо через Интернет, либо через Wi-Fi, у нас есть бесплатный Wi-Fi в кафе внизу, так как они пьют кофе. Или наш внутренний Wi-Fi. Машина-машина сейчас присутствует всегда. Это не является частью Интернета вещей, но это также связано. Интернет вещей - совершенно новая игра сложности, которая ошеломляет. Искусственный интеллект, и если вы думаете, что то, с чем мы сейчас играем, со всеми Siri и другими связанными устройствами, с которыми мы разговариваем, является сложным, подождите, пока вы не окажетесь в ситуации, когда вы увидите нечто, называемое Olli, которое является трехмерным напечатанный автобус, который везет около шести человек и может ехать по городу, и вы можете говорить на нем простым английским языком, и он ответит вам. Если он попадает в движение, он решает повернуть налево или направо от главной зоны, где есть движение. Когда он поворачивает, и вы беспокоитесь о том, почему он повернул налево или направо от главной дороги, он скажет вам: «Не волнуйтесь, я собираюсь повернуть налево. Впереди движение, и я собираюсь обойти его ».
Управление производительностью всех систем и всей сложностью, отслеживание того, куда эти данные поступают, попадают ли они в базу данных, все межсоединения и все соответствующие биты, просто ошеломляет. Реальность такова, что для управления производительностью и соглашениями об уровне обслуживания на современных скоростях и масштабах требуются инструменты и системы, и по умолчанию это уже не то, что вы думаете, что было бы неплохо иметь инструмент - это обязательное условие; это просто абсолютно необходимо. Вот лишь небольшой пример, список высокоуровневых диаграмм разработки приложений для OpenStack, программного обеспечения с открытым исходным кодом облака. Это просто большой кусок. Это не просто серверы, а база данных. Это где каждый маленький синий шарик представляет группы вещей. В некоторых случаях работают файлы и серверы или сотни баз данных или, конечно, не более десятков тысяч маленьких кусочков логики приложений. Это маленькая версия. Это действительно ошеломляет, когда вы начинаете думать о сложности, которая возникает в этом. Сегодня даже в большом пространстве данных я просто выложу скриншоты только для брендов. Когда вы думаете обо всех элементах, которыми мы должны здесь управлять, мы не просто говорим об одном бренде обязательно, это все бренды в области больших данных и топ-бренд, а не просто каждый маленький или открытый. Ты выглядишь и думаешь, что это ошеломляющая диаграмма.
Давайте просто посмотрим на пару вертикалей. Давайте возьмем маркетинг, например. Вот аналогичная диаграмма, но из стеков технологий, которые доступны только в маркетинговой технологии. Это график 2011 года. Вот версия 2016 года. Подумайте только, это просто количество брендов продуктов, которые вы можете использовать для технологий в отношении маркетинга технологий. Не сложность систем внутри, не различное приложение и веб и разработка и сеть и все остальное. Просто бренд. Это было пять лет назад и сегодня. Будет только хуже. Сейчас мы находимся в том месте, где реальность такова, что люди просто не могут обеспечить все соглашения об уровне обслуживания. Мы не можем погрузиться в достаточно подробно, достаточно быстро и в нужном нам масштабе. Вот пример того, как выглядит консоль мониторинга сейчас. Это похоже на почти двадцать с лишним экранов, склеенных вместе, притворяясь, что они представляют собой один большой проецируемый экран, отслеживающий каждую маленькую деталь. Здесь интересно, я не буду упоминать бренд, но эта платформа мониторинга отслеживает отдельное приложение в среде логистики и доставки. Всего одно приложение. Если подумать, о чем говорил Робин, где организации могут иметь 40000 баз данных в рабочих средах. Можете ли вы просто представить, какими могут быть 40000 версий этой коллекции экранов, контролирующих одно приложение? Это очень смелый мир, в котором мы живем. Как сказал Робин, и я буду абсолютно, на 100 процентов повторять, что без правильных инструментов, без правильной поддержки и людей на столе, использующих эти инструменты, производительность приложений является проигранной игрой для людей и это должно быть сделано с помощью инструментов и программного обеспечения.
С этим я перейду к нашим друзьям в IDERA.
Эрик Кавана: Хорошо, Билл.
Билл Эллис: Спасибо. Разделяю мой экран здесь. Я думаю, кто-нибудь может подтвердить, что вы видите мой экран?
Доктор Робин Блур: Да.
Эрик Кавана: Все выглядит хорошо.
Билл Эллис: Спасибо. Единственное, на что он ссылался, было то, что я действительно не могу ждать, это машина с автоматическим управлением. Одна вещь, о которой я не слышал, чтобы кто-то говорил, что происходит, когда идет снег? Интересно, поняли ли инженеры в Калифорнии, что в других частях страны снег идет совсем немного?
Дез Бланчфилд: Мне это нравится, я запомню это.
Эрик Кавана: типичная миля в час.
Билл Эллис: Мы здесь, чтобы поговорить об управлении производительностью приложений в сложной среде. Одна вещь, о которой мне нравится говорить, это то, что многие люди, когда говорят о производительности, имеют характер реакции: больше серверов, больше ресурсов процессора, больше памяти и т. Д. Другая сторона этой медали - эффективность обработки. На самом деле это две стороны одной медали, и мы собираемся взглянуть на них обоих. Конечной целью является выполнение соглашений об уровне обслуживания для бизнес-транзакций. В конечном итоге вся эта технология существует для бизнеса. Мы говорили о первой в отрасли базе данных по управлению эффективностью. Идеал этого заключается в том, чтобы вписаться в идеальную форму производительности и управлять ею с самого начала жизненного цикла приложений.
Темы действительно сводятся к четырем частям; Одним из них является процесс управления производительностью. Мы говорили со всеми, и у всех есть инструменты. Если у них нет инструментов, у них есть сценарии или команды, но они упускают контекст. Контекст просто соединяет точки через стеки приложений. Эти приложения для - на основе браузера. Они очень тесно связаны между собой. Как взаимодействуют уровни, также жизненно важно. Затем мы говорим о бизнес-транзакции. Мы собираемся предоставить информацию не только техническим специалистам, но и владельцам приложений и руководителям операций.
У меня есть пара примеров, чтобы просто поделиться с вами тем, как клиенты используют их. Это очень практичная часть презентации здесь. Давайте посмотрим на то, что обычно происходит. Мне нравится строить диаграммы - это было похоже на невероятный коллаж технологий. Количество технологий в дата-центре только выросло, выросло и выросло. Между тем, конечный пользователь не заботится об этом и не замечает этого. Они просто хотят осуществить транзакцию, сделать ее доступной, быстро завершить ее. Как правило, профессионалы в области ИТ не знают, что у конечных пользователей возникли проблемы, пока они не сообщат о себе. Это начинает отнимать много времени, медленный процесс и часто разочаровывает. Происходит следующее: люди открывают свои инструменты и смотрят на часть своего стека приложений. С этим подмножеством становится очень трудно ответить на самый простой вопрос. Это нормально для вас, чтобы иметь проблему? Что это за транзакция? Где в стеке приложений находится узкое место? Потратив все это время, просматривая уровень за уровнем, не имея возможности ответить на эти вопросы, вы в конечном итоге тратите много времени и энергии, много персонала, средств и энергии на выяснение.
Чтобы решить эту проблему, чтобы предоставить более точный способ, компания Precise фактически берет транзакцию отслеживания конечного пользователя, собирает метаданные о ней, следует за транзакцией через сеть, на веб-сервер, на уровень бизнес-логики и мы поддерживаем .NET и ABAP и PeopleCode и E-Business Suite в многоуровневых приложениях, которые в конечном итоге все транзакции будут взаимодействовать с системой записи. Будь то инвентаризация, отработанное время отчетности, они всегда взаимодействуют с базой данных. База данных становится основой эффективности бизнеса. База данных, в свою очередь, опирается на хранилище. На что отвечают метаданные о транзакциях, кто, какая транзакция, где находится в стеке приложений, а затем мы имеем глубокую видимость на уровне кода, чтобы показать вам, что выполняется. Эта информация непрерывно собирается, помещается в базу данных управления эффективностью - это становится единым музыкальным листом для всех, чтобы увидеть, что происходит. Есть разные люди и организации, которые заботятся о том, что происходит: технические эксперты, владельцы приложений, в конечном счете, сам бизнес. Когда возникает проблема, вы хотите иметь возможность извлечь информацию об этой транзакции.
Прежде чем мы рассмотрим инвестиционную транзакцию, я хочу показать вам, как это может выглядеть для разных людей в организации. На уровне управления может потребоваться обзор нескольких приложений. Возможно, вы захотите узнать о состоянии здоровья, которое рассчитывается на основании соответствия SLA и доступности. Это здоровье не означает, что все на 100 процентов работает идеально. В этом случае есть место, где вы можете видеть, что инвестиционная транзакция находится в статусе предупреждения. Теперь, немного глубже, возможно, в сфере бизнеса, вы хотите получить некоторую дополнительную информацию об отдельных транзакциях, когда они нарушают SLA, количество транзакций и т. Д. Операционная группа захочет получить уведомление об этом через предупреждение некоторых Сортировать. У нас есть встроенные оповещения о производительности. Мы фактически измеряем производительность в браузере конечного пользователя. Будь то Internet Explorer, Chrome, Firefox и т. Д., Которые мы можем обнаружить, это отвечает на первый вопрос: возникла ли проблема у конечного пользователя?
Давайте окунемся и посмотрим, что еще мы можем показать по этому поводу. Люди, которые заинтересованы в производительности, откроют Precise. Они будут оценивать транзакции. Они будут смотреть на столбец SLA, чтобы определить транзакции, которые не соответствуют SLA. Они смогут увидеть конечных пользователей, которые были затронуты, а также то, что эта транзакция сделала, когда она проходила через приложение. То, как вы расшифруете эти иероглифы, - это браузер, URL, U для URL, это точка входа в JVM. Теперь эта конкретная JVM вызывает веб-сервер для вызова второй JVM, которая затем выполняет оператор SQL. Это явно проблема с базой данных, потому что этот оператор SQL отвечал за 72 процента времени ответа. Мы сосредоточены на времени. Время - это валюта производительности. Это то, как конечные пользователи испытывают, работают ли они медленно или нет, и это мера потребления ресурсов. Это очень удобно; это своего рода единая метрика, которая наиболее важна для оценки производительности. Когда эта проблема передается администратору базы данных, это не просто проблема с базой данных, это оператор SQL. Это контекст, о котором я говорил.
Теперь, вооружившись этой информацией, я могу войти и проанализировать, что произошло. Прежде всего, я вижу, что ось Y - это время в течение дня. Извините, ось Y - время отклика, ось X - время дня. Я вижу, что есть проблема с базой данных, есть два вхождения, вернемся к этому потоку, возьмем этот оператор SQL и перейдем в экспертное представление, где Precise может показать вам, что происходит, его элементы управления, сколько времени занимает этот код для выполнить. На уровне базы данных это план выполнения. Вы заметите, что Precise выбрал реальный план выполнения, который использовался во время выполнения, который отличается от предполагаемого плана, который будет, когда план был дан, а не во время выполнения. Это может или не может отражать, что база данных на самом деле.
Теперь здесь, анализ времени ответа для оператора SQL. Девяносто процентов времени, проведенного на хранении; десять процентов было использовано в процессоре. Я вижу текст оператора SQL, а также отчет о результатах. Текст оператора SQL фактически начинает обнаруживать некоторые проблемы кодирования. Это избранная звезда; который возвращает все строки - извините, все столбцы из строк, которые были возвращены. Мы возвращаем дополнительные столбцы, которые могут понадобиться приложению Эти столбцы потребляют пространство и ресурсы для обработки. Если вы запустите SAP, одно из больших изменений, поскольку база данных HANA является столбчатой, заключается в том, что, по сути, переписывая SAP, не выбирайте select star, чтобы они могли значительно сократить потребление ресурсов. Это в основном то, что часто происходит и в доморощенных приложениях, будь то Java, .NET и т. Д.
Этот экран показывает, кто, что, когда, где и почему. Почему, как, например, SQL-оператор и план выполнения, позволяет решать проблемы. Поскольку Precise работает непрерывно, вы можете на самом деле измерить до и после, на уровне операторов SQL, на уровне транзакций, так что вы можете измерить для себя, а также для владельцев приложений и для управления, что вы решили проблему, Эта документация действительно полезна. В этом стеке приложений много сложностей. Фактически, из многих приложений, с которыми мы говорили, по крайней мере часть стека приложений работает под управлением VMware. В этом случае они смотрят на приложение для обслуживания клиентов, они смотрят на время транзакции и соотносят его с замедлением - событием виртуализации. Точно отслеживает все события виртуализации. У нас есть плагин для vCenter, чтобы поднять это.
Мы также можем обнаружить конфликт. Разногласия отличаются от использования. Фактически показывает, когда, возможно, шумный сосед влияет на вашу гостевую виртуальную машину в контексте приложения сервера клиента. Теперь я могу углубиться и получить информацию, и я могу фактически увидеть две виртуальные машины, которые в данном случае борются за ресурсы ЦП. Это позволяет мне иметь видимость, чтобы я мог смотреть на планирование. Я могу разместить гостевую виртуальную машину на другом физическом сервере. Все эти типы вещей, на которые вы могли бы реагировать, а затем, в дополнение к этому, я могу реально взглянуть на эффективность кода, чтобы, возможно, он использовал меньше ресурсов процессора. Я думаю, что у меня есть довольно хороший пример в этой презентации, как кто-то смог уменьшить потребление процессора на порядки.
Это был VMware. Давайте перейдем к самому коду, к коду приложения. Precise сможет показать вам, что происходит в Java, .NET, коде ABAP, E-Business, PeopleCode и т. Д. Это точки входа, в данном случае в WebLogic. Здесь внизу есть отчет о результатах, который говорит мне, что вам нужно посмотреть на эти EJB, и скажет, что у вас также произошла блокировка в этой системе. Еще раз рассмотрим уровень бизнес-логики, чтобы показать, что происходит. В этом случае я смотрю на конкретные случаи; Я также поддерживаю кластеризацию. Если у вас работает множество JVM, вы можете посмотреть на кластер в целом или на узкие места в отдельной JVM.
Когда вы попадете в блокировку, я могу попасть в исключения. Исключение немного отличается от проблемы с производительностью. Как правило, исключения выполняются очень быстро. Потому что есть логическая ошибка, и как только вы нажмете эту логическую ошибку, она закончится. Мы смогли зафиксировать трассировку стека в самом начале исключения, это может сэкономить много времени, так как он пытается выяснить, что происходит, у вас просто есть трассировка стека, прямо здесь. Мы также можем фиксировать утечки памяти. Решение также включает в себя уровень базы данных, я могу войти, я могу оценить экземпляр базы данных. Еще раз, ось Y - это место, где было потрачено время, ось X - это время в течение дня. Есть отчет о результатах, который просто автоматически сообщает мне, что происходит в системе и на что я мог бы посмотреть.
Одна из вещей, о которых говорится в отчете о результатах Precise, это не только просмотр журналов или состояния ожидания, но и просмотр всех состояний выполнения, включая ЦП, а также возврат информации из хранилища. Хранение является очень важной частью стека приложений, особенно с появлением твердого состояния. Наличие информации по этим направлениям может быть очень полезным. Для определенных единиц хранения мы можем развернуть и показать, что происходит на уровне отдельных устройств. Этот тип информации - еще раз, это глубокая видимость; она имеет широкий охват - она дает вам достаточно информации, чтобы вы могли использовать ее как профессионала в области производительности приложений, чтобы вы могли оптимизировать свои приложения на сквозной основе для выполнения этих бизнес-операций.
У меня есть пара примеров, которыми я хотел бы поделиться с вами. Мы путешествуем довольно быстро; Я надеюсь, что я иду в нормальном темпе. Говоря о хранилище, все со временем меняют аппаратное обеспечение. Есть гарантия на оборудование. Это действительно доставило то, что сказал вам продавец? Вы можете оценить это с помощью Precise. Вы входите, и что здесь произошло, они в основном вставили новый блок хранения, но когда администраторы хранилища посмотрели только на уровень блока хранения, они увидели много споров и подумали, что может быть проблема с этим новым блоком хранения., Глядя на большее с точки зрения сквозной перспективы, чтобы точно показать, где это на самом деле произойдет. Они на самом деле шли с пропускной способностью около 400 мегабайт в секунду, где хранилище отвечало за 38 процентов времени отклика, так что оно довольно высокое. С новым модулем хранения мы фактически увеличили пропускную способность до шести, семисот мегабайт в секунду, что в два раза больше, и мы можем сократить вклад уровня хранения в время транзакции вдвое. Я могу на самом деле наметить это раньше, это период перехода, а затем после.
Итак, еще раз, документация, чтобы доказать, что инвестиции в оборудование того стоили, и они доставили, как того ожидал конкретный поставщик. Есть все, из-за сложности, количества вещей, есть все виды вещей, которые могут произойти. В этом случае у них фактически была ситуация, когда все как бы обвиняли DBA, DBA было похоже «ну, не так быстро». Здесь мы на самом деле смотрим на приложение SAP, я думаю, что этот тип сценария довольно распространен, Случилось так, что они разрабатывали пользовательскую транзакцию для пользователя. Пользователь говорит: «Это так медленно». Кодер ABAP - это язык программирования в SAP - сказал: «Это проблема с базой данных». В итоге они открыли Precise; они измерили этого конечного пользователя за 60 секунд, то есть за минуту. Пятьдесят три секунды было проведено в задней части. Они просверлили задний план и смогли показать оператор SQL, представленный в порядке убывания.
Это главный оператор SQL, который отвечает за 25 процентов потребления ресурсов, его среднее время выполнения составляет две миллисекунды. Вы вроде не можете винить базу данных. Знаешь, эй, не так быстро, парень. Вопрос в том, почему так много казней? Ну, они вернули его обратно в ABAP, он вошел, посмотрел на вложенность цикла, обнаружил, что они вызывают базу данных не в том месте, они в основном внесли изменения, протестировали изменения, и теперь новое время ответа пять секунд Немного медленно, но они могли бы жить с этим. Намного лучше, чем 60 секунд. Иногда, просто выводя, это код приложения, это база данных, это хранилище? Это те области, где Precise, имея контекст сквозных транзакций, именно здесь Precise вступает в игру. Вы в основном заканчиваете эти вещи.
Я смотрю на время, похоже, у нас еще есть немного времени, чтобы пройти еще пару из них. Я смотрю через них. Это приложение разрабатывалось более года. Когда они вошли в QA, они увидели, что веб-серверы были загружены на 100%, и казалось, что приложение не может работать под VMware. Первое, что все сказали, было: «Поместите это на физическое; он не может работать под VMware ». Точные фактически предложили им дополнительные способы решения проблемы. Мы посмотрели на транзакции, мы увидели вызов веб-сервера, он входит как ASMX в IIS.NET. Это фактически выявило основной код. Вы видите это, куда я указываю? Это 23 дня, 11 часов. Вау, как это возможно? Ну, каждый вызов занимает 9, 4 секунды, и эта вещь вызывается 215 000 раз. Для каждого вызова он использует 6 секунд процессора. Это причина, этот код является причиной, почему эта вещь никогда не может масштабироваться. На самом деле, он не мог масштабироваться в физическом плане.
То, что они сделали, - они вернулись к своим разработчикам и сказали: «Кто-то может внести изменения?». У них был какой-то конкурс, и они протестировали различные предложения, и они выдвинули предложение, которое могло много работать более эффективно. Новый закончил одну точку, чуть меньше двух секунд, с двухсотыми долями секунды в процессоре. Теперь это может масштабироваться и может работать на ферме VMware. Мы смогли документально подтвердить это как на уровне кода, так и на уровне транзакций. Это вид до, а потом после. Теперь, когда вы можете увидеть здесь на гистограмме стека, которая показывает сеть, .NET и базу данных, теперь вы взаимодействуете с базой данных. Это профиль, который вы ожидаете увидеть для приложения, которое работает более нормально.
Хорошо, я выбираю и выбираю в плане дополнительных вещей, которые я могу вам показать. Многим это нравится, потому что это ослепляет множество магазинов. Если вы не можете выполнить соглашение об уровне обслуживания, и все говорят: «Помогите нам». В этом магазине возникла ситуация, когда соглашение об уровне обслуживания находится в заказах, полученных к 15:00, то он отправлен в тот же день. Очень важно, чтобы они получали заказы, а склад был очень занят. Этот экран заказа на продажу JD Edwards замерзал, и вы можете очень хорошо понять, что это своевременная система управления розничными запасами. Пустые полки недопустимы в рознице. Нужно иметь товар там, чтобы продать его. То, что мы сделали, мы погрузились, в этом случае, мы смотрим на базу данных сервера SQL. Внешний вид одинаков, будь то SQL, Oracle, DB2 или Sybase.
Мы определили выбор из PS_PROD, и мы можем зафиксировать продолжительность, факт, что они выполняют так много. Темно-синий цвет соответствовал ключу, который сказал, что они не ожидают какого-то состояния ожидания, некоторого ведения журнала или даже хранения - эта вещь связана с процессором. Мы отслеживали оператор SQL по 34301, поэтому каждый раз, когда он выполняется, мы увеличиваем наши счетчики, чтобы отслеживать его. Это означает, что у нас есть подробная история, и я могу получить к ней доступ, нажав эту кнопку настройки. Вот вкладка истории. Этот экран показывает среднюю продолжительность и изменения. Среда, четверг, пятница, средняя продолжительность составила около двух десятых секунды. Очень немногие зависания экрана, они могут встретить бизнес SLA. 27 февраля, что-то меняется, и внезапно время выполнения здесь истекло, и это на самом деле достаточно медленно, чтобы вызвать тайм-ауты, что приводит к зависанию экрана. Точно, сохраняя подробную историю, включая план выполнения и общие изменения в индексах таблицы, если этот SQL используется. Нам удалось выяснить, что план доступа изменился 27 февраля. С понедельника по пятницу плохая неделя. Приходите 5 марта, план доступа снова изменился. Это хорошая неделя Эта розовая звезда говорит нам, что объем обновлен.
Здесь видно, что количество строк в базовых таблицах растет, что типично для бизнеса. Вы хотите, чтобы ваши столы росли. Дело в том, что операторы разбираются, приходят операторы SQL, оптимизатор должен решить, что делать, и выбрать, когда план выполнения быстр, выбрать другой план выполнения, когда он медленный, вызывая зависание экрана. На глубоком технологическом уровне мне нужно знать, что такое план выполнения, и Precise фиксирует его для меня вместе с отметкой даты и времени. Это тот, который был быстрым и эффективным, это тот, который был медленным и неэффективным. Это соединение фильтра просто использует намного больше ЦП для согласования, чтобы сделать этот конкретный оператор SQL. Они все еще имеют тот же самый конечный эффект, но у этого в основном есть более медленный, менее эффективный рецепт для доставки набора результатов. Итак, мы проходим. Эй, у нас есть время еще на пару?
Эрик Кавана: Да, пойти на это.
Билл Эллис: Хорошо, я пропущу. Я хочу, чтобы вы обратили внимание на одну вещь: мы говорили об оборудовании, говорили о SAP, мы говорили о .NET, мы говорили о JD Edwards и среде Java-SQL Server. Это SAP, здесь мы смотрим на PeopleSoft. Матрица поддержки Precise широка и глубока. Если у вас есть приложение, более чем вероятно, мы сможем обеспечить его таким уровнем видимости. Одним из самых больших изменений, которые происходят сейчас, является мобильность. PeopleSoft представил мобильность с помощью своего Fluid UI. Пользовательский интерфейс Fluid использует систему совсем по-другому. Это приложение развивается. Пользовательский интерфейс Fluid - с точки зрения управления он позволяет конечным пользователям использовать свой телефон и значительно повышает производительность. Если у вас есть сотни, тысячи или даже больше сотрудников, если вы можете увеличить их производительность, на 1–2 процента, вы можете оказать огромное влияние на заработную плату и все остальное. Случилось так, что именно этот магазин развернул интерфейс PeopleSoft Fluid. Теперь, говоря о сложности, это стек PeopleSoft. Одно приложение, минимум шесть технологий, множество конечных пользователей. Как вы это начали?
Еще раз Precise сможет следить за этими транзакциями. Здесь мы показываем составленную столбчатую диаграмму, показывающую клиент, веб-сервер, Java, базу данных Tuxedo, стек приложений PeopleSoft. Зеленый цвет отображает J2EE, что довольно необычно для WebLogic. Это переход. Конечные пользователи начинают использовать интерфейс Fluid, и время отклика может составлять от полутора до двух секунд, до девяти, десяти секунд. То, что этот экран не показывает, это количество людей, которые «не отвечают». Они фактически получили зависания экрана в приложении. Давайте рассмотрим некоторые сведения, которые Precise может предоставить этому клиенту.
Прежде всего, когда я смотрю на транзакции PeopleSoft, они могут видеть, в основном, мы видели такие вещи по всем направлениям. Все транзакции были затронуты, а также все места. Кстати, когда вы смотрите на это, вы можете увидеть места по всему миру. От Азиатско-Тихоокеанского региона до Европы и Северной Америки. Проблема с производительностью не связана с конкретной транзакцией или конкретным географическим местоположением, она распространяется на всю систему. Это своего рода способ сказать, что изменение или способ, которым пользовательский интерфейс Fluid был глобальным по своим последствиям. Вы можете видеть здесь с точки зрения масштабируемости, люди пытаются выполнять тот же тип активности, но время отклика в основном просто ухудшается и ухудшается. Вы можете видеть, что вещи не масштабируются. Дела идут очень и очень плохо. Здесь, когда я смотрю на количество осей и одновременных соединений, вы видите что-то очень интересное с точки зрения количества обращений и соединений. Здесь мы только увеличиваем примерно до 5000, и вы смотрите примерно, это достигает 100 одновременных подключений. Это сделано после; это раньше. Итак, что мое реальное требование к системе, если эта вещь может масштабироваться, находится в диапазоне 300 000. В старые времена с классическим пользовательским интерфейсом вы просматривали 30 одновременных подключений.
Теперь это говорит о том, что пользовательский интерфейс Fluid использует как минимум 10x одновременных подключений. Мы начинаем рассказывать о том, что происходит под покровом PeopleSoft, чтобы вы могли увидеть влияние на веб-серверы того факта, что SLA начинают нарушать. Не буду вдаваться в подробности, но в итоге они полагаются на обмен сообщениями. Они в основном упражняются в WebLogic и вызывают очереди в смокинге. На самом деле существовала проблема многоуровневой зависимости, которая появилась в Fluid UI, но Precise смог показать это с помощью целого ряда разных вещей, на которых мы можем сосредоточиться на том, в чем заключалась проблема. Оказывается, что была проблема и в самой базе данных. На самом деле есть файл журнала обмена сообщениями, и из-за всех одновременных пользователей этот файл журнала блокировался. Он в основном имел настройки для каждого уровня в стеке приложений. Говоря о сложности, вот фактически уровень Tuxedo, показывающий вам очереди, и вы также можете увидеть снижение производительности на этом уровне. Я мог видеть процессы; Я мог видеть домены и серверы. В Tuxedo для людей, которые используют это, обычно вы открываете дополнительные очереди, домены и серверы, как в супермаркете, чтобы уменьшить перегруженность, чтобы минимизировать время ожидания. Последний и последний вариант, Precise показывает много информации.
Как я упоминал ранее, каждая значимая транзакция взаимодействует с системой записей. Видимость в базе данных имеет первостепенное значение. Precise показывает, что происходит в базе данных, в WebLogic, в Java, .NET, в браузере, но место, которое Precise действительно превосходит, находится на уровне базы данных. Это слабость наших конкурентов. Позвольте мне показать вам один из способов, которым Precise может помочь вам пройти через это. Я не собираюсь тратить время на треугольник оптимизации баз данных, но мы в основном смотрим на недорогие, с низким риском, на широкомасштабные, с высоким риском, дорогостоящие изменения типов. На самом деле я потом напишу этот слайд, если люди захотят взглянуть на него. Я думаю, это довольно большое руководство по настройке проблем. Вот мнение эксперта Precise for Oracle. Сверху в отчете о результатах 60% -ное влияние оказывает именно этот оператор SQL. Если вы откроете этот экран активности, он покажет его там. Я могу посмотреть на этот оператор выбора, есть один план выполнения. Каждое исполнение занимает секунду - 48 000 казней. Это добавляет до 48 000 часов казней.
Темно-синий, опять же, процессор. Эта вещь связана с процессором, а не состояние ожидания, а не журнал. Я подчеркиваю, что, поскольку некоторые из наших конкурентов смотрят только на состояния ожидания и журналирования событий, но, вообще говоря, CPU является самым загруженным состоянием выполнения и предлагает наибольшую отдачу. Зайдя в эту экспертную точку зрения - и я иду очень быстро - я посмотрел на таблицу, 100 000 строк, 37 000 блоков. Мы делаем полный стол, но у нас есть шесть индексов на эту вещь. Что тут происходит? Что ж, когда я смотрю на предложение where, то, что делает это предложение where, это на самом деле преобразование столбца в верхний регистр и говорит, что оно равно верхнему регистру, найти переменную. То, что происходит, происходит каждый раз, когда выполняется эта вещь, Oracle должен преобразовывать этот столбец в верхний регистр. Вместо того, чтобы делать это почти пятьдесят тысяч раз, гораздо эффективнее построить этот индекс в верхнем регистре индекса на основе функций, и он доступен не только в подразделении Oracle на предприятии, но и в стандартном подразделении. Когда вы сделаете это, то вы сможете проверить план выполнения, выдав верхний регистр нового пользователя для индекса, это было просто мое мнение.
Затем, из измерения до и после, вы просматриваете время выполнения в одну секунду, агрегирующее до 9 часов 54 минуты с тем же самым точным оператором SQL, но с индексом, встроенным в верхний регистр для 58 000 выполнений, - ответ время падает до миллисекунд, а в совокупности оно достигает семи секунд. Я в основном сэкономил десять часов процессора на моем сервере. Это огромно. Потому что, если мне не нужно обновлять сервер, я могу жить на этом сервере. На самом деле я сократил использование этого сервера на 20 процентов, и вы можете увидеть до и после. Именно такой видимость может обеспечить Precise. Есть также некоторые дополнительные вещи, на которые мы могли бы взглянуть, почему у вас есть все эти индексы, если они не используются? Они могут следить за этим. Есть архитектура, и я ее завершу, так как мы достигли вершины часа. Я верный сторонник этого решения, и мы хотим, чтобы вы были истинным сторонником. В IDERA мы считаем, что пробная версия делает клиента, поэтому, если вы заинтересованы, мы можем провести оценку на вашем сайте.
С этим я передам маяк обратно.
Эрик Кавана: Да, это была потрясающая деталь, которую вы там показали. Это действительно довольно увлекательно. Я думаю, что, возможно, я упоминал вам в прошлом, что - и я знаю, что в некоторых других веб-трансляциях, которые мы проводили с IDERA, я упоминал об этом - я фактически отслеживал Precise еще до того, как он был приобретен IDERA, вплоть до 2008 года, я думаю, или 2009 года. Я был очарован им тогда. Мне любопытно узнать, сколько работы уходит на то, чтобы оставаться в курсе новых выпусков приложений. Вы упомянули, что SAP HANA, что, я думаю, было довольно впечатляющим, поскольку вы можете действительно углубиться в архитектуру HANA и провести там поиск неисправностей. Сколько у вас людей? Сколько усилий вы приложили, и сколько из этого можно сделать несколько динамически, то есть, когда инструмент будет развернут, вы начнете ползать и видеть разные вещи? Насколько это может быть динамически определено инструментом, чтобы вы могли помочь людям устранять неполадки в сложных средах?
Билл Эллис: Вы задавали много вопросов там.
Эрик Кавана: Я знаю, извините.
Билл Эллис: Я предоставил много деталей, потому что для этих приложений, глядя на код, дьявол кроется в деталях. Вы должны иметь такой уровень детализации, чтобы действительно иметь возможность действовать. Без действенных метрик вы просто знаете о симптомах. Вы на самом деле не решаете проблемы. IDERA - это решение проблем. Оставаться в курсе новых релизов и прочего - большая проблема. Вопрос о том, что нужно для этого, это действительно для управления продуктом. Я не очень хорошо представляю команду, которая в основном держит нас в курсе событий. С точки зрения HANA, это фактически новое дополнение к линейке продуктов IDERA; это очень волнительно. Одна из вещей с HANA - позвольте мне поговорить о задаче на секунду. В этой задаче магазины SAP будут выполнять репликацию базы данных для целей отчетности. Тогда вам нужно, чтобы люди мирились с тем, что на самом деле актуально. У вас будут эти разные базы данных, и они будут не синхронизированы на разных уровнях. Просто много времени и усилий, плюс оборудование, программное обеспечение и люди, чтобы поддерживать все это.
Идея HANA иметь высокопараллельную базу данных в памяти, чтобы избежать необходимости дублирования баз данных. У нас есть одна база данных, один источник правды, она всегда актуальна, так что вы избегаете необходимости делать все это согласование. Важность производительности базы данных HANA возрастает - я скажу, что это в 10 раз или, по крайней мере, более ценно, чем сумма всех этих других баз данных, оборудования, ресурсов, которые можно купить. Будучи способным управлять HANA, теперь этот компонент на самом деле находится в стадии бета-тестирования, и это скоро будет GA. Так что для IDERA и для нас очень интересно поддерживать платформу SAP. Я не уверен, что другие части вашего вопроса я как бы обманул, но -
Эрик Кавана: Нет, там все хорошо. Я бросил на вас целую кучу сразу, так что извините за это. Я просто очарован, правда, я имею в виду, что это не очень простое приложение, верно? Вы углубляетесь в эти инструменты и понимаете, как они взаимодействуют друг с другом, и, к вашему мнению, вы должны как-то соединить историю в своей голове. Вы должны объединить кусочки информации, чтобы понять, что на самом деле происходит и что вызывает у вас проблемы, чтобы вы могли пойти туда и решить эти проблемы.
Один из участников спрашивает, насколько сложно реализовать Precise? Другой человек спросил, кто эти люди - очевидно, администраторы баз данных - но кто такие другие роли в организации, которые будут использовать этот инструмент?
Билл Эллис: Precise немного сложнее в развертывании. Вы должны иметь некоторые знания о среде приложения, с точки зрения, вы знаете, это приложение работает на этой базе данных, оно нуждается или - веб-серверы среднего уровня и т. Д. Я думаю, учитывая сложность некоторых из этих приложений, это на самом деле относительно легко. Если я смогу подключить веб-сервер к вашей базе данных, я смогу сделать это сквозным. Вы заметили, что я ничего не сказал об инструментах для конечного пользователя, и это потому, что мы делаем то, что мы фактически включаем динамически, поэтому вам не нужно менять свой код или что-то еще. JavaScript входит в рамку страницы приложения. Независимо от того, где пользователь находится в мире, когда он получает доступ к URL из вашего приложения и закрывает эту страницу, он поставляется с Precise. Это позволяет нам выбрать идентификатор пользователя, его IP-адрес, а также время рендеринга первого байта каждого времени выполнения скрипта компонентов страницы в браузере конечного пользователя.
С точки зрения транзакций, вам не нужно планировать транзакции, потому что они тесно связаны. Этот URL становится точкой входа в JVM, а затем вызывает это сообщение, в результате чего JVC перехватывается из базы данных. Мы можем в основном поймать эти естественные точки подключения и затем представить их вам на экране транзакций, который я показал вам, где мы также рассчитали, сколько времени или процент времени, затраченного на каждый отдельный шаг. Все это делается автоматически. Вообще говоря, мы выделяем 90 минут на то, чтобы установить ядро Precise, а затем приступить к реализации приложения. В зависимости от знания приложения, нам может потребоваться несколько дополнительных сессий, чтобы проинструктировать все приложение. Многие люди используют только компонент базы данных Precise. Все в порядке. Вы можете просто разбить это, разбить его на компоненты, которые, по вашему мнению, нужны вашему сайту. Мы определенно верим, что контекст инструментария всего стека приложений позволяет увидеть, что зависимость от уровня к уровню фактически увеличивает ценность мониторинга отдельного уровня. Если кто-то захочет продолжить изучение инструментов своего стека приложений, перейдите на наш веб-сайт - я полагаю, что это самый простой способ запросить дополнительную информацию, и мы обсудим это немного дальше.
Эрик Кавана: Позвольте мне задать вам один или два быстрых вопроса. Я предполагаю, что со временем вы собираете и создаете хранилище, как для отдельных клиентов, так и для всей корпоративной организации, взаимодействий между различными приложениями и различными базами данных. Другими словами, я полагаю, что моделирование сценариев - это то, на что я намекаю. Это тот случай? Поддерживаете ли вы на самом деле хранилище общих сценариев, так что вы можете вносить предложения конечным пользователям, когда в игру вступают определенные вещи? Как и эта версия E-Business Suite, эта версия этой базы данных и т. Д. Вы делаете много из этого?
Билл Эллис: Хорошо, этот тип информации встроен в отчет о результатах. В отчете о результатах говорится, что существуют узкие места в производительности, и он основан на времени выполнения. Часть этого отчета о результатах - узнать больше и что вы будете делать дальше. Информация или опыт клиентов и т. Д. В основном включены в эту библиотеку рекомендаций.
Эрик Кавана: Хорошо, это звучит хорошо. Ну, ребята, фантастическая презентация сегодня. Билл, мне понравилось, как много деталей у тебя было. Я просто подумал, что это действительно фантастическая, грубая, детальная информация, показывающая, как все это делается. В определенный момент это почти как черная магия, но на самом деле это не так. Ребята, вы разработали очень специфическую технологию, чтобы понять очень, очень сложные среды и сделать людей счастливыми, потому что никому не нравится, когда приложения работают медленно.
Ну, ребята, мы будем архивировать эту веб-трансляцию. Вы можете прыгнуть онлайн в Techopedia или insideanalysis.com и ничего себе, спасибо, что уделили нам время, мы встретимся с вами в следующий раз. Береги себя, пока-пока.
