От служители на Techopedia, 2 ноември 2016 г.
Отнемане: Домакинът Ерик Кавана обсъжда ефективността на приложението и как да подобри ефективността с д-р Робин Блур, Дез Бланчфийлд и Бил Елис на IDERA.
В момента не сте влезли. Моля, влезте или се регистрирайте, за да видите видеото.
Ерик Кавана: Дами и господа, привет и добре дошли отново за горещи технологии. Да, именно! Казвам се Ерик Кавана, ще бъда ваш домакин за поредния уебкаст днес в тази наистина забавна и вълнуваща поредица, която получихме като комплимент към нашата поредица от брифинг стаи. Заглавието е „Ускорение на приложенията: по-бърза производителност за крайните потребители.“ Хайде, хора, кой не иска това? Ако аз съм човекът, помагащ на приложението ви да работи по-бързо, мисля, че съм човекът, който ще си купи бири в бара след работа. Трябва да е доста готино нещо, за да влезете и да ускорите приложението на никого.
Има слайд за вашето наистина, ударете ме в Twitter @Eric_Kavanagh. Винаги се опитвам да следя назад и винаги повторям чуруликане, ако ме споменавате, така че не се колебайте да ме споменавате.
Цялата цел на това предаване е да се съсредоточи върху различни аспекти на корпоративната технология и наистина да помогне да се дефинират определени дисциплини или определени лица, ако желаете. Доста пъти продавачите ще се качват при определени маркетингови условия и ще говорят как правят това или онова или друго. Това шоу беше наистина създадено, за да помогне на нашата аудитория да разбере какво софтуерно средство трябва да има, за да бъде лидер в своето пространство. Форматът на това е двама анализатори. Всяко тръгва първо, за разлика от Стаята за брифинг, където продавачът отива първи. Всеки от тях ще поеме това, което смята за важно за вас, за да знаете за определен вид технологии.
Днес говорим за ускоряване на приложението. Ще се чуем от Дез Бланчфийлд, както и от доктор Робин Блур - днес сме навсякъде по света - и тогава Бил Елис набира номера от по-голямата област Вирджиния. С това ще го предам на първия ни водещ, д-р Блур. Между другото туитирахме хештега на #podcast, така че не се колебайте да туитвате. Отнеси го.
Д-р Робин Блур: Добре, благодаря за това въведение. Ефективност на приложенията и нива на обслужване - това е един вид област, през годините съм свършил много работа в тази област, в смисъл всъщност съм свършил страшно много работа за наблюдение на работата и работа в едно по друг начин, как да опитате и да изчислите тези нива. Трябва да се каже, че до преди имахме тази ера, когато хората изграждаха системи в силози. По принцип, количеството работа, която всъщност трябва да свършат, за да накара системата да работи достатъчно добре, ако тя е в силоз, всъщност не е твърде трудна, защото има много малко, много малко количество променливи, които трябва да вземете под внимание. Веднага след като получихме правилна мрежа, интерактивната и сервизната ориентация влязоха в уравнението. Стана малко трудно. Изпълнението може да бъде едномерно. Ако просто се сещате за приложение, изпълняващо определен път на кода многократно, правилното го правилно и навреме се чувства като едномерно нещо. Веднага щом започнете да говорите за нивата на услугите, всъщност говорите за множество неща, които се състезават за компютърен ресурс. Тя става многоизмерна много бързо. Ако започнете да говорите за бизнес процеси, бизнес процесите могат да бъдат сплотени заедно от множество приложения. Ако говорите за ориентирана към услуги архитектура, тогава дадено приложение може всъщност да има достъп до възможностите на множество приложения. Тогава става много сложно нещо.
Погледнах - отдавна нарисувах тази диаграма. Тази диаграма е на поне 20 години. По принцип го наричам Диаграма на всичко, защото това е начин да се разгледа всичко, което съществува в ИТ средата. Наистина са само четири части: потребители, данни, софтуер и хардуер. Разбира се, те се променят с течение на времето, но вие всъщност осъзнавате, когато погледнете това, че има йерархична експлозия на всяко едно от тези парчета. Хардуерно да, хардуер може да бъде сървър, но сървърът се състои от евентуални множество процесори, мрежови технологии и памет, и това, нещо като ужасно много контролери, както се случва. Ако всъщност погледнете това, всичко се разпада на парчета. Ако всъщност мислите да опитате да организирате всичко това по отношение на данните, които се променят, производителността на софтуера се променя, защото хардуерът се променя и така нататък и така нататък, всъщност разглеждате невероятно трудна ситуация с много различни варианти. Това е кривата на сложност. Разбира се, това е крива на сложност за почти всичко, но съм виждал, че е изтеглян отново и отново, когато говорим за компютри. По принцип, ако поставите възли на една ос и важните връзки на другата ос, завършвате с крива на сложност. Почти няма значение какви са възлите и връзките и това ще се случи, ако искате представяне на ръста на силата на звука в телефонната мрежа.
Всъщност, когато говорим за възли в компютърната среда, вие говорите за отделни неща, които се грижат един за друг. Оказа се, че сложността е въпрос на разнообразна структура и различни ограничения, които се опитвате да спазвате. Също така числата. Когато числата се повишат, те полудяват. Вчера имах интересен чат, разговарях с някого - не мога да спомена кой е, но всъщност няма значение - те говориха за сайт с 40 000 - това са четири нула, 40 000 - случаи на бази данни в сайта. Помислете само за това - 40 000 различни бази данни. Разбира се единственото нещо, което имахме - те очевидно са имали много, много хиляди приложения. Говорим за много голяма организация, но не мога да я назова. Всъщност гледате на това и всъщност се опитвате, по един или друг начин, да получите нива на услуги, които ще бъдат адекватни за всички няколко потребители, с множество различни, ако желаете, очаквания. Това е сложна ситуация и това, което всъщност казвам, е сложно. Числата винаги се увеличават. Ограниченията се определят от бизнес процесите и бизнес целите. Ще забележите, че очакванията се променят.
Спомням си, че щом Gmail, Yahoo и Mail и Hotmail, всички тези пощенски системи се появиха, хората започнаха да очакват своите вътрешни пощенски системи в организацията да заслужат нивата на услугите на тези огромни операции с огромни сървърни ферми извън организацията и започна да се оказва натиск, за да се случи всичко това. Всъщност споразуменията на ниво услуги са едно, но очакванията са друго нещо и те се бият помежду си в рамките на организация, неудобно нещо. Ето само бизнес перспектива. В някои системи оптималното време за реакция е една десета от секундата от времето за отговор на човека. Една десета от секундата е времето, което отнема на кобра, за да ви ухапе. Ако стоиш пред кобра и тя реши да те ухапе, вече е късно, защото не можеш да отговориш на една десета от секундата. Една десета от секундата е около времето, което отнема на топката, за да остави ръката на стомна, за да стигне до човека с бухалката. По принцип, тъй като вижда топката хвърлена, той трябва да реагира точно в този момент. Човешки отговор, нещо интересно нещо. Софтуерът до софтуер, очевидно може да има по-големи очаквания.
Тогава вие попадате в някои ситуации, които според мен са онези пазарни ситуации, където да бъдете на първо място е къде е бизнес стойността. Това е все едно, ако искате да продадете определен акция на фондовия пазар, вероятно е по-малко, например, защото смятате, че се понижава и много други хора смятат, че се понижава, вие получавате най-добрата цена, ако стигнете до пазара първо. Има много ситуации, показване на реклами и подобни неща, много подобна ситуация. Имате това движение по отношение на очакванията за ниво на обслужване. Имате едно нещо, което е един вид стъклен таван за човешка реакция. След като това е софтуер до софтуер, ако имате тази ситуация на тавана, тогава няма най-добро ниво на обслужване. По-бързо от всички останали е най-доброто.
Добре, това е, струва ми се, последният слайд, който направих, но това е само за да ви дам голяма картина на сложността, след като всъщност погледнете изискванията на организацията, услугата. Имате, като отидете нагоре по лявата страна тук, имате управление на системата, което е набор от софтуер, който служи за управление на услуги, който се опитва да управлява ниво на обслужване. По-горе имате управление на резултатите от бизнеса. След това, ако погледнете долу долу, в областта за автоматизация на управлението на услуги, имате фрагментирани услуги, които се превръщат в стандартизирани услуги, ако всъщност искате да инвестирате в такива неща, които се развиват в интегрирани услуги, които се развиват в оптимизирани услуги, Най-вече това, което хората са направили, е само в долния ляв ъгъл на това. Може би малко управление на услугите. Управление на резултатите от бизнеса, много рядко. Раздробена, почти цялата. Перфектен свят би запълнил тази мрежа. Инструментация - споменах проблем с под оптимизацията. Можете да оптимизирате части от системата и това не е добре за цялата система. Ако направите сърцето оптимално, кръвта ви може да циркулира твърде бързо за останалите органи. Това е проблем с големите организации и нивата на обслужване. Ясно е, че нищо няма да бъде постигнато без сложни инструменти, защото променливите току-що са се получили - ами има твърде много променливи, които да се опитат и оптимизират.
След като каза това, ще предам на Дез, който ще говори за нещо друго изцяло, надявам се.
Дез Бланчфийлд: Благодаря ти, Робин. Подобно на д-р Робин Блур, прекарах твърде много години в мислене за работата на много сложни системи в много големи мащаби. Вероятно не е със същия мащаб като Робин, но изпълнението е ежедневна тема и е част от нашата ДНК да искаме представяне, да извлечем най-доброто от всичко. Всъщност използвах графика на едно от любимите ми неща в света, автомобилните състезания Формула I, където цялата планета седи все още известно време и гледа как автомобилите се движат в кръгове много бързо. Всеки един аспект няма аспект от Формула I, който да не е конкретно за постигане на ефективност. Голяма част от хората играят спорта, защото смятат, че това е загуба на пари. Оказва се, че колата, която караме всеки ден, за да пускаме децата на футбол през уикендите и училището през останалите дни, е получена от развитие и изследвания, базирани на резултати. Това е животът на автомобилните състезания във Формула I. Ежедневната технология, ежедневната наука, често идва от харесванията на нещо, което е фокусирано чисто върху висока производителност.
Реалността обаче е, че новият ни свят "винаги е в готовност", който изисква 100 процента продължителност - както Робин спомена по-рано - с неща като въвеждането на уеб поща и други услуги, които приемаме за даденост в непрекъснато пространство и сега очакваме това в нашето предприятие и работна среда. Реалността е, че това, че сте готови, не означава винаги, че отговаряте на споразумението си на ниво услуги. Имам това отношение към необходимостта да се управлява изпълнението на приложенията и споразуменията за ниво на достъпност услугата претърпя съществена промяна през последното десетилетие. Вече не се опитваме да се тревожим за работата на една система. Когато светът беше малко по-прост, може да имаме ситуация, при която един сървър, работещ с множество услуги, може да бъде наблюдаван на живо и той беше сравнително лесен за поддръжка. Бихме могли - и ето моето малко - нещата, за които се тревожехме, когато бях системен администратор, например, преди много години - щяхме да се огледаме, обслужва ли се обикновено услугата и отговаря ли? Мога ли да вляза в терминал например? Отговаря ли операционната система и мога ли да въвеждам команди? Приложенията стартират ли се и работят? Мога ли да виждам процеси и памет при правене на неща и I / O в мрежата и т.н.? В дните на мейнфрейм можете да чуете касети, които преминават от цип-цип и хартия, падаща от тях.
Отговарят ли приложенията и можем ли да влизаме и да правим неща по тях? Потребителите могат ли да се свържат с някои от тези сървъри? Това продължава. Те са доста фундаментални, нали знаете. Тогава няколко смешни - зеленото бюро е зелено? Защото ако не, тогава всичко върви добре и кой ще вземе поничките? Животът беше наистина прост в онези дни. Дори в онези дни, а после говоря преди 20-30 години, сложността беше все още наистина голяма. Бихме могли по сравнително пряк начин да управляваме споразумения за ниво на обслужване и да следим изпълнението. Повече не можем да го направим на ръка, както Робин намекваше. Предизвикателството е твърде голямо. Факт е времето, когато няколко добри приложения, администратори, системна мрежа и база данни, администраторите могат да наблюдават и отговарят на SLA-тата за ефективност. SLAs са толкова далеч сега, че се борих снощи, когато слагах окончателните си бележки, дори да мисля за годината, когато за последно успях да разгледам система от много сложен стек, и да го осмисля и дори да разбера какво е става под капака и идвам от дълбока техническа подготовка. Не мога да си представя какво е да се сблъскваме с това ежедневно сега по административен начин.
Какво стана? Е, през 1996 г. приложенията, базирани на база данни, се трансформират с интернет бума. Много от нас са преминали през това. Дори и да не бяхте около бума на интернет, лесно можете просто да се огледате и да осъзнаете, че в ежедневието, ние свързваме всичко към интернет сега. Вярвам, че имаме тостер, който очевидно идва с опцията да вляза в Wi-Fi, което е нелепо, защото нямам нужда от моя тостер, свързан с интернет. През 2000-те години, особено в началото на 2000-те години, трябваше да се справим с този мащабен растеж на кръга на сложността, осигуряващ ефективност на услугите в бут дот-ком. След това още една нелепа неудобна искра в уеб 2.0, където се появиха смартфони и сега приложенията бяха в ръцете ни 24/7 и бяха постоянно включени.
Вече е 2016 г., изправени сме пред още едно трептене под формата на облак, големи данни и мобилност. Това са системи, които са толкова големи, че често са трудни за разбиране и поставяне на обикновен английски език. Когато се замислим върху факта, че някои от големите еднорози, за които говорим, имат десетки стотици петабайти данни. Това е целия етаж на дисково пространство и място за съхранение, само за да съхранявате своя имейл, изображения и социални медии. Или в някои случаи в транспортната и корабоплавателната логистика всичко е в банковото дело, това е къде са парите ви, или къде е вашата публикация, или вашата, където е нещото, което сте купили на eBay. Следващата голяма вълна, пред която сме изправени, е това много тежко предизвикателство от интернет на нещата.
Ако това не беше достатъчно лошо, ние сме на път да изградим изкуствен интелект и когнитивни изчисления в почти всичко. Днес разговаряме със Siri и Google двигатели. Знам, че Amazon има своя собствена. Baidu имат едно от тези устройства, с които можете да говорите, те го превръщат в текст, който преминава в нормална система, базата данни прави запитване и се връща и обръща процеса. Помислете за сложността, която влиза в това. Реалността е, че сложността на днешния стандартен стек от приложения е далеч над човешките възможности. Когато мислите за всичко, което се случва, когато натиснете бутон на вашето устройство на смартфон или таблет, вие говорите с него, преобразува го в текст, изпълнява това до интернет в бек-енд система, предно устройство получава това, преобразува го в заявка, изпълнява заявката през стека на приложенията, преминава през база данни, удря диск, излиза обратно, а в средата има мрежа от оператори, има център за статус на локална мрежа. Сложността е луда.
Ние ефективно твърдим това като свръхмащабна. Сложността и скоростта на свръхмащаб е само поливане на очите. Приложенията и базите данни станаха толкова големи и толкова сложни, че управлението на производителността всъщност е наука сама по себе си. Мнозина го наричат ракетна наука. Имаме технология на място, имаме външна технология, имаме набор от възможности за центрове за данни; физически и виртуални. Имаме физически и виртуални сървъри, имаме облак, имаме инфраструктура като услуга и платформа като услуга и софтуер като услуга е нещо, което сега приемаме за даденост. Последното, софтуерът като услуга, стана страшно известно време преди няколко години, когато финансовите директори и части от организацията разбраха, че могат да си вземат кредитната карта и просто да си купят нещата и да обикалят CIO и ефективно ние нарекохме тази „сянка IT “и CIO сега се опитват да върнат този гръб и да се борят контрола над.
В инфраструктурата имаме софтуерно дефинирани мрежи, виртуализация на мрежовите функции, по-долу това, вероятно над, сега имаме микро услуги и приложения на активни услуги. Когато щракнете върху URL адрес, има куп бизнес логика, която се намира в края на този URL адрес, който описва какво точно трябва да го достави. Не е задължително да има предварително изградена логика, която го чака. Имаме традиционни бази данни от едната страна, които мащабират много, много големи. Имаме харесването на инфраструктурата и екосистемите на Hadoop от другия спектър, които са просто толкова големи, че, както казах, знаете, сега хората говорят за стотици петабайти данни. Имаме мобилност по сложност, що се отнася до устройства, които носят наоколо, лаптопи, телефони и таблети.
Имаме BYOD в някои затворени среди и все повече, тъй като опитните хора от Gen Y носят свои собствени устройства. Просто ги оставяме да говорят с тях за уеб интерфейси. Или по интернет, или през Wi-Fi, ние имаме безплатен Wi-Fi в кафето долу, тъй като те пият кафе. Или нашият вътрешен Wi-Fi. Машина до машина е винаги присъстваща. Това не е пряко част от интернет на нещата, но също е свързано. Интернет на нещата е съвсем нова игра със сложност, която е умопомрачителна. Изкуствен интелект и ако смятате, че това, с което играем сега, с всички Siri и други свързани устройства, с които говорим, е сложно, изчакайте, докато стигнете до ситуация, когато видите нещо, наречено Olli, което е 3-D отпечатан автобус, който поема около шест души и може сам да се движи из града, а на него можете да говорите обикновен английски и той ще ви отговори. Ако удари трафик, той ще реши да завие наляво или надясно от основната зона, където има трафик. Когато завие и се тревожиш защо е завит наляво или надясно от главния път, той ще ти каже: „Не се притеснявай, предстои ми завиване наляво. Предстои трафик и аз ще го заобиколя. "
Управлението на производителността на всички системи там и цялата сложност, проследяване накъде отиват тези данни, дали те влизат в базата данни, всички взаимосвързвания и всички съответни битове е просто умопомрачително. Реалността е, че управлението на производителността и SLAs при днешна скорост и мащаб изисква инструменти и системи и по подразбиране това вече не е нещо, където просто бихте си помислили, че би било хубаво да имате инструмент - това е задължително условие; просто е абсолютно необходимо. Ето нещо като малък пример, списък на диаграмите за проектиране на приложения на високо ниво за облака, дефиниран със софтуер с отворен код. Това е просто голям къс. Това не са само сървъри и база данни. Тук всяко малко синьо петно представлява струпвания от неща. В някои случаи файлове и сървъри или стотици бази данни или, разбира се, не повече от десетки хиляди малки парчета от логически приложения на приложения. Това е малка версия. Наистина е доста умопомрачително, когато започнете да мислите за сложността, която възниква в това. Днес, дори и само в пространството с големи данни, ще сложа няколко скрийншота само на марките. Когато мислите за всички парчета, които трябва да управляваме тук, ние не говорим само за една марка задължително, това са всички марки от големия пейзаж на данни и топ марката, а не само за всеки малък малък или с отворен код. Поглеждаш и смяташ, че е доста умопомрачителна диаграма.
Нека да разгледаме няколко вертикала. Нека вземем маркетинг, например. Ето подобна диаграма, но от стековете от технологии, които се предлагат само в маркетинговите технологии. Това е графиката за 2011 г. Ето и версията за 2016 г. Помислете само, това е само броят на марките продукти, които можете да пускате за технологии по отношение на маркетинговите технологии. Не сложността на системите вътре там, не и различното приложение и уеб и разработка и мрежа и всички останали. Просто марката. Има преди, преди пет години и ето днес. Само ще се влоши. Сега сме в момента, в който е реалността, хората просто не могат да гарантират всички споразумения на ниво услуги. Не можем да се потопим в достатъчно подробности, достатъчно бързо и в необходимия мащаб. Ето пример за това как изглежда конзола за наблюдение сега. Това е като почти двадесет странни екрана, залепени заедно, преструвайки се, че са един страхотен, голям проектиран екран за наблюдение на всяко малко парче. Тук вече е интересно, няма да споменавам марката, но тази платформа за мониторинг следи едно приложение в среда на логистика и доставка. Само едно приложение. Ако се замислите какво е говорил Робин, където организациите могат да имат 40 000 бази данни сега в производствена среда. Можете ли само да визуализирате какви могат да бъдат 40 000 версии на тази колекция от екрани, които наблюдават едно приложение? Това е много смел свят, в който живеем. Както каза Робин и аз абсолютно, 100 процента ехо, че без правилните инструменти, без подходящата подкрепа и фолк на масата, използвайки тези инструменти, изпълнението на приложенията е загубена игра за хората и трябва да стане с инструменти и софтуер.
С това ще предам на нашите приятели в IDERA.
Ерик Кавана: Добре, Бил.
Бил Елис: Благодаря. Споделяне на екрана ми тук. Предполагам някой може да потвърди, че можете да видите екрана ми?
Д-р Робин Блур: Да.
Ерик Кавана: Изглежда всичко е наред.
Бил Елис: Благодаря. Единственото нещо, което той спомена, беше, че наистина не мога да чакам, е самоуправляващият се автомобил. Единственото нещо, за което не бях чувал никой да говори, е какво се случва, когато се сня? Някак се чудя дали инженерите в Калифорния разбраха, че в други части на страната снегори доста.
Дез Бланчфийлд: Харесва ми това, ще го запомня.
Ерик Кавана: Типична една миля на час.
Бил Елис: Тук сме, за да поговорим за управлението на производителността на приложенията в сложна среда. Едно нещо, за което обичам да говоря, е, че много хора, когато говорят за производителност, естеството на реакцията е, ей повече сървъри, повече процесор, повече памет и т.н. Другата страна на тази монета е ефективността на обработката. Наистина, това са две страни на една и съща монета и ще разгледаме и двете. Крайната цел е да се изпълнят споразуменията на ниво услуги за бизнес транзакциите. В крайна сметка цялата тази технология съществува за бизнеса. Говорихме за наличието на първа в индустрията база данни за управление на производителността. Идеалът на това е да се впише в идеалната форма на изпълнение и да го управлява от началото на жизнения цикъл на приложенията.
Темите наистина се свеждат до четири парчета; едното е процесът на управление на изпълнението. Разговаряхме с всички и всеки има инструменти. Ако нямат инструменти, те имат скриптове или команди, но това, което им липсва, е контекстът. Контекстът е просто свързване на точките в стековете на приложенията. Тези приложения за - са базирани на браузъра. Те са много плътно съчетани от ниво на ниво. Как взаимодействат редовете също е от жизненоважно значение. След това говорим за бизнес транзакцията. Ще осигурим видимостта не само на техническите хора, но и на собствениците на приложения и операторите.
Имам няколко казуса, за да споделя само с вас как клиентите са ги използвали. Това е много практична част от презентацията тук. Нека да разгледаме какво обикновено се случва. Харесва ми да правя диаграма - беше като невероятен колаж от технологии. Броят на технологиите в центъра за данни току-що се разраства и расте и нараства. Междувременно крайният потребител не се интересува от него и не го обръща внимание. Те просто искат да упражнят транзакцията, да е налична, да бъде завършена бързо. Това, което обикновено се случва е, че професионалистите в ИТ не знаят, че крайните потребители дори са имали проблем, докато не се самоотчитат. Това стартира вид отнемащ време, бавен процес и често разочароващ. Това, което се случва е, че хората ще отворят своите инструменти и ще погледнат подмножество от стека на приложенията си. С това подмножество става много трудно да се отговори на най-простия въпрос. Обичайно ли е да имате проблем? Каква сделка е? Къде в стека на приложения е тясното място? Прекарвайки цялото това време, гледайки ниво на ниво, не сте в състояние да отговорите на тези въпроси, вие в крайна сметка харчите много време и енергия, много персонал, средства и енергия.
За да се реши това, за да се осигури по-добър начин, това, което прави Precision, всъщност е да предприеме транзакцията за проследяване на крайния потребител, улавя метаданни за него, следва транзакцията през мрежата, в уеб сървъра, в слоя на бизнес логиката и ние поддържаме .NET и ABAP, PeopleCode и E-Business Suite, в многостранни приложения, че в крайна сметка всички транзакции ще взаимодействат със системата на запис. Независимо дали става въпрос за търсене на инвентара, за отчитане на отработеното време, те винаги взаимодействат с базата данни. Базата данни се превръща в основата на бизнес резултатите. Базата данни от своя страна разчита на съхранение. Какво отговаря на метаданните за транзакциите, кой, коя транзакция, къде в стека на приложения и след това имаме дълбока видимост на ниво код, за да ви покажем какво се изпълнява. Тази информация се улавя непрекъснато, поставя се в базата данни за управление на производителността - това се превръща в един лист музика за всеки, за да види какво се случва. Има различни хора и организации, които се интересуват от случващото се: техническите експерти, собствениците на приложения, в крайна сметка самият бизнес. Когато се появи проблем, искате да можете да извлечете информация за тази транзакция.
Преди да разгледаме инвестиционната транзакция, искам да ви покажа как това може да изглежда на различни хора в организацията. На ниво управление можете да имате преглед на множество приложения. Може да искате да знаете за здравословното състояние, което се изчислява от спазването на SLA и наличността. Това здраве не означава, че всичко е на 100 процента работи перфектно. В този случай има място, за което можете да видите, че инвестиционната транзакция е в състояние на предупреждение. Сега, малко по-задълбочено, може би в сферата на бизнеса, искате да имате някои допълнителни подробности относно отделните транзакции, когато те нарушават SLAs, броя на транзакциите и т.н. Оперативният екип ще иска да бъде уведомен за това чрез предупреждение на някои вид. Вградени сме сигнали за ефективност. Всъщност измерваме ефективността в браузъра на крайния потребител. Независимо дали става въпрос за Internet Explorer, Chrome, Firefox и т.н., ние можем да открием, това отговаря на първия въпрос: има ли проблем с крайния потребител?
Нека се потопим и да видим какво още можем да покажем за това. Хората, които се интересуват от представянето, ще отворят Precision. Те биха оценили транзакциите. Те ще разгледат колоната за SLA, за да идентифицират транзакции, които не са съвместими със SLA. Те ще могат да видят крайните потребители, които са били засегнати, както и какво е направила тази транзакция, докато е преминала през приложението. Начинът, по който дешифрирате тези йероглифи, това е браузърът, URL адресът, U е за URL, това е входната точка в JVM. Сега този конкретен JVM извиква уеб сървър към втория JVM, който след това изпълнява SQL оператора. Това очевидно е проблем с базата данни, тъй като това SQL изявление е отговорно за 72 процента от времето за отговор. Ние сме фокусирани върху времето. Времето е валутата на изпълнението. Това е начина, по който крайните потребители изпитват дали нещата вървят бавно или не, и това е мярка за потреблението на ресурси. Много е удобен; това е един вид показател, който е най-важен за оценка на ефективността. Когато този проблем се предаде на DBA, това не е просто проблем с база данни, това е SQL изявление. Това е контекста, за който говорих.
Сега въоръжен с тази информация, мога да вляза и да анализирам случилото се. Виждам на първо място, Y-оста е време през деня. Извинете, y-оста е времето за отговор, x-os е време през деня. Виждам, че има проблем с базата данни, има две събития, върнете се в този поток, вземете това SQL изявление и отидете в експертния изглед, където Precision е в състояние да ви покаже какво се случва, неговите контроли, колко време отнема този код изпълни. В подреждането на базата данни това е планът за изпълнение. Ще отбележите, че Precision е избрал реалния план за изпълнение, използван по време на изпълнение, който се различава от прогнозния план, който би бил, когато планът е бил даден, а не по време на изпълнение. Възможно е или не може да отразява, че базата данни всъщност е била.
Сега тук долу е анализът на времето за отговор на SQL оператора. Деветдесет процента от времето, прекарано в съхранение; десет процента бяха използвани в процесора. Виждам текста на SQL израза, както и доклада за констатациите. Текстът на SQL израза всъщност започва да разкрива някои проблеми с кодирането. Това е избрана звезда; който връща всички редове - извинете ме, всички колони от върнатите редове. Обръщаме обратно допълнителни колони, които приложението може или не може да има нужда. Тези колони консумират пространство и ресурси за обработка. Ако стартирате SAP, една от големите промени, тъй като базата данни на HANA е колонна, е, че основно пренаписване на SAP, за да не се избира избрана звезда, така че те да намалят значително потреблението на ресурси. Това всъщност е нещо, което се случва много време и в домашни приложения, независимо дали Java, .NET и т.н.
Този екран, това ви показва кой, какво, кога, къде и защо. Защо стига до, като SQL оператора и план за изпълнение, който ви позволява да решавате проблеми. Тъй като Precision работи непрекъснато, всъщност можете да измервате преди и след това, на ниво SQL изявление, на ниво транзакция, така че или можете да измервате за себе си, както и чрез собствениците на приложения и за управление, че сте решили проблема, Тази документация е наистина полезна. В този стек на приложения има много сложност. Всъщност от много приложения всички, с които сме говорили, изпълняват поне част от стека на приложенията под VMware. В този случай те разглеждат приложението за обслужване на клиенти, разглеждат времето за транзакция и го свързват със забавянето е събитие за виртуализация. Прецизно проследява всички събития за виртуализация. Имаме приставка към vCenter, за да вземем това.
Ние също сме в състояние да открием спора. Спорът е различен от използването. Всъщност показва, когато може би шумен съсед влияе на виртуалния ви сайт, в контекста на приложението на клиентския сървър. Сега мога да проуча и да получа информация и всъщност мога да видя двете виртуални машини, които се конкурират в този случай за ресурси на процесора. Това ми позволява да имам видимост, така че да мога да гледам график. Мога да сложа гост VM на различен физически сървър. Всички тези типове неща, на които може да отговорите и след това в допълнение към това, всъщност мога да разгледам ефективността на кода, за да го накарам да използва по-малко процесор. Мисля, че имам доста добър пример в това представяне на това как някой успя да намали консумацията на процесори с порядък.
Това беше VMware. Нека да влезем в самия код, кода на приложението. Точните ще могат да ви покажат какво се случва в Java, .NET, ABAP код, E-Business, PeopleCode и т.н. Това са входните точки в, в този случай, в WebLogic. Тук долу има доклад за констатациите, който ми казва, че трябва да разгледате тези EJB, и ще ми каже, че и вие имате заключване в тази система. Още веднъж, проучването надолу в слоя на бизнес логиката, за да покаже какво се случва. В този случай разглеждам конкретни случаи; Подкрепям и клъстеризирането. Ако имате многобройни JVMs, можете или да разгледате клъстера като цяло, или да разгледате затрудненията в отделните JVM.
Когато влезете в заключване, мога да попадна на изключения. Изключението е малко по-различно от проблема с производителността. Обикновено изключенията се изпълняват много бързо. Тъй като има логическа грешка и след като натиснете тази логическа грешка, тя свършва. Успяхме да заснемем следа в стека в разцвета на изключение, това може да спести много време, тъй като минава през опит да разберем какво се случва, просто имате следата в стека, точно там. Ние също можем да уловим течове на памет. Решението включва също и ниво на базата данни, мога да вляза, мога да оценя инстанцията на базата данни. Отново y-оста е мястото, където е прекарано времето, x-os е времето през деня. Има доклад за констатациите, който просто автоматично ми казва какво се случва в системата и какво бих могъл да погледна.
Едно от нещата в отчета за констатациите на Precision, той не просто разглежда журнали или състояние на изчакване - той разглежда всички състояния на изпълнение, включително CPU, както и връщане на информация от съхранение. Съхранението е много важна част от стека на приложенията, особено с появата на твърдо състояние. Информацията по тези линии може да бъде много полезна. За определени единици за съхранение можем всъщност да пробием и да покажем какво се случва на ниво отделно устройство. Този тип информация - отново, това е дълбока видимост; той е широк по обхват - да ви даде достатъчно информация, за да имате повече възможности за използване като професионалист по приложението, така че да можете да оптимизирате приложенията си от край до край, за да посрещнете тези бизнес транзакции.
Имам няколко казуса, които исках да споделя с вас. Ние обикаляме доста бързо; Надявам се да вървя с добро темпо. Говорейки за съхранение, всеки с времето сменя хардуера. Има хардуерна гаранция. Наистина ли достави това, което ви каза продавачът? Можете да оцените това с Precision. Влизате и какво се е случило тук, те основно поставят ново устройство за съхранение, но когато администраторите за съхранение погледнаха точно на ниво единица за съхранение, те видяха много спорове и смятаха, че може да има проблем с тази нова единица за съхранение, Гледайки повече от гледна точка от край до край, точно за да покажем къде всъщност ще се случи това. Те всъщност отидоха от пропускателна способност от около 400 мега в секунда, където съхранението беше отговорно за 38 процента от времето за реакция, така че е доста високо. С новото устройство за съхранение всъщност натрупахме пропускателната способност до шест, седемстотин мега в секунда, така че в общи линии се удвоява и ние сме в състояние да намалим наполовина приноса на ниво на съхранение към времето за транзакция. Всъщност мога да графирам това преди, това е периодът на прекъсване и след това.
И така, още веднъж, документация, която да докаже, че инвестицията в хардуер си заслужава и те предоставиха така, както очакваше този конкретен доставчик. Има всичко, поради сложността, броя на нещата, има всякакви неща, които могат да се случат. В този случай те всъщност имаха ситуация, в която всички бяха обвиняващи DBA, DBA беше като „Е, не е толкова бързо.“ Тук всъщност разглеждаме приложение на SAP, мисля, че този тип сценарии е доста често срещан, Това, което се случи, бяха да разработят персонализирана транзакция за потребител. Потребителят е: „Това е толкова бавно“. Кодерът ABAP - това е езикът за програмиране в SAP - каза: „Това е проблем с базата данни.“ Те в крайна сметка отвориха Precision; те измериха този краен потребител 60 секунди, така че много повече от минута. Петдесет и три секунди бяха изкарани в задния край. Те пробиха в задния край и всъщност успяха да разкрият SQL израза, представен в низходящ ред.
Това най-високо SQL изявление, което е отговорно за 25 процента от потреблението на ресурси, средното му време за изпълнение е две милисекунди. Не можете да обвинявате базата данни. Знаеш ли, ей, не толкова бързо, човек. Въпросът е защо има толкова много екзекуции? Е, върнаха го обратно към ABAP, той влезе, погледна към вмъкването на цикъла, разбра, че извикват базата данни на неправилно място, по същество направиха промяната, тестваха промяната и сега новото време за реакция е пет секунди Малко бавно, но те биха могли да живеят с това. Далеч по-добре от 60 секунди. Понякога, просто извличане, това е кодът на приложението, база данни ли е, съхранение ли е? Това са областите, в които Precision, като има контекста на транзакциите от край до край, ето къде играе Precision. По принцип прекратявате тези неща.
Гледам времето, изглежда, че все още имаме малко време да преминем през още няколко от тях. Предавам през тях. Това приложение се разработва повече от година. Когато влязоха в QA, те видяха, че уеб сървърите са максирани 100 процента и изглежда, че приложението не може да работи под VMware. Първото нещо, което всички казаха, беше: „Поставете това на физическо; не може да работи под VMware. ”Точно всъщност им предложи допълнителни начини за решаване на проблема. Разгледахме транзакциите, видяхме повикване на уеб сървър, той влиза като ASMX в IIS.NET. Той всъщност разкри основния код. Виждате ли това, където съм сочен? Това е 23 дни, 11 часа. Леле, как е възможно това? Е, всяко извикване отнема 9, 4 секунди и това нещо се извиква 215 000 пъти. За всяко извикване той използва 6 секунди процесор. Това е причината, този код е причината това нещо никога да не може да бъде мащабирано. Всъщност тя не можеше да мащабира във физическото.
Това, което направиха, се върнаха при своите разработчици и те казаха: „Може ли някой да направи промяна?“ Те някак си имаха конкурс и тестваха различните предложения и излязоха с предложение, което успя да изпълни много по-ефективно. Новият завърши една точка, малко по-малко от две секунди, с две стотни от секундата в процесора. Сега това може да се мащабира и може да работи във фермата на VMware. По принцип успяхме да документираме това както на ниво код, така и на ниво транзакция. Това е вид преди, а след това и след. Сега, когато можете да видите тук в графиката на стека, която показва уеб, .NET и база данни, сега взаимодействате с базата данни. Това е профил, който бихте очаквали да видите за приложение, което работи по-нормално.
Добре, подбирам и избирам по отношение на допълнителни неща, които мога да ви покажа. Много хора харесват това, защото това покрива много магазини. Ако не можете да се срещнете с SLA за бизнес и всички са като: „Помогнете ни.“ В този магазин имаше ситуация, в която бизнес SLA е в поръчки, получени до 15:00, той се доставя този ден. Наистина е жизненоважно, че те изваждат поръчките, а складът е много зает. Този екран за поръчки на JD Edwards беше замразен и можете да получите много добра представа, че това е току-що въведена система за управление на инвентаризацията на дребно. Празните рафтове са недопустими в търговията на дребно. Трябва да има стоката там, за да я продаде. Това, което направихме е, че се потопихме в този случай, разглеждаме базата данни на SQL сървъра. Външният вид е същият, независимо дали е SQL, Oracle, DB2 или Sybase.
Ние идентифицирахме избраното от PS_PROD и успяваме да уловим продължителността, фактът, че те изпълняват толкова много. Тъмно синьото съответства на ключа, който казваше, че не чакат някакво състояние на изчакване или някакво регистриране или дори съхранение - това нещо е обвързано от процесора. Проследихме SQL израза до 34301, така че всеки път, когато това се изпълнява, увеличаваме броячите си, за да го следим. Това означава, че имаме подробна история и мога да достъпа до нея, като щракна върху този мелодия. Ето раздела история. Този екран тук показва средна продължителност спрямо промените. Сряда, четвъртък, петък, средната продължителност беше около две десети от секундата. Много малко екрани замръзват, те са в състояние да се срещнат с бизнес SLA. Елате 27 февруари, нещо се променя и внезапно времето за изпълнение е тук и това всъщност е достатъчно бавно, за да предизвика изчакване, което води до замръзване на екрана. Точно, като запазите подробна история, включително план за изпълнение и общи промени в индексите на таблицата, ако този SQL се използва. Успяхме да разберем, че планът за достъп се промени на 27 февруари. От понеделник до петък лошата седмица. Елате на 5 март, планът за достъп отново се промени. Това е добра седмица. Тази розова звезда ни казва обновения обем.
Можете да видите тук броят на редовете в основните таблици нараства и това е типично за бизнес. Искате вашите маси да растат. Работата е там, че операторите са анализирани, SQL операторите влизат, оптимизаторът трябва да реши какво да прави и да избере, когато планът за изпълнение е бърз, да избере друг план за изпълнение, когато е бавен, което води до замръзване на екрана. На дълбока технологична основа трябва да знам какъв е планът за изпълнение и Precision го заснема в комплект с печат на дата и час. Това е бързото и ефективно, това е бавно и неефективно. Това свързване на филтри просто използва много повече процесор за съгласуване, за да направи това конкретно SQL изявление. Те все още имат същия краен ефект, но този в основата си има по-бавна, по-малко ефективна рецепта за предоставяне на набора от резултати. И така, ние преминаваме през. Ей, имаме ли време за още няколко?
Ерик Кавана: Да, продължи.
Бил Елис: Добре, ще прескоча напред. Едно нещо, което искам да направите забележка, говорихме за хардуер, говорихме за SAP, говорихме за .NET, говорихме за JD Edwards и средата на Java-SQL Server. Това е SAP, тук разглеждаме PeopleSoft. Поддържащата матрица на Precis е широка и дълбока. Ако имате приложение, повече от вероятно можем да го инструментираме, за да осигурим това ниво на видимост. Една от най-големите промени, които се случват в момента, е мобилността. PeopleSoft представи мобилност със своя Fluid UI. Fluid UI използва система много различно. Това приложение се развива. Fluid UI - това, което прави от гледна точка на управлението е, че позволява на крайните потребители да използват телефона си и това значително увеличава производителността. Ако имате стотици хиляди или дори повече служители, ако можете да увеличите тяхната производителност, 1-2%, можете да окажете огромно влияние върху заплатите и всичко останало. Това, което се случи, беше, че този конкретен магазин разгърна потребителския интерфейс PeopleSoft Fluid. Сега, като говорим за сложността, това е стека PeopleSoft. Едно приложение, минимум шест технологии, множество крайни потребители. Как да започнете?
За пореден път Precision ще може да следва тези транзакции. Това, което ви показваме тук, е подредена базова графика, показваща клиент, уеб сървър, Java, база данни Tuxedo, стек от приложения PeopleSoft. Зелените карти на J2EE, което е нещо като фантастичен начин да се каже WebLogic. Това е прекъсването. Крайните потребители започват да използват Fluid UI и времето за реакция преминава от около една и половина, две секунди, до около девет, десет секунди. Това, което този екран не показва, е броят на хората, които „не реагират“. Те всъщност замразяват екрана в приложението. Нека да разгледаме някои от видимостта, която Precision е в състояние да предостави на този клиент.
На първо място, когато разгледам транзакциите на PeopleSoft, те могат да видят основно, ние видяхме този тип неща навсякъде. Всички транзакции бяха засегнати, както и всички местоположения. Между другото, когато погледнете това, всъщност можете да видите места по целия свят. От Азиатско-Тихоокеанския басейн, в Европа, както и в Северна Америка. Проблемът с производителността не беше разположен в конкретна транзакция или конкретно географско местоположение, а в цялата система. Това е някакъв начин да се каже, че промяната или начинът, по който Fluid UI има глобално въздействие. Можете да видите тук от гледна точка на мащабируемостта, хората се опитват да извършват един и същ вид на активност, но времето за реакция по принцип е просто влошено и влошено. Можете да видите, че нещата не са мащабирани. Нещата вървят много, много зле. Тук, когато гледам броя на оста и едновременните връзки, виждате нещо, което е много интересно по отношение на броя на достъпа и връзките. Тук ние мащабираме само до около 5000 и вие разглеждате, това достига до 100 едновременни връзки. Това се прави след; това е преди. И така, какво е моето реално търсене в системата, ако това нещо може да се мащабира, е в обхвата от 300 000. В стари времена с класическия потребителски интерфейс търсите 30 едновременни връзки.
Това, което ви казва това е, че Fluid UI използва поне 10x броя едновременни връзки. Започваме да дърпаме назад случващото се под капаците с PeopleSoft, за да можете да започнете да виждате въздействието върху уеб сървърите, факта, че SLA започват да се нарушават. Няма да навлизам във всичко, но това, което в крайна сметка се случва, е, че те основно разчитат на съобщения. Те по принцип са WebLogic и причиняват опашки в Tuxedo. Всъщност имаше проблем с мултиерийна зависимост, който се появи с Fluid UI, но Precision успя да покаже, че с куп различни неща можем да се съсредоточим върху проблема. Оказва се, че имаше проблем и в самата база данни. Всъщност има лог файл за съобщения и поради всички едновременни потребители, този лог файл се заключва. По принцип имаше неща, които трябва да се настройват, във всеки отделен слой в стека на приложението. Говорете за сложността, ето всъщност слоят Tuxedo ви показва опашката и можете да видите представянето, влошаващо се и в този слой. Виждах процесите; Виждах домейните и сървърите. В Tuxedo, за хората, които да използват това, обикновено това, което правите е да отворите допълнителни опашки, домейни и сървъри, точно както в супермаркета, за да облекчите задръстванията, за да сведете до минимум времето за опашка. Последна и последна опция, Precision показва много информация.
Както споменах по-рано, всяка значима транзакция взаимодейства със системата от записи. Видимостта в базата данни е от първостепенно значение. Точно показва какво се случва в базата данни, в WebLogic, в Java, .NET, в браузъра, но мястото, което Precision наистина превъзхожда, е в нивото на базата данни. Това е слабостта на нашите конкуренти. Позволете ми да ви покажа един от начините, по които Precision може да ви помогне да преминете през това. Няма да отделя време за триъгълника на оптимизацията на базата данни, но основно разглеждаме нискотарифни, нискорискови, широкообхватни, високорискови, висококачествени промени в типа. Всъщност ще туитвам този слайд след това, ако хората искат да опитат и да го погледнат. Според мен това е доста голямо ръководство за проблеми с настройката. Ето експертното мнение на Precision for Oracle. Най-отгоре в доклада за констатациите, 60-процентното въздействие е това конкретно SQL изявление. Ако отворите този екран на дейност, той го показва там. Мога да разгледам това изявление за избор, има един план за изпълнение. Всяко изпълнение отнема секунда - 48 000 екзекуции. Това добавя до 48 000 повече екзекуции.
Тъмно синьото отново е CPU. Това нещо е свързано с процесора, а не състояние на изчакване, не лог. Подчертавам, че тъй като някои от нашите конкуренти гледат само състояния на изчакване и събития на регистрация, но като цяло, процесорът е най-натовареното състояние на изпълнение и предлага най-много обратно изкупуване. Навлизайки в този експертен изглед - и аз отивам много бързо - това, което направих, е, че погледнах масата, 100 000 реда, 37 000 блока. Правим пълна таблица, но въпреки това имаме шест индекса на това нещо. Какво става тук? Е, когато гледам клаузата къде, това, което прави тази клауза, е, че всъщност преобразува колона в големи букви и казва къде е равно на главни, намери променлива. Случва се всеки път, когато това нещо се изпълнява, Oracle трябва да преобразува тази колона в големи букви. Вместо да правим това близо петдесет хиляди пъти, е много по-ефективно да се изгради този индекс в главни букви на индекс, базиран на функции, и той е достъпен не само в подразделението на Oracle Enterprise, но и в стандартното разделение. Когато направите това, това, което можете да направите, е да проверите плана за изпълнение, издавайки този нов потребител на индекс Perm в главни букви, това беше просто нещо мое нещо.
След това, от измерване преди и след това, гледате на една секунда време за изпълнение, обобщава до 9 часа 54 минути, със същия точен SQL израз, но с този индекс вграден в големи букви за 58 000 екзекуции, отговорът времето пада до подмилисекунди, агрегира се заедно, стига до седем секунди. По принцип спестих десет часа процесор на моя сървър. Това е огромно. Защото, ако не ми се налага обновяване на сървъра, мога да живея на този сървър. Всъщност намалявам използването на сървъра с 20 процента и всъщност можете да видите преди и след това. Това е видът на видимост, който Precision може да осигури. Има и някои допълнителни неща, които бихме могли да разгледаме, защо имате всички тези индекси, ако не се използват? Те могат да продължат с това. Има архитектура и аз ще я затворя, тъй като достигаме върха на часа. Аз съм истински вярващ в това решение и искаме да сте истински вярващ. В IDERA вярваме, че пробен период прави клиент, така че ако се интересувате, можем да направим оценки на вашия сайт.
С това ще върна маяка обратно.
Ерик Кавана: Да, това беше огромна подробност, която показахте там. Наистина е доста завладяващо. Мисля, че може би съм ви споменавал в миналото, че - и знам в някои от другите уеб предавания, които сме правили с IDERA, съм го споменал - всъщност проследявам Precision, преди да бъде придобита от IDERA, чак през 2008 г., мисля, или през 2009 г. Бях очарован от него тогава. Любопитно ми е да знам колко много работи е да останеш над новите версии на приложенията. Споменахте, че SAP HANA, който според мен беше доста впечатляващ, че всъщност можете да се ровите в архитектурата на HANA и да направите някои проблеми за там. Колко хора имате? Колко усилия е от ваша страна и колко от това може да се направи някак динамично, което означава, когато инструментът се разгърне, започнете да пълзите наоколо и виждате различни неща? Колко от това може да бъде установено динамично, нещо като, установено от инструмента, така че да помогнете на хората да отстраняват сложни среди?
Бил Елис: Зададохте много въпроси там.
Ерик Кавана: Знам, извинявай.
Бил Елис: Аз предоставих много подробности, защото за тези приложения, като гледам кода, дяволът е в детайла. Трябва да имате това ниво на детайлност, за да можете наистина да имате нещо, което е изпълнимо. Без приложими показатели просто знаете за симптомите. Всъщност не решавате проблеми. IDERA е за решаване на проблеми. Оставането на върха на новите версии и други неща е голямо предизвикателство. Въпросът какво е необходимо за това, това наистина е за управление на продуктите. Нямам много видимост в екипа, който по принцип ни държи в течение на нещата. По отношение на HANA, това всъщност е ново допълнение към продуктовата линия IDERA; много е вълнуващо Едно от нещата с HANA е - нека да говоря за задачата за секунда. В тази задача магазините на SAP биха направили, че ще копират база данни за целите на отчитането. Тогава ще трябва да накарате хората да се примирят с това, което всъщност е актуално. Ще имате тези различни бази данни и те ще се синхронизират на различни нива. Има само много време и усилия, плюс хардуер, софтуер и хора, които да поддържат всичко това.
Идеята на HANA да има високо паралелна база данни в паметта, за да се избегне необходимостта от дублиране на бази данни. Имаме една база данни, един източник на истина, тя винаги е актуална, по този начин вие избягвате необходимото да направите всичко това помирение. Значението на работата на базата данни на HANA нараства - искам да кажа 10 пъти или поне по-ценно от сбора на всички онези други бази данни, хардуер, ресурси, които могат да купят. Да можеш да управляваш HANA, сега този компонент всъщност е в бета тестване в момента, това е нещо, което ще започне GA скоро. Така че това е доста вълнуващо за IDERA и за нас, че основно поддържаме SAP платформата. Не съм сигурен в кои други части на въпроса ви го променям, но -
Ерик Кавана: Не, това са всичко хубаво. Хвърлих цял куп наведнъж, така че съжалявам за това. Просто съм очарован, наистина, искам да кажа, че това не е много просто приложение, нали? Копаеш дълбоко в тези инструменти и разбираш как те си взаимодействат помежду си и до теб, трябва да подредиш историята заедно в главата си. Трябва да комбинирате битове информация, за да разберете какво всъщност се случва и какво ви създава неприятностите, така че можете да влезете там и да разрешите тези проблеми.
Един от участниците пита, колко е трудно да се приложи Precision? Друг човек попита кои са хората - очевидно DBA, но кои са някои други роли в организацията, които биха използвали този инструмент?
Бил Елис: Прецизността е малко по-сложна за разгръщане. Трябва да имате известни познания за приложната среда, по отношение на, знаете, това приложение работи на тази база данни, то се нуждае от това или - средните нива на сървърите и т.н. Мисля, че предвид сложността на някои от тези приложения, всъщност е сравнително лесно. Ако мога да инструментирам уеб сървъра до вашата база данни, мога да го направя от край до край. Забелязвате, че не казах нищо за инструментализирането на клиент за краен потребител и това е така, защото това, което правим е, ние всъщност включваме динамично, така че не е нужно да променяте кода или нещо друго. JavaScript влиза в рамката на страницата на приложението. Без значение къде се намира потребителят в света, когато той има достъп до URL адреса от приложението ви и те свалят тази страница, той се снабдява с Precision. Това ни позволява да изберем идентификационния номер на потребителя, техния IP адрес, както и времето за представяне на първия байт на всяко от страницата за изпълнение на скрипта на компонентите на страницата в браузъра на крайния потребител.
По отношение на транзакциите не е нужно да правите картографски транзакции, защото те са плътно свързани. Този URL адрес става входна точка за JVM и след това се позовава на това съобщение, в резултат на което JVC е хванат от базата данни. По принцип сме в състояние да уловим тези естествени точки на връзка и след това да ви ги представим в този екран за транзакции, който ви показах къде сме изчислили също колко време или процентът време, прекарано във всяка отделна стъпка. Всичко това се извършва автоматично. Най-общо казано, отделяме 90 минути, за да направим - основно да инсталираме Precision core и след това да започнем да прилагаме приложението. В зависимост от познанието на приложението, може да ни отнеме няколко допълнителни сесии, за да се снабди с цялото приложение. Много хора използват само компонента на базата данни на Precision. Това е добре. Можете по принцип да разбиете това, да го разделите на компонентите, които чувствате, че вашият сайт се нуждае. Определено вярваме, че контекстът на разполагане на целия стек на приложения е инструментален, така че можете да видите, че зависимостта от ниво на ниво всъщност увеличава стойността на мониторинга на отделен слой. Ако някой иска да проучи допълнително инструменталния си стек, моля, отидете на нашия уебсайт - предполагам, че това е най-лесният начин да поискате допълнителна информация и ще го обсъдим малко по-нататък.
Ерик Кавана: Нека ви задам един или два бързи въпроса. Предполагам, че във времето събирате и изграждате хранилище, както за отделни клиенти, така и като корпоративно образувание, на взаимодействия между различни приложения и различни бази данни. С други думи, предполагам моделиране на сценарии. Така ли е? Поддържате ли всъщност хранилище от общи сценарии, така че да можете да правите предложения на крайните потребители, когато някои неща влязат в игра? Като тази версия на E-Business Suite, тази версия на тази база данни и т.н. - правите ли много от това?
Бил Елис: Е, този тип информация е вградена в доклада за констатациите. В доклада за констатациите се казва какви са пречките за изпълнение и се основава на времето за изпълнение. Част от този доклад за резултатите е научете повече и какво правите по-нататък. Информацията или опитът на клиентите и т.н. е основно включена в тази библиотека с препоръки.
Ерик Кавана: Добре, това звучи добре. Ами хора, фантастично представяне днес. Бил, много ми хареса колко подробности имаш там. Просто мислех, че това е наистина фантастична, зърнеста, подробна информация, показваща как се правят всички тези неща. В определен момент това е почти като черна магия, но наистина не е така. Това е много специфична технология, която момчетата комбинирате, за да разберете много, много сложна среда и да направите хората щастливи, защото никой не харесва, когато приложенията работят бавно.
Ами хора, ние ще архивираме това излъчване. Можете да скачате онлайн на Techopedia или insideanalysis.com и уау, благодаря за отделеното време, ние ще ви догоним следващия път. Внимавайте, чао-чао.
