От персонала на Техопедия, 31 август 2016 г.
Отнемане: Домакинът Ребека Джозвяк обсъжда проблемите с отстраняването на неизправности в базата данни и проблемите с ефективността с анализаторите Ерик Кавана и Дез Бланчфийлд, както и Бил Елис от IDERA.
В момента не сте влезли. Моля, влезте или се регистрирайте, за да видите видеото.
Rebecca Jozwiak: Дами и господа, здравей, и добре дошли в горещите технологии на 2016 г. Днешната тема е „Приложението работи бавно? Време е да получите точност“. И не знаем ли всички прекалено добре проблемите, които могат да възникнат, когато нещата вървят бавно? Това е Ребека Джозвяк, аз попълвам Ерик, който днес е нещо като нова роля. Да, тази година е гореща и, нали знаете, що се отнася до технологиите, както казах, единственото нещо, което наистина не искате, е бавно работа на каквато и да е част от вашата система. И само за да използвате потребителски пример, искам да кажа, че ако имате ресторант, няма значение колко страхотна е храната, ако услугата е бавна, вероятно няма да свършите обратно. Сега е лесно, някак си, в ресторант да разберем защо нещо върви бавно. Може би кухнята е с къс персонал или е имало неизправност с някакво оборудване, или може би служителите на чакащите са малко мързеливи и е лесно да се идентифицират и да се поправят.
Но когато мислите за център за данни, това е съвсем различна история. Това може да е проблем с мрежата, лоша заявка, която заглушава нещата, производителността на приложението или дефектен кабел, дори може да причини някои проблеми. А отстраняването на проблеми с този тип сложност може да бъде, в най-добрия случай, трудно. За това ще говорим днес. И както казах, Ерик Кавана влезе като анализатор днес. Имаме Дез Бланчфийлд наш учен по данни и имаме Бил Елис от IDERA, който ще говори за решението на неговата компания, което помага при управлението на производителността на приложенията. И с това ще предам топката на Ерик. Ерик, пода е твой.
Ерик Кавана: Добре, звучи добре, хора. И всъщност това беше чудесна аналогия, защото вие говорихте за трудностите или лекотата, с които може да се извърши отстраняване на неизправности и стигате веднага до нея. Проблемите с производителността винаги са резултат от някакъв проблем, който е в мрежата. Искам да кажа, че може да бъде толкова просто, колкото старият хардуер например, но най-долният ред е всяка ситуация като тази, която изисква отстраняване на проблеми. За това днес ще говоря. И нека продължим напред и да скочим върху пързалките тук.
Тук идва проблем. Отстраняване на проблеми - забавно е за хората, които го харесват, това е готиното. Ако намерите някой, който обича да се занимава с отстраняване на проблеми, дръжте се за този човек, дайте им някои инструменти, за да свършите работата, защото наистина добри неща, ако можете да намерите някой, който може да стигне до дъното на нещо и да свърши нещата. Но най-важното е, че отстраняването на проблеми е проблематично и винаги е било и винаги ще бъде, и ако започнете да говорите за отстраняване на неизправности, това, което наистина получавате, е анализът на първопричината. Какво причинява проблема?
Е, ако просто седнете и мислите за секунда дори за дните на мейнфрейм, можеха да възникнат всякакви проблеми. И тогава трябваше да имаш хора, които наистина знаеха техните неща, защото нямаше дори добри инструменти за отстраняване на проблеми, така че наистина трябваше да знаеш командния си ред и ще говорим за това след секунда. И всъщност забравих да сложа един от любимите ми слайдове, ще го потърся, докато сме на шоуто днес, може би по време на представянето на Dez. Но исках да покажа, за всеки, който не го е гледал, едно от най-смешните британски телевизионни предавания досега, то се нарича „IT Crowd.“ И по отношение на отстраняването на неизправности - ирландецът, който е един от двамата ИТ хора в цялата компания винаги казва едно и също нещо, когато започва всяко обаждане: „Опитали ли сте да го изключите и включите отново?“ Така че, опитайте да го изключите и включите отново. Ще се учудите колко често това просто нещо може да реши някои проблеми.
Тези от вас, които сте направили отстраняване на проблеми у дома, може би с родителите си или приятели, вероятно не с децата си, защото те са склонни да знаят какво да правят, изключете го и го включете отново. Но независимо от това, отстраняването на неизправности не е лесно, никога няма да е лесно, но днес ще поговорим за някои от нещата, които можете да направите, за да го улесните. И така, командният ред - да, наистина, аз съм достатъчно стар, за да си спомня първите дни на изчислението, когато всичко, което имахте, беше командният ред да направите DIR, Enter. Това е, което ще видите, директория с файлове и чувствате положително, че всъщност има някаква команда, нали? Дез, разбира се, нашият учен по данни, той знае как да използва командния ред. И ако можете да използвате командния ред, това е чудесно, защото повечето от нас простосмъртните използват някакъв GUI, графичен потребителски интерфейс, но винаги има нещо, винаги има някакво прекъсване между GUI и командния ред отдолу. И само за да ви дам случаен пример, ако искате да знаете колко код някои от основните програми навлизат в документите днес, влезте в най-новата версия на Microsoft Word, напишете „здравей свят“ и след това направете „запиши като HTML. “След това отворете получения документ в текстов редактор и вероятно ще видите страници и страници с тагове. Това се нарича разширяване на кода и разширяването на кода не е много добро за отстраняване на проблеми, а само за да бъде тъп.
Разбира се, клиент-сървърът идваше и това беше страхотно. И по някакъв начин ние се връщаме в тази посока, но просто помислете за сложността, която се появи със ситуацията, сега къде е проблемът, дали е на клиента, на сървъра ли е, мрежата ли е? Къде е? Какво може да се случи в тези сайтове, които просто мислят за вируси, и когато вирус може да влезе в такъв в мрежа. Може да отиде навсякъде. Нарушенията на данните са луди в наши дни. Те причиняват проблеми с изпълнението. Имали сме руски хакери, които можем да идентифицираме по IP адреса. Почти сме сигурни, че са руснаци, или са много близки, или са много умни украинци, полски или дори американци, използвайки прокси. Но през годините хакери навлизаме в нашия малък стар сайт, „Вътрешен анализ“ и причиняват всякакви проблеми. Нещата просто спират да работят, не можете да свършите нещата. Нещата, които са работили, не работят. Откъде знаеш? Откъде знаеш какво е? Точно като друг пример тук е много сложна среда, много е трудно да влезете в плевелите и наистина да разберете как се развиват нещата и работят за нас, особено ако получите цял куп приставки. Нещата могат да полудеят доста бързо. По някакъв начин изпреварвам себе си.
Хвърлих се тук, винаги внимавайте за надстройката. Надстройките винаги плашат дневните светлини от мен. Със сигурност операционни системи. Спомням си дните, когато Microsoft всъщност предполагаше, че да, можете да надстроите вашата операционна система от тази версия до тази версия. Е, опитах няколко пъти и това никога, никога не се получи. Само не забравяйте, че колкото по-голяма, толкова по-сложна е обстановката, толкова по-неудобна става ситуацията. И тогава има виртуализация. Помислете какво направи VMware с ИТ. Тя революционизира ИТ, но също така създаде този слой абстракции. Ако имате абстракция на слой на това основополагащо ниво, това е съвсем нова игра с топка, това е съвсем нова топка от восък и наистина трябва да преоцените какво правите и всички стари инструменти трябваше да се променят. И сега, разбира се, това е облакът, нали? За клиента облакът е страхотен, тъй като е много прост, потребителският интерфейс е доста лесен, но разбира се, всъщност нямате много контрол върху облака. Но за хората, които са зад кулисите, има много неща, които те трябва да знаят и разбират в наши дни. Средата стана много, много по-сложна. И със сигурност с електронната търговия и мислите за всички пари, които търгуват ръцете в наши дни. Ето защо скоро няма да ме намерите в полза на безкасово общество. Изводът тук е, че ситуацията става все по-проблемна с всеки изминал ден.
И поддържането на оптимална ефективност винаги включва някакъв елемент на отстраняване на проблеми. Не ме интересува какво ви казва някой, няма перфектен инструмент, няма сребърен куршум и никога няма да го има, защото - в друга интересна гледна точка тук - все още се учим да говорим силиций. Все още се учим да разбираме как функционират дори мрежите на ниско зърнесто ниво. Ако погледнете софтуера за управление на системите, днес става доста добре. Но все пак гледате линии, които вървят нагоре и надолу и гледате репрезентации на реалността, ще отнеме човек, който знае какво се случва, за да се съчетаят заедно с уликите, които можете да се вгледате в оптимални инструменти, за да можете да разберете какво работи и какво не и е много опит и грешки, само за да е тъп. С това ще го предам на Дез Бланчфийлд и тогава ще чуем от Бил Елис от IDERA, който ще ни посрами с неговите знания. С това, Дез, отнеси го.
Дез Бланчфийлд: Ей, благодаря Ерик. Благодаря ти. Повели се чудесно в моята малка мъка. Моето заглавие „Performance Art“ мисля, че е изключително подходящо в контекста на това, за което си говорим днес, защото по много начини, когато мислим за пърформанс изкуството, мислим за танци и музика и други творчески неща. И честно казано по-често, отколкото не, ако решаваме проблеми и в много мащабни ИТ среди и бизнес системи наистина има елемент на изкуството и често черно изкуство, защото ситуацията в моя опит от около 25 и повече години е, че модерните стекове на приложения, много бързо увеличават сложността със скорост, която никога не сме виждали досега. И ние откровено се борим да поддържаме напредък и има организации като Uber например и каквото и да е, и екипът за развитие на Pokémon Go, искам да кажа, че те изживяват растеж и сложност и увеличаване на сложността със скорости, които са просто астрономически. Не са написани дори книги за това, защото не бяхме замислили това ниво на растеж. Моето мнение е, че основната дефиниция на стека на приложения се пречупи експоненциално и аз ще обясня защо смятам, че това е така, и след това ще доведе до предизвикателството, че моите добри приятели в IDERA изглежда имат решение за решаване,
Накратко, всички ги знаем, но само за да ги обобщим, знаете, в първите дни имахме това, което наричам, архитектура на приложения, версия 1.0. Това беше сървърен компютър, в случая мейнфреймът с куп терминали, беше сравнително лесно да се диагностицират проблеми, ако не виждате неща на терминала - можете да проследите кабела между терминала и след това сървърния компютър и това беше или нулев кабел, или конектор, или някакъв проблем, ако не беше свързан с терминала, и виждате нещата на екрана, беше доста лесно да разберете, че нещата, които причиняват проблемите, са в самата машина. И бавно бихте могли да диагностицирате къде в стека, който е от хардуера, чак до софтуерния слой и потребителския интерфейс. В това, което наричам версия 1.1, го направихме малко по-сложно. Поставяме устройства в средата, за да можем да поставим повече терминали. И те бяха някакво комуникационно устройство и често бяха мукси или мултиплексори и щяха или да преминат през специална линия или набирана линия и така да имате мейнфрейм на далечно място - това може да бъде междудържавно или международно - и някакво устройство свързан през SMA връзка или някаква WAN връзка и тези терминали все още работят по същия начин. Но имахте малко по-голяма сложност, защото трябваше да разберете дали проблемът е между терминалите и устройството comms или устройството comms и мейнфрейм. Но стекът остана сравнително подобен в мейнфрейм.
Версия 1.2, малко по-сложна отново, защото сега добавихме още устройства, добавихме принтери и други неща и ги групирахме, и мисля за челен процесор, който ще се справи с всички проблеми на устройствата локално, принтери и терминали и така нататък с мейнфрейм този отдалечен край. Малко по-голяма сложност. Но отново, постоянната тема на мейнфрейм бяха приложенията, работещи локално, така че решаването на проблеми остана доста сходно в стека на приложенията. И тогава хората с умения избягаха да подреждат проблемите с терминалите и принтерите и клъстерните контролери. Но след това усложнихме нещата и изградихме мрежи и изведнъж една и съща архитектура въвежда мрежов слой. Изведнъж имахме мрежов превключвател, а работните станции бяха доста по-сложни. И тази версия на архитектурата често разполагахме с приложения за графичен потребителски интерфейс на работната станция. Не само, че имахме сървър, изпълняващ стека на приложения, но имахме и още един стек от приложения, работещи локално, и разбира се същия основен модел устройства, свързващи се със сървър. След това направихме квантов скок към по-новия модел на това, което аз наричам 2.1, откъдето взехме този стек от приложения и го направихме много по-сложен, много по-труден за диагностициране. И ние представихме много повече устройства в предния край, в уеб браузъри и персонални компютри и мобилни устройства, и така нататък. И тук стека на приложенията след това започна да се потопи малко по-дълбоко в интеграцията като операционна система и хипервизор.
На това изображение тук отдясно имаме целият стек, включително мрежовата инфраструктура, сървърите за съхранение, виртуалните машини, операционната система и след това традиционните три нива на приложения за металообработка на база данни и т.н., в предната дясна дясна страна. Диагностицирането на проблеми с приложенията и проблемите с производителността на този модел просто стана много по-трудно. Има толкова много движещи се части и опитът да се пробие през този стек беше просто, знаете, стана кошмар и трябваше да включите допълнителни набори от умения и организация, за да се справите с това. Вече не беше само екипът ви за приложения, изведнъж сега имахте хора от инфраструктурата, разполагате с специалисти по бази данни, чисто работещи само върху бази данни и нищо друго - за разлика от системен програмист, който знаеше пътя им около базите данни. Сега имаме сценарий, при който ИТ отделите трябва да се справят със значително по-широка сложност „като услуга“ и това, когато светът просто се взриви и нашите предизвикателства за решаване на проблеми, преминаха от кошмар до просто нещо, което е почти нетърпимо по някакъв начин.
И това стана като решаващ мащаб, ние се опитваме да предоставяме услуги на. Версия 3 от това, което считам за стека на приложенията - въведе го като модел на услугата, където традиционният модел отляво, корпоративният ИТ стек, където всичко трябваше да се управлява в нашия край като потребител и доставчик на услуги - от база данни за сигурност на приложения, операционни системи, съхранение на услуги за виртуализация, мрежови центрове за данни - трябваше да управляваме всичко това, но имахме достъп до всичко това и така можем да мащабираме наборите си от възможности и технически умения и можехме да пробием право надолу през този стек и можехме да намерим нещата. Но тъй като инфраструктурното обслужване и услугата на платформата и моделът на софтуерната услуга се появиха, изведнъж достъпът ни до бек-енд инфраструктурата, достъпът ни до платформите и инструмента, от който доставихме услуги, бяха някак ни отнети. Тъй като започнахме да консумираме инфраструктурна услуга, ние наистина наистина разполагахме с първите четири части от операционната система, базата данни, стека на приложения за защита на околната среда и по-горе. Всичко под това беше черна магия. И става още по-интересно, когато преминете към услуга на платформата, защото също така просто управлявате стека на приложенията.
Когато стигнете до софтуер като услуга и традиционен модел за това е уеб поща или интернет банкиране, всичко, което имате, е достъп до уеб браузър, така че се опитвате да диагностицирате какво стои зад това, което е непоносимо, определено. И аз разбих това на часови зони, на слотове от време или области от време, ако желаете или поколения, в това от ляво на дясно, ние сме преминали от вид преди 2000-те и традиционния стек, до който имахме достъп към цялата среда и бихме могли да разгледаме това. Но с течение на времето ставаше все по-сложно. В началото на 2000-те до средата на 2000 г., до края на 2000 г. до днешния ден, където сме преминали от инфраструктурна услуга, обслужване на платформа, софтуерна услуга, до сега основно се отнасяме до бизнес услуга. И сложността се е увеличила драстично. Има толкова много повече движещи се части. Но наличието на умения става все по-трудно и все по-трудно да се възползваме. Намирането на хора с правилните комплекти умения с правилния достъп до правилните инструменти, за да влязат и да се гмуркат в този стек и да разберат къде работи нещо бавно. Това е моят лаптоп или моят десктоп, това ли е телефонът или таблетът ми, свързаност ли е над 3 или 4G, или моята специална връзка с ADSL, или ISDN каквото и да е? Или дори набиране на номера, въпреки че в наши дни това е все по-малко. Краят на уеб сървъра ли е нещо вътре в уеб сървъра? Това сървърът на приложения ли е? Има ли нещо около паметта и диска на процесора и мрежовата производителност вътре в сървъра за приложения? Базата данни работи ли там?
И можете да си представите, че рисувате много бързо тази картина на сложността, която започва да се разширява като нещо като голям взрив, на този непрекъснато увеличаващ се балон, който се опитваме да си прегърнем и да имаме умения да се гмурнем в и знанието и с какво да се разсече и раздърпа. И сега сме много в ерата, в която, знаете ли, човешките същества не могат да се справят с физическия мащаб, дори ако имате способността да раздърпате средата на базата данни и да раздърпате тази база данни и да се потопите в подробности в тази база данни. Броят на базите данни, които трябва да управлявате сега, бързо нараства. Сега всичко се захранва от база данни. Много малко приложения в наши дни не се захранват от база данни. И видовете бази данни също бързо нарастват. Това не е само традиционните бази данни SQL вече, понякога неговият SQL, понякога неговият не-SQL, понякога е графична база данни, понякога това е база данни с документи. И има всички тези различни видове функции, които имат тези различни видове бази данни и в резултат на това всяка от тях има различни предизвикателства за производителността и различни критерии за ефективност. Регистрирането на базите данни и базите данни на документи изпълняват много, много различно и изпълняват различна функция спрямо традиционната, съвместима с ACID, ANSI 92-съвместима SQL база данни. И видовете неща, които съхраняваме там.
Според мен сме в един момент, където - и мисля, че Ерик намеква за това - че човешките същества се надпреварват със сложността на това, което изграждаме, и скоростта, с която изграждаме, и ние сега сме в момента, в който единственият начин да управляваме тази инфраструктура и единственият начин да наблюдаваме и да задълбочаваме проблемите, пред които сме изправени, са инструментите и правилните видове инструменти. И тогава неизменно правилното поколение инструменти. Инструменти, които всъщност разбират back-end инфраструктурата. Вече не е наред, просто да хвърлите SQL монитор или SQL инструмент за заявки на нещо и да започнете да разделяте заявка и да видите какво я кара да работи. Всъщност се нуждаем от инструмент, който разбира формирането на заявките и подходящия начин за формиране на заявки, както и подходящите начини за заявки да говорят с инфраструктурата в задния край и как да се справят, докато правят това. И да погледнем времето на тези взаимодействия и реда, в който те се осъществяват.
И това е много по-сложно предизвикателство и това ме води до моята въпросителна за обсъждане, а това е, че тъй като сложността на пакетите от приложения, които разработваме, се увеличава, инструментите за ефективност и инструментите, които използваме за управление на тези, задължително се нуждаят за да станем все по-умни и много по-способни да гледат повече неща. Но също така много по-интелигентни в това, как се задълбочават в това, което работи в задния край и какво могат да открият за него и потенциално дори да се извършва някакъв вид анализи, за да се разбере, че взаимодействията и производителността се доставят и защо се изпълнява по-бавно или по-бързо.
И тогава с това ще премина към нашия скъп приятел от IDERA, Бил Елис, и ще видя какво има да каже днес за това как решават този въпрос. Бил, при теб.
Бил Елис: Добре. Казвам се Бил Елис и много ви благодаря. Ще говорим за това, че молбата ми работи бавно, време е да се получи Precision. Нека да видим какво може да направи Precision, продукт на IDERA и как може да ви помогне. Много пъти само разберете, че е имало проблем с производителността, защото краен потребител ви е извикал и това наистина е голям проблем сам по себе си. От всички в ИТ никой не знаеше, докато телефонът звънна. Следващият голям проблем е как да помогнем на този конкретен индивид и всъщност не е тривиален проблем. Има едно извличане от това. Това е над и отвъд този слайд, над и извън останалите. И искам да видите дали можете да го получите каквото е. Но както споменахме, приложение изисква, разчита на много различни технологии, стекът от приложения е висок и нараства. И много хора имат достъп до приложение чрез браузър и изненадващо има все повече и повече обработки, които се случват в браузъра с скриптове и т.н., и тогава разбира се, че имате мрежата, уеб сървъра, бизнес логическия код и базата данни. Това, което искам да вземете предвид, е, че всяка значима бизнес транзакция взаимодейства с базата данни, независимо дали това е отчитане на карти по време, търсене на инвентар, поръчка за покупка, базата данни се актуализира. И така базата данни става наистина основата на производителността. И базата данни разбира се може да се включи или да разчита на надолу по веригата за съхранение. Всяка от тези технологии е плътно свързана и може да види какво се случва. Трябва да знаете какво се случва, за да можете да измервате е критично важно.
Едно нещо, което откриваме е, че много от нашите клиенти имат инструмент и имат инструмент за всяка технология, но това, което те нямат, е контекст. И контекстът е в основата на възможността да свързвате точките между всеки ред в стека на приложенията, а това всъщност е сравнително просто. Преди имахме ограничение от дванадесет нива, но в основата си го променихме, имаме неограничени нива и поддържаме смесени среди, така че по принцип можем да бъдем изключително сложни с точно решение.
Сега на високо ниво това решаваме проблема и се фокусираме върху транзакцията, транзакцията на крайния потребител от щракване към диск, казва ни кои от тях работят бавно, кои консумират ресурси, но ключът е това - ние ви позволяваме да вземете и идентифицирате потребителя тяхното местоположение и не само цялото време на транзакцията, но и колко време се изразходва на всяка отделна стъпка. Времето е валутата на ефективността, а също така показва къде се изразходват ресурси. Не знаем отпред къде ще се намира проблемът, така че трябва да разполагаме с адекватни показатели и аналитика на всеки от нивата, за да можем да диагностицираме какъв е проблемът, къде може да е проблемът.
Сега, в днешната презентация, която ще се съсредоточа в тази област, искам да бъдете сигурни, че по принцип осигуряваме едно и също ниво на видимост на всяко ниво в стека на приложенията и решаващото нещо, това ли ще ни каже кой, какво, къде и след това тази част, това ще ни каже защо. И наистина това е изключително важно за решаването на проблеми, а не само да знаем за тях. Сега другото, което излезе много ясно в презентацията, беше, че това е невъзможно да се направи. Имате нужда от автоматизация. А автоматизацията означава, че сте сигнализирали, имате нещо, което ви казва, надяваме се пред общността на крайните потребители, че имате постоянна тенденция, изградено отклонение от предупреждението за тренд. И тогава ние също предлагаме линия в пясъка, вие всъщност нарушавате SLA. Сега предлагате много различна информация - не всеки трябва да консумира бюфета, някои хора просто искат да имат лека закуска, това е салата и така с това, че предлагаме портал, можем да качваме информация, просто се нуждае от конкретен потребител или нуждите на информацията от конкретна общност относно представянето. Приложението работи бавно, време е да получите Precision. Наистина ще се съсредоточим върху четири неща. Едното е местоположението, въвеждането на крайния потребител. За пореден път, този контекст, който свързва точките, и третата част от изследванията показват, че близо 90 процента проблеми с приложенията са в базата данни и така наистина е вид травестит, че повечето решения за производителност могат да ви кажат едно SQL изявление. Но те не ви казват защо това SQL изявление работи бавно.
И така, защо винаги е най-важното нещо, а Precision е отличен в показването защо, за всеки слой и в частност на базата данни, и просто да споделим малко за нашата матрица за поддръжка с вас, която поддържаме SQL Server, Sybase, DB2 и / или насипно състояние. Външният вид на решението е много подобен, така че ако разглеждате множество приложения, но малко по-различни архитектури. Информацията, която споделям тук, има външния вид и усещането, подходът, той е един и същ, независимо какви са основните технологии в употреба. Precision е активиран в мрежата. Влизаме, удостоверяваме Precision и с това влизаме и първото нещо, което бихме могли да искаме да разгледаме, е изпълнението по местоположение. И така всъщност можете да видите тук различните места, където хората всъщност имат достъп до екзекуциите си. Можете да видите дали някой е изоставил дадена страница, преди тя да се е представила напълно или има грешки.
Едно нещо при тези приложения е мрежата или разстоянието от сървъра за приложения наистина се различава. Тук е много лесно да видите, че има някакво ниво на мрежа. Виждам кога хората са заети и след това още нещо интересно, говорихме как има обработка в браузъра, всъщност забелязват, че някои от различните типове браузъри осигуряват по-добра среда за бърза обработка. И така знаейки дали хората имат достъп чрез Chrome или IE, или каквото и да се случи, всъщност много често можете да откриете, че една инверсия от тип браузър всъщност е по-добра от друга. Сега, понякога сте публично изправени, не контролирате браузъра, понякога приложенията са вътрешни, където можете да препоръчате на хората тип браузър на вашата общност на крайния потребител и така това са видовете дълбоко видимост и аналитичност, които Прецизността е в състояние да осигури. Сега ние разглеждаме приложение.
Не съм сигурен дали можете да видите показалеца ми, но исках да ви опиша горната графика. Y-ос показва средно време за реакция. Оста x е време през ден. И всъщност има подредена бар графика и тази подредена бар графика, общата ви показва каква е производителността и след това тя показва подреждане на това колко време е прекарано във всяка отделна стъпка или всеки отделен слой на приложението. От клиента, през уеб сървъра, зеленото е Java, това място използваме Tuxedo и надолу в базата данни. Сега долната половина на екрана показва различните менюта в мрежата, до които се осъществява достъп, и след това сме разбрали само с малка зелена стрелка, сочеща надолу. Тя е в низходящ ред и балончетата нагоре, уеб менюто започва да го показва. Всъщност показваме времето за изпълнение, времето за реакция на всяка отделна технология и тогава всъщност има графична лента за всяко от тези уеб менюта и така получаваме, започваме да добиваме представа какво се случва. Сега не забравяйте, че сме сортирали всичко това с краен потребител, който би се обадил, но как да намеря крайния потребител? Влизам тук, отварям меню, което ми позволява да филтрирам върху конкретен потребител, така че зададох този потребител на Alex Net, щракнете върху OK и след това сме фокусирани само върху дейността от Alex Net. Това, което прави това, позволява ли ИТ и ИТ управлението да отговарят директно на крайния потребител и по-специално, че те разглеждаха управлението на съдържанието, което имаше шест изпълнения с време за реакция малко повече от три секунди. Ами три секунди е доста добре, не е ужасно, но е, може би е по-бавно.
Това, което мога да направя с това, е дали мога да нарязвам и нарязвам тази информация по различни начини. Мога да кажа, добре, бавна ли е тази транзакция за всички? Днес за Алекс ли е по-бавно, отколкото беше вчера? Бавно ли е за всеки потребител в определено местоположение? Или, и това, което прави, ми позволява да изреждам филийки и зарчета и да получа представа за случващото се, колко универсален е проблемът и е много важно да можем да идентифицираме крайния потребител, защото не става въпрос само за софтуера, инфраструктурата, става въпрос и за това как крайните потребители упражняват приложението. Често може да имате нов служител или някой с нова функция за работа, а те не са запознати с определени SAP екрани или определени панели PeopleSoft и им е необходим малък указател, може би те оставят полета празни или поставят скривалища и те ' принуждава големи резултати да бъдат върнати от базата данни. Но като имате идентификационния номер на потребителя, всъщност можете да им се обадите, преди да ви се обадят. Другото, което откриваме е, че след като общността на потребителите осъзнае, че ИТ знае какво правят, много пъти те се държат по-добре и много проблеми, много неща, които са били проблеми, просто вид се изпаряват, защото хората, които се държат, просто оперират малко по-внимателно. Те използват системата с по-голяма грижа.
Идентификацията на крайния потребител е от съществено значение. В крайна сметка е важно ИТ да може да помогне на конкретен краен потребител. Сега, това, което сме свършили тук, е отидохме в раздела „Поток“. Можете да видите това в горния ляв ъгъл. И ние се съсредоточихме върху един конкретен компонент от уеб менюто. И от дясната страна е анализ на тази конкретна транзакция, така че в горната част това всъщност е браузърът и след това View, само за да се запознаете с малко от иконите в GUI е за уеб сървъра, така че можем да видим атрибутивната точка. И тогава "J" е за Java и "T" е за Tuxedo и естествено "Q" е SQL. Добре, че стойността на парите основно идентифицира конкретно SQL изявление. Помислете какво прави това. Ние идентифицирахме потребителя по транзакция, към основния код на приложението, включително отделните SQL оператори. Сега, когато гледам тези отделни SQL изявления, мога да видя това за общото време за отговор, всеки от тях е отговорен за около шест процента и когато добавят първите четири SQL изявления, те поеха около една четвърт от транзакцията време.
Сега често базата данни е най-лесната за манипулиране. Обикновено е най-лесно да получите евтино, много по-превъзходно представяне. Сега трябва да отида малко по-надълбоко, за да разбера какво се случва и какво, искам примерът да е в състояние да разкрие всъщност индивидуалното SQL изявление и знаете, че почти мога да ви гарантирам само от всеки един кадър на линията имах някакъв вид инструмент за база данни и това, което прави инструментът за база данни, но просто гледайки една технология изолирано, е, че гледате, фокусирате се върху здравето на тази технология. И много пъти хората разглеждат списък на десетте най-добри. Сега това SQL изявление е доста бързо, няма да бъде в списъка на първите десет, но това е SQL изявлението, на което разчита тази транзакция. И така, това, което мога да направя обратно в тази дума, контекст, е, че сега мога да насоча това към внимателния поглед, но в контекста на отделното SQL изявление.
Сега този човек може да се отвори Precision в контекста на отделния SQL оператор и Precision улавя действителния план за изпълнение, който използва, времето за изпълнение, което е важно за DBA, всъщност ще покаже, можете да видите, че 50 процента от времето се изразходва в очакване за съхранение. Петдесет процента от времето се използва в процесора, така че започвате да получавате идеи къде се изразходва времето, как бих могъл да се клатуша това време надолу и идеята е да дадете опции на хората, защото различните отговори имат различни разходи и риск, свързани с, В идеалния случай ние търсим решение на проблем с нискорисково и евтино решение. Сега, когато SQL операторът се проследява от хеш-стойност и в лявата част на средата на екрана има този малък бутон „Настройка“ и това, което ще направите, ще ви отведе до SQL задача. И тази SQL задача е вид предварително изградена работна група и какво прави това, позволява ли ми да анализирам конкретно какво влияе на SQL оператора, като се започне с плана за изпълнение. Планът за изпълнение се избира от оптимизатора, когато операторът е анализиран, той - обратно към аналогията на храните, това е рецептата, която се следва за разрешаване на SQL израза.
И някои рецепти са по-сложни от други и затова предоставяме констатации. И това всъщност ще покаже тук, ей, много време прави последователни входове / изходи на определен индекс. И вижте сега, когато, връщайки се към кислорода, следвайте този индекс. Наскоро дефрагментиран ли е този индекс, какво е здравето, ако? В какво пространство на масата живее? Дали пространството на таблицата е разделено от таблицата, на която се позовава? И така започва да ви дава всякакви идеи как бихте могли да решите проблема. Сега очевидно, знаете, ние изграждаме в индекс. Това е много по-нисък риск, много по-лесно, отколкото може би преместването на индекс от едно пространство на таблица в друго пространство на таблицата, така че това, което искаме да направим, е вид натрупване на опции, така че да можем да разгърнем вариант с най-ниска цена и най-нисък риск за решаване на проблема.
Прецизният също може да прави неща като улавяне на променливи, които са прехвърлени към SQL оператор. Очевидно променливите, които са подадени, ще контролират размера на набора от резултати. И ще контролира колко време отнема това SQL изявление, за да се изпълни и колко данни трябва да бъдат предадени и обработени от приложението през Java, чрез .NET, в уеб сървъра и мрежата, накрая предоставени в браузъра на крайния потребител, Това, което се случва в базата данни, влияе директно на времето на браузъра. И така ще бъде от решаващо значение да има това ниво на видимост, за да можем да знаем какво точно се случва и да дадем на DBA най-много опции, така че да могат да изберат кой от тях има най-голям смисъл, предвид конкретната ситуация.
Това са някои от цитатите и те са от магазин PeopleSoft, който има глобално внедряване. Прецизно поддържа PeopleSoft и SAP, Siebel, Oracle, E-Business Suite, домашни Java и .NET приложения. Ние поддържаме, така че ако правите обаждания от уеб услуги към множество JVM, от Java до .NET обратно до Java, можем да проследим всичко това. Може да е на прем, може да е в облака. Важното е, че нещата трябва да бъдат инструментални.
И така, само няколко цитата от един от нашите клиенти: „Преди точно, нашите DBA използваха OEM“, - това е инструмент, който е само за база данни, и те основно казаха: „Хей, инстанциите изглеждат страхотно.“ Но те можеха помогнете да кажете или да разрешите проблем с определена транзакция. Прецизно предостави видимостта да се направи това. И така наличието на тази информация за SQL изявленията беше от решаващо значение за осигуряване на видимост на DBA за пълно изтласкване на производителността от базата данни. И така беше наистина приятно. Вид отвъд и извън някои от инструментите, които може да търсите.
И тогава ИТ мениджмънтът наистина хареса факта, че Precision успя да преведе сложен URL адрес в име на панела. И по този начин, ако краен потребител се обади и каже: „Ей, имам проблеми с това“, можете да изолирате и да видите кой е този потребител, какво изпълняват, каква ефективност, всъщност измерват рендеринга време в браузъра на крайния потребител. Това е истинска мярка за изживяването на крайния потребител. И така също, наличието на този потребителски идентификатор е абсолютно необходимо за подпомагане на конкретен човек, който се обажда.
Как Precision прави това? И така бихме искали да споделим по някакъв начин нашата архитектура. Точните трябва да живеят в собствен сървър, а в VM, той може да живее в облака. В предната част Precision е активиран в мрежата, независимо дали използвате табла за управление, интерфейс за предупреждение или графичен интерфейс на Expert. От страна на събирането на данни всъщност можем да правим агенти за няколко различни технологии. Често обаче ще се нуждаем от агент и има плюсове и минуси, за да имаме агент. Голям плюс е това дали събраните данни могат да бъдат предварително обработени, преди да бъдат изпратени във вашата локална мрежа. И това означава, че можем да сведем до минимум общото въздействие на мониторинговото решение върху целевата среда.
Сега просто помислете като алтернатива, ако имате „агент без агенти“, все още има колектор на данни, просто е въпросът къде живее и извършва разговори и пренасяне на сурови данни за целевото приложение във вашата LAN. И всъщност е доста скъпо. И така чрез предварителна обработка можем всъщност да сведем до минимум отпечатъка. Ще можете да наблюдавате както физически, така и виртуални. И едно нещо, което исках да кажа за виртуалната технология, е, че наистина се фокусира върху използването. Това, върху което се фокусира Precision, е спорът. Кога технологията VMware всъщност минимизира ресурсите за вашия гост VM? И така става наистина лесно. Ако гледате само в рамките на гост VM, имате само част от снимката. Това, че е в състояние автоматично да открива и сигнализира за спора, е наистина важно.
Precision може да наблюдава до 500 екземпляра, така че много големи внедрения в общи линии имат множество Precision сървъри. А за глобално внедряване обикновено това е точен сървър във всеки център за данни. Между другото, за най-големите внедрявания всъщност можете да ги обедините заедно, за да можете да разгледате корпоративната информация какво се случва и да можете да предлагате отчети и т.н. Сега, както споменах, имаме много технически анализи. Не всеки трябва да влиза в експертния графичен интерфейс, затова предлагаме персонализирано табло за управление. И всеки от тези портлети или джаджи, всички те са незадължителни. И някой може просто да иска да отиде: „Ей, как можеш да натиснеш сигнал на всяко ниво в нашата среда? Как се справят групите за крайна употреба от гледна точка на ефективността? “Или може би имате въпрос относно инфраструктурата, влизайки в може би дори Tuxedo изпълнение. Или дори балансиране на натоварването. Тук е интересно в тази част за балансиране на натоварването. Гледам портлета в средата от лявата страна. Можете да видите, че броят на екзекуциите е много сходен между всеки от уеб сървърите. Но времето за отговор е много различно в горния. Всъщност можете да проучите и да разберете точно причината, поради която времето за реакция на този уеб сървър беше много по-бавно от останалите.
Едно нещо за балансирането на натоварването, това е много важно и политиките за балансиране на натоварването, знаете, не всяка политика за балансиране на натоварването е подходяща за всяко приложение. Всъщност наистина е полезно да утвърдите вашата политика за балансиране на натоварването. Всъщност виждаме с някои приложения като новия GUI PeopleSoft Fluid, където всъщност някои уеб сървъри ще преминат офлайн. И това е нещо, което е наистина критично. Ако използвате GUI на PeopleSoft Fluid, моля, свържете се с нас. Можем да ви предоставим много вникване и много знания за това, с което са се сблъсквали други клиенти. Всеки от тези портлети може да бъде доста подробен. Подобно на средната дясна част, със синьото и зеленото, всъщност се показва моделът на върха на меча, това показва, че вашата колекция за боклук в слоя WebLogic работи по начина, по който очаквате. Всеки от тези портлети може да бъде силно фокусиран или може да бъде на много високо ниво. И причината, че това е важно или би могло да бъде важно, е много пъти да не е достатъчно само да разполагате с тази информация в IT, понякога трябва да споделяте тази информация със собствениците на приложения, а понякога и с висшето ръководство, за това, което се случва,
Исках да споделя с вас няколко истории от рода на „Успехът в Центъра за данни“. И това са фокусирани върху базата данни и имам други истории, които са съсредоточени в средната степен. Но за днес наистина искам да се съсредоточа върху нивото на базата данни. Нека да разгледаме замръзването на екрана. Това, което се случи тук, е, че този конкретен магазин имаше бизнес SLA, че ако поръчка бъде получена до 15:00, поръчката изпраща този ден. И така складът е изключително зает през този период от време. И тогава със замръзването на екрана беше много разочароващо. И така супервайзърът - това е по-малка компания - супервайзърът всъщност влезе в ИТ и, разбира се, стига до DBA и казва: "Сега, какво става?" И така, какво направихме, успяхме ли да покажем точно какво ставаше. Това е JD Edwards, многостепенно приложение, това е екранът за поръчки на продажби. Можете да добиете представа за това какъв е бил бизнесът, като цяло това е своевременно инвентаризация и затова основно разглеждате складови приложения. Сега вече доставяте до различни сайтове за клиенти, различни магазини. И това, което направихме е, че отворихме Precision.
В този случай, преди да разгледаме Oracle, тук разглеждаме SQL Server, а сега горната половина ни показва подредена стълбова графика на мястото, където SQL операторите прекарват времето си по време на изпълнение. Всяко слабо състояние се отчита в оста y. Оста x, ако разбира се във времето и можете да видите, че подредената лентова графика се променя от времевия отрязък в зависимост от това какво се изпълнява и как използва системата. Сега в този конкретен случай се фокусирахме върху третата SQL последователност от върха. Това е текстово SELECT FROM PS_PROD и можете да видите в тази колона, че сме заснели действителния план за изпълнение. И можете да видите по целия брой екзекуции. Фактът, че това конкретно SQL изявление е било отговорно за 9.77 процента от потреблението на ресурси през този период от време, който разглеждаме - и това е важен момент, времевата рамка, Precision съхранява непрекъсната история - и така по принцип мога да набирам в и разберете какво се е случило във всеки конкретен момент от време или с течение на времето. В състояние съм да видя тенденция.
Сега това SQL изявление, виждате, че там е подредена базова графика, тя е тъмно синя. Това казва, че използваме всички процесори. Нека да продължим напред и да се съсредоточим, като щракнем върху този бутон „TUNE“ върху конкретния SQL оператор. Това, което правим, е, че го вкарваме в тази работилница, предварително изградена работилница, която е предназначена да казва: „Ами какво ще знае DBA за този конкретен SQL оператор?“ И можете да видите отдясно, че има раздел, наречен „ История “, която е избрана. И това, което бих искал да направите сега, е вид преминаване към лявата страна, където пише „Промени срещу продължителност средна“, средна продължителност. И всеки от тези барове представлява събития на ден.
Можете да видите в сряда, четвъртък, петък, времето за екзекуция беше, аз ще закръгля до точка две. Оста y показва точка четири секунди, така че точка две. Много малко екрани замръзват, операциите вървят чудесно в SLA. За съжаление на 27 февруари планът за изпълнение се промени и това предизвика незабавна промяна във времето за изпълнение. Изведнъж времето за екзекуция се увеличава, четири Х, може би пет Х и нещата вървят наистина зле. Сега точно, в неговото хранилище всъщност се регистрират всички промени, които могат да повлияят на поведението. И тук можете да видите, че всъщност сме заснели промените в равнината на оста. Този в средата казва „Обемът на таблицата е променен.“ И така таблиците растат и ние сме точно на върха, когато SQL операторът е анализиран, оптимизаторът избира един план за изпълнение или друг план за изпълнение.
Сега за щастие, тази седмица тук в понеделник се обърна, така че беше в подходящ момент. За съжаление той се обръща отново и знаете ли какво, крайните потребители започват да очакват, че екранът ще замръзне и те ще започнат да го предават отново и да натискат брояча на изпълнението и нагоре и нагоре. Имаме огромно количество подробности, но за да разрешим този проблем и след това да го избегнем в бъдеще, се нуждаем от още една информация. И това ми се показва при сравнението на тези планове за изпълнение. На 5 март, когато беше бързо и ефективно, от лявата страна показва плана за изпълнение. Когато беше бавно и неефективно на 12 март, можете да видите, че прави филтриране. Присъединяването на филтъра просто принуждава много повече консумация на процесор, вършейки много повече работа. Резултатът е идентичен, просто върши много повече работа. Сякаш отивате и си набавяте доставките по една съставка наведнъж, вместо да отидете в килера и да получите всички съставки наведнъж. И затова съществува този вид по-ефикасен начин за това. Сега обикновено знаейки това, DBA успя да използва план за заявки, за да избегне този план за бавно изпълнение и да се заключи в бърза, висока производителност.
Следващият вид история на войната беше „Докладите са късни“. Мисля, че много хора могат да се идентифицират с този сценарий. Може да имате ad hoc отчитане, може да използвате инструмент като NVISION, може да имате инструмент за отчитане на трети страни. И това, което се случва е, че инструментът развива SQL. И често SQL не е кодиран толкова добре. И това би могло да се приложи и за ситуация, в която, знаете, имате някакво приложение от трети страни, нали, където SQL не е написано вътрешно и така като DBA: „Не контролирам SQL, какво Ще направя ли по въпроса? “Pa Precision предоставя нещо, за което не съм запознат с каквото и да е друго средство за предоставяне на база данни и това е изглед на обект. В съчетание с препоръки и моделиране. И така това, което можем да направим, е всъщност да обърнем видимостта на главата си. Вместо да разгледаме само активността, нека да проучим, добре кой обект е най-тежък в системата? И в натура на долната част на екрана можете да видите реда за SQL ред и можете да видите колоната „в MS-SQL“. И таблицата на реда за поръчки е като десет пъти по-натоварена от всяка друга таблица в системата. Мисля, че това, което също ще забележите в горната половина, разпределението на пространството расте и можете да разгледате спецификациите на сървъра каква версия на софтуера работим. Точните всъщност ще проверяват проследените промени в основните настройки. Още веднъж причина и следствие.
Сега, като се съсредоточа върху таблицата за ред на поръчките, това, което мога да направя с моето подробно историческо хранилище е, че всъщност мога да съпоставя SQL изразите, които са в противоречие с таблицата за ред на поръчката. И можете да започнете да разглеждате клаузата къде в тези SQL изрази. И започвате да забелязвате, че клаузата където е доста сходна между различните SQL изрази. И бих ви предложил, че във вашата система за запис ще намерите същото. Тъй като бизнес потребителите, бизнес анализаторите ще искат да правят неща като съвкупна бизнес активност през последния ден, последната седмица, последния месец, последното тримесечие, последната година. Ще видите много подобно, където клаузите, подреждането по, групирането по и това означава, че ще има определени индекси, които имат смисъл за тези SQL изрази.
И така Precision има механизъм за препоръки, можете да видите, че в горния десен ъгъл и това, което можем да направим, е всъщност да получите препоръки. Кажете: „Ей, изпълнявам всички SQL изрази, какви индекси биха ги адресирали?“ Индексите са ви представени и всъщност можете да видите DBL. Сега Precision е само за четене, той не предлага възможността да кликнете върху бутон и да създадете индекса, но това е достатъчно лесно да се направи извън Precision. Но тук е важното: Precision ви позволява да оцените и моделирате промените, така че в долния ляв ъгъл на екрана има този бутон за оценка. И това, което прави, е, че показва SQL изразите в преди и след.
Нека разгледаме тези SQL изявления. Виждате ли тази колона тук, която казва „в MS-SQL“ и казва един час, четири минути? Това най-високо SQL изявление изпълнява или изразходва около 64 минути ресурси. А прогнозираното му подобрение е 98 процента. Тези промени ще спестят часове за обработка. Следващият SQL оператор е 27 минути и по принцип ще спести една трета. Това е около десет минути обработка. Обобщени заедно, всъщност ще спестите часове и часове за обработка от тези предложени промени. И така да можеш да знаеш това отпред, да можеш да моделираш това. Можете също така да използвате способността „какво-ако“, за да кажете „Е, не искам да правя този индекс или какво ще се случи, ако променя реда на колоната?“ И така мога да използвам тази способност за моделиране за да разберете какво точно ще продължи.
Другото, което е решаващо, е, че когато направя промяната, всъщност мога да измеря за отделен SQL оператор. Вие видяхте историята на SQL изразите в предишния пример и всъщност мога да проверя дали съм постигнал спестяванията, които бяха моделирани. И така, че обратната връзка, завършването на веригата за обратна връзка е абсолютно решаващо.
Добре, ето последният пример, който щях да имам за вас. Това е SAP магазин и знаете ли, те бяха отишли за по-голямо надграждане, правеха някои неща с персонализирани транзакции и всъщност крайният потребител беше недоволен от работата. И така, това, което направихме, успяхме да се съсредоточим върху това, което преживя този краен потребител. И можете да видите в горната част на списъка „ИЗБОР“, а времето за отговор е малко над 61 секунди. Това нещо отнема минута за изпълнение. Сега можете да видите, че имаме подредена лентова графика, насочена към SAP. В дясната страна показва клиентско време, време за опашка. Синьото е време за кандидатстване и в SAP среда, това е ABAP код и след това базата данни. И така базата данни, знаете, може да е Oracle, може да бъде SQL, може да е HANA. По принцип сме в състояние да покажем това.
Сега, което правим с Precision, е да фокусираме, за тази транзакция и за този потребител, какви SQL изявления излизат. Още веднъж този контекст за свързване на точките. Сега това най-високо SQL изявление, можете да видите, че е кръгло, то се изпълнява за две милисекунди. Наистина не можете да обвинявате базата данни, ако тя се изпълнява толкова бързо. Броят на изпълнението е много голям. Всъщност ние можем да се върнем към кодера на ABAP и да кажем: „Ей, какво става?“ Всъщност установихме, че кодът в базата данни е поставен на неправилно място, гнездил на неправилното място в цикъла, направи промяна и след това сме в състояние да измерим след. Всъщност можете да видите какво е изпълнението след това. Не само на ниво SQL оператор, но и на ниво персонализиран код. И така те биха могли да живеят с време за изпълнение четири и половина секунди. И така, това са само няколко примера за това как може да се използва точност, може да го използвате. Точно като бързо резюме, Precision показва производителност по местоположение, чрез идентификационния номер на крайния потребител, той предоставя контекст чрез стека на приложенията. Можете да разгледате първопричината. И мисля, че един от големите диференциатори е да може да знае не само операторът SQL, но защо SQL операцията работи бавно и да може да идентифицира спора и основно да предложи повече възможности за решаване на проблеми. Това е, което Precision може да предложи и можете да ни консумирате по лек начин или ако имате много дълбоки, много предизвикателни проблеми, ние обичаме да приемаме и тези.
Ерик Кавана: Добре, трябва да кажа, че това беше много фантастичен детайл, Бил. Благодаря ви, че показахте всички тези екранни снимки. И от моя гледна точка наистина сте изпълнили това, което обяснявах в началото на часа, който е номер едно, трябва да имате правилния инструмент. Трябва да имате инструмент, който ви позволява количеството контекст, необходимо за идентифициране на всички елементи в уравнението, както някой каза във филм веднъж, това беше някак смешно. Но нека да продължа напред и да го предам на Dez, защото се обзалагам, че има някои въпроси към вас и искам да натисна още един от тези слайдове само за визуални бонбони, ако щете. Всъщност, дръжте, нека да го върна. Но Дез, сигурен съм, че имаш някои въпроси, отнеси го.
Дез Бланчфийлд: Да, да, уау. Този инструмент измина доста далеч, тъй като първоначално го знаех и не знаех, че всъщност сте попаднали толкова дълбоко в стека. Това е просто умопомрачително. Просто наистина бързо, няколко неща. Моделът на внедряване, можете ли наистина бързо, след минута или две, просто да очертаете традиционния или типичен модел на внедряване. Споменахте, че е достъпна като виртуална машина. Може да се стартира в облака. И предполагам един от въпросите, който вероятно ще възникне и мисля, че имаше няколко въпроса, които се появиха в раздела за въпроси и отговори. Само за да ги резюмираме в обобщение, така че нормалният модел на внедряване и вида ос, който е необходим, традиционно ли се разполага в помещение или хостван или в облака? Какви са типовете модели на внедряване, които обикновено виждате? И какъв тип ос е необходима, за да може тази работа да работи? Трябва ли да променяме нещата на ниво сигурност около достъпа до мрежата и т.н.? Или това може просто да се държи като краен потребител?
Бил Елис: Да, така че в момента по-голямата част от инсталациите са готови. Все повече хора поставят компоненти в стека на приложението в облака и така можем да се справим и с това. Разгръщането, от което се нуждаем сървър, за да работи, то ще отговаря на определени спецификации. Трябва да имаме база данни, за да съхраняваме историческото хранилище, така че изпълнението на тези предпоставки е вид първата стъпка. Следващото нещо е, че определено трябва да имаме известни познания за самото приложение и инсталацията е задвижвана от съветника и по принцип да попълваме празните места. Поради дълбочината на информацията, която получаваме, от ниво на уеб процес до кода, който се изпълнява, ние трябва да имаме някои привилегии. Имаме сигурен модел на данни или модел за сигурност, трябва да кажа, защото агентите работят под идентификационни данни, които са напълно отделни от хората, които използват метаданните за транзакциите и т.н.? Прецизно комуникира чрез TCP през IP и затова изискваме определени портове да бъдат отворени. Като бърз пример, като пристанището ни по подразбиране е 2702. Този тип подробни неща са нещо, ако хората се интересуват, бихме могли да влезем в него по-подробно. Но обикновено ние сме много бързи по време. Ако някой е изправен пред голям проблем, често можем да инсталираме нещото и да запалим ярка светлина за ситуация за няколко часа.
Дез Бланчфийлд: Да, определено имам и този смисъл. В модела на внедряване вие говорихте за много голям мащаб и до 500 инстанции и как това може да бъде федерално. На самото начално ниво, как изглежда, ако някой иска - защото знам, че IDERA е много голям в предоставянето на достъп до безплатни опити, безплатни демонстрации и си спомням, че видях в уебсайта почти всичко, което може да се играе. За фолк тук и мисля, че го пропуснах по-рано, но мисля, че възникна въпрос около това как изглежда типичен сайт и как хората получават достъп до това и започват да играят с него и да получат този тип на опит, където те могат да видят дали имат начин да се справят с някои проблеми с производителността? Могат ли да изтеглят ODS и да го въртят на своя хипервизор, Hyper-V или лаптоп или им трябва специална машина, за да го стартират? Вие очертахте архитектурата преди, но само накратко, след минута-две, как изглежда това за внедряване на входно ниво, само за да докажете концепция например?
Бил Елис: Да, така че моделът ни е малко по-различен от инструментите IDERA. Ние се вписваме повече в сценария на Embarcadero, където бихте искали да се свържете с един от нашите представители на продажбите. Бихме искали просто да обсъдим с вас какви са предизвикателствата и тогава обикновено обикновено бихме могли да назначим един от SE, който ще работи чрез инсталацията с някого. Обикновено не бихте пускали Precision на вашия лаптоп. Бихте искали да имате VM или сървър в центъра за данни, където живее приложението, за да направите колекциите. Но ние ще ви помогнем през всяка стъпка от това. Ако някой се интересува от това, определено искате да се свържете с IDERA.
Дез Бланчфийлд: Едно от другите неща, които ме впечатлиха, беше, че искам да кажа, че много от това, което разгледахме днес, е около реагирането на проблеми с представянето. Но ми се стори, че и в средата на живо, тъй като хората ги използват така, както първото ви слайдшоу, някой вдига телефона и казва: „Приложението работи бавно, помогнете.“ Но ме порази това по време на предварително пускане на приложения или ъпгрейди или нови корекции и корекции, можете да преминете през куп планиране на капацитет и стрес тестове и да прецизно да разгледате цялата среда и всъщност да намерите проблеми, преди дори да поставите крайните потребители на околната среда. Това случай на употреба, какъвто сте виждали преди, или хора също така правят, или това не е типичен случай на употреба?
Бил Елис: Абсолютно бихме искали да използваме Precision през целия жизнен цикъл на разработката на приложението или жизнения цикъл на ъпгрейда. Precision предлага изглед на мащабируемост, той ще покаже броя изпълнения, наслагвани с времето за отговор. Очевидно е, че както броят на екзекуциите, така и времето за реакция нарастват заедно, не сте мащабирани и трябва да направите нещо. Този тип неща са помогнали неимоверно. Мисля, че сега е малко по-малко вярно, но когато хората започнаха да пускат производствени приложения към VMware, те бяха малко колебливи и беше като, знаете, първо нещо щеше да им хареса: „О, трябва да преместим това на физически. ”И това, което всъщност можем да направим, е да покажем какво е потреблението на ресурси, за да можете да направите приложението по-ефективно. На всяка стъпка от жизнения цикъл на приложението определено искате да използвате Precision. Но трябва да кажа, че производството наистина е там, където работата е най-важна и точно е насочена към денонощен мониторинг на производството, така че наистина не искате да стартирате своите производствени приложения без видимост.
Дез Бланчфийлд: Абсолютно. Още един бърз въпрос точно относно този специален тест - задълбочен тест, имиграция, UAT и така нататък - искам да кажа, че е чудесно да разполагате с този инструмент и предполагам, че разработчиците на приложения биха се радвали да имат достъп до това през жизнените цикли на жизнения цикъл на развитието., С по-сложните архитектури, които виждате сега, така че ние преминахме от специализирана услуга към виртуализации и виртуализация, сега преминаваме към някакво, знаете, приемане на аутсорсинг към облачен хостинг и също виждаме преход до контейнеризация. Виждали ли сте много хора да разгръщат това и моделират вида на регионите или зоните, така че някой може да има - и в Австралия имаме много голям проблем около личния живот и знам, че в Европа е едно и също нещо и мисля, че става все по-голям случай в САЩ, където данните, които могат да ме идентифицират лично, често трябва да са в по-сигурна среда спрямо реалния слой на приложението към уеб слоя. И така сега имаме тези внедрения, където хората може да поддържат своята база данни и приложенията си вътрешно, но те могат да поставят своя уеб слой и край на приложението и приложението си и така нататък в облачен доставчик като Azure или или Amazon Web Services и софтуер, Как работи това с нормалното ви внедряване? Това ли е случай, че току-що сте се сдобили с друг набор от колекционери в региона и те просто събират още няколко? Как изглежда това в точния свят в днешния вид бимодален подход за управление на ИТ на стари наследствени неща на едно място и стоките ви понякога са в облака?
Бил Елис: Да, така че поддържаме смесена среда. Едно нещо трябва да се има предвид, че има различни договори с облачните доставчици. Някои от тях няма да позволяват какъвто и да е агент или какъвто и да е вид външен мониторинг в облака. За да инсталирате и наблюдавате с Precision, трябва да имате тип договор, който позволява този тип достъп. Определено има някои ограничения, през които понякога се налага да работим и затова те са важни критерии, които вземате предвид, когато, предполагам, първо подписвате тези договори и след това и / или ако трябва да внедрите Precision.
Дез Бланчфийлд: Да, видях редица случаи, когато дори и с традиционна среда за бази данни, ако го закупувате като част от услугата, особено с харесването на Azure, тъй като осигурявате харесванията на HDInsight или SQL като като платформа, обичайните ви инструменти могат да се гмуркат само толкова дълбоко, защото всъщност не са толкова желаещи да погледнете какво има под капака. И така в крайна сметка с определено ниво или дълбочина, на която можете да следите, и изведнъж просто не можете да видите зад магическата завеса. Самообслужването нещо ли е? Това традиционно ли е нещо, което да работи в центъра за мрежови операции, където техническият екип, хората по CIO биха получили достъп само до това, или това също е нещо, до което можете да осигурите ниво на достъп на крайните потребители? Може би не е задължително приемното бюро и традиционните HR и финансисти, но знаете по-разбираеми потребители, които например правят, например, учени по данни, актюери, статистици, хора, които правят наистина големи натоварвания. Случайно ли е те да получат достъп до някакъв вид достъп до самообслужване, за да видят какво се случва, когато изпълняват тези тежки заявки и къде се появява болката, така че да могат да настроят начина си на натоварване?
Бил Елис: Има доста добра сигурност в рамките на Precision, така че можете да настроите потребители, които имат различни нива на достъп. На много основни нива само контролните табла осигуряват надзор. И тогава в рамките на, знаете, ако някой е искал да влезе в Expert GUI, можете да ограничите какво могат да виждат и какво могат да правят. И един вид въртене към предишния ви въпрос, че знаете, че в здравеопазването имате всички закони на HIPAA и затова определено има някои съображения и всъщност има някои опции за разполагане, така че да можем да работим с него и в двете среди. Едно нещо, което трябва да вземете предвид при данните, които сте виждали в тази презентация, е, че всички метаданни за производителността, а не съдържанието на таблиците, знаете, и така наистина е, няма да навлизате в такива видове опасения за поверителност.
Дез Бланчфийлд: Да, аз така го направих. Имах момент на еврика за вашия четвърти или пети слайд на екрана и щях да разбера, че просто дърпате производителност, а не просто, но дърпате данни за ефективността, дърпате неща, както казахте, метаданни от различните нива на стека, всъщност не гледате на съдържанието. И мисля, че това е интересно, защото е един от онези инструменти, където бихте могли или да го разгърнете за кратко време и да погледнете какво се случва в околната среда, но не е нужно да имате достъп до самите данни. Можете дори да погледнете начина, по който се управляват екипажите. Последното нещо, предполагам, просто бързо и тогава ще се върна на Ерик, така че ако имате въпрос, след това накарайте Ребека да се увие, споменахте преди, че режийните разходи са номинални, случаят е, че е дори забележимо режийно покритие от страна на наблюдението на нещата и просто гледане на заден план или това е толкова нищожно количество режийни разходи, че просто не си струва да се обмисля?
Бил Елис: Да, така мисля, че на ниво база данни знаете, всяка технология е малко по-различна. В нивото на базата данни Precision е доста добре известен, за да победи най-ниските режийни. На средния слой има, знаете, има някакъв балансиращ акт, знаете, не е само Прецизен, а се прилага за всички, по отношение на видимостта и режийните разходи. И така едно от нещата е, че предлагаме редица сложни инструменти, за да контролираме какъв е режийният. Ние сме проектирани за производство и, знаете, определено е полезно да отнемете колкото се може повече проблеми в развитието на развитието и качеството, но, знаете, няма какво да знаете какво се случва в производството.
Дез Бланчфийлд: Ерик, имаш ли някакви последни въпроси?
Ерик Кавана: Да, просто ще кажа, че мисля, че сте се справили чудесно, като сте посочили, че контекстът наистина е ключът и е почти като ако се придвижим към тази ера в интернет на нещата, искате всичко да е инструментално. И мисля, че стандартът в производството е да се прави това, което е добра новина, нали? Защото искате да можете да изтеглите информация от всички тези различни среди и да ги зашиете заедно. И предполагам, че просто ще ви го предам за някои последващи коментари. Това е, върху което се фокусирате, е да осигурите визуален интерфейс, чрез който някой анализатор, по същество ИТ анализатор, може да наблюдава и анализира случващото се в тази сложна среда и след това да разбере какво да промените. Защото не е само инструмент. Трябва да имате инструмента, но имате нужда от този човек, който ще се рови в този детайл и ще намери отговорите, нали?
Бил Елис: Да, някак си възприемам това като кипене до върха и определяне с приоритет къде е най-много откупуване, нали знаете? Ако се окаже, че това е различна ситуация, защото не всеки проблем е в базата данни. Ако базата данни е, знаете ли, че нещата се изпълняват за една десета от секундата, но на нивото на приложението нещата отнемат три секунди, това е мястото, където е най-много обратно изкупуване. И така е възможно да изолирате проблемния слой и след това какво се случва в този ред, за да се съсредоточите наистина върху мястото, където е изкупването. Това наистина ускорява разделителната способност и оптимизирането на приложението и е много по-бързо и много по-добро и толкова по-забавно, отколкото хората, събрани в конферентна зала, които казват: „Ами не съм аз, трябва да е някой друг.“
Ерик Кавана: Точно така. Онзи ден видях страхотен мем, който каза нещо от рода на: „Бъдете информирани, а не само изразявайте увереност.“ Влизате в среща, имате информация, можете да насочите към данните. Това е ключът и стигаме до там, слава богу. Добре, че ще продължим напред и ще приключим, но архивираме всички тези излъчвания за по-късно гледане. Чувствайте се свободни да го проверите по всяко време. Ние изброяваме всички наши излъчвания в момента, серията Hot Tech и сериите за брифинг в Techopedia.com, така че хоп онлайн и проверете тези хора. С това ще се сбогуваме. Благодаря за отделеното време днес, Бил. Благодаря на вас и на цялата ви упорита работа, Dez. И ще говорим с вас следващия път, хора. Пази се. Чао чао.
