Персоналом Техопедии, 31 августа 2016 г.
Вывод: Хозяин Ребекка Йозвиак обсуждает вопросы устранения неполадок с базами данных и проблемы эффективности с аналитиками Эриком Кавана и Дезом Бланчфилдом, а также с Биллом Эллисом из IDERA.
Вы не вошли в систему. Пожалуйста, войдите или зарегистрируйтесь, чтобы увидеть видео.
Ребекка Йозвиак: Уважаемые дамы и господа, привет, добро пожаловать в Hot Technologies 2016 года. Сегодняшняя тема «Медленное выполнение приложения? Время, чтобы стать точным». И разве мы все не слишком хорошо знаем проблемы, которые могут возникнуть, когда все работает медленно? Это Ребекка Джозвиак, я заменяю Эрика, который сегодня играет здесь новую роль. Да, этот год жаркий, и, знаете, когда речь заходит о технологиях, как я уже сказал, единственное, чего вы на самом деле не хотите, так это медленного запуска чего-либо, любой части вашей системы. И просто для примера потребительского характера, я имею в виду, если у вас есть ресторан, то не имеет значения, насколько вкусна еда, если обслуживание медленное, вы, вероятно, не собираетесь возвращаться. В ресторане легко понять, почему что-то работает медленно. Возможно, на кухне не хватает персонала, или было какое-то неисправное оборудование, или, возможно, обслуживающий персонал немного ленив, и это легко определить и починить.
Но когда вы думаете о центре обработки данных, это совсем другая история. Это может быть проблема с сетью, неправильный запрос, из-за которого возникают проблемы, производительность приложения или неисправный кабель, могут даже вызвать некоторые проблемы. А устранение неполадок с такой сложностью может быть, в лучшем случае, трудным. Это то, о чем мы будем говорить сегодня. И у нас есть, как я уже сказал, Эрик Кавана в качестве аналитика сегодня. У нас есть Dez Blanchfield, наш специалист по данным, и у нас есть Билл Эллис из IDERA, который расскажет о решении своей компании, которое помогает в управлении производительностью приложений. И с этим я собираюсь передать мяч Эрику. Эрик, слово твое.
Эрик Кавана: Хорошо, звучит хорошо, ребята. И это была отличная аналогия, на самом деле, потому что вы говорили о трудностях или легкости, с которыми можно выполнить устранение неполадок, и вы приступили прямо к этому. Проблемы с производительностью всегда возникают из-за каких-то проблем в сети. Я имею в виду, что это может быть так же просто, как старое оборудование, например, но суть в том, что любая ситуация, подобная этой, требует устранения неполадок. Об этом я сегодня и поговорю. И давайте идти вперед и прыгать на слайдах здесь.
Здесь приходит беда. Устранение неполадок - это весело для людей, которым это нравится, это крутая вещь. Если вы найдете кого-то, кто любит заниматься поиском и устранением неисправностей, держитесь за этого человека, дайте ему некоторые инструменты для выполнения работы, потому что это действительно хорошая вещь, если вы можете найти кого-то, кто может разобраться в чем-то и выполнить работу. Но суть в том, что устранение неполадок является проблематичным, оно всегда было и всегда будет, и если вы начнете говорить о поиске и устранении неисправностей, то на самом деле вы получите анализ первопричин. В чем причина проблемы?
Что ж, если вы просто откинетесь на секунду и подумаете хотя бы о днях мэйнфреймов, могут возникнуть всевозможные проблемы. И тогда у вас были люди, которые действительно знали свое дело, потому что не было даже хороших инструментов для устранения неполадок, поэтому вы действительно должны были знать командную строку, и мы поговорим об этом через секунду. И я на самом деле забыл вставить один из моих любимых слайдов, я буду искать его, пока мы будем на шоу сегодня, может быть, во время презентации Деза. Но я хотел показать, для любого, кто его не видел, одно из самых забавных британских телешоу в истории, оно называется «Толпа ИТ». И с точки зрения устранения неполадок, ирландец, который является одним из двух ИТ-специалистов в Вся компания всегда говорит одно и то же, когда начинается любой звонок: «Вы пытались выключить и снова включить его?» Итак, попробуйте выключить и снова включить его. Вы будете удивлены, как часто эта простая вещь может решить некоторые проблемы.
Те из вас, кто занимался устранением неполадок дома, возможно, с вашими родителями или друзьями, возможно, не с вашими детьми, потому что они, как правило, знают, что делать, выключают и снова включают. Но, несмотря на это, устранение неполадок не просто, это не всегда будет легко, но сегодня мы поговорим о некоторых вещах, которые вы можете сделать, чтобы сделать это проще. Итак, командная строка - да, действительно, я достаточно взрослый, чтобы помнить первые дни вычислений, когда все, что у вас было, - это командная строка для выполнения DIR, Enter. Это то, что он будет видеть, каталог файлов и чувствовать себя уверенным, что он действительно выполнил какую-то команду, верно? Дез, конечно, наш специалист по данным, он знает, как использовать командную строку. И если вы можете использовать командную строку, это здорово, потому что большинство из нас, простых смертных, используют какой-то графический интерфейс, графический пользовательский интерфейс, но всегда есть что-то, всегда есть некоторое разъединение между графическим интерфейсом и командной строкой внизу. И просто для того, чтобы привести случайный пример, если вы хотите узнать, сколько кода некоторые базовые программы выпекают в документы в наши дни, перейдите в последнюю версию Microsoft Word, введите «hello world» и затем «сохранить как». HTML ». А затем откройте полученный документ в текстовом редакторе, и вы, вероятно, увидите страницы и страницы тегов. Это называется раздуванием кода, и раздувание кода не очень хорошо для устранения неполадок, просто чтобы быть тупым.
Конечно, появился клиент-сервер, и это было здорово. И в некотором смысле мы как бы возвращаемся в этом направлении, но просто подумайте о сложности, которая возникла с ситуацией, теперь, где проблема, это на клиенте, на сервере, в сети? Где это? Что может случиться с этими сайтами, которые просто думают о вирусах, и когда вирус может попасть в один из них в сети? Это может пойти куда угодно. Нарушения данных в наши дни сумасшедшие. Они вызывают проблемы с производительностью. У нас были русские хакеры, которых мы можем идентифицировать по IP-адресу. Мы почти уверены, что они русские, или они очень близки, или они очень умные украинцы или поляки или даже американцы, использующие прокси. Но на протяжении многих лет хакеры заходили на наш маленький старый сайт Inside Analysis и вызывали всевозможные проблемы. Материал просто перестает работать, вы не можете сделать вещи. Вещи, которые раньше работали, не работают. Откуда вы знаете? Откуда ты знаешь, что это? Как и другой пример, это очень сложная среда, очень трудно проникнуть в сорняки и действительно понять, как все происходит и работает для нас, особенно если вы получаете целую кучу плагинов. Материал может сойти с ума довольно быстро. Я вроде забегаю вперед.
Я бросил сюда, всегда быть осторожным с обновлением. Обновления всегда пугают дневной свет из меня. Конечно операционные системы. Я помню дни, когда Microsoft фактически предлагала, что да, вы можете обновить операционную систему с этой версии до этой версии. Ну, я пробовал несколько раз, и это никогда не работало. Просто помните: чем больше, чем сложнее окружение, тем более непростой будет ситуация. И затем есть виртуализация. Подумайте о том, что VMware сделала с ИТ. Это революционизировало ИТ, но также создало этот уровень абстракций. Если у вас есть абстракция слоя на этом базовом уровне, это совершенно новая игра с мячом, это совершенно новый шарик воска, и вам действительно нужно пересмотреть то, что вы делаете, и все старые инструменты должны были измениться. И теперь, конечно, это облако, верно? Для клиента облако - это здорово, потому что оно очень простое, пользовательский интерфейс довольно прост, но, конечно, у вас нет большого контроля над облаком. Но для тех, кто за кулисами, есть много вещей, которые они должны знать и понимать в эти дни. Окружающая среда стала намного, намного сложнее. И, конечно, с электронной коммерцией, и вы думаете обо всех деньгах, которые торгуют в наши дни. Вот почему вы не найдете меня в пользу безналичного общества в ближайшее время. Суть в том, что ситуация становится все более проблемной с каждым днем.
А поддержание оптимальной производительности всегда будет включать в себя элемент устранения неполадок. Мне все равно, что кто-то говорит вам, нет идеального инструмента, нет серебряной пули и никогда не будет, потому что - в другой интересной перспективе - мы все еще учимся говорить на кремнии. Мы все еще учимся понимать, как даже работа в сети работает на мельчайшем уровне. Если вы посмотрите на программное обеспечение для управления системами, в наши дни оно становится довольно хорошим. Но, тем не менее, вы смотрите на линии, идущие вверх и вниз, и вы смотрите на представления реальности, потребуется человек, который знает, что происходит, чтобы соединить воедино ключи, которые вы могли бы посмотреть на оптимальные инструменты, чтобы иметь возможность понять, что работает, а что нет, и это много проб и ошибок, просто чтобы быть тупым. После этого я передам его Дезу Бланчфилду, а затем мы услышим от Билла Эллиса из IDERA, который собирается опозорить нас своими знаниями. С этим, Дез, забери это.
Дез Бланчфилд: Привет, спасибо, Эрик. Спасибо. Привел красиво в мою маленькую игру. Мое название «Performance Art», я думаю, очень уместно в контексте того, о чем мы говорим сегодня, потому что во многих отношениях, когда мы думаем об исполнительском искусстве, мы думаем о танцах, музыке и других творческих вещах. И, честно говоря, чаще всего, если мы решаем проблемы и в очень крупномасштабных ИТ-средах и бизнес-системах действительно присутствует элемент искусства, а зачастую и черное искусство, потому что в моем опыте за 25 с лишним лет стеки современных приложений очень быстро увеличивают сложность со скоростью, которую мы никогда раньше не видели. И мы, честно говоря, изо всех сил стараемся не отставать, и есть такие организации, как Uber, например, и тому подобное, и команда разработчиков Pokémon Go, я имею в виду, что они испытывают рост и сложность, а также усложнение со скоростью, которая является просто астрономической. Об этом даже не написано, потому что мы не задумывали этот уровень роста. Я считаю, что базовое определение стека приложений изменилось в геометрической прогрессии, и я собираюсь объяснить, почему я думаю, что это так, а затем привести к сложному вопросу, что у моих хороших друзей в IDERA, кажется, есть решение, которое нужно решить.,
Короче говоря, мы все это знаем, но просто для того, чтобы подвести итог, вы знаете, в первые дни у нас было то, что я называю архитектурой приложений, версия 1.0. Это был серверный компьютер, в данном случае мэйнфрейм с несколькими подключенными терминалами, было довольно легко диагностировать проблемы, если вы не видели ничего на терминале - вы могли отследить кабель между терминалом и затем сервером и это был либо нулевой кабель, либо разъем, либо какая-то проблема, если она не была связана с терминалом, и вы видите вещи на экране, было довольно легко понять, что то, что вызывало проблемы, было в сама машина. И вы можете медленно диагностировать, где в стеке находится аппаратное обеспечение, вплоть до уровня программного обеспечения и пользовательского интерфейса. В том, что я называю версией 1.1, мы сделали это немного сложнее. Мы поместили устройства посередине, чтобы мы могли разместить больше терминалов. И они были чем-то вроде коммуникационного устройства, и часто они были мультиплексорами или мультиплексорами, и они работали либо по выделенной линии, либо по коммутируемой линии, поэтому у вас был мэйнфрейм в удаленном месте - это может быть межгосударственный или международный уровень - и какое-то устройство подключен по SMA-каналу или к какому-либо WAN-соединению, и эти терминалы по-прежнему работают таким же образом. Но у вас было немного больше сложности, потому что вы должны были выяснить, была ли проблема между терминалами и устройством связи или устройством связи и мэйнфреймом. Но стек остался относительно похожим в мэйнфрейме.
Версия 1.2 снова немного сложнее, потому что теперь мы добавили больше устройств, добавили принтеры и другие вещи, и мы сгруппировали эти вещи, и я думаю о внешнем процессоре, который будет решать все проблемы устройств локально, принтеры и терминалы и так далее с базовым блоком, который отдаленный конец. Чуть больше сложности. Но опять же, главной темой мейнфрейма были приложения, работающие локально, поэтому решение проблем в стеке приложений оставалось довольно схожим. А потом у нас были люди с навыками, которые разбирались с терминалами, принтерами и кластерными контроллерами. Но затем мы усложнили вещи и создали сети, и внезапно такая же архитектура вводит сетевой уровень. Внезапно у нас появился сетевой коммутатор, и рабочие станции стали намного сложнее. И в этой версии архитектуры у нас часто были приложения с графическим интерфейсом пользователя на рабочей станции. У нас был не только сервер, на котором выполнялся стек приложений, но и другой локальный стек приложений, и, конечно, та же базовая модель устройств, подключающихся к серверу. Затем мы совершили качественный скачок к более новой модели, которую я называю 2.1, - именно там мы взяли этот стек приложений, и мы сделали его намного более сложным, намного сложнее диагностировать. И мы представили намного больше устройств во внешнем интерфейсе, в веб-браузерах, ПК и мобильных устройствах и так далее. И вот тут стек приложений начал углубляться в интеграцию как операционной системы, так и гипервизора.
На этом рисунке справа мы видим весь стек, включая сетевую инфраструктуру, серверы хранения, виртуальные машины, операционную систему, а также традиционные три уровня приложений для работы с металлом баз данных и т. Д., В правой передней части. Диагностика проблем приложений и производительности в этой модели стала намного сложнее. Есть так много движущихся частей, и попытка углубиться в этот стек просто стала кошмаром, и вам пришлось задействовать дополнительные наборы навыков и организацию, чтобы справиться с этим. Теперь это была не просто ваша прикладная команда, внезапно у вас появились специалисты по инфраструктуре, у вас были специалисты по базам данных, которые просто работали над базами данных и ничего больше - в отличие от системного программиста, который разбирался в базах данных. Теперь у нас есть сценарий, в котором ИТ-отделам приходится иметь дело со значительно более широкой сложностью «как услуга», и тогда мир только взорвался, и наши задачи по решению проблем превратились из кошмара в нечто, что почти невыносимо в какой-то степени.
И это стало масштабируемостью, к которой мы стремимся предоставлять услуги. Версия 3 того, что я считаю стеком приложений - он представил это как модель сервиса, где традиционная модель слева - корпоративный ИТ-стек, где все должно было управляться с нашей стороны как потребителя и поставщика сервисы - от базы данных безопасности приложений, операционных систем, хранилища сервисов виртуализации до сетевых центров обработки данных - мы должны были управлять всем этим, но у нас был доступ ко всему этому, поэтому мы могли масштабировать свои возможности и технические навыки, и мы могли углубляться в детали через этот стек, и мы могли бы найти вещи. Но поскольку сервис инфраструктуры и сервис платформ и модель сервисов программного обеспечения пришли вместе, внезапно наш доступ к серверной инфраструктуре, наш доступ к платформам и инструменту, с которого мы предоставляли сервисы, были как бы отняты у нас. Когда мы начали использовать инфраструктурный сервис, нам были доступны только четыре верхних компонента из операционной системы, базы данных, стека приложений среды безопасности и выше. Все под этим было черной магией. И это становится еще интереснее, когда вы переходите на сервис платформы, потому что вы просто управляете стеком приложений.
Когда вы переходите на программное обеспечение как услугу, и традиционной моделью этого является веб-почта или интернет-банкинг, все, что у вас есть, - это доступ к веб-браузеру, поэтому попытаться диагностировать то, что стоит за этим, недопустимо, безусловно. И я разбил это на часовые пояса, на временные или временные промежутки времени, если хотите или поколений, в том, что слева направо, мы прошли путь от 2000-х до традиционного стека, к которому у нас был доступ для всей среды, и мы могли бы углубиться в это. Но со временем это становилось все более и более сложным. До начала 2000-х и до середины 2000-х, до конца 2000-х годов и до сегодняшнего дня, когда мы перешли от обслуживания инфраструктуры, обслуживания платформы, обслуживания программного обеспечения, и теперь мы по существу имеем в виду бизнес-службу. И сложность резко возросла. Есть так много движущихся частей. Но доступность навыков становится все сложнее и сложнее. Поиск людей с правильными наборами навыков с правильным доступом к нужным инструментам, чтобы получить и погрузиться в этот стек и выяснить, где что-то работает медленно. Это мой ноутбук или мой рабочий стол, это мой телефон или мой планшет, это мое соединение через 3 или 4G, или моя выделенная связь с ADSL, или ISDN, что бы это ни было? Или даже дозвона, хотя в наши дни это все реже и реже. Конец веб-сервера, это что-то внутри веб-сервера? Это сервер приложений? Это что-то вокруг памяти и диска процессора и производительности сети внутри сервера приложений? База данных работает там?
И вы можете себе представить, вы очень быстро рисуете эту картину сложности, которая начинает расширяться, как образ большого взрыва, этого постоянно растущего пузыря, в который мы пытаемся обнять руки и у которого есть навыки, чтобы погрузиться и знание и способ рассекать и разбирать. И мы очень сейчас в эпоху, когда, вы знаете, люди не могут справиться с физическим масштабом, даже если у вас есть возможность разделить среду базы данных, разделить эту базу данных и погрузиться в подробно в этой базе данных. Количество баз данных, которыми вы должны управлять сейчас, быстро растет. Все теперь работает на базе данных. Очень немногие приложения в наши дни не работают на базе данных. И типы баз данных также быстро растут. Это больше не просто традиционные базы данных SQL, иногда это SQL, иногда не-SQL, иногда это графическая база данных, иногда это база данных документов. И есть все эти различные типы функций, которые имеют эти различные типы баз данных, и в результате каждая из них имеет различные проблемы производительности и разные критерии производительности. Журналирование баз данных и баз данных документов работает очень, очень по-разному и выполняет функции, отличные от традиционной базы данных SQL, совместимой с ACID и ANSI 92. И типы вещей, которые мы там храним.
На мой взгляд, мы находимся в точке, где - и я думаю, что Эрик намекал на это - что люди борются за то, чтобы не отставать от сложности того, что мы строим, и от скорости, с которой мы строим, и мы Сейчас мы находимся в точке, где единственный способ для нас управлять этой инфраструктурой и единственный способ отслеживать и вникать в проблемы, с которыми мы сталкиваемся, - это инструменты и правильные типы инструментов. И затем неизменно правильное поколение инструментов. Инструменты, которые действительно понимают внутреннюю инфраструктуру. Уже не в порядке просто бросить монитор SQL или инструмент SQL-запроса на что-то и начать разбирать запрос и посмотреть, что заставляет его работать. На самом деле нам нужен инструмент, который понимает формирование запросов и соответствующий способ формирования запросов, а также соответствующие способы взаимодействия запросов с инфраструктурой на бэкэнде и то, как они работают при этом. И посмотреть на сроки этих взаимодействий и порядок, в котором они происходят.
И это гораздо более сложная задача, и это подводит меня к моему вопросу о сводке, заключающемуся в том, что по мере увеличения сложности стеков приложений, которые мы разрабатываем, инструменты производительности и инструменты, которые мы используем для управления ими, обязательно нуждаются в становиться все умнее и гораздо более способным смотреть на большее. Но также гораздо умнее в том, как они вникают в то, что работает на бэк-энде, и что они могут узнать об этом и, возможно, даже какую-то аналитику, выполняемую над этим, чтобы понять, что взаимодействия и производительность доставляются, и почему он работает медленнее или быстрее.
И затем я собираюсь передать нашему дорогому другу из IDERA Биллу Эллису и посмотреть, что он скажет сегодня о том, как они решают эту проблему. Билл, к тебе.
Билл Эллис: Хорошо. Меня зовут Билл Эллис и большое спасибо. Мы поговорим о том, что мое приложение работает медленно, пора получить Precise. Давайте посмотрим, что может сделать Precise, продукт IDERA, и как он может вам помочь. Часто вы обнаруживаете, что возникла проблема с производительностью, потому что конечный пользователь позвонил вам, и это действительно большая проблема сама по себе. Из всех, кто работал в сфере информационных технологий, никто не знал, пока не зазвонил телефон. Теперь следующая большая проблема - как мы можем помочь этому конкретному человеку, и это на самом деле не тривиальная проблема. Есть один вывод из этого. Это выше и за пределами этого слайда, это выше и за пределами других. И я хочу, чтобы вы посмотрели, сможете ли вы понять, что это такое. Но, как мы уже упоминали, приложение требует, опирается на множество различных технологий, стек приложений высок и растет. И многие люди получают доступ к приложению через браузер, и удивительно, что в браузере происходит все больше и больше обработки с использованием сценариев и т. Д., И, конечно, у вас есть сеть, веб-сервер, код бизнес-логики и база данных. Я хочу, чтобы вы учли, что каждая значимая бизнес-операция взаимодействует с базой данных, будь то отчетность по тайм-карте, поиск инвентаря, заказ на покупку, база данных обновляется. Итак, база данных становится действительно основой производительности. И база данных, конечно, может включаться или полагаться на нисходящий поток при хранении. Каждая из этих технологий тесно связана и способна видеть, что происходит. Вы должны знать, что происходит, чтобы иметь возможность измерить, имеет решающее значение.
Теперь, одна вещь, которую мы находим, состоит в том, что у многих наших клиентов есть инструмент, и у них есть инструмент для каждой технологии, но у них нет контекста. А контекст - это в основном возможность соединять точки между каждым уровнем в стеке приложений, и это на самом деле относительно просто. Раньше у нас было ограничение в двенадцать уровней, но в основном оно изменилось, у нас есть неограниченное количество уровней, и мы поддерживаем смешанные среды, поэтому мы можем существенно усложнить решение Precise.
Теперь, на высоком уровне, именно так мы решаем проблему, и она фокусируется на транзакции, транзакции конечного пользователя от клика на диск, говорит нам, какие из них работают медленно, какие потребляют ресурсы, но ключ к этому - мы позволяем подобрать и идентифицировать пользователя свое местоположение и не только все время транзакции, но и сколько времени затрачивается на каждом отдельном шаге. Время - это валюта производительности, и оно также показывает, где потребляются ресурсы. Мы не знаем заранее, где будет проблема, поэтому нам нужно иметь адекватные метрики и аналитику на каждом из уровней, чтобы можно было диагностировать, в чем проблема, где может быть проблема.
Теперь, в сегодняшней презентации, я собираюсь сосредоточиться на этой области, я хочу, чтобы вы были уверены, что мы в основном обеспечиваем одинаковый уровень видимости на каждом уровне стека приложений, и самое важное, скажет ли это нам, кто, что, где, а затем эта часть, это расскажет нам почему. И это действительно то, почему это абсолютно важно для решения проблем, а не просто знать о них. Еще одна вещь, которая очень отчетливо проявилась в презентации, это то, что это невозможно сделать. Вам нужна автоматизация. А автоматизация означает, что у вас есть оповещение, у вас есть что-то, что, как мы надеемся, до сообщества конечных пользователей, говорит о том, что у вас есть постоянный тренд, что создает отклонение от оповещения о трендах. И затем мы также предлагаем линию на песке, вы на самом деле нарушаете SLA. Теперь вы предлагаете много различной информации - не всем нужно употреблять шведский стол, некоторые люди просто хотят перекусить, это салат, и поэтому, когда мы предлагаем портал, мы можем загружать информацию, ему просто нужен конкретный пользователь. или потребности сообщества в информации о производительности. Приложение работает медленно, пришло время получить Precise. Мы действительно собираемся сосредоточиться на четырех вещах. Одним из них является местоположение, ввод конечного пользователя. Еще раз, тот контекст, который связывает точки, и третья часть исследования показывают, что почти 90 процентов проблем с приложениями находятся в базе данных, и поэтому это действительно своего рода пародия на то, что большинство решений для производительности могут сказать вам одну инструкцию SQL. Но они не говорят вам, почему этот оператор SQL выполняется медленно.
И так, почему это всегда важная вещь, и Precise превосходно показывает, почему для каждого уровня и, в частности, базы данных, и просто делится с вами небольшой информацией о нашей матрице поддержки, которую мы поддерживаем SQL Server, Sybase, DB2. и / или Навальный. Внешний вид решения очень похож, поэтому, если вы смотрите на несколько приложений, но немного отличающихся архитектур. Информация, которой я делюсь здесь, имеет внешний вид, подход, это одно и то же, независимо от того, какие базовые технологии используются. Точный веб-включен. Мы входим, мы аутентифицируем Precise, и с этим мы входим, и первое, на что мы можем обратить внимание - это производительность по местоположению. И поэтому вы можете увидеть здесь различные места, где люди на самом деле получают доступ к своим казням. Вы можете увидеть, если кто-то оставил страницу до того, как она полностью отобразилась, или есть ошибки.
Одна вещь, связанная с этими приложениями, это то, что сеть или расстояние от сервера приложений действительно различаются. Здесь очень легко увидеть, что существует некоторый уровень сети. Я вижу, когда люди становятся занятыми, а затем еще одна интересная вещь, мы говорили о том, как происходит обработка в браузере, они фактически замечают, что некоторые из различных типов браузеров обеспечивают лучшую среду для быстрой обработки. И поэтому, зная, получают ли люди доступ через Chrome, IE или что-то еще, вы на самом деле очень часто обнаруживаете, что одна инверсия типа браузера на самом деле превосходит другую. Теперь, когда вы общаетесь публично, вы не контролируете браузер, иногда приложения являются внутренними, и вы можете рекомендовать людям тип браузера для вашего сообщества конечных пользователей, и это те виды глубокой наглядности и аналитики, которые Точное в состоянии обеспечить. Теперь мы рассмотрим приложение.
Я не уверен, что вы, ребята, видите мой указатель, но я хотел описать вам верхний график. Ось Y показывает среднее время отклика. Ось X - это время в течение дня. И на самом деле есть гистограмма с накоплением и эта гистограмма с накоплением, общая сумма показывает, какова производительность, а затем показывает, сколько времени затрачивается на каждый отдельный шаг или каждый отдельный уровень приложения. От клиента, через веб-сервер, зеленый - это Java, в этом месте мы используем смокинг и вниз в базу данных. Теперь нижняя половина экрана отображает различные веб-меню, к которым осуществляется доступ, и мы затем отсортировали их по маленькой зеленой стрелке, указывающей вниз. Это в порядке убывания, и это всплывает вверх, веб-меню начинает показывать это. На самом деле мы показываем время выполнения, время отклика каждой отдельной технологии, а затем на самом деле есть гистограмма для каждого из этих веб-меню, и мы начинаем понимать, что происходит. Теперь помните, что мы отсортировали все это по вызову конечного пользователя, но как мне найти конечного пользователя? Я захожу сюда, я открываю меню, которое позволяет мне фильтровать по конкретному пользователю, поэтому я установил для этого пользователя значение Alex Net, нажмите кнопку ОК, и затем мы сосредоточимся только на активности Alex Net. Теперь, что это делает, так это позволяет ИТ-отделу и ИТ-менеджменту напрямую реагировать на конечного пользователя и, в частности, на то, что он рассматривал управление контентом, которое имело шесть исполнений с временем отклика чуть более трех секунд. Ну, три секунды - это неплохо, не страшно, но, может быть, медленнее.
Что я могу с этим сделать, так это то, что могу порезать и нарезать эту информацию по-разному. Я мог бы сказать, хорошо, эта транзакция медленная для всех? Для Алекса сегодня медленнее, чем вчера? Это медленно для каждого пользователя в определенном месте? Или, и что это делает, это позволяет мне что-то вроде кусочков и кубиков и получить представление о том, что происходит, насколько универсальна проблема, и очень важно иметь возможность идентифицировать конечного пользователя, потому что речь идет не только о программном обеспечении, инфраструктура, это также о том, как конечные пользователи используют приложение. Часто у вас может быть новый сотрудник или кто-то с новой функцией работы, и они не знакомы с определенными экранами SAP или определенными панелями PeopleSoft, и им нужен небольшой указатель, возможно, они оставляют поля пустыми или вставляют подстановочные знаки, и они ' заставляя большие результаты быть возвращенными из базы данных. Но имея идентификатор пользователя, вы можете позвонить им прежде, чем они позвонят вам. Другая вещь, которую мы находим, заключается в том, что, как только сообщество пользователей осознает, что ИТ-специалисты знают, что они делают, они часто ведут себя лучше и много проблем, много проблем, которые были проблемами, просто отчасти испариться, потому что люди ведут себя, просто действовать немного более осторожно. Они используют систему с большей осторожностью.
Идентификация конечного пользователя необходима. В конце концов, для ИТ важно иметь возможность помочь конкретному конечному пользователю. Теперь, что мы сделали здесь, мы перешли на вкладку «Поток». Вы можете видеть это в верхнем левом углу. И мы сосредоточились на одном конкретном компоненте веб-меню. А с правой стороны - анализ этой конкретной транзакции, и поэтому на самом деле это браузер, а затем просмотр, просто чтобы немного познакомиться с иконками в графическом интерфейсе для веб-сервера, поэтому мы можем увидеть точку атрибута. И затем «J» для Java, а «T» для смокинга и, естественно, «Q» является SQL. Хорошо, что денежная стоимость в основном идентифицирует определенный оператор SQL. Посмотрите, что это делает. Мы определили пользователя для транзакции, для базового кода приложения, включая отдельные операторы SQL. Теперь, когда я смотрю на эти отдельные операторы SQL, я вижу, что из общего времени ответа каждый из них отвечает примерно за шесть процентов, а когда они складывают четыре верхних оператора SQL, они занимают около четверти транзакции. время.
Сейчас часто базой данных легче всего манипулировать. Обычно проще всего получить недорогую, намного превосходящую производительность. Теперь мне нужно пойти немного глубже, чтобы выяснить, что происходит и что, я хочу, чтобы пример был способен на самом деле раскрыть отдельный оператор SQL, и вы знаете, я могу почти гарантировать вас только каждым выстрелом в строке У меня был какой-то инструмент для работы с базами данных, и то, что делает инструмент для работы с базами данных, но просто рассматривая одну технологию отдельно, это то, что вы смотрите на ее работоспособность. И много раз люди смотрят список первой десятки. Теперь этот оператор SQL довольно быстрый, он не будет в первой десятке, но это оператор SQL, на который опирается эта транзакция. И поэтому я могу вернуться к этому слову, контексту, и теперь я могу обратить на это пристальное внимание, но в контексте отдельного оператора SQL.
Теперь этот человек может открыть Precise в контексте отдельного оператора SQL, и Precise фиксирует фактический план выполнения, который он использует, время выполнения, которое является важным для DBA, фактически покажет, вы можете видеть, что 50 процентов время тратится на ожидание на хранение. Пятьдесят процентов времени используется в ЦП, так что вы начинаете понимать, где тратится время, как я могу потратить это время, и идея состоит в том, чтобы дать людям варианты, потому что разные ответы связаны с разными затратами и рисками., В идеале мы ищем решение проблемы с низким уровнем риска и низкой стоимостью. Теперь, когда оператор SQL отслеживается по хэш-значению, в левой части экрана есть маленькая кнопка «Настроить», и она собирается перейти к задаче SQL. И эта задача SQL является своего рода предварительно созданным рабочим столом, и это позволяет мне действительно анализировать, что конкретно влияет на инструкцию SQL, начиная с плана выполнения. План выполнения выбирается оптимизатором при синтаксическом анализе оператора, он - обратно к аналогии с пищей, это рецепт, который используется для разрешения оператора SQL.
И некоторые рецепты сложнее, чем другие, и поэтому мы предоставляем результаты. И здесь на самом деле будет показано, эй, много времени он выполняет последовательный ввод-вывод по определенному индексу. И посмотрите сейчас, когда, возвращаясь к кислороду, следуйте этому указателю. Был ли этот индекс недавно дефрагментирован, каково его здоровье? В каком табличном пространстве оно живет? Является ли табличное пространство отдельным от таблицы, на которую оно ссылается? И поэтому он начинает давать вам всевозможные идеи о том, как вы можете решить проблему. Теперь, очевидно, вы знаете, мы строим индекс. Это намного менее рискованно, намного проще, чем, возможно, перемещение индекса из одного табличного пространства в другое табличное пространство, поэтому мы хотим сделать несколько вариантов построения, чтобы мы могли развернуть вариант с наименьшей стоимостью и наименьшим риском решить проблему.
Precise также может выполнять такие вещи, как захват переменных связывания, которые приводятся к выражению SQL. Очевидно, что приведенные переменные будут управлять размером набора результатов. И он будет контролировать, сколько времени потребуется для выполнения этого оператора SQL и сколько данных должно быть передано и обработано приложением через Java, через .NET, в веб-сервер и сеть, наконец, отображаемую в браузере конечного пользователя., То, что происходит в базе данных, напрямую влияет на время браузера. И поэтому будет крайне важно иметь такой уровень видимости, чтобы мы могли точно знать, что происходит, и предоставить АБД максимальное количество опций, чтобы они могли выбирать, какой из них наиболее целесообразен, с учетом конкретной ситуации.
Вот некоторые из этих цитат, и они принадлежат магазину PeopleSoft, имеющему глобальное развертывание. Precise поддерживает PeopleSoft и SAP, Siebel, Oracle, E-Business Suite, доморощенные приложения Java и .NET. Мы поддерживаем, поэтому, если вы делаете вызовы веб-сервисов для нескольких JVM, от Java до .NET и обратно на Java, мы можем отслеживать все это. Это может быть накануне, это может быть в облаке. Главное, что вещи должны быть оснащены инструментами.
Итак, всего пара цитат одного из наших клиентов: «До Precise наши администраторы баз данных использовали OEM», - это инструмент только для баз данных, и они в основном говорили: «Эй, экземпляры выглядят великолепно». Но они могли помогите рассказать или решить проблему с конкретной транзакцией. Точно обеспечил видимость, чтобы сделать это. И поэтому наличие этой информации об операторах SQL было критически важным для предоставления администраторам баз данных возможности полностью выжать производительность из базы данных. И это было действительно приятно. Вид выше и вне некоторых инструментов, которые вы, возможно, смотрите.
А затем ИТ-менеджменту очень понравился тот факт, что Precise смог перевести сложный URL-адрес в имя панели. И таким образом, если конечный пользователь звонит и говорит: «Эй, у меня проблемы с этим», вы можете изолировать и посмотреть, кто этот пользователь, что он выполняет, какую производительность, они фактически измеряют рендеринг. время в браузере конечного пользователя. Это истинная мера опыта конечного пользователя. И так же, наличие этого идентификатора пользователя абсолютно необходимо для помощи конкретному человеку, который звонит.
Как Precise делает это? И поэтому мы хотели бы поделиться своей архитектурой. Precise должен жить на своем собственном сервере, и жить на виртуальной машине, он может жить в облаке. С другой стороны, Precise поддерживает веб, независимо от того, используете ли вы инструментальные панели, интерфейс оповещения или экспертный графический интерфейс. Что касается сбора данных, мы можем фактически сделать безагентные для нескольких различных технологий. Однако часто нам требуется агент, и у агента есть свои плюсы и минусы. Большим плюсом является то, что собранные данные можно предварительно обработать перед отправкой по локальной сети. И это означает, что мы можем минимизировать общее влияние решения по мониторингу на целевую среду.
Теперь рассмотрим в качестве альтернативы, если у вас есть «безагентный», есть еще сборщик данных, это просто вопрос того, где он живет, и он делает звонки и передает необработанные данные о целевом приложении через вашу локальную сеть. И это на самом деле довольно дорого. И, таким образом, путем предварительной обработки мы можем минимизировать занимаемую площадь. Вы сможете контролировать как физическое, так и виртуальное. И одна вещь, которую я хотел сказать о виртуальных технологиях, заключается в том, что на самом деле основное внимание уделяется использованию. На чем акцентирует внимание Precise - это спор Когда технология VMware фактически минимизирует ресурсы вашей гостевой виртуальной машины? И так становится действительно легко. Если вы смотрите только на гостевую виртуальную машину, у вас есть только часть изображения. Возможность автоматически обнаруживать и предупреждать о конфликтах, это действительно важно.
Precise может отслеживать до 500 экземпляров, поэтому в очень крупных развертываниях в основном используется несколько серверов Precise. А для глобального развертывания обычно это будет сервер Precise в каждом центре обработки данных. Между прочим, для самых крупных развертываний вы можете объединить их вместе, чтобы вы могли смотреть на весь корпоративный процесс и предлагать отчеты и т. Д. Теперь, как я уже говорил, у нас много технической аналитики. Не всем нужно заходить в экспертный графический интерфейс, поэтому мы предлагаем настраиваемую панель инструментов. И каждый из этих портлетов или виджетов, они все необязательны. И кто-то может просто захотеть сказать: «Эй, как вы можете активировать оповещение на любом уровне в нашей среде? Как группы конечных пользователей работают с точки зрения производительности? »Или, возможно, у вас возникнет вопрос об инфраструктуре, возможно, даже о производительности Tuxedo. Или даже балансировка нагрузки. Это довольно интересно здесь, в этой части балансировки нагрузки. Я смотрю на портлет посередине с левой стороны. Вы можете видеть, что количество выполнений очень похоже между каждым из веб-серверов. Но время отклика сильно отличается на верхнем. На самом деле вы можете подробно изучить причину, по которой время отклика на этом веб-сервере было намного медленнее, чем на других.
Одна вещь о балансировке нагрузки, это очень важно, и политики балансировки нагрузки, вы знаете, не каждая политика балансировки нагрузки подходит для каждого приложения. На самом деле очень полезно проверить вашу политику балансировки нагрузки. На самом деле мы наблюдаем с некоторыми приложениями, такими как новый графический интерфейс PeopleSoft Fluid, где некоторые веб-серверы отключаются. И это то, что действительно важно. Если вы развертываете PeopleSoft Fluid GUI, пожалуйста, свяжитесь с нами. Мы можем предоставить вам много знаний и знаний о том, с чем столкнулись другие клиенты. Каждый из этих портлетов может быть довольно подробным. Как и в центре справа, с синим и зеленым, на самом деле показан образец кончика меча, он как бы показывает, что ваша сборка мусора на уровне WebLogic работает так, как вы ожидаете. Каждый из этих портлетов может быть очень сфокусированным или иметь очень высокий уровень. И причина того, что это важно или может быть важно, часто заключается в том, что недостаточно просто иметь эту информацию в ИТ, иногда вам приходится делиться этой информацией с владельцами приложений, а иногда с высшим руководством, о том, что происходит.,
Я хотел поделиться с вами несколькими историями, вроде «Успех в центре обработки данных». И они ориентированы на базу данных, и у меня есть другие истории, которые ориентированы на средний уровень. Но на сегодня я действительно хочу сосредоточиться на уровне базы данных. Давайте посмотрим на зависания экрана. Теперь, что здесь произошло, это то, что в этом конкретном магазине был бизнес-SLA, и если заказ получен к 15:00, заказ будет отправлен в тот же день. И поэтому склад очень занят в этот период времени. А потом с получением зависаний экрана это было очень сложно. И поэтому руководитель - это небольшая компания - руководитель фактически вошел в ИТ и, конечно, подошел к администратору базы данных и сказал: «Теперь, что происходит?» И так, что мы сделали, мы смогли показать точно что происходило. Теперь это JD Edwards, многоуровневое приложение, это экран заказа на продажу. Вы можете получить представление о том, чем занимался бизнес, как правило, о своевременной инвентаризации, и поэтому вы в основном смотрите на складские приложения. И теперь вы в основном отправляете товары на различные сайты клиентов, в разные магазины. И то, что мы сделали, мы открыли Precise.
Теперь в этом случае, прежде чем мы взглянули на Oracle, здесь мы смотрим на SQL Server, и теперь верхняя половина показывает нам гистограмму, на которой операторы SQL проводят свое время при выполнении. Каждое слабое состояние учитывается по оси Y. Ось X, если, конечно, во времени, и вы можете видеть, что столбчатая диаграмма с накоплением изменяется от временного интервала в зависимости от того, что выполняется и как она использует систему. Теперь в данном конкретном случае мы сосредоточились на третьей последовательности SQL сверху. Это текст SELECT FROM PS_PROD, и вы можете увидеть в этом столбце, что мы зафиксировали фактический план выполнения. И вы можете видеть по всему количеству казней. Тот факт, что этот конкретный оператор SQL был ответственен за 9, 77 процента потребления ресурсов в течение этого периода времени, который мы рассматриваем - и это важный момент, период времени, Precise хранит скользящую историю - и поэтому я могу в основном набрать номер и выяснить, что произошло в любой конкретный момент времени или со временем. Я могу просматривать тренды.
Теперь этот оператор SQL, вы видите там гистограмму с накоплением, она темно-синего цвета. Это говорит о том, что мы используем весь процессор. Давайте продолжим и сосредоточимся, нажав эту кнопку «TUNE» на данном конкретном операторе SQL. Что мы делаем, так это то, что мы принимаем это на этом семинаре, готовом семинаре, который предназначен для того, чтобы сказать: «Ну, что администратор базы данных узнает об этом конкретном операторе SQL?». И вы видите, что справа есть вкладка под названием « История », которая была выбрана. И то, что я хотел бы, чтобы вы сделали сейчас, это своего рода сдвиг влево, где написано «Изменения в сравнении с средней длительностью», средней продолжительностью. И каждый из этих столбцов представляет события в день.
Вы можете видеть в среду, четверг, пятницу, время выполнения было, я собираюсь округлить до пункта два. Ось Y показывает точку четыре секунды, поэтому точка две. Очень мало зависаний экрана, операции в SLA идут отлично. К сожалению, 27 февраля план исполнения изменился, что привело к немедленному изменению времени исполнения. Внезапно время выполнения увеличивается, четыре X, может быть пять X, и все работает очень плохо. Теперь Precise в своем репозитории фактически регистрирует все изменения, которые могут повлиять на поведение. И вы можете видеть здесь, что мы фактически зафиксировали изменения плоскости оси. Один посередине говорит: «Изменен объем таблицы». Таким образом, таблицы растут, и мы находимся на пороге, когда синтаксический оператор SQL анализируется, оптимизатор выбирает один план выполнения или другой план выполнения.
Теперь, к счастью, на этой неделе здесь, в понедельник, он перевернулся, так что это было хорошее время. К сожалению, он снова переворачивается, и вы знаете, что, конечные пользователи начинают ожидать зависания экрана, и они начинают повторную передачу этого экрана, и они увеличивают счетчик выполнения вверх и вверх и вверх. У нас есть огромное количество деталей, но чтобы решить эту проблему, а затем избежать ее в будущем, нам понадобится еще одна дополнительная информация. И это показано мне при сравнении этих планов выполнения. 5 марта, когда он был быстрым и эффективным, слева показывается план выполнения. Когда 12 марта он был медленным и неэффективным, вы можете видеть, что он выполняет фильтрацию. Объединение фильтра просто требует гораздо больше ресурсов процессора и делает гораздо больше работы. Результат идентичен, он просто делает намного больше работы. Это похоже на то, как вы идете и получаете свои материалы по одному ингредиенту за раз, а не идете в кладовку и получаете все ингредиенты одновременно. Таким образом, существует более эффективный способ сделать это. Теперь, как правило, зная это, администратор баз данных мог использовать план запросов, чтобы избежать этого плана медленного выполнения и зафиксировать высокую производительность.
Теперь следующая история войны была «Отчеты опаздывают». Я думаю, что многие люди могут идентифицировать себя с этим сценарием. У вас могут быть специальные отчеты, вы можете использовать такой инструмент, как NVISION, у вас может быть какой-то сторонний инструмент для отчетов. И что происходит, инструмент развивает SQL. И часто SQL не очень хорошо написан. И это также может относиться к ситуации, когда, вы знаете, у вас есть какое-то стороннее приложение, верно, где SQL не был написан собственными силами, и поэтому как администратор БД: «Я не контролирую SQL, что я собираюсь с этим поделать? ». Хорошо, Precise предоставляет кое-что, чего я не знаю ни о каком другом инструменте для работы с базами данных, и это представление объекта. В сочетании с рекомендациями и моделированием. Итак, что мы можем сделать, так это перевернуть видимость с ног на голову. Вместо того, чтобы просто посмотреть на активность, давайте выясним, какой объект является самым тяжелым в системе? В виде нижней части экрана вы видите строку заказа SQL и столбец «в MS-SQL». И таблица строки заказа примерно в десять раз больше, чем любая другая таблица в системе. Я думаю, что вы также заметите в верхней половине, распределение пространства растет, и вы также можете посмотреть спецификации сервера, какую версию программного обеспечения мы используем. Precise фактически проверит отслеживаемые изменения основных настроек. Еще раз, причина и следствие.
Теперь, сосредоточившись на таблице строк заказа, я могу сопоставить операторы SQL, которые идут с таблицей строк заказа, с моим подробным историческим репозиторием. И вы можете начать смотреть на предложение where в этих операторах SQL. И вы начинаете замечать, что предложение where довольно сильно отличается между различными операторами SQL. И я хотел бы предложить вам, что в вашей системе записи вы найдете то же самое. Поскольку бизнес-пользователи, бизнес-аналитики собираются делать такие вещи, как совокупная деловая активность за последний день, последнюю неделю, последний месяц, последний квартал, прошлый год. Вы увидите очень похожие выражения, порядок, порядок, группировка, и это означает, что будут определенные индексы, которые имеют смысл для этих операторов SQL.
Итак, у Precise есть механизм рекомендаций, вы можете увидеть это в правом верхнем углу, и мы можем получить рекомендации. Скажите: «Эй, я выполняю все операторы SQL, какие индексы будут к ним обращаться?». Индексы представлены вам, и вы действительно можете увидеть DBL. Теперь Precise доступен только для чтения, он не дает возможности нажать кнопку и создать индекс, но это достаточно просто сделать вне Precise. Но здесь важно то, что Precise позволяет оценивать и моделировать изменения, поэтому в левом нижнем углу экрана есть эта кнопка Evaluate. И что он делает, это показывает операторы SQL в до и после.
Давайте посмотрим на эти операторы SQL. Вы видите здесь этот столбец с надписью «в MS-SQL» и один час четыре минуты? Эти главные операторы SQL выполняются или потребляют около 64 минут ресурсов. И его прогнозируемое улучшение составляет 98 процентов. Эти изменения позволят сэкономить часы обработки. Следующий оператор SQL занимает 27 минут и в основном сэкономит третье. Это около десяти минут обработки. Суммируя вместе, вы фактически сэкономите часы и часы на обработку этих предложенных изменений. И поэтому возможность знать это заранее, быть способным моделировать это. Вы также можете использовать возможность «что, если», чтобы сказать: «Ну, я не хочу делать этот индекс, или что произойдет, если я изменю порядок столбца?» И поэтому я могу использовать эту возможность моделирования чтобы выяснить, что именно будет происходить.
Другая важная вещь заключается в том, что когда я делаю изменения, я могу фактически измерять отдельные операторы SQL. Вы видели историю операторов SQL в предыдущем примере, и я действительно могу проверить, достигла ли я экономии, которая была смоделирована. И так, что обратная связь, завершение обратной связи, абсолютно необходима.
Хорошо, вот последний пример, который я собирался иметь для вас. Это магазин SAP, и вы знаете, они пошли на серьезное обновление, они делали некоторые вещи с пользовательскими транзакциями, и в основном конечный пользователь был недоволен производительностью. Итак, мы смогли сосредоточиться на том, что испытал этот конечный пользователь. И вы можете увидеть в верхней части списка «ВЫБОР», и время отклика составляет чуть более 61 секунды. Эта вещь занимает минуту, чтобы выполнить. Теперь вы можете видеть, что у нас есть гистограмма, ориентированная на SAP. В правой части он показывает время клиента, время ожидания. Синим цветом обозначено время приложения, а в среде SAP это код ABAP, а затем база данных. Итак, база данных, вы знаете, это может быть Oracle, это может быть SQL, это может быть HANA. Мы в принципе можем показать это.
Теперь, что мы делаем с Precise, мы фокусируем для этой транзакции и этого пользователя на том, какие SQL-операторы выходили. Еще раз, этот контекст, чтобы соединить точки. Теперь этот главный оператор SQL, вы можете видеть, что он обведен кружком, он выполняется за две миллисекунды. Вы действительно не можете винить базу данных, если она выполняется так быстро. Количество казней очень велико. На самом деле мы можем вернуться к кодировщику ABAP и сказать: «Эй, что происходит?» Мы на самом деле обнаружили, что код в базе данных был размещен не в том месте, вложен не в то место в цикле, сделал изменить, а затем мы можем измерить после. Вы действительно можете увидеть, что после спектакля. Не только на уровне оператора SQL, но и на уровне пользовательского кода. И поэтому они могли жить со временем исполнения четыре с половиной секунды. Итак, это всего лишь пара примеров того, как Precise может быть использован, вы можете использовать его. Точно так же, как быстрый обзор, Precise показывает производительность по местоположению, по идентификатору конечного пользователя, он обеспечивает контекст через стек приложений. Вы можете углубиться в основную причину. И я думаю, что один из главных отличий заключается в том, чтобы иметь возможность знать не только оператор SQL, но и почему оператор SQL работает медленно, а также уметь выявлять конфликты и предлагать больше вариантов решения проблем. Это то, что может предложить Precise, и вы можете потреблять нас, вы знаете, легким способом или, если у вас есть очень глубокие, очень сложные проблемы, мы также любим их решать.
Эрик Кавана: Хорошо, я должен сказать, что это было много фантастических деталей, Билл. Спасибо за показ всех этих скриншотов. И с моей точки зрения, вы действительно выполнили то, что я как бы объяснял в самый разгар часа, а именно, номер один, вам нужен правильный инструмент. У вас должен быть инструмент, который позволяет вам определить контекст, необходимый для идентификации всех элементов уравнения, как когда-то сказал один из фильмов, это было довольно забавно. Но позвольте мне пойти дальше и передать его Дезу, потому что, держу пари, у него есть к вам несколько вопросов, и я хочу отодвинуть еще один из этих слайдов просто для визуальной конфетки, если хотите. Я на самом деле, подожди, позволь мне взять это обратно. Но Дез, я уверен, что у тебя есть вопросы, убери их.
Дез Бланчфилд: Да, вау. Этот инструмент прошел долгий путь с тех пор, как я изначально знал его, и я не знал, что вы на самом деле так глубоко погрузились в стек. Это просто ошеломляет. Просто очень быстро, пара вещей. Модель развертывания, вы можете просто очень быстро, за минуту или две, просто наметить традиционную или типичную модель развертывания. Вы упомянули, что это было доступно как виртуальная машина. Это может быть запущено в облаке. И я предполагаю, что один из вопросов, который, вероятно, возникнет, и я думаю, что в разделе вопросов и ответов была пара вопросов. Вкратце, приведем их кратко. Итак, обычная модель развертывания и требуемый тип оси. Традиционно она развертывается локально, размещается или в облаке? Какие типы моделей развертывания вы обычно видите? И какой тип оси требуется, чтобы заставить это работать? Должны ли мы что-то менять на уровне безопасности в отношении доступа к сети и т. Д.? Или это может вести себя как конечный пользователь?
Билл Эллис: Да, так что в настоящее время большинство инсталляций происходит на месте. Все больше и больше людей помещают компоненты стека приложений в облако, и мы можем справиться и с этим. При развертывании нам нужен сервер для запуска, он будет соответствовать определенным спецификациям. Нам нужна база данных для хранения исторического хранилища, поэтому выполнение этих предварительных условий является своего рода первым шагом. Следующим шагом является то, что нам определенно необходимо иметь некоторые знания о самом приложении, и установка осуществляется с помощью мастера и в основном заполняет пробелы. Из-за глубины информации, которую мы получаем, вы знаете, от уровня веб-процесса до кода, который выполняется, нам нужны некоторые привилегии. Я должен сказать, что у нас есть защищенная модель данных или модель безопасности, потому что агенты работают с учетными данными, которые полностью отделены от людей, которые используют метаданные о транзакциях и т. Д.? Precise взаимодействует через TCP по IP, поэтому мы требуем, чтобы определенные порты были открыты. В качестве быстрого примера, например, наш порт по умолчанию - 2702. Этот тип подробного материала - это то, что, если людям интересно, мы могли бы вникнуть в него более подробно. Но обычно мы очень быстро оцениваем стоимость. Если кто-то сталкивается с большой проблемой, мы часто можем установить его и пролить яркий свет на ситуацию за считанные часы.
Дез Бланчфилд: Да, я тоже это чувствую. В модели развертывания вы говорили об очень крупном масштабе и до 500 экземпляров и о том, как это можно объединить. На самом начальном уровне, на что это похоже, если кто-то захочет - потому что я знаю, что IDERA очень хорошо предоставляет доступ к бесплатным пробным версиям, бесплатным демонстрациям, и я помню, что на веб-сайте почти все можно играть. Для людей здесь, и я думаю, что я пропустил это раньше, но я думаю, что возник вопрос, как выглядит типичный сайт и как люди получают доступ к этому и начинают играть с ним и получать этот тип опыта, где они могут увидеть, есть ли у них способ решить некоторые проблемы с производительностью? Могут ли они загрузить ODS и развернуть его на своем гипервизоре, Hyper-V или ноутбуке, или им нужен выделенный компьютер для его запуска? Вы обрисовали архитектуру раньше, но очень кратко, через минуту или две, как это выглядит для развертывания начального уровня просто для подтверждения концепции, например?
Билл Эллис: Да, наша модель немного отличается от инструментов IDERA. Мы в большей степени вписываемся в сценарий Embarcadero, где вы хотели бы связаться с одним из наших торговых представителей. Мы хотели бы просто обсудить с вами, какие проблемы существуют, и тогда мы, как вы знаете, обычно назначаете одну из SE, и в основном работаете с кем-то через установку. Обычно вы не запускаете Precise на своем ноутбуке. Вы бы хотели иметь виртуальную машину или сервер в центре обработки данных, где живет приложение, для выполнения коллекций. Но мы поможем вам на каждом этапе этого. Если кто-то заинтересован в этом, вы определенно хотите связаться с IDERA.
Дез Бланчфилд: Еще одна вещь, которая меня поразила, это то, что я имею в виду, что многое из того, что мы рассмотрели сегодня, касается реакции на проблемы с производительностью. Но мне показалось, что в реальных условиях, когда люди их используют, в качестве первого слайд-шоу кто-то поднимает трубку и говорит: «Приложение работает медленно, помогите». Но меня поразило, что во время предварительного выпуска приложений или Обновления или новые исправления и исправления позволят вам провести комплексное планирование емкости и стресс-тестирование, а также Precise проанализировать всю среду и фактически обнаружить проблемы, прежде чем вы даже введете в среду конечных пользователей. Это тот случай использования, который вы видели раньше, или люди тоже это делают, или это не типичный вариант использования?
Билл Эллис: Безусловно, мы хотели бы использовать Precise на протяжении всего жизненного цикла разработки приложения или жизненного цикла обновления. Precise предлагает представление масштабируемости, оно покажет количество выполнений, накладываемое на время отклика. Очевидно, что если количество выполнений и время отклика растут вместе, вы не масштабируете и вам нужно что-то делать. Подобные вещи очень помогли. Я думаю, что сейчас это немного менее верно, но когда люди начали помещать производственные приложения в VMware, они немного колебались, и это было похоже на, вы знаете, первое, на что они будут похожи: «О, нам нужно перенести это на на самом деле ». И что мы действительно можем сделать, это показать, каково потребление ресурсов, чтобы вы могли сделать приложение более эффективным. На каждом этапе жизненного цикла приложения вы определенно хотите использовать Precise. Но я должен сказать, что на самом деле производительность - это то, где производительность важнее всего, и Precise ориентирован на круглосуточный мониторинг производства, поэтому вы действительно не хотите запускать свои производственные приложения без наглядности.
Дез Бланчфилд: Абсолютно. Еще один быстрый вопрос, касающийся спецификаций - тестирование глубины, иммиграция, UAT и т. Д. - я имею в виду, это здорово, когда есть этот инструмент, и я полагаю, что разработчики приложений очень хотели бы иметь доступ к нему в течение жизненных циклов жизненного цикла разработки., С более сложными архитектурами, которые вы видите сейчас, мы перешли от выделенного сервиса к виртуализации и виртуализации, теперь мы переходим к своего рода переходу от аутсорсинга к облачному хостингу, и мы также наблюдаем переход для контейнеризации. Видели ли вы, что многие люди применяют это и моделируют те или иные регионы или зоны, чтобы кто-то мог - и в Австралии у нас очень большая проблема с конфиденциальностью, и я знаю, что в Европе это то же самое, и я думаю, что это становится все более значимым в США, где данные, которые могут идентифицировать меня лично, часто должны находиться в более защищенной среде, чем на реальном прикладном уровне и на веб-уровне. Итак, сейчас у нас есть эти развертывания, где люди могут хранить свои базы данных и свои приложения для внутреннего использования, но они могут поместить свой веб-уровень и конечную точку доставки, а также приложение и т. Д. В облачного провайдера, такого как Azure или, или Amazon Web Services и программное обеспечение., Как это работает с вашим обычным развертыванием? Это тот случай, когда у вас есть еще один набор коллекционеров в регионе, и они просто собирают еще немного? Как это выглядит в мире Precise в сегодняшнем бимодальном подходе к запуску ИТ старых устаревших вещей в одном месте, а ваши товары иногда находятся в облаке?
Билл Эллис: Да, поэтому мы поддерживаем смешанную среду. Следует учитывать, что существуют разные контракты с облачными провайдерами. Некоторые из них не позволят какой-либо агент или какой-либо внешний мониторинг в облаке. Для установки и мониторинга Precise вам необходимо иметь тип контракта, который разрешает этот тип доступа. Определенно существуют некоторые ограничения, через которые нам иногда приходится работать, и поэтому это важный вид критериев, которые вы учитываете, когда, я полагаю, вы сначала подписываете эти контракты, а затем и / или если вам необходимо развернуть Precise.
Дез Бланчфилд: Да, я видел несколько случаев, когда даже с традиционной средой баз данных, если вы приобретаете ее как часть службы, особенно с подобными Azure, так как вы приобретаете подобные HDInsight или SQL как Сервис, как платформа, ваши обычные инструменты могут погружаться только так глубоко, потому что вам не очень интересно смотреть на то, что находится под капотом. Таким образом, вы в конечном итоге получаете определенный уровень или глубину, которую вы можете отслеживать, и внезапно вы просто не можете видеть за волшебным занавесом. Это самообслуживание вещь? Является ли это традиционно чем-то, что запускается внутри сетевого операционного центра, где техническая группа, сотрудники ИТ-отдела, получают доступ только к нему, или же вы также можете обеспечить такой уровень доступа для конечных пользователей? Может быть, это не обязательно стойка администратора и традиционные сотрудники отдела кадров и финансов, но и более опытные пользователи, которые занимаются этим, вы знаете, как, например, исследователи данных, актуарии, статистики, люди, которые выполняют действительно тяжелую работу. Является ли это случаем, что они могут получить доступ к некоторому виду доступа к самообслуживанию, чтобы увидеть, что происходит, когда они выполняют эти тяжелые запросы и где возникает боль, чтобы они могли как-то настроить свою рабочую нагрузку?
Билл Эллис: В Precise очень хорошая безопасность, поэтому вы можете настроить пользователей с разными уровнями доступа. На самых базовых уровнях только информационные панели обеспечивают контроль. А потом, знаете ли, если кто-то захочет войти в Expert GUI, вы можете ограничить то, что он может видеть и что он может делать. И вроде бы возвращаюсь к вашему предыдущему вопросу о том, что, как вы знаете, в сфере здравоохранения у вас есть все законы HIPAA, и поэтому есть определенные соображения, и на самом деле есть некоторые варианты развертывания, чтобы мы могли работать с ними в обеих средах. С данными, которые вы видели в этой презентации, следует обратить внимание на то, что это все метаданные о производительности, а не о содержании таблиц, вы знаете, и поэтому на самом деле, в эти типы вопросы конфиденциальности.
Дез Бланчфилд: Да, мне это понравилось. У меня был момент Эврики о вашем четвертом или пятом слайде снимков экрана, и я понял, что вы просто повышаете производительность, ну не просто, но вы извлекаете данные о производительности, вы вытаскиваете вещи, как вы сказали, из метаданных из различные уровни стека, вы на самом деле не смотрите на контент. И я думаю, что это интересная вещь, потому что это один из тех инструментов, где вы можете либо развернуть его на короткий срок и посмотреть, что происходит в среде, но вам не нужно иметь доступ к самим данным. Вы даже можете посмотреть, как работают экипажи. Последнее, я думаю, просто быстро, а затем я вернусь к Эрику, так что если у вас есть вопрос, то попросите Ребекку закончить, вы упомянули ранее, что накладные расходы являются номинальными, это тот случай, когда это даже заметные накладные расходы со стороны мониторинга и просто наблюдение за фоном или это настолько незначительные накладные расходы, что их просто не стоит рассматривать?
Билл Эллис: Да, я думаю, что на уровне базы данных, вы знаете, каждая технология немного отличается. На уровне базы данных Precise, как известно, побеждает самые низкие издержки. На среднем уровне, вы знаете, есть своего рода балансирование, вы знаете, это не просто Точный, он применяется ко всем, с точки зрения видимости и накладных расходов. И вот одна из вещей, которые мы предлагаем, это ряд сложных инструментов для контроля над издержками. Мы созданы для производства, и, вы знаете, определенно полезно пресечь столько проблем в области разработки и контроля качества, но, знаете, нет ничего лучше, чем знать, что происходит в производстве.
Дез Бланчфилд: Эрик, к тебе, у тебя есть последние вопросы?
Эрик Кавана: Да, я просто скажу, что я думаю, что вы проделали большую работу, указав, что контекст действительно является ключом, и почти как если бы мы приближались к этой эре интернета вещей, вы хотите, чтобы все инструктировали. И я думаю, что стандарт сейчас на производстве - это делать, что является хорошей новостью, верно? Потому что вы хотите иметь возможность извлекать информацию из всех этих различных сред и объединять ее воедино. И я думаю, я просто передам это вам для некоторых последующих комментариев, хотя. Это то, на чем вы, ребята, сосредоточены, - это предоставление визуального интерфейса, с помощью которого какой-то аналитик, в основном ИТ-аналитик, может отслеживать и анализировать то, что происходит в этой сложной среде, а затем выяснять, что нужно изменить. Потому что это не просто инструмент. У вас должен быть инструмент, но вам нужен тот человек, который собирается разобраться в этой детали и найти ответы, верно?
Билл Эллис: Да, я как бы вижу, что это вскипает до вершины и расставляет приоритеты, где самый большой выкуп, понимаете? Если окажется, что это другая ситуация, потому что не все проблемы в базе данных. Если база данных работает, вы знаете, все выполняется за одну десятую секунды, но на уровне приложений это занимает три секунды, и именно в этом и заключается обратный выкуп. И, таким образом, возможность выделить уровень проблемы и то, что происходит внутри уровня, чтобы действительно сосредоточиться на том, где происходит обратный выкуп. Это действительно ускоряет разрешение и оптимизацию приложения, и это намного быстрее, намного лучше и намного веселее, чем люди собрались в конференц-зале: «Ну, это не я, это должен быть кто-то другой».
Эрик Кавана: Это верно. На днях я увидел замечательного мема, который сказал что-то вроде: «Будь информированным, а не просто самоуверенным». Вы идете на встречу, у вас есть информация, вы можете указать на данные. Это ключ, и мы добираемся туда, слава богу. Ладно, ребята, мы собираемся подвести итоги, но мы архивируем все эти веб-трансляции для последующего просмотра. Не стесняйтесь проверить это в любое время. Сейчас мы перечислим все наши веб-трансляции, серию Hot Tech и серию Briefing Room на Techopedia.com, так что прыгайте онлайн и посмотрите на них. После этого мы прощаемся с вами. Спасибо за ваше время сегодня, Билл. Спасибо тебе и всей твоей тяжелой работе, Дез. И мы поговорим с вами в следующий раз, ребята. Береги себя. Пока-пока.
