Autors: Techopedia Staff, 2016. gada 2. novembris
Izņemšana: Uzņēmējs Ēriks Kavanaghs apspriež lietojumprogrammu veiktspēju un to, kā uzlabot efektivitāti, ar Dr. Robinu Blooru, Dezu Blanšfīldu un IDERA vadītāju Bilu Ellisu.
Pašlaik neesat pieteicies. Lai redzētu video, lūdzu, pierakstieties vai reģistrējieties.
Ēriks Kavanagh: dāmas un kungi, sveicināti un vēlreiz sveicam Hot Hot Technologies. Jā, patiesi! Mans vārds ir Ēriks Kavanaghs. Es šodien būšu jūsu vietnieks vēl vienai interneta pārraidei šajā patiešām jautrajā, aizraujošajā seriālā, kuru esam ieguvuši kā komplimentu mūsu Briefing Room sērijai. Nosaukums ir “Lietojumprogrammu paātrināšana: ātrāka veiktspēja lietotājiem”. Nāc, ļaudis, kas to nevēlas? Ja es esmu tas puisis, kurš palīdz jūsu lietojumprogrammai darboties ātrāk, es domāju, ka es esmu tas, kurš puisis pēc darba saņem man alus, ko nopirku bārā. Tā ir diezgan forša lieta, lai ieietu un paātrinātu ikviena pieteikšanos.
Tur ir slaids par tavu patiesi, mani uzpūta Twitter @Eric_Kavanagh. Es vienmēr cenšos sekot līdzi un vienmēr atkārtoju čivināšanu, ja jūs mani pieminat, tāpēc jūtieties brīvi pieminēt mani.
Viss šīs izrādes mērķis ir pievērsties dažādiem uzņēmuma tehnoloģiju aspektiem un, ja vēlaties, patiešām palīdzēt noteikt noteiktas disciplīnas vai noteiktas sejas. Daudzas reizes pārdevēji izvēlēsies noteiktus mārketinga nosacījumus un runās par to, kā viņi dara šo vai citu, vai citu lietu. Šī izrāde patiešām bija izstrādāta, lai palīdzētu mūsu auditorijai saprast, kāds programmatūras rīks ir nepieciešams, lai būtu līderis savā telpā. Formāts ir divi analītiķi. Katrs iet pirmais, atšķirībā no informatīvās telpas, kur pārdevējs dodas pirmais. Katrs pats uzņemas to, kas, viņuprāt, ir svarīgi, lai jūs zināt par konkrētu tehnoloģiju.
Šodien mēs runājam par lietojumprogrammu paātrināšanu. Mēs dzirdēsim no Deza Blanšfīlda un arī no doktora Robina Bloora - mēs šodien esam visā pasaulē -, un tad Bils Ellijs iezvanās no lielākās Virdžīnijas teritorijas. Līdz ar to es nodošu to mūsu pirmajam vadītājam Dr. Blooram. Starp citu, mēs tviterī ievietojām #podcast hashtag, tāpēc jūtieties brīvi tweet. Ņem to prom.
Dr Robin Bloor: Labi, labi, paldies par šo ievadu. Lietojumprogrammu veiktspēja un pakalpojumu līmeņi - tā ir sava veida joma, gadu gaitā šajā jomā esmu paveicis daudz darba, kas nozīmē, ka patiesībā esmu paveicis šausmīgi daudz darba, pārraugot veiktspēju un izstrādājot darbu vienā tā vai citādi, kā izmēģināt un aprēķināt šos līmeņus. Jāsaka, ka līdz - mums kādreiz bija šis laikmets, pirms kāda laika cilvēki būvēja sistēmas tvertnēs. Būtībā darba apjoms, kas viņiem faktiski jādara, lai sistēma darbotos samērā labi, ja tas atradās tvertnē, patiesībā nebija pārāk smags, jo ir ļoti maz, ļoti mazs mainīgo daudzums, kas jums bija jāņem vērā. Tiklīdz mēs tikām pienācīgi savienoti, vienādojumā ienāca interaktīva un orientēta uz pakalpojumu. Tas kļuva mazliet grūti. Performance var būt viendimensionāla. Ja jūs domājat tikai par lietojumprogrammu, kas atkārtoti izpilda noteiktu koda ceļu, darot to saprātīgi un savlaicīgi, tas jūtas kā viendimensionāla lieta. Tiklīdz jūs sākat runāt par pakalpojumu līmeņiem, jūs faktiski runājat par vairākām lietām, kas konkurē par datora resursiem. Tas ļoti ātri kļūst daudzdimensionāls. Ja sākat runāt par biznesa procesiem, biznesa procesus var savienot kopā no vairākām lietojumprogrammām. Ja jūs runājat par uz pakalpojumiem orientētu arhitektūru, tad konkrētā lietojumprogramma faktiski var piekļūt vairāku programmu iespējām. Tad tā kļūst par ļoti sarežģītu lietu.
Es paskatījos - sen es uzzīmēju šo diagrammu. Šī diagramma ir vismaz 20 gadus veca. Būtībā es to saucu par visa diagrammu, jo tas ir veids, kā aplūkot visu, kas pastāv IT vidē. Tas tiešām ir tikai četri gabali: lietotāji, dati, programmatūra un aparatūra. Protams, tie laika gaitā mainās, bet, apskatot šo, jūs patiešām saprotat, ka katram no šiem gabaliem ir hierarhisks eksplozija. Aparatūra jā, aparatūra var būt serveris, bet serveri veido, iespējams, vairāki CPU, tīkla tehnoloģija un atmiņa, un tas ir šausmīgi daudz kontrolieru, kā tas notiek. Ja patiesībā paskatās uz šo, tas viss sadalās gabalos. Ja jūs patiešām domājat par to, kā mēģināt visu organizēt, mainoties datiem, mainās programmatūras veiktspēja, jo mainās aparatūra un tā tālāk un tā tālāk, jūs patiesībā skatāties neticami grūtā, daudzpusīgā situācijā. Šī ir sarežģītības līkne. Protams, tā ir sarežģītības līkne gandrīz visam, bet es esmu to redzējis atkal un atkal, runājot par datoriem. Būtībā, ja jūs ievietojat mezglus uz vienas ass un svarīgos savienojumus uz otras ass, jūs galu galā saņemat sarežģītības līkni. Gandrīz nav svarīgi, kas ir mezgli un savienojumi, un tas tiks darīts, ja vēlaties, lai tālruņa tīklā tiktu parādīts apjoma pieaugums.
Patiesībā, runājot par mezgliem datoru vidē, jūs runājat par atsevišķām lietām, kas rūp viena otrai. Sarežģītība, izrādās, ir dažādības struktūras jautājums un dažādi ierobežojumi, kuriem jūs mēģināt pakļauties. Arī skaitļi. Kad skaitļi palielinās, viņi iet traki. Man vakar bija interesanta tērzēšana, es runāju ar kādu - es nevaru nepieminēt, kas viņš bija, bet tam nav īsti nozīmes - viņi runāja par vietni, kurā bija 40 000 - tas ir četru nulles, 40 000 - datu bāzu gadījumi vietnē. Iedomājieties tikai to - 40 000 dažādu datu bāzu. Protams, vienīgais, kas mums bija - viņiem acīmredzot bija daudz, daudz tūkstošu pieteikumu. Mēs runājam par ļoti lielu organizāciju, bet es to nevaru nosaukt. Jūs to patiesībā skatāties, un jūs faktiski cenšaties vienā vai otrā veidā iegūt tādu pakalpojumu līmeni, kas būs atbilstošs visiem lietotājiem vairākiem lietotājiem, ar vairākām atšķirīgām, ja vēlaties, cerībām. Tā ir sarežģīta situācija, un es tikai saku, ka šī lieta ir sarežģīta. Skaitļi vienmēr palielinās. Ierobežojumus nosaka biznesa procesi un biznesa mērķi. Jūs būsiet pamanījis, kā mainās cerības.
Es atceros, tiklīdz parādījās Gmail, Yahoo un Hotmail, visas šīs pasta sistēmas, cilvēki sāka cerēt, ka viņu iekšējās pasta sistēmas organizācijā pelnīs šo milzīgo operāciju pakalpojumu līmeni ar plašām serveru fermām ārpusē organizāciju un sāka spiedienu, lai visas šāda veida lietas notiktu. Faktiski pakalpojumu līmeņa vienošanās ir viena lieta, bet cerības ir cita lieta, un organizācijas tās savstarpēji cīnās, kas ir neērta lieta. Šeit ir tikai biznesa perspektīva. Dažās sistēmās optimālais reakcijas laiks ir viena sekundes desmitdaļa no cilvēka reakcijas laika. Viena sekundes desmitdaļa ir laiks, kas nepieciešams, lai kobra jūs iekost. Ja jūs stāvat kobas priekšā un tā nolemj jūs iekost, ir jau par vēlu, jo jūs nevarat atbildēt sekundes desmitdaļā. Viena sekundes desmitdaļa ir par laiku, kas vajadzīgs, lai bumba atstātu krūka roku, lai puisi sasniegtu ar nūju. Būtībā, redzot iemesto bumbu, viņam ir jāreaģē tieši tajā brīdī. Cilvēciska reakcija, sava veida interesanta lieta. No programmatūras uz programmatūru acīmredzami var būt lielākas cerības.
Tad jūs nonākat dažās situācijās, kuras, manuprāt, ir tajās tirgus situācijās, kad būt pirmajai ir tā, kur ir biznesa vērtība. Tas ir tāpat kā tad, ja vēlaties pārdot kādu noteiktu akciju akciju tirgū, iespējams, ir mazāk, piemēram, tāpēc, ka, jūsuprāt, tas samazinās, un daudzi citi cilvēki domā, ka tas samazinās, jūs iegūstat vislabāko cenu, ja vispirms nokļūsit tirgū. Ir ļoti daudz situāciju, reklāmu rādīšanas un tamlīdzīgas lietas, ļoti līdzīga situācija. Šī kustība ir atkarīga no pakalpojuma līmeņa cerībām. Jums ir viena lieta, kas ir sava veida stikla griesti cilvēku reakcijai. Kad tas ir no programmatūras uz programmatūru, ja jums ir radusies šāda griestu situācija, tad nav vislabākā pakalpojumu līmeņa. Ātrāk nekā visi citi ir vislabākie.
Labi, ka, manuprāt, šis ir pēdējais slaids, ko es darīju, bet tas ir tikai tāpēc, lai sniegtu jums labu priekšstatu par sarežģītību, tiklīdz jūs faktiski apskatīsit organizācijas prasības, pakalpojumu. Dodoties augšup pa kreiso pusi, jums ir sistēmas pārvaldība, kas ir programmatūras kopums, kas kalpo pakalpojumu pārvaldībai un kas mēģina pārvaldīt pakalpojumu līmeni. Turklāt jums ir biznesa izpildes vadība. Tad, ja jūs paskatīsities uz leju šeit, pakalpojumu pārvaldības automatizācijas jomā, jums ir sadrumstaloti pakalpojumi, kas pārtapa par standartizētiem pakalpojumiem, ja patiesībā vēlaties ieguldīt šāda veida lietās, kas pārtapa integrētos pakalpojumos, kas pārtapa optimizētos pakalpojumos. . Lielākoties tas, ko cilvēki ir izdarījuši, ir tikai tā apakšējā kreisajā stūrī. Varbūt mazliet par pakalpojumu vadību. Uzņēmējdarbības izpildes vadība, ļoti reti. Sadrumstalots, gandrīz viss no tā. Ideāla pasaule aizpildītu šo režģi. Instrumentācija - es minēju apakšoptimizācijas problēmu. Jūs varat optimizēt sistēmas daļas, un tas nenāk par labu visai sistēmai. Ja jūs padarīsit sirdi optimālu, tad jūsu asinis varētu cirkulēt pārāk ātri pārējiem jūsu orgāniem. Tā ir problēma ar lielām organizācijām un pakalpojumu līmeņiem. Skaidrs, ka nekas netiks sasniegts bez sarežģītiem rīkiem, jo mainīgie ir tikko ieguvuši - labi, ka ir pārāk daudz mainīgo, lai tos mēģinātu optimizēt.
To sakot, es nodošu Dezam, kurš, cerams, runās par kaut ko citu.
Dez Blanchfield: Paldies, Robin. Tāpat kā doktors Robins Bloors, es pārāk daudz gadus esmu pavadījis, domājot par ļoti sarežģītu sistēmu darbību ļoti lielā mērogā. Droši vien ne gluži tādā pašā mērogā kā Robins, taču sniegums ir ikdienas tēma, un tā ir mūsu DNS sastāvdaļa, lai gribētu izpildījumu, lai pēc iespējas labāk izmantotu visu. Patiesībā es esmu izmantojis grafiku, kurā redzama viena no manām iecienītākajām lietām pasaulē, Formula I autosacīkstes, kur visa planēta kādu laiku sēž mierīgi un vēro, kā automašīnas ļoti ātri pārvietojas riņķī. Neatkarīgi no tā, kāds ir Formula I aspekts, tas nav tieši saistīts ar veiktspējas uzlabošanu. Daudzi cilvēki poo-poo sportu, jo viņi domā, ka tā ir naudas izšķiešana. Izrādās, ka automašīna, ar kuru mēs braucam katru dienu, lai nedēļas nogalēs aizmestu bērnus uz futbolu un pārējās dienās - ir iegūta no uz rezultātiem balstītas attīstības un pētījumu rezultātiem. Tāda ir Formula I autosacīkšu dzīve. Ikdienas tehnoloģijas, ikdienas zinātne, bieži nāk no kaut kā tā, kas ir vērsta tikai uz augstu veiktspēju.
Tomēr realitāte ir tāda, ka mūsu jaunā pasaule "vienmēr ieslēgta", kurai ir nepieciešams 100% darbspējas laiks - kā jau iepriekš minēja Robins - ar tādām lietām kā tīmekļa pasta ieviešana un citi pakalpojumi, kurus mēs uzskatām par pašsaprotamiem nepārtrauktā telpā, un mēs tagad gaidām, ka mūsu uzņēmums un darba vide. Realitāte ir tāda, ka esamība ne vienmēr nozīmē, ka jūs izpildāt savu pakalpojumu līmeņa vienošanos. Man tas ir vajadzīgs, lai pārvaldītu lietojumprogrammu veiktspēju un pieejamības pakalpojumu līmeņa līgumi pēdējās desmit gadu laikā ir piedzīvojuši būtiskas pārmaiņas. Mēs vairs ne tikai cenšamies uztraukties par vienas sistēmas veiktspēju. Kad pasaule bija mazliet vienkāršāka, mums varētu būt situācija, kad vienu serveri, kurā darbojas vairāki pakalpojumi, var novērot tiešraidē, un to atbalstīt bija samērā vienkārši. Mēs varētu - un šeit ir mana mazā - lietas, par kurām mēs, piemēram, pirms daudziem gadiem, kad bijām sistēmas administrators, mēs uztraucāmies, mēs paskatītos apkārt, vai pakalpojums parasti darbojas un reaģē? Vai, piemēram, var ieiet terminālī? Vai operētājsistēma reaģē un vai es varu rakstīt komandas? Vai lietojumprogrammas darbojas un darbojas? Vai es varu redzēt procesus un atmiņu, veicot darījumus, un I / O tīklā un tā tālāk? Lieldatoru dienās varēja dzirdēt lentes, kas tiek rādītas ar rāvējslēdzēju, un papīrs, kas no tām izkrīt.
Vai lietotnes reaģē un vai mēs varam pieteikties un rīkoties ar tām? Vai lietotāji var izveidot savienojumu ar dažiem no šiem serveriem? Tas turpinās. Viņi ir diezgan fundamentāli, jūs zināt. Tad daži smieklīgi - vai palīdzības dienests ir zaļš? Tā kā, ja nē, tad viss rit kārtībā, un kurš iegūs donukus? Dzīve tajos laikos bija patiešām vienkārša. Pat tajās dienās, un tad es runāju ar pirms 20–30 gadiem, sarežģītība joprojām bija patiešām liela. Mēs varētu samērā tiešā veidā pārvaldīt pakalpojumu līmeņa līgumus un sekot līdzi veiktspējai. Mēs to vairs nevaram izdarīt ar roku, kā Robins atsaucās. Izaicinājums ir pārāk liels. Fakts ir laiks, kad dažas labas lietotnes, administratori, sistēmas tīkls un datu bāze, administratori var uzraudzīt un izpildīt veiktspējas SLA. SLA vairs nav tik tālu, ka es pagājušajā naktī cīnījos, apkopojot galīgās piezīmes, lai pat domātu par gadu, kad man pēdējo reizi izdevās aplūkot ļoti sarežģītas kaudzītes sistēmu, to saprast un pat saprast, kas bija kas notiek zem kapuces, un es nāku no dziļi tehniskas vides. Es nevaru iedomāties, ar ko tas ikdienā saskaras administratīvi.
Kas notika? Nu, 1996. gadā ar interneta uzplaukumu tika pārveidotas datu bāzu vadītas lietotnes. Daudziem no mums tas ir noticis. Pat ja jūs nebijāt apkārt interneta uzplaukumam, varat vienkārši paskatīties apkārt un saprast, ka ikdienas dzīvē mēs visu piesaista internetam. Es uzskatu, ka mums ir tosters, kas acīmredzot ir aprīkots ar smieklīgu Wi-Fi piekļuvi, jo man nav nepieciešams, lai mans tosteris būtu savienots ar internetu. 2000. gados, īpaši 2000. gadu sākumā, mums bija jātiek galā ar šo milzīgo sarežģītības pieaugumu, nodrošinot pakalpojumu sniegšanu dot-com uzplaukumā. Tad vēl viena smieklīga neveikla dzirkste Web 2.0, kurā radās viedtālruņi un tagad lietojumprogrammas bija mūsu rokās visu diennakti un visu laiku bija ieslēgtas.
Tagad ir 2016. gads, un mēs saskaramies ar vēl vienu straumi mākoņu, lielu datu un mobilitātes veidā. Šīs ir sistēmas, kas ir tik lielas, ka tās bieži ir grūti saprast un ievietot vienkāršā angļu valodā. Kad mēs domājam par faktu, ka dažiem lielajiem vienradžiem, par kuriem mēs runājam, ir desmitiem simtu petabaitu datu. Šis ir viss diska vietas un krātuves stāvs, lai turētu jūsu e-pastu, attēlus un sociālos medijus. Vai dažos gadījumos transporta un pārvadājumu loģistikā tas viss notiek banku jomā - tur, kur ir jūsu nauda vai kur atrodas jūsu pasts, vai arī - tur, kur atrodas lieta, ko iegādājāties eBay. Nākamais lielais vilnis, ar kuru mēs saskaramies, ir šis ļoti smagais lietu interneta izaicinājums.
Ja tas nebija pietiekami slikti, mēs gatavojamies mākslīgo intelektu un kognitīvo skaitļošanu veidot gandrīz visā. Mūsdienās mēs runājam ar Siri un Google motoriem. Es zinu, ka Amazon ir viena no tām. Baidu ir viena no šīm ierīcēm, ar kuru jūs varat sarunāties, viņi to konvertē uz tekstu, kas nonāk normālā sistēmā, datu bāze veido vaicājumu, atgriežas un apgriež procesu. Padomājiet par sarežģītību, kas tajā nonāk. Realitāte ir tāda, ka mūsdienu standarta lietojumprogrammu pakete ir daudz sarežģītāka nekā cilvēka iespējas. Kad jūs domājat par visu, kas notiek, nospiežot pogu viedtālruņa ierīcē vai planšetdatorā, jūs ar to runājat, konvertējat to uz tekstu, visu internetu palaižat uz fona sistēmu, priekšējā daļa saņem tas, pārveidojot to vaicājumā, palaiž vaicājumu caur lietojumprogrammu kaudzīti, iet caur datu bāzi, iegūst disku, iznāk atpakaļ, un pa vidu ir pārvadātāju tīkls, tur ir lokālā tīkla statusa centrs. Sarežģītība ir traka.
Mēs to faktiski apgalvojam kā hiperskalu. Hiperskalu sarežģītība un ātrums ir tikai acu laistīšana. Lietojumprogrammas un datu bāzes ir kļuvušas tik lielas un tik sarežģītas, ka darbības pārvaldīšana faktiski ir zinātne pati par sevi. Daudzi to dēvē par raķešu zinātni. Mums ir tehnoloģija klātienē, mums ir tehnoloģija ārpus uzņēmuma, mums ir dažādas datu centra iespējas; fiziskā un virtuālā. Mums ir fiziski un virtuāli serveri, mums ir mākonis, mums ir infrastruktūra kā pakalpojums un platforma kā pakalpojums un programmatūra kā pakalpojums ir lieta, ko tagad uzskatām par pašsaprotamu. Pēdējais, programmatūra kā pakalpojums, pirms dažiem gadiem uz brīdi kļuva drausmīgs, kad CFO un organizācijas daļas saprata, ka viņi var paņemt savu kredītkarti un paši vienkārši iegādāties lietas un apiet CIO, un faktiski mēs to sauca par “ēnu”. IT ”un CIO tagad mēģina to apturēt un atkal cīnīties.
Infrastruktūrā mums ir programmatūras definēts tīklojums, tīkla funkciju virtualizācija, zem tā, iespējams, ir beigusies, tagad mums ir mikro pakalpojumi un aktīvo pakalpojumu lietotnes. Noklikšķinot uz vietrāža URL, URL beigās ir virkne biznesa loģiku, kas apraksta, kas vajadzīgs, lai to faktiski piegādātu. Tam nav obligāti jābūt iebūvētai loģikai. Mums vienā pusē ir tradicionālās datu bāzes, kuru mērogs ir ļoti, ļoti liels. Mums ir ļoti patīk Hadoop infrastruktūra un ekosistēmas otrā spektrā, kas ir tik lielas, ka, kā jau teicu, jūs zināt, tagad cilvēki runā par simtiem datu petabaitu. Mums ir sarežģīta mobilitāte, ciktāl ierīces pārvietojas visur, klēpjdatori, tālruņi un planšetdatori.
Mēs esam ieguvuši BYOD dažās slēgtās vidēs un arvien vairāk tagad, kopš Gen Y pieredzējušie cilvēki piegādā savas ierīces. Mēs tikai ļāvām viņiem sarunāties ar viņiem par tīmekļa saskarnēm. Vai nu internetā, vai izmantojot Wi-Fi, lejā esošajā kafejnīcā ir bezmaksas bezvadu internets, jo viņi kafiju lieto. Vai arī mūsu iekšējais Wi-Fi. Tagad mašīna vienmēr ir vienmēr sastopama. Tas nav tieši lietu interneta sastāvdaļa, bet tas ir arī saistīts. Lietu internets ir pilnīgi jauna sarežģītības spēle, kas prātā ienīst. Mākslīgais intelekts un ja jūs domājat, ka tas, ar ko mēs tagad spēlējam, ar visām Siri un citām saistītām ierīcēm, ar kurām mēs runājam, ir sarežģīts, pagaidiet, kamēr nonāksit situācijā, kad redzēsit kaut ko sauc par Olli, kas ir trīsdimensiju drukāts autobuss, kas aizņem apmēram sešus cilvēkus un kurš pats var braukt pa pilsētu, un jūs varat ar to runāt vienkāršā angļu valodā, un tas runās ar jums. Ja tas nokļūst satiksmē, tā nolems nogriezties pa kreisi vai pa labi no galvenās zonas, kur notiek satiksme. Kad pagriežas un jūs uztraucaties par to, kāpēc no galvenā ceļa ir nogriezts pa kreisi vai pa labi, tas jums sacīs: “Neuztraucieties, es gatavojos pagriezties pa kreisi. Tur ir satiksme priekšā, un es došos ap to. ”
Pārvaldīt visu tur esošo sistēmu veiktspēju un visu sarežģītību, izsekot, kur šie dati nonāk, vai tie nonāk datu bāzē, visos savstarpējos savienojumos un visos attiecīgajos bītos, ir tikai prātā. Realitāte ir tāda, ka, lai pārvaldītu veiktspēju un SLA šodienas ātrumā un mērogā, nepieciešami rīki un sistēmas, un pēc noklusējuma tas vairs nav kaut kas tāds, kur jūs vienkārši domājat, ka rīks būtu jauki - tas ir priekšnoteikums; tas ir tikai absolūti nepieciešams. Šeit ir kaut kas neliels piemērs - OpenStack, atvērtā pirmkoda programmatūras definēta mākoņa, augsta līmeņa lietojumprogrammu dizaina diagrammu saraksts. Tas ir tikai liels rieciens. Tas nav tikai serveri un datu bāze. Šeit katra mazā zilā lāse pārstāv lietu kopas. Dažos gadījumos darbojas faili un serveri vai simtiem datu bāzu vai, protams, ne vairāk kā desmitiem tūkstošu mazu lietojumprogrammu loģikas gabalu. Tā ir maza versija. Tas tiešām ir diezgan prātā, ja sākat domāt par sarežģītību, kas šajā sakarā rodas. Šodien pat lielā datu telpā es ievietošu dažus ekrānuzņēmumus tikai ar zīmoliem. Kad jūs domājat par visiem gabaliem, kas mums šeit jāpārvalda, mēs ne tikai runājam par vienu zīmolu, bet tie ir visi lielās datu ainavas un augstākā līmeņa zīmoli, ne tikai katrs mazs vai atvērts avots. Jūs skatāties un domājat, ka tā ir diezgan prātojoša diagramma.
Apskatīsim tikai pāris vertikāles. Ņemsim, piemēram, mārketingu. Šeit parādīta līdzīga tabula, bet no tehnoloģijām, kas ir pieejamas tikai mārketinga tehnoloģijās. Šī ir 2011. gada diagramma. Šeit ir 2016. gada versija. Padomājiet tikai par to, ka tas ir tikai to produktu zīmolu skaits, kurus varat izmantot tehnoloģijai attiecībā uz mārketinga tehnoloģiju. Ne jau tur esošo sistēmu sarežģītība, ne atšķirīgā lietotne un tīmeklis, kā arī izstrāde un tīkls un viss pārējais. Tikai zīmols. Tur bija pirms, pirms pieciem gadiem, un šeit ir šodien. Tas tikai pasliktināsies. Mēs šobrīd atrodamies situācijā, kad cilvēki vienkārši nespēj nodrošināt visus pakalpojumu līmeņa līgumus. Mēs nevaram ienirt pietiekami detalizēti, pietiekami ātri un vajadzīgajā mērogā. Šeit ir piemērs tam, kā tagad izskatās uzraudzības konsole. Tas ir tāpat kā gandrīz divdesmit nepāra ekrāni, kas salīmēti kopā, izliekoties, ka tie ir viens lielisks, liels, projicēts ekrāns, kurš uzrauga katru mazo gabalu. Tagad šeit ir interesanti, es neminēšu zīmolu, bet šī uzraudzības platforma pārrauga vienu lietojumprogrammu loģistikas un kuģniecības vidē. Tikai viena lietotne. Ja jūs domājat par to, ko runāja Robins, kur organizācijām ražošanas vidē tagad var būt 40 000 datu bāzu. Vai jūs varat vienkārši iztēloties, kādas varētu būt šīs ekrānu kolekcijas 40 000 versijas, kas uzrauga vienu lietojumprogrammu? Tā ir ļoti drosmīga pasaule, kurā mēs dzīvojam. Kā Robins teica, un es absolūti 100% atbalsošos, ka bez pareiziem instrumentiem, bez pareiza atbalsta un tautas galda, izmantojot šos rīkus, lietojumprogrammu veiktspēja ir zaudēta spēle cilvēkiem un tas jādara ar rīkiem un programmatūru.
Ar to es nodošos mūsu draugiem IDERA.
Ēriks Kavanaghs: Labi, Bils.
Bils Eliss: Paldies. Šeit tiek koplietots mans ekrāns. Es domāju, vai kāds var apstiprināt, ka varat redzēt manu ekrānu?
Dr Robin Bloor: Jā.
Ēriks Kavanaghs: Tas izskatās viss kārtībā.
Bils Eliss: Paldies. Vienīgais, uz kuru viņš atsaucās, es tiešām nevaru gaidīt, ka tas bija pašpiedziņas automašīna. Viena lieta, par kuru es vēl nebiju dzirdējis, ka būtu runāts, kas notiek, kad snigs? Es brīnos, vai Kalifornijas inženieri saprata, ka citās valsts daļās daudz snigs.
Dezs Blanšfīlds: Man tas patīk, es atcerēšos to.
Ēriks Kavanaghs: tipiska jūdze stundā.
Bils Elliss: Mēs esam šeit, lai runātu par lietojumprogrammu veiktspējas pārvaldību sarežģītā vidē. Viena lieta, par kuru man patīk runāt, ir tā, ka daudziem cilvēkiem, kad viņi runā par veiktspēju, reakcijas būtība ir: hey more serveri, vairāk CPU, vairāk atmiņas utt. Šīs monētas otra puse ir apstrādes efektivitāte. Tiešām, tās ir vienas monētas divas puses, un mēs to apskatīsim abas. Galīgais mērķis ir izpildīt pakalpojuma līmeņa vienošanās par darījumiem. Galu galā visa šī tehnoloģija pastāv biznesam. Mēs runājām par to, ka mums ir nozarē pirmā veiktspējas pārvaldības datu bāze. Ideāls tam ir iekļauties ideālā veiktspējas veidnē un pārvaldīt to no lietojumprogrammu dzīves cikla sākuma.
Tēmas patiešām sakrājas līdz četriem gabaliem; viens ir veiktspējas pārvaldības process. Mēs runājām ar visiem, un visiem ir instrumenti. Ja viņiem nav rīku, viņiem ir skripti vai komandas, bet viņiem trūkst konteksta. Konteksts ir vienkārši punktu pievienošana lietojumprogrammu kaudzēm. Šīs lietojumprogrammas - ir balstītas uz pārlūku. Tie ir ļoti cieši saistīti no viena līmeņa uz otru. Ļoti svarīgi ir arī tas, kā līmeņi mijiedarbojas. Tad mēs runājam par biznesa darījumu. Mēs nodrošināsim redzamību ne tikai tehniskajiem ļaudīm, bet arī lietojumprogrammu īpašniekiem un operāciju vadītājiem.
Man ir pāris gadījumu izpētes, lai tikai pastāstītu par jums, kā klienti tos ir izmantojuši. Šī šeit ir ļoti praktiska prezentācijas daļa. Apskatīsim, kas parasti notiek. Man patīk diagramma - tas bija gluži kā neticami tehnoloģiju kolāža. Tehnoloģiju skaits datu centrā ir tikai pieaudzis, un tas ir pieaudzis un audzis. Tikmēr tiešajam lietotājam tas nerūp, un viņš to aizmirst. Viņi vienkārši vēlas veikt darījumu, ja tas ir pieejams, ja tas tiek ātri pabeigts. Parasti notiek tas, ka IT profesionāļi nezina, ka gala lietotājiem pat ir bijusi problēma, līdz viņi paši ziņo. Tas sāk laikietilpīgu, lēnu procesu un bieži vien nomāktu. Notiek tas, ka cilvēki atver savus rīkus un aplūko savas lietojumprogrammu kaudzes apakškopu. Izmantojot šo apakškopu, kļūst ļoti grūti atbildēt uz vienkāršāko jautājumu. Vai jums parasti tā ir problēma? Kāds ir darījums? Kur pieteikuma kaudzē ir sašaurinājums? Pavadot visu šo laiku, skatoties pēc kārtas, nespējot atbildēt uz šiem jautājumiem, jūs patērējat daudz laika un enerģijas, daudz personāla, līdzekļu un enerģijas veida, lai to uzzinātu.
Lai to atrisinātu, lai nodrošinātu labāku veidu, precīzi tas, ko patiesībā izdara, veic gala lietotāja izsekošanas darījumu, notver metadatus par to, seko darījumam caur tīklu, tīmekļa serverī, biznesa loģikas līmenī un mēs atbalstām .NET un ABAP, PeopleCode un E-Business Suite daudzpakāpju lietojumprogrammās, kas galu galā visi darījumi mijiedarbosies ar ierakstu sistēmu. Neatkarīgi no tā, vai tas ir krājumu uzmeklēšana, pārskata laiks, viņi vienmēr mijiedarbojas ar datu bāzi. Datubāze kļūst par biznesa izpildes pamatu. Datubāze savukārt balstās uz krātuvi. Ko atbild par transakciju metadatiem, kurš, kāds darījums, kur atrodas lietojumprogrammu kaudzē, un tad mums ir dziļa koda līmeņa redzamība, lai parādītu, kas tiek izpildīts. Šī informācija tiek nepārtraukti iegūta, ievietota izrādes vadības datu bāzē - tā kļūst par vienu mūzikas lapu visiem, lai redzētu notiekošo. Ir dažādi cilvēki un organizācijas, kurām rūp notiekošais: tehniskie eksperti, lietojumprogrammu īpašnieki, galu galā pats bizness. Kad rodas problēma, vēlaties iegūt informāciju par šo darījumu.
Pirms mēs aplūkojam investīciju darījumu, es vēlos jums parādīt, kā tas varētu parādīties dažādiem organizācijas darbiniekiem. Pārvaldības līmenī jūs varētu vēlēties pārskatu par vairākām lietojumprogrammām. Jūs varētu vēlēties uzzināt par veselību, ko aprēķina, ievērojot SLA atbilstību un pieejamību. Šī veselība nenozīmē, ka viss simtprocentīgi darbojas nevainojami. Šajā gadījumā ir vietas, jūs varat redzēt, ka ieguldījumu darījums ir brīdinājuma stāvoklī. Tagad, mazliet dziļāk, varbūt biznesa jomā, jūs vēlaties iegūt sīkāku informāciju par atsevišķiem darījumiem, ja tie pārkāpj SLA, darījumu skaitu utt. Operāciju grupa vēlēsies, lai par to tiktu informēts, izmantojot brīdinājumu par dažiem uzņēmumiem. kārtot. Mums ir iebūvēti brīdinājumi par veiktspēju. Mēs faktiski novērtējam veiktspēju gala lietotāja pārlūkprogrammā. Neatkarīgi no tā, vai tas ir Internet Explorer, Chrome, Firefox utt., Ko mēs varam atklāt, tas atbild uz pirmo jautājumu: vai gala lietotājam ir problēma?
Iedziļināsimies un redzēsim, ko vēl mēs varam parādīt par to. Cilvēki, kurus interesē sniegums, atvērs Precīzu. Viņi novērtēja darījumus. Viņi apskatīja SLA kolonnu, lai identificētu darījumus, kas nebija atbilstoši SLA. Viņi varēs redzēt gala lietotājus, kuri tika ietekmēti, kā arī to, ko darījums izdarīja, plūstot visā lietojumprogrammā. Šos hieroglifus atšifrējat, tas ir pārlūks, URL, URL ir URL, tas ir, JVM ieejas punkts. Tagad šis konkrētais JVM liek tīmekļa serverim izsaukt otro JVM, kurš pēc tam izpilda SQL paziņojumu. Tas nepārprotami ir jautājums par datu bāzi, jo šis SQL paziņojums bija atbildīgs par 72 procentiem no reakcijas laika. Mēs koncentrējamies uz laiku. Laiks ir izpildes valūta. Tas ir tas, kā galalietotāji izjūt to, vai viss rit lēnām vai nē, un tas ir resursa patēriņa rādītājs. Tas ir ļoti parocīgs; tā ir viena metrika, kas ir vissvarīgākā veiktspējas novērtēšanai. Kad šī problēma tiek nodota DBA, tā nav tikai datu bāzes problēma, tas ir šis SQL paziņojums. Šis ir konteksts, par kuru es runāju.
Tagad, kad esmu apbruņojies ar šo informāciju, es varu iedziļināties un analizēt notikušo. Pirmkārt, es redzu, ka y ass ir laiks visu dienu. Piedodiet, y ass ir reakcijas laiks, x ass ir laiks dienā. Es redzu, ka ir problēma ar datu bāzi, ir divi gadījumi, dodieties atpakaļ uz šo plūsmu, paņemiet šo SQL paziņojumu un dodieties uz eksperta skatu, kur Precise spēj parādīt, kas notiek, tā vadīklas, cik ilgs laiks šim kodam nepieciešams izpildīt. Datubāzes līmenī tas ir izpildes plāns. Jūs atzīmēsit, ka Precīzs izvēlējās reālo izpildes plānu, kas tika izmantots izpildes laikā un kas atšķiras no aprēķinātā plāna, tas būtu, kad plāns tika dots, nevis izpildes laikā. Tas var vai nevar atspoguļot to, ka datu bāze faktiski ir notikusi.
Šeit ir SQL paziņojuma reakcijas laika analīze. Deviņdesmit procenti no glabāšanā pavadītā laika; CPU tika izmantoti desmit procenti. Es redzu SQL paziņojuma tekstu, kā arī ziņojumu par atradumiem. SQL paziņojuma teksts faktiski sāk atklāt dažas kodēšanas problēmas. Tā ir zvaigzne; kas atgriež visas rindas - atvainojiet, visas kolonnas no tām rindām, kuras tika atgrieztas. Mēs atgriežamies pie papildu kolonnām, kuras var būt vajadzīgas lietojumprogrammai. Šīs kolonnas patērē vietu un resursus apstrādei. Ja palaižat SAP, viena no lielajām izmaiņām, jo HANA datu bāze ir kolonnveida, ir tāda, ka pamatā SAP pārrakstīšana, lai neizvēlētos atlasītu zvaigzni, lai tās varētu ievērojami samazināt resursu patēriņu. Tas būtībā ir tas, kas daudz laika notiek arī pašmāju lietojumprogrammās, piemēram, Java, .NET utt.
Šis ekrāns parāda, kurš, ko, kad, kur un kāpēc. Kāpēc nokļūst, piemēram, SQL paziņojums un izpildes plāns, kas ļauj jums atrisināt problēmas. Tā kā precīzi darbojas nepārtraukti, jūs faktiski varat izmērīt gan pirms, gan pēc, SQL paziņojuma līmenī, transakciju līmenī, lai jūs varētu novērtēt problēmu pats, kā arī ar lietojumprogrammu īpašnieku un vadības starpniecību. . Šī dokumentācija ir patiešām noderīga. Šajā lietojumprogrammu kaudzē ir daudz sarežģījumu. No daudzām lietojumprogrammām faktiski visi, ar kuriem mēs esam runājuši, palaiž vismaz daļu lietojumprogrammu kaudzes zem VMware. Šajā gadījumā viņi skatās uz klientu apkalpošanas lietojumprogrammu, darījuma laiku un korelē to ar palēninājumu, kas ir virtualizācijas notikums. Precīzi izseko visus virtualizācijas notikumus. Lai to uzņemtu, mums ir spraudnis vCenter.
Mēs arī spējam atklāt strīdus. Apgalvojums ir savādāks nekā izmantošana. Faktiski tiek parādīts, kad, iespējams, trokšņains kaimiņš ietekmē jūsu viesa VM klienta servera lietojumprogrammas kontekstā. Tagad es varu veikt izpēti un iegūt informāciju, un es faktiski varu redzēt divus virtuālos automātus, kas šajā gadījumā sacenšas par procesora resursiem. Tas ļauj man panākt redzamību, lai es varētu apskatīt plānošanu. Es varu ievietot viesa virtuālo serveri citā fiziskā serverī. Visas šīs lietas, uz kurām jūs varētu reaģēt, un papildus tam es faktiski varu apskatīt koda efektivitāti, lai varbūt tam būtu mazāk CPU. Es domāju, ka man šajā prezentācijā ir diezgan labs piemērs, kā kāds spēja samazināt CPU patēriņu par lieluma secību.
Tas bija VMware. Iedziļināsimies pašā kodā, lietojumprogrammas kodā. Precīzs varēs parādīt, kas notiek Java, .NET, ABAP kodā, E-Business, PeopleCode utt. Šie ir ieejas punkti WebLogic. Šeit ir atradumu ziņojums, kas man saka, ka šie EJB ir jāapskata, un man pateiks, ka jūs arī bloķējāties šajā sistēmā. Vēlreiz padziļināti iepazīstieties ar biznesa loģikas līmeni, lai parādītu notiekošo. Šajā gadījumā es aplūkoju konkrētus gadījumus; Es arī atbalstu klasteru veidošanu. Ja jums ir daudz JVM, kas darbojas, varat aplūkot kopu kopumā vai arī aplūkot sašaurinājumus atsevišķā JVM.
Iekļaujoties bloķēšanā, es varu nonākt izņēmumos. Izņēmums nedaudz atšķiras no veiktspējas problēmas. Parasti izņēmumus veic ļoti ātri. Tā kā pastāv loģikas kļūda, un, tiklīdz esat pieļāvis šo loģikas kļūdu, tā beidzas. Mēs varējām uztvert kaudzes pēdas, ievērojot izņēmumu, tas varētu ietaupīt daudz laika, jo notiek mēģinājums izdomāt, kas notiek, jums vienkārši ir kaudzītes pēdas turpat. Mēs varam uztvert arī atmiņas noplūdes. Risinājumā ietilpst arī datu bāzes līmenis, es varu ieiet, es varu novērtēt datu bāzes gadījumu. Atkal, y ass ir vieta, kur tika pavadīts laiks, x ass ir laiks pa dienu. Tur ir atradumu ziņojums, kas vienkārši automātiski man norāda, kas notiek sistēmā un ko es varētu aplūkot.
Viena no lietām, kas attiecas uz Precise's atradumu pārskatu, tajā nav aplūkoti tikai žurnāli vai gaidīšanas stāvoklis - tiek apskatīti visi izpildes stāvokļi, ieskaitot CPU, kā arī informācijas atgriešana no krātuves. Krātuve ir ļoti svarīga lietojumprogrammu kaudzes sastāvdaļa, it īpaši ar cietā stāvokļa parādīšanos. Šāda informācija var būt ļoti noderīga. Noteiktām glabāšanas vienībām mēs faktiski varam veikt izpēti un parādīt, kas notiek atsevišķas ierīces līmenī. Šāda veida informācija - atkal tā ir dziļa redzamība; tā darbības joma ir plaša - lai sniegtu jums tikai pietiekami daudz informācijas, lai būtu vairāk līdzekļu, lai piesaistītu jūs kā lietojumprogrammu veiktspējas profesionāli, lai jūs varētu optimizēt savas lietojumprogrammas no vienas puses uz otru, lai izpildītu šos biznesa darījumus.
Man ir pāris gadījumu izpēte, ko vēlējos padalīties ar jums. Braucam garām diezgan ātri; Es ceru, ka eju pareizā tempā. Runājot par krātuvi, visi laika gaitā maina aparatūru. Pastāv aparatūras garantija. Vai tas tiešām piegādāja to, ko pārdevējs jums teica? To var novērtēt ar Precise. Jūs ienācat, un, kas šeit notika, viņi būtībā ievietoja jaunu krātuves vienību, bet, kad krātuves administratori apskatīja tikai krātuves vienības līmeni, viņi redzēja daudz strīdu un domāja, ka šai jaunajai krātuves vienībai varētu būt problēmas. . Raugoties vairāk no visa gala, precīzi parādot, kur tas patiesībā notiktu. Viņi faktiski pārgāja no caurlaidspējas aptuveni 400 meg sekundē, kur krātuve bija atbildīga par 38 procentiem reakcijas laika, tāpēc tas ir diezgan augsts. Ar jauno glabāšanas vienību mēs faktiski palielinājām caurlaidspēju līdz sešiem, septiņiem simtiem megu sekundē, tātad būtībā divkāršā apjomā, un mēs varam uz pusi samazināt uzglabāšanas līmeņa ieguldījumu darījuma laikā. Es varu reāli grafiku, ka iepriekš, šis ir pārslēgšanās periods, un pēc tam.
Tātad vēlreiz dokumentācija, kas pierāda, ka aparatūras ieguldījums bija tā vērts, un tie tika piegādāti tā, kā konkrētais pārdevējs bija gaidījis. Sarežģītības un lietu skaita dēļ var būt visdažādākās lietas. Šajā gadījumā viņiem faktiski bija situācija, kad visi kaut ko vainoja DBA, DBA bija tāda kā “Nu, ne tik ātri.” Šeit mēs faktiski skatāmies uz SAP lietojumprogrammu, es domāju, ka šāda veida scenāriji ir diezgan izplatīti. . Notika tas, ka viņi izstrādāja pielāgotu darījumu lietotājam. Lietotājs ir tāds: “Tas notiek tik lēni.” ABAP kodētājs, tas ir, SAP programmēšanas valoda, sacīja: “Šī ir datu bāzes problēma.” Viņi galu galā atvēra precīzu; viņi šo gala lietotāju izmērīja 60 sekundes, tātad krietni vairāk par minūti. Aizmugurē tika pavadītas piecdesmit trīs sekundes. Viņi iedziļinājās aizmugurē, un viņi faktiski varēja atklāt SQL paziņojumu, kas parādīts dilstošā secībā.
Šis top SQL paziņojums, kas ir atbildīgs par 25 procentiem no resursa patēriņa, tā vidējais izpildes laiks ir divas milisekundes. Jūs nevarat vainot datu bāzi. Jūs zināt, hey, ne tik ātri, puisis. Jautājums ir, kāpēc ir tik daudz nāvessodu? Viņi atleca atpakaļ uz ABAP, viņš iegāja, izpētīja cilpas ligzdošanu, uzzināja, ka izsauc datu bāzi nepareizajā vietā, viņi būtībā veica izmaiņas, pārbaudīja izmaiņas un tagad ir jaunais atbildes laiks. piecas sekundes. Nedaudz lēni, bet viņi ar to varēja dzīvot. Daudz labāk nekā 60 sekundes. Dažreiz tas ir tikai fermentācijas laikā, vai tas ir lietojumprogrammas kods, vai tā ir datu bāze, vai tā ir krātuve? Šīs ir jomas, kurās Precise, ņemot vērā visaptverošu darījumu kontekstu, tiek izmantota precizitāte. Jūs būtībā izbeidzat šīs lietas.
Es skatos tajā laikā, izskatās, ka mums vēl ir mazliet laika iziet cauri vēl pāris no šiem. Es straumēju caur šiem. Šī lietojumprogramma tika izstrādāta vairāk nekā gadu. Ienākot QA, viņi redzēja, ka tīmekļa serveri ir pilnībā izsmelti, un likās, ka lietojumprogramma nevarēja darboties zem VMware. Pirmais, ko visi teica, bija: “Liec to fiziski; tas nevar darboties zem VMware. ”Precīzs viņiem faktiski piedāvāja papildu veidus, kā atrisināt problēmu. Mēs apskatījām darījumus, redzējām Web servera zvanu, tas IIS.NET parādās kā ASMX. Tas faktiski atklāja pamatā esošo kodu. Vai jūs to redzat, kur es norādu? Tas ir 23 dienas, 11 stundas. Oho, kā tas ir iespējams? Katrs izsaukums prasa 9, 4 sekundes, un šī lieta tiek izsaukta 215 000 reizes. Katrā ielūgumā tas izmanto 6 sekundes CPU. Tas ir iemesls, šis kods ir iemesls, kāpēc šī lieta nekad nevarēja būt mērogā. Patiesībā tas fiziski nevarēja mērogot.
Ko viņi izdarīja, viņi devās atpakaļ pie izstrādātājiem un sacīja: “Vai kāds var izdarīt izmaiņas?” Viņiem bija konkurss, un viņi izmēģināja dažādus ieteikumus, un viņi nāca klajā ar ieteikumu, kas spēja daudz vadīt. efektīvāk. Jaunais pabeidza vienu punktu, nedaudz mazāk par divām sekundēm, ar divu sekundes simtdaļām CPU. Tagad tas varētu mērogot, un tas varētu darboties VMware fermā. Mēs to galvenokārt varējām dokumentēt gan koda līmenī, gan darījuma līmenī. Tas ir pirms un pēc tam. Tagad, kad jūs varat redzēt šeit skursteņu joslas diagrammā, kas parāda web, .NET un datu bāzi, tagad jūs mijiedarbojaties ar datu bāzi. Šis ir profils, kuru jūs varētu redzēt lietojumprogrammai, kura darbojas normāli.
Labi, es izvēlos un izvēlos papildu lietas, kuras es jums varu parādīt. Daudziem patīk, ka tas apbēdina daudzus veikalus. Ja nevarat satikties ar uzņēmuma SLA un visi ir līdzīgi: “Palīdziet mums!” Šajā veikalā bija situācija, kad uzņēmuma SLA ir pasūtījumi, kas saņemti līdz plkst. 15:00, tas tiek nosūtīts tajā dienā. Ir ļoti svarīgi, lai viņi saņemtu pasūtījumus, un noliktava ir ļoti aizņemta. Šis JD Edwards pārdošanas pasūtījuma ekrāns tika iesaldēts, un jūs varat iegūt ļoti labu ideju, ka šī ir tieši laikā veiktā mazumtirdzniecības krājumu pārvaldības sistēma. Tukši plaukti nav pieļaujami mazumtirdzniecībā. Tur man bija prece, lai to pārdotu. Tas, ko mēs izdarījām, mēs esam ieniruši, šajā gadījumā mēs skatāmies uz SQL servera datu bāzi. Izskats un izjūta ir vienāda neatkarīgi no tā, vai tas ir SQL, Oracle, DB2 vai Sybase.
Mēs identificējām atlasīto no PS_PROD un spējam uztvert ilgumu, faktu, ka viņi tik daudz izpilda. Tumši zilā krāsa atbilda atslēgai, kas teica, ka viņi negaida gaidīšanas stāvokli vai reģistrēšanu vai pat glabāšanu - šo lietu saista CPU. Mēs izsekojām SQL paziņojumu ar 34301, tāpēc katru reizi, kad tas tiek izpildīts, mēs palielinām skaitītājus, lai sekotu tam. Tas nozīmē, ka mums ir detalizēta vēsture, un es tai varu piekļūt, noklikšķinot uz šīs melodijas pogas. Šeit ir cilne Vēsture. Šajā ekrānā šeit redzams vidējais ilgums salīdzinājumā ar izmaiņām. Trešdiena, ceturtdiena, piektdiena vidējais ilgums bija apmēram divas sekundes desmitdaļas. Ļoti maz ekrānu sasalst, viņi spēj satikt biznesa SLA. Nāc 27. februāris, kaut kas mainās, un pēkšņi izpildes laiks ir pienācis klāt, un tas faktiski ir pietiekami lēns, lai izraisītu noildzi, kā rezultātā ekrāns tiek iesaldēts. Precīzi, saglabājot detalizētu vēsturi, ieskaitot izpildes plānu un tabulas indeksu vispārīgās izmaiņas, ja SQL tiek izmantots. Mēs varējām pamanīt, ka piekļuves plāns mainījās 27. februārī. No pirmdienas līdz piektdienai sliktā nedēļa. Nāciet 5. martā, piekļuves plāns atkal tika mainīts. Šī ir laba nedēļa. Šī rozā zvaigzne stāsta mums par atjaunināto skaļumu.
Šeit varat redzēt, ka rindu skaits pamata tabulās pieaug, un tas ir raksturīgi biznesam. Jūs vēlaties, lai jūsu galdi augtu. Lieta ir tāda, ka paziņojumi ir parsēti, SQL paziņojumi ienāk, optimizētājam ir jāizlemj, ko darīt, un jāizvēlas, kad izpildes plāns ir ātrs, jāizvēlas cits izpildes plāns, kad tas ir lēns, izraisot ekrāna iesaldēšanu. Balstoties uz dziļu tehnoloģiju, man jāzina, kas ir izpildes plāns, un Precīzs to uztver man pilnā apjomā ar datuma un laika zīmogu. Šis bija ātrs un efektīvs, tas bija lēns un neefektīvs. Šis filtra savienojums vienkārši izmanto daudz vairāk centrālā procesora, lai saskaņotu šo konkrēto SQL paziņojumu. Viņiem joprojām ir tāds pats galīgais efekts, taču šim principam ir lēnāka, mazāk efektīva receptes rezultātu kopuma nodrošināšanai. Tātad, mēs soli cauri. Hei, mums ir laiks vēl pāris?
Ēriks Kavaņahs: Jā, ejiet uz to.
Bils Elliss: Labi, es izlaidīšu. Viena lieta, ko es vēlos, lai jūs ņemtu vērā, mēs runājām par aparatūru, runājām par SAP, mēs runājām par .NET, mēs runājām par JD Edwards un Java-SQL Server vidi. Tas ir SAP, šeit mēs skatāmies uz PeopleSoft. Precīza atbalsta matrica ir plaša un dziļa. Ja jums ir lietojumprogramma, vairāk nekā iespējams, mēs to varam izmantot, lai nodrošinātu šo redzamības līmeni. Viena no lielākajām izmaiņām, kas notiek šobrīd, ir mobilitāte. PeopleSoft ieviesa mobilitāti ar savu Fluid UI. Fluid UI izmanto sistēmu ļoti atšķirīgi. Šī lietojumprogramma attīstās. Fluid UI - tas no pārvaldības viedokļa ir tas, ka tas ļauj gala lietotājiem izmantot tālruni, un tas ievērojami palielina produktivitāti. Ja jums ir simtiem vai tūkstošiem vai pat vairāk darbinieku, ja jūs varat palielināt viņu produktivitāti par 1–2 procentiem, jums var būt milzīga ietekme uz algu un visu pārējo. Notika tas, ka šis konkrētais veikals izveda PeopleSoft Fluid UI. Tagad runājot par sarežģītību, šī ir PeopleSoft kaudze. Viena programma, vismaz sešas tehnoloģijas, daudzi gala lietotāji. Kā jūs to sākat?
Vēlreiz Precise varēs sekot šiem darījumiem. Šeit mēs parādīsim sakārtotu joslu diagrammu, kurā parādīts klients, tīmekļa serveris, Java, Tuxedo datu bāze, PeopleSoft lietojumprogrammu kaudze. Zaļās kartes J2EE, kas ir sava veida izdomāts veids, kā pateikt WebLogic. Šī ir pārgriešana. Galalietotāji sāk izmantot Fluid UI, un reakcijas laiks svārstās no pusotra, divām sekundēm līdz aptuveni deviņām, desmit sekundēm. Tas, ko šis ekrāns neparāda, ir to cilvēku skaits, kuri “nereaģēja”. Viņi faktiski ekrānā iesaldēja lietojumprogrammu. Apskatīsim dažas redzamības iespējas, ko Precise spēj nodrošināt šim klientam.
Pirmkārt, kad es aplūkoju PeopleSoft darījumus, viņi būtībā var redzēt, ka šāda veida lietas mēs redzam vispār. Tika ietekmēti visi darījumi, kā arī visas atrašanās vietas. Starp citu, apskatot šo, jūs faktiski varat redzēt vietas visā pasaulē. No Āzijas Klusā okeāna līdz Eiropai, kā arī Ziemeļamerikai. Veiktspējas problēma neatrodas noteiktā darījumā vai noteiktā ģeogrāfiskajā atrašanās vietā, tā ir visa sistēmas mēroga. Tas ir sava veida veids, kā pateikt, ka izmaiņas vai veids, kā Fluid UI bija globāla ietekme. Šeit var redzēt no mērogojamības viedokļa, cilvēki mēģina veikt tāda paša veida aktivitātes, taču reakcijas laiks būtībā ir tikai pasliktinājies un pasliktinājies. Var redzēt, ka lietas nesamazinās. Viss notiek ļoti, ļoti slikti. Šeit, aplūkojot asu skaitu un vienlaicīgos savienojumus, jūs redzat kaut ko ļoti interesantu piekļuves skaita un savienojumu ziņā. Šeit mēs mērojam tikai aptuveni 5000, un jūs skatāties apmēram, un tas pārsniedz 100 vienlaicīgus savienojumus. Tas tiek darīts pēc; tas ir iepriekš. Tātad, kāds ir mans patiesais pieprasījums pēc sistēmas, ja šī lieta varētu mērogot, ir 300 000 diapazonā. Vecajās dienās ar klasisko lietotāja interfeisu jūs apskatījāt 30 vienlaicīgus savienojumus.
Tagad tas jums saka, ka Fluid UI izmanto vismaz 10x vienlaicīgu savienojumu skaitu. Mēs sākam atvilkt atpakaļ notiekošo zem vākiem ar PeopleSoft, lai jūs varētu redzēt, kāda ir ietekme uz tīmekļa serveriem, tas, ka SLA sāk pārkāpt. Neiedziļināšos visā, bet viss, kas galu galā notiek, ir tas, ka viņi galvenokārt paļaujas uz ziņojumapmaiņu. Viņi galvenokārt izmanto WebLogic un rada rindas Tuxedo ietvaros. Faktiski bija daudzlīmeņu atkarības problēma, kas parādījās ar Fluid UI, bet Precise spēja parādīt, ka ar veselu virkni dažādu lietu mēs varam koncentrēties uz to, kas bija problēma. Izrādās, ka arī pašā datu bāzē bija problēma. Faktiski pastāv ziņojumapmaiņas žurnālfails, un visu vienlaikus esošo lietotāju dēļ šis žurnālfails tika bloķēts. Pamatā tam bija jāsaskaņo lietas katrā līmenī lietojumprogrammu kaudzē. Runājot par sarežģītību, šeit faktiski ir Tuxedo līmenis, kas parāda jums rindas, un jūs varat redzēt, ka arī šī līmeņa darbība pazemina. Es varēju redzēt procesus; Es varēju redzēt domēnus un serverus. Tuxedo, lai cilvēki to lietotu, parasti tas, ko jūs darāt, ir papildu rindu, domēnu un serveru atvēršana, tāpat kā lielveikalā, lai mazinātu sastrēgumus, lai samazinātu rindošanas laiku. Pēdējais un pēdējais variants Precise parāda daudz informācijas.
Kā jau minēju iepriekš, katrs nozīmīgais darījums mijiedarbojas ar ierakstu sistēmu. Pārredzamība datu bāzē ir sevišķi svarīga. Precīzs parāda to, kas notiek datu bāzē, WebLogic, Java, .NET, pārlūkprogrammā, bet vieta, kurā Precīzi patiešām izceļas, ir datu bāzes līmenī. Tas, iespējams, ir mūsu konkurentu vājums. Ļaujiet man parādīt jums vienu no veidiem, kā Precise varētu jums palīdzēt to pārdomāt. Es negaidīšu laiku datu bāzes optimizācijas trijstūrī, bet mēs galvenokārt skatāmies uz zemām izmaksām, zemu risku, līdz plaša mēroga, augsta riska, augstām izmaksām. Es pēc tam es čivināšu šo slaidu, ja cilvēki vēlas izmēģināt un to apskatīt. Manuprāt, tas ir diezgan liels ceļvedis problēmu noregulēšanai. Šeit ir precīza informācija par Oracle ekspertu viedokli. Rezultātu ziņojuma sākumā 60% ietekme ir šim konkrētajam SQL paziņojumam. Ja atverat šo darbības ekrānu, tas tur to parāda. Es varu apskatīt šo atlasīto paziņojumu, tur ir viens izpildes plāns. Katra izpildīšana prasa sekundi - 48 000 izpildījumu. Tas nozīmē vēl 48 000 nāvessodu stundu.
Tumši zils atkal ir CPU. Šī lieta ir saistīta ar CPU, nevis gaidīšanas stāvokli, nevis žurnālu. Es uzsveru, ka tāpēc, ka daži no mūsu konkurentiem skatās tikai uz gaidīšanas stāvokļiem un reģistrēšanas notikumiem, bet kopumā runājot, CPU ir visintensīvākais izpildes stāvoklis un piedāvā vislielāko atpirkšanu. Iegūstot šo ekspertu viedokli - un es dodos ļoti ātri - tas, ko es izdarīju, ir tas, ka es paskatījos uz tabulu, 100 000 rindu, 37 000 bloku. Mēs strādājam pie pilna galda, taču mums ir seši indeksi par šo lietu. Kas šeit notiek? Nu, kad es skatos, kur klauzula, ko dara šī klauzula, patiesībā kolonnu pārveido par lielajiem burtiem un saka, kur tā ir vienāda ar lielajiem burtiem, atrodiet mainīgo. Kas notiek, katru reizi, kad šī lieta tiek izpildīta, Oracle ir jāpārvērš šī kolonna ar lielajiem burtiem. Tā vietā, lai to izdarītu gandrīz piecdesmit tūkstošus reižu, daudz efektīvāk ir izveidot šo indeksu ar funkcijām balstītā indeksa lielajiem burtiem, un tas ir pieejams ne tikai Oracle uzņēmuma nodaļā, bet arī standarta nodaļā. To darot, jūs varat pārbaudīt izpildes plānu, ar kuru tiek izsniegts jaunais indeksa lietotāja perm lielie burti, tā bija tikai mana lieta.
Pēc tam, veicot mērījumus pirms un pēc, tiek apskatīts vienas sekundes izpildes laiks, apkopojot līdz 9 stundām 54 minūtēm ar tādu pašu precīzu SQL paziņojumu, taču, ja šis indekss ir iebūvēts ar lielajiem burtiem 58 000 izpildījumiem, atbilde laiks samazinās līdz apakšmilisekundēm, summējoties kopā, tas ilgst līdz septiņām sekundēm. Es būtībā saglabāju desmit stundas CPU uz sava servera. Tas ir milzīgi. Tā kā, ja man nav pienākums atsvaidzināt serveri, es varu dzīvot uz šī servera. Es faktiski samazināju šī servera izmantošanu par 20 procentiem, un jūs faktiski varat redzēt pirms un pēc. Tas ir tāds redzamības veids, ko Precīzs var nodrošināt. Ir arī dažas papildu lietas, kuras mēs varētu apskatīt, kāpēc jums ir visi šie indeksi, ja tie netiek izmantoti? Viņi to var sekot. Tur ir arhitektūra, un es to iesaiņošu, jo mēs sasniedzam stundas virsotni. Es patiesi ticu šim risinājumam un vēlamies, lai jūs būtu patiess ticīgais. Uzņēmumā IDERA mēs uzskatām, ka izmēģinājums padara klientu par labu, tāpēc, ja jūs interesē, mēs varam jūsu vietnē veikt novērtēšanu.
Ar to es nodošu bāku atpakaļ.
Ēriks Kavaņahs: Jā, tā bija milzīga detaļa, ko jūs tur parādījāt. Tas tiešām ir diezgan aizraujoši. Es domāju, ka es jums, iespējams, jau iepriekš esmu pieminējis, ka - un es zinu, ka dažos citos tīmekļa pārraidījumos, ko mēs esam veikuši ar IDERA, - es patiesībā esmu izsekojis Precise kopš tā laika, kad IDERA to ieguva, Es domāju, ka līdz pat 2008. gadam vai līdz 2009. gadam. Es toreiz to fascinēju. Man ir interese uzzināt, cik daudz darba paliek, lai saglabātu papildinājumu jaunām lietojumprogrammu izlaidumiem. Jūs pieminējāt SAP HANA, kas, manuprāt, bija diezgan iespaidīgs, ka jūs faktiski varat iedziļināties HANA arhitektūrā un veikt tur traucējummeklēšanu. Cik cilvēku jums ir? Cik lielas pūles jūs novirzāt no jūsu puses un cik lielu daļu no tā var izdarīt nedaudz dinamiski, proti, kad rīks tiek izmantots, jūs sākat rāpot un redzēt dažādas lietas? Cik daudz no tā var būt dinamiski, kāda veida, ar rīka palīdzību noskaidrots, lai jūs varētu palīdzēt cilvēkiem novērst sarežģītas vides problēmas?
Bils Elliss: Jūs tur uzdevāt daudz jautājumu.
Ēriks Kavanagh: Es zinu, atvainojiet.
Bils Elliss: Es sniedzu daudz detaļu, jo šīm lietojumprogrammām, skatoties uz kodu, velns ir sīkumos. Jums ir jābūt tik detalizētai, lai tiešām būtu kaut kas, ar kuru var rīkoties. Bez metrikas, kuru var izmantot, jūs vienkārši zināt par simptomiem. Jūs faktiski neatrisināt problēmas. IDERA mērķis ir problēmu risināšana. Uzturēt jaunumus un jaunumus ir liels izaicinājums. Jautājums par to, kas nepieciešams, lai to izdarītu, tas tiešām attiecas uz produktu pārvaldību. Man nav daudz redzamības komandā, kas mūs pamatā uztur. HANA ziņā tas faktiski ir jauns IDERA produktu līnijas papildinājums; tas ir ļoti aizraujoši. Viena no lietām, kas saistītas ar HANA, ir - ļaujiet man brīdi runāt par uzdevumu. Veicot šo uzdevumu, SAP veikali rīkotos, ja viņi replicētu datu bāzi ziņošanas vajadzībām. Tad jums vajadzēs likt cilvēkiem samierināties ar pašreizējo. Jums būtu šīs dažādās datu bāzes, un tās dažādos līmeņos nebūtu sinhronizētas. Lai to visu uzturētu, ir nepieciešams daudz laika un pūļu, kā arī aparatūra, programmatūra un cilvēki.
HANA ideja par ļoti paralēlu atmiņu datu bāzi, lai pamatā izvairītos no datu kopiju dublēšanas nepieciešamības. Mums ir viena datu bāze, viens patiesības avots, tā vienmēr ir atjaunināta, tādējādi izvairoties no nepieciešamības veikt visu šo samierināšanu. HANA datu bāzes veiktspējas nozīme pieaug - es teikšu, ka desmit reizes vai vismaz vērtīgāk nekā visu to citu datu bāzu, aparatūras un resursu summa, ko var iegādāties. Spēja pārvaldīt HANA, jo tagad šis komponents faktiski tiek pārbaudīts beta versijā, un tas drīz notiks GA. Tas ir diezgan aizraujoši IDERA un mums, lai pamatā atbalstītu SAP platformu. Es neesmu pārliecināts, kādas citas jūsu jautājuma daļas es īsumā mainīju, bet -
Ēriks Kavanaghs: nē, tas tur ir viss labais. Es iemetu jums veselu baru uzreiz, tāpēc par to žēl. Mani tiešām fascinē, es domāju, ka šī nav ļoti vienkārša lietojumprogramma, vai ne? Jūs dziļi iedziļināties šajos rīkos un saprotat, kā viņi mijiedarbojas viens ar otru, un, pēc jūsu domām, jums ir sava veida stāsts jāsagatavo galvā. Jums ir jāapvieno informācijas biti, lai saprastu, kas patiesībā notiek un kas jums sagādā grūtības, lai jūs varētu tur ieiet un šīs problēmas atrisināt.
Viens dalībnieks jautā, cik grūti ir precīzi ieviest? Cits cilvēks vaicāja, kuri ir cilvēki - acīmredzami DBA -, bet kas ir dažas citas organizācijas lomas, kas izmantotu šo rīku?
Bils Elliss: Precīzi ieviest ir mazliet sarežģītāk. Jums ir jābūt zināmām zināšanām par lietojumprogrammu vidi, runājot par to, ka, jūs zināt, šī lietojumprogramma darbojas šajā datu bāzē, tai ir nepieciešams vai - vidēja līmeņa tīmekļa serveri utt. Es domāju, ka, ņemot vērā dažu šo lietojumu sarežģītību, patiesībā tas ir salīdzinoši viegli. Ja es varu pielāgot tīmekļa serveri jūsu datu bāzei, es to varu darīt no gala līdz galam. Jūs ievērojat, ka es neko neteicu par gala klienta instrumentiem, un tas ir tāpēc, ka mēs to darām, mēs faktiski iekļaujam dinamiski, tāpēc jums nav jāmaina savs kods vai kas cits. Lietojumprogrammas lapas ietvarā tiek ievadīts JavaScript. Neatkarīgi no tā, kur atrodas lietotājs pasaulē, kad viņi piekļūst URL no jūsu lietojumprogrammas un nolaiž šo lapu, tas ir aprīkots ar precīzu. Tas ļauj mums izvēlēties lietotāja ID, viņu IP adresi, kā arī katra lapas komponenta skripta izpildes pirmā baita atdošanas laiku gala lietotāja pārlūkā.
Runājot par darījumiem, jums nav jāplāno darījumi, jo tie ir cieši saistīti. Šis URL kļūst par JVM ieejas punktu un pēc tam izsauc šo ziņojumu, kā rezultātā JVC tiek noķerts no datu bāzes. Mēs principā varam noķert šos dabiskos savienojuma punktus un pēc tam tos parādīt jums tajā darījumu ekrānā, kurā es parādīju, kur mēs arī aprēķinājām, cik daudz laika vai procentus laika pavadīja katrā atsevišķā solī. Tas viss tiek darīts automātiski. Vispārīgi runājot, mēs atvēlam 90 minūtes, kas jādara - lai pamatā instalētu Precise kodolu un tad mēs sāktu ieviest lietojumprogrammu. Atkarībā no zināšanām par lietojumu, lai iegūtu visu lietojumprogrammu, var būt vajadzīgas dažas papildu sesijas. Daudzi cilvēki izmanto tikai datu bāzes komponentu Precise. Tas ir labi. Jūs to principā varat salauzt, sadalīt komponentos, kas jums liekas nepieciešami vietnei. Mēs noteikti uzskatām, ka visa lietojumprogrammu kaudze ir aprīkota ar instrumentiem, lai jūs varētu redzēt, ka atkarība no līmeņa līdz līmenim faktiski palielina atsevišķa līmeņa uzraudzības līmeni. Ja kāds vēlas sīkāk izpētīt, kā instrumentēt savu lietojumprogrammu kaudzi, lūdzu, dodieties uz mūsu vietni - es domāju, ka tas ir vienkāršākais veids, kā pieprasīt papildu informāciju, un mēs to nedaudz apspriedīsim.
Ēriks Kavanaghs: Ļaujiet man uzdot jums vienu vai divus ātrus jautājumus. Es domāju, ka laika gaitā jūs savācat un veidojat krātuvi - gan atsevišķiem klientiem, gan kopumā kā korporatīvajai vienībai - mijiedarbību starp dažādām lietojumprogrammām un dažādām datu bāzēm. Citiem vārdiem sakot, scenāriju modelēšana, es domāju, ir tas, uz ko es atsaucos. Vai tas tā ir? Vai jūs tiešām uzturat sava veida parasto scenāriju krātuvi, lai jūs varētu sniegt ieteikumus galalietotājiem, kad tiek parādītas noteiktas lietas? Tāpat kā šī E-Business Suite versija, šī datu bāzes versija utt. - vai jūs to daudz darāt?
Bils Elliss: Nu, šāda veida informācija ir iebūvēta atzinumu ziņojumā. Rezultātu ziņojumā teikts, kas ir darbības vājās vietas, un tas ir pamatots ar izpildes laiku. Daļa no šī atzinuma ziņojuma ir uzzināt vairāk un tas, ko jūs darāt tālāk. Informācija vai klientu pieredze utt. Galvenokārt ir iekļauta šajā ieteikumu bibliotēkā.
Ēriks Kavanagh: Labi, tas izklausās labi. Nu ļaudis, fantastiska prezentācija šodien. Bils, man patika, cik daudz sīkumu tev tur bija. Es tikai domāju, ka šī ir patiešām fantastiska, smieklīga, sīka informācija, kas parāda, kā viss šis saturs tiek darīts. Noteiktā brīdī tas ir gandrīz kā melnā maģija, bet patiesībā tā nav. Tā ir ļoti specifiska tehnoloģija, kuru jūs puiši saliecat, lai saprastu ļoti, ļoti sarežģīto vidi un padarītu cilvēkus laimīgus, jo nevienam nepatīk, kad lietojumprogrammas darbojas lēni.
Labi ļaudis, mēs arhivēsim šo tīmekļa apraidi. Jūs varat tiešsaistē meklēt vietni Techopedia vai insideanalysis.com un wow, paldies par jūsu laiku, mēs ar jums sazināsimies nākamreiz. Esiet piesardzīgi.
