Przez Techopedia Staff, 2 listopada 2016
Na wynos: gospodarz Eric Kavanagh omawia wydajność aplikacji i sposoby poprawy wydajności z dr Robin Bloor, Dez Blanchfield i Billem Ellisem z IDERA.
Obecnie nie jesteś zalogowany. Zaloguj się lub zarejestruj, aby zobaczyć wideo.
Eric Kavanagh: Panie i panowie, cześć i witam ponownie w Hot Technologies. W rzeczy samej! Nazywam się Eric Kavanagh, będę dziś gospodarzem kolejnego webcastu w tej naprawdę zabawnej, ekscytującej serii, którą uzupełniamy w naszej serii Briefing Room. Tytuł brzmi „Przyspieszenie aplikacji: większa wydajność dla użytkowników końcowych”. Drodzy ludzie, kto tego nie chce? Jeśli jestem facetem, który pomaga twojej aplikacji działać szybciej, myślę, że jestem facetem, który po pracy kupuje mi piwo w barze. To musi być całkiem fajna rzecz, aby wejść i przyspieszyć czyjąś aplikację.
Jest naprawdę slajd o twoim, traf mnie na Twitterze @ Eric_Kavanagh. Zawsze staram się śledzić i zawsze tweetować, jeśli o mnie wspominasz, więc śmiało możesz o mnie wspomnieć.
Głównym celem tego pokazu jest skupienie się na różnych aspektach technologii korporacyjnej i naprawdę pomóc zdefiniować pewne dyscypliny lub określone twarze, jeśli chcesz. Wiele razy dostawcy wybierają określone warunki marketingowe i mówią o tym, jak to robią, robią to czy tamto, czy coś innego. Ten program został naprawdę zaprojektowany, aby pomóc naszym odbiorcom zrozumieć, czego potrzebuje oprogramowanie, aby być liderem w swojej przestrzeni. Jest to format dwóch analityków. Każde z nich jest pierwsze, w przeciwieństwie do pokoju odpraw, w którym sprzedawca jest pierwszy. Każdy z nich przedstawia swoje zdanie na temat tego, co według nich jest ważne, aby wiedzieć o konkretnym rodzaju technologii.
Dzisiaj mówimy o przyspieszeniu aplikacji. Dez Blanchfield, a także doktor Robin Bloor - dziś jesteśmy na całym świecie - a potem zadzwoni Bill Ellis z okolic Wirginii. Po tym przekażę to naszemu pierwszemu prezenterowi, dr Bloorowi. Nawiasem mówiąc, napisaliśmy tweeta z hasłem #podcast, więc śmiało tweetuj. Zabierz to.
Dr Robin Bloor: Dobra, dziękuję za to wprowadzenie. Wydajność aplikacji i poziomy usług - jest to rodzaj obszaru, przez lata wykonałem dużo pracy w tym obszarze, w tym sensie, że wykonałem strasznie dużo pracy w zakresie monitorowania wydajności i pracy w jednym w ten czy inny sposób, jak spróbować obliczyć te poziomy. Trzeba powiedzieć, że do tego czasu - dawno temu, mieliśmy epokę, w której ludzie budowali systemy w silosach. Zasadniczo ilość pracy, którą faktycznie muszą wykonać, aby system działał dość dobrze, jeśli był w silosie, nie był zbyt trudny, ponieważ istnieje bardzo mała, bardzo mała liczba zmiennych, które trzeba wziąć pod uwagę. Gdy tylko udało nam się właściwie połączyć w sieć, do równania doszły interakcje i orientacja na usługi. To stało się trochę trudne. Wydajność może być jednowymiarowa. Jeśli pomyślisz o aplikacji, która wielokrotnie wykonuje określoną ścieżkę kodu, wykonanie jej w rozsądny sposób w odpowiednim czasie wydaje się jednowymiarowe. Gdy tylko zaczniesz mówić o poziomach usług, w rzeczywistości mówisz o wielu rzeczach rywalizujących o zasoby komputerowe. Bardzo szybko staje się wielowymiarowy. Jeśli zaczniesz mówić o procesach biznesowych, procesy biznesowe mogą być powiązane z wieloma aplikacjami. Jeśli mówisz o architekturze zorientowanej na usługi, to dana aplikacja może faktycznie uzyskiwać dostęp do możliwości wielu aplikacji. To staje się bardzo skomplikowane.
Spojrzałem - dawno temu narysowałem ten schemat. Ten schemat ma co najmniej 20 lat. Zasadniczo nazywam to Diagramem wszystkiego, ponieważ jest to sposób spojrzenia na wszystko, co istnieje w środowisku IT. To tak naprawdę tylko cztery elementy: użytkownicy, dane, oprogramowanie i sprzęt. Oczywiście zmieniają się one z czasem, ale w rzeczywistości zdajesz sobie sprawę, kiedy na to patrzysz, istnieje hierarchiczna eksplozja każdego z tych elementów. Sprzęt tak, sprzęt może być serwerem, ale serwer może składać się z wielu procesorów, technologii sieciowej i pamięci, a to, jak się zdarza, okropnej ilości kontrolerów. Jeśli naprawdę na to spojrzysz, wszystko się rozpadnie. Jeśli naprawdę zastanawiasz się nad próbą zorganizowania tego wszystkiego, w odniesieniu do danych, które się zmieniają, zmienia się wydajność oprogramowania, ponieważ zmiany sprzętowe itd., To naprawdę patrzysz na niezwykle trudną, wielowymiarową sytuację. To jest krzywa złożoności. Oczywiście jest to krzywa złożoności dla prawie wszystkiego, ale widziałem, że rysuje się to wielokrotnie, gdy mówimy o komputerach. Zasadniczo, jeśli umieścisz węzły na jednej osi, a ważne połączenia na drugiej osi, uzyskasz krzywą złożoności. Prawie nie ma znaczenia, jakie są węzły i połączenia, i zrobi to, jeśli chcesz reprezentować wzrost głośności w sieci telefonicznej.
W rzeczywistości, gdy mówimy o węzłach w środowisku komputerowym, mówimy o pojedynczych sprawach, które są dla siebie ważne. Okazuje się, że złożoność jest kwestią struktury różnorodności i różnych ograniczeń, których próbujesz przestrzegać. Również liczby. Kiedy liczby rosną, oszaleją. Wczoraj miałem ciekawy czat, rozmawiałem z kimś - nie mogę wspomnieć, kim on był, ale to nie ma znaczenia - rozmawiali o stronie, która miała 40 000 - to jest cztery zero, 40 000 - instancji baz danych na stronie. Pomyśl o tym - 40 000 różnych baz danych. Oczywiście jedyne, co mieliśmy - mieli oczywiście wiele, wiele tysięcy aplikacji. Mówimy o bardzo dużej organizacji, ale nie mogę jej nazwać. Właściwie to na to patrzysz i próbujesz, w ten czy inny sposób, uzyskać poziomy usług, które będą odpowiednie dla wielu użytkowników, z wieloma różnymi, jeśli chcesz, oczekiwaniami. To złożona sytuacja i wszystko, co tak naprawdę mówię, to skomplikowane rzeczy. Liczby zawsze rosną. Ograniczenia są określane przez procesy biznesowe i cele biznesowe. Zauważysz zmianę oczekiwań.
Pamiętam, jak tylko Gmail, poczta Yahoo i Hotmail, wszystkie te systemy pocztowe pojawiły się, ludzie zaczęli oczekiwać, że ich wewnętrzny system pocztowy w organizacji zasłuży na poziom usług tych ogromnych operacji z ogromnymi farmami serwerów poza organizacji i zaczęto wywierać presję, aby wszystko to się wydarzyło. W rzeczywistości umowy dotyczące poziomu usług to jedno, ale oczekiwanie to coś innego, a one walczą ze sobą w organizacji, co jest niezręczne. Oto tylko perspektywa biznesowa. W niektórych systemach optymalny czas reakcji stanowi jedną dziesiątą sekundy czasu reakcji człowieka. Jedna dziesiąta sekundy to czas, w którym kobra cię gryzie. Jeśli stoisz przed kobrą i postanawia cię ugryźć, jest już za późno, bo tak nie jest, ponieważ nie możesz zareagować w ciągu jednej dziesiątej sekundy. Jedna dziesiąta sekundy to mniej więcej tyle czasu, ile potrzeba, aby piłka opuściła rękę miotacza i dotarła do faceta z kijem. Zasadniczo, kiedy widzi rzuconą piłkę, musi odpowiedzieć dokładnie w tym momencie. Ludzka reakcja, coś interesującego. Oprogramowanie do oprogramowania może oczywiście mieć większe oczekiwania.
Następnie przechodzisz do niektórych sytuacji, które moim zdaniem są sytuacjami rynkowymi, gdzie na pierwszym miejscu jest wartość biznesowa. To tak, jakbyś chciał sprzedać konkretną akcję na giełdzie, na przykład prawdopodobnie mniej, ponieważ myślisz, że spada, a wiele innych osób myśli, że spada, otrzymasz najlepszą cenę, jeśli wejdziesz na rynek jako pierwszy. Jest wiele sytuacji, wyświetlanie reklam i podobne rzeczy, bardzo podobna sytuacja. Masz ten ruch pod względem oczekiwań na poziomie usług. Masz jedną rzecz, która jest rodzajem szklanego sufitu dla ludzkiej reakcji. Gdy jest to oprogramowanie do oprogramowania, jeśli masz taką pułap, nie ma najlepszego poziomu usług. Szybszy niż wszyscy inni jest najlepszy.
Okay, myślę, że to ostatni slajd, który robiłem, ale to po to, aby dać Ci pełny obraz złożoności, kiedy spojrzysz na wymagania organizacji, usługi. Przechodząc tutaj po lewej stronie, masz zarządzanie systemem, czyli zestaw oprogramowania służącego do zarządzania usługami, które próbuje zarządzać poziomem usług. Ponad to masz zarządzanie wydajnością biznesową. Jeśli spojrzysz w dół na obszar automatyzacji zarządzania usługami, masz rozdrobnione usługi, które ewoluują w usługi standardowe, jeśli faktycznie chcesz zainwestować w tego rodzaju rzeczy, które ewoluują w usługi zintegrowane, które ewoluują w usługi zoptymalizowane . Ludzie robią przede wszystkim tylko w lewym dolnym rogu tego. Może trochę zarządzania usługami. Zarządzanie wydajnością biznesową, bardzo rzadkie. Rozdrobniony, prawie cały. Idealny świat wypełniłby tę siatkę. Oprzyrządowanie - wspomniałem o problemie z suboptymalizacją. Możesz zoptymalizować części systemu, a to nie jest dobre dla całego systemu. Jeśli sprawisz, że serce będzie optymalne, twoja krew może krążyć zbyt szybko dla reszty narządów. Jest to problem dotyczący dużych organizacji i poziomów usług. Wyraźnie nic nie zostanie osiągnięte bez wyrafinowanych narzędzi, ponieważ zmienne właśnie się dostały - cóż, jest zbyt wiele zmiennych, aby spróbować je zoptymalizować.
Powiedziawszy to, przekażę Dezowi, który, mam nadzieję, opowie o czymś zupełnie innym.
Dez Blanchfield: Dziękuję Robin. Podobnie jak dr Robin Bloor, spędziłem zbyt wiele lat myśląc o wydajności bardzo złożonych systemów na bardzo dużą skalę. Prawdopodobnie nie w tej samej skali co Robin, ale wydajność jest codziennym tematem i częścią naszego DNA jest chęć wydajności, aby jak najlepiej wykorzystać wszystko. W rzeczywistości użyłem grafiki jednej z moich ulubionych rzeczy na świecie, wyścigów Formuły I, gdzie cała planeta stoi przez chwilę nieruchomo i patrzy, jak samochody krążą w kółko. W każdym aspekcie nie ma aspektu Formuły I, który nie byłby specjalnie związany z osiąganiem wydajności. Wiele osób kupuje ten sport, ponieważ myślą, że to strata pieniędzy. Okazuje się, że samochód, którym jeździmy każdego dnia, aby upuszczać dzieci na piłkę nożną w weekendy i szkołę w pozostałe dni, jest pochodną rozwoju i badań opartych na wynikach. To rodzaj życia w wyścigach Formuły I. Codzienna technologia, codzienna nauka często wywodzą się z czegoś, co koncentruje się wyłącznie na wysokiej wydajności.
Rzeczywistość jest jednak taka, że nasz nowy „zawsze włączony” świat, który wymaga 100-procentowej dostępności - jak wspomniano wcześniej Robin - z takimi rzeczami, jak wprowadzenie poczty internetowej i innych usług, które przyjmujemy za pewnik w ciągłej przestrzeni, i teraz oczekujemy, że w nasze środowisko przedsiębiorstwa i pracy. W rzeczywistości nie zawsze oznacza to, że spełniasz warunki umowy o gwarantowanym poziomie usług. Rozumiem potrzebę zarządzania wydajnością i dostępnością aplikacji. Umowy dotyczące poziomu usług uległy zasadniczej zmianie w ciągu ostatniej dekady. Nie staramy się już więcej martwić o wydajność jednego systemu. Gdy świat był nieco prostszy, możemy mieć sytuację, w której jeden serwer z wieloma usługami może być monitorowany na żywo, a obsługa była stosunkowo łatwa. Moglibyśmy - a oto moje małe - rzeczy, którymi martwiliśmy się na przykład, kiedy byłem administratorem systemu, wiele lat temu - rozglądalibyśmy się, czy usługa zazwyczaj działa i odpowiada? Czy mogę na przykład zalogować się do terminala? Czy system operacyjny reaguje i czy mogę pisać polecenia? Czy aplikacje działają i działają? Czy widzę procesy i pamięć w robieniu rzeczy i we / wy w sieci i tak dalej? W dniach komputerów mainframe można było usłyszeć taśmy zamykane na zamek błyskawiczny i wypadający z nich papier.
Czy aplikacje odpowiadają i czy możemy się zalogować i robić na nich różne rzeczy? Czy użytkownicy mogą łączyć się z niektórymi z tych serwerów? To idzie. Są dość fundamentalne. Potem kilka śmiesznych - czy biuro pomocy jest zielone? Bo jeśli nie, to wszystko działa dobrze, a kto dostanie pączki? W tamtych czasach życie było naprawdę proste. Nawet w tych dniach, a potem rozmawiam z 20–30 lat temu, złożoność była wciąż bardzo wysoka. W stosunkowo prosty sposób moglibyśmy zarządzać umowami dotyczącymi poziomu usług i mieć oko na wydajność. Jak już wspomniał Robin, nie możemy tego robić ręcznie. Wyzwanie jest zbyt duże. Faktem jest, że kilka dobrych aplikacji, administratorów, sieci systemowej i bazy danych, administratorzy mogą monitorować i spełniać SLA wydajności. Umowy SLA odeszły już tak daleko, że walczyłem zeszłej nocy, kiedy zbierałem swoje ostatnie notatki, aby nawet pomyśleć o roku, w którym po raz ostatni udało mi się spojrzeć na system o bardzo złożonym stosie, zrozumieć go, a nawet zrozumieć, co było dzieje się pod maską, a ja wywodzę się z głęboko technicznego zaplecza. Nie mogę sobie wyobrazić, jak to jest zmierzyć się z tym na co dzień, teraz w sposób administracyjny.
Co się stało? W 1996 r. Aplikacje oparte na bazach danych zostały przekształcone wraz z boomem internetowym. Wielu z nas przeszło przez to. Nawet jeśli nie byłeś w boomie internetowym, możesz po prostu rozejrzeć się i zdać sobie sprawę, że w życiu codziennym wszystko zaczepiamy teraz w Internecie. Wydaje mi się, że mamy toster, który najwyraźniej jest wyposażony w opcję dostępu do Wi-Fi, co jest śmieszne, ponieważ nie potrzebuję, aby mój toster był podłączony do Internetu. W 2000 r., Szczególnie na początku 2000 r., Musieliśmy poradzić sobie z tym ogromnym wzrostem złożoności w zakresie dostarczania usług w boomie dot-com. Potem kolejna śmieszna, niewygodna iskra w web 2.0, gdzie powstały smartfony, a teraz aplikacje były w naszych rękach 24 godziny na dobę, 7 dni w tygodniu i były zawsze włączone.
Jest rok 2016, mamy do czynienia z kolejnym trzęsieniem ziemi w postaci chmury, dużych zbiorów danych i mobilności. Są to systemy, które są tak duże, że często trudno je zrozumieć i wyrazić po angielsku. Kiedy myślimy o tym, że niektóre z dużych jednorożców, o których mówimy, mają dziesiątki setek petabajtów danych. To całe piętro miejsca na dysku i miejsce na przechowywanie wiadomości e-mail, zdjęć i mediów społecznościowych. Lub w niektórych przypadkach, w logistyce transportu i spedycji, to wszystko w bankowości, tam gdzie są twoje pieniądze lub gdzie jest twój post lub twój, gdzie jest rzecz kupiona na eBayu. Następna wielka fala, przed którą stoimy, to bardzo ciężkie wyzwanie Internetu rzeczy.
Jeśli nie było wystarczająco źle, mamy zamiar wbudować sztuczną inteligencję i przetwarzanie poznawcze w prawie wszystko. Obecnie rozmawiamy z silnikami Siri i Google. Wiem, że Amazon ma swoją własną. Baidu ma jedno z tych urządzeń, z którymi możesz rozmawiać, konwertują go na tekst, który przechodzi do normalnego systemu, baza danych wysyła zapytanie, wraca i odwraca proces. Pomyśl o złożoności, która się z tym wiąże. Rzeczywistość jest taka, że złożoność dzisiejszego standardowego stosu aplikacji znacznie wykracza poza ludzkie możliwości. Gdy myślisz o wszystkim, co dzieje się po naciśnięciu przycisku na smartfonie lub tablecie, mówisz do niego, konwertujesz go na tekst, uruchamiasz całą drogę do Internetu w systemie zaplecza, a front-end odbiera konwertuje je na zapytanie, uruchamia zapytanie przez stos aplikacji, przechodzi przez bazę danych, trafia na dysk, wraca, a pośrodku jest sieć operatora, jest centrum statusu sieci lokalnej. Złożoność jest szalona.
Skutecznie potwierdzamy to jako hiperskalę. Złożoność i szybkość hiperskali jest po prostu oszałamiająca. Aplikacje i bazy danych stały się tak duże i tak złożone, że zarządzanie wydajnością jest w rzeczywistości nauką samą w sobie. Wielu nazywa to nauką o rakietach. Mamy technologię onsite, mamy technologię offsite, mamy szereg opcji centrum danych; fizyczny i wirtualny. Mamy fizyczne i wirtualne serwery, mamy chmurę, mamy infrastrukturę jako usługę i platformę jako usługę, a oprogramowanie jako usługę jest rzeczą, którą teraz bierzemy za pewnik. To ostatnie, oprogramowanie jako usługa, stało się przerażające na kilka lat temu, kiedy dyrektorzy finansowi i części organizacji zdali sobie sprawę, że mogą odebrać swoją kartę kredytową i po prostu kupić rzeczy samodzielnie i obejść CIO i skutecznie nazwaliśmy to „cieniem” IT ”i CIO próbują teraz to odwrócić i zapanować nad kontrolą.
W infrastrukturze mamy zdefiniowaną programowo sieć, wirtualizację funkcji sieciowych, poniżej, prawdopodobnie już skończyliśmy, teraz mamy mikrousługi i aplikacje aktywnych usług. Po kliknięciu adresu URL na końcu tego adresu znajduje się logika biznesowa, która opisuje, czego potrzebuje, aby go faktycznie dostarczyć. Nie musi na to czekać przygotowana logika. Z jednej strony mamy tradycyjne bazy danych, które są skalowane bardzo, bardzo duże. Mamy infrastrukturę i ekosystemy Hadoop w innym spektrum, które są tak duże, że, jak powiedziałem, ludzie mówią teraz o setkach petabajtów danych. Mamy złożoność mobilności, jeśli chodzi o urządzenia, które noszą przy sobie, laptopy, telefony i tablety.
Mamy BYOD w niektórych zamkniętych środowiskach i coraz częściej, odkąd doświadczeni ludzie z pokolenia Y przynoszą własne urządzenia. Po prostu pozwalamy im rozmawiać o interfejsach sieciowych. Zarówno przez Internet, jak i przez Wi-Fi, mamy bezpłatne Wi-Fi w kawiarni na dole, gdy piją kawę. Lub nasze wewnętrzne Wi-Fi. Maszyna do maszyny jest zawsze obecna. To nie jest bezpośrednio częścią Internetu rzeczy, ale jest również powiązane. Internet przedmiotów to zupełnie nowa gra o złożoności, która oszałamia mózg. Sztuczna inteligencja, a jeśli uważasz, że to, z czym teraz bawimy, przy wszystkich Siri i innych powiązanych urządzeniach, z którymi rozmawiamy, jest złożone, poczekaj, aż dojdziesz do sytuacji, w której zobaczysz coś o nazwie Olli, czyli trójwymiarowość drukowany autobus, który zabiera około sześciu osób i może sam jeździć po mieście i możesz mówić do niego po angielsku, a on odpowie ci. Jeśli dojdzie do ruchu, zdecyduje się skręcić w lewo lub w prawo z głównego obszaru, w którym jest ruch. Gdy się skręca i martwisz się, dlaczego skręca w lewo lub w prawo od głównej drogi, powie ci: „Nie martw się, zaraz skręcę w lewo. Przed nami ruch i zamierzam go obejść. ”
Zarządzanie wydajnością wszystkich znajdujących się tam systemów i całą ich złożonością, śledzenie, gdzie idą te dane, czy trafiają do bazy danych, wszystkich połączeń i wszystkich istotnych bitów, jest po prostu oszałamiające. Rzeczywistość jest taka, że zarządzanie wydajnością i umowami SLA przy dzisiejszej szybkości i skali wymaga narzędzi i systemów, a domyślnie nie jest to już coś, w czym można by pomyśleć, że byłoby miło mieć narzędzie - to warunek konieczny; jest to absolutnie konieczne. Oto coś jak mały przykład, lista diagramów projektowania aplikacji wysokiego poziomu dla OpenStack, chmury zdefiniowanej programowo dla oprogramowania typu open source. To tylko duży kawałek. To nie tylko serwery i baza danych. To tutaj każda mała niebieska kropelka reprezentuje skupiska rzeczy. W niektórych przypadkach pliki i serwery lub setki baz danych lub oczywiście nie więcej niż dziesiątki tysięcy małych logik aplikacji działających. To jest mała wersja. To naprawdę zadziwiające, gdy zaczynasz myśleć o złożoności, która się z tym wiąże. Dzisiaj, nawet w obszarze dużych zbiorów danych, zamieszczę zrzuty ekranu tylko marek. Kiedy myślisz o wszystkich elementach, którymi musimy tu zarządzać, nie mówimy koniecznie o jednej marce, to wszystkie marki w środowisku dużych zbiorów danych i najlepsza marka, a nie każda mała mała lub open source. Patrzysz i myślisz, że to dość zadziwiająca mapa.
Rzućmy okiem na kilka pionów. Weźmy na przykład marketing. Oto podobny wykres, ale z zestawów technologii dostępnych w samej technologii marketingowej. To jest wykres z 2011 roku. Oto wersja 2016. Pomyśl tylko, że to tylko liczba marek produktów, które możesz uruchomić dla technologii w odniesieniu do technologii marketingowej. Nie złożoność znajdujących się tam systemów, ani różnych aplikacji i sieci oraz rozwoju i sieci. Tylko marka. Jest przedtem, pięć lat temu i oto dzisiaj. Będzie tylko gorzej. Jesteśmy teraz w tym miejscu, gdzie jest rzeczywistość, ludzie po prostu nie mogą zapewnić wszystkich umów dotyczących poziomu usług. Nie możemy zagłębić się w wystarczająco dużo szczegółów, wystarczająco szybko i na taką skalę, jakiej potrzebujemy. Oto przykład, jak teraz wygląda konsola monitorująca. To jest jak prawie dwadzieścia dziwnie sklejonych ekranów, które udają, że są jednym wielkim, dużym ekranem wyświetlającym każdy monitor. Teraz jest tutaj ciekawie, nie wspomnę o marce, ale ta platforma monitorowania monitoruje pojedynczą aplikację w środowisku logistycznym i wysyłkowym. Tylko jedna aplikacja. Jeśli pomyślisz o tym, o czym mówił Robin, gdzie organizacje mogą obecnie mieć 40 000 baz danych w środowiskach produkcyjnych. Czy potrafisz sobie wyobrazić, jak mogłoby wyglądać 40 000 wersji tej kolekcji ekranów monitorujących jedną aplikację? To bardzo odważny świat, w którym żyjemy. Jak powiedział Robin i absolutnie w 100 procentach powiem, że bez odpowiednich narzędzi, bez odpowiedniego wsparcia i ludzi na stole za pomocą tych narzędzi, wydajność aplikacji jest dla ludzi straconą grą i musi to być zrobione za pomocą narzędzi i oprogramowania.
Dzięki temu przekażę naszym znajomym w IDERA.
Eric Kavanagh: W porządku, Bill.
Bill Ellis: Dziękuję. Udostępniam mój ekran tutaj. Chyba ktoś może potwierdzić, że widzisz mój ekran?
Dr Robin Bloor: Tak.
Eric Kavanagh: Wygląda dobrze.
Bill Ellis: Dziękuję. Jedyną rzeczą, o której mówił, było to, że naprawdę nie mogę się doczekać, to samochód z własnym napędem. Jedyne, o czym nikt nie słyszał, to to, co się dzieje, gdy pada śnieg? Zastanawiam się, czy inżynierowie w Kalifornii zdali sobie sprawę, że w innych częściach kraju pada całkiem sporo.
Dez Blanchfield: Podoba mi się, zamierzam to zapamiętać.
Eric Kavanagh: Typowa jedna mila na godzinę.
Bill Ellis: Jesteśmy tutaj, aby porozmawiać o zarządzaniu wydajnością aplikacji w złożonym środowisku. Jedną z rzeczy, o których lubię rozmawiać, jest to, że wiele osób mówi o wydajności, charakter reakcji to, hej więcej serwerów, więcej procesora, więcej pamięci itp. Drugą stroną tej monety jest wydajność przetwarzania. Naprawdę, to dwie strony tej samej monety i przyjrzymy się im obu. Ostatecznym celem jest spełnienie umów dotyczących poziomu usług dla transakcji biznesowych. Ostatecznie cała ta technologia istnieje dla firmy. Rozmawialiśmy o stworzeniu pierwszej w branży bazy danych do zarządzania wydajnością. Ideałem tego jest dopasowanie się do idealnej formy wydajności i zarządzanie nią od początku cyklu życia aplikacji.
Tematy naprawdę sprowadzają się do czterech części; jeden to proces zarządzania wydajnością. Rozmawialiśmy ze wszystkimi i każdy ma narzędzia. Jeśli nie mają narzędzi, mają skrypty lub polecenia, ale brakuje im kontekstu. Kontekst po prostu łączy kropki w stosach aplikacji. Te aplikacje - są oparte na przeglądarce. Są bardzo ściśle powiązane między poziomami. Istotny jest również sposób interakcji poziomów. Następnie mówimy o transakcji biznesowej. Zapewnimy widoczność nie tylko pracownikom technicznym, ale także właścicielom aplikacji i menedżerom operacji.
Mam kilka studiów przypadku, aby podzielić się z Wami sposobem, w jaki klienci wykorzystali je. To bardzo praktyczna część prezentacji tutaj. Rzućmy okiem na to, co zwykle się dzieje. Lubię rysować - to było jak niesamowity kolaż technologii. Liczba technologii w centrum danych właśnie wzrosła, wzrosła i wzrosła. Tymczasem użytkownik końcowy nie dba o to i jest tego nieświadomy. Chcą tylko wykonać transakcję, mieć ją dostępną, szybko ją zrealizować. To, co zwykle się zdarza, to fakt, że specjaliści IT nie zdają sobie sprawy, że użytkownicy końcowi mieli nawet problem, dopóki się nie zgłosili. Rozpoczyna się to czasochłonnym, powolnym procesem i często frustrującym. Co się stanie, ludzie otworzą swoje narzędzia i spojrzą na podzbiór stosu aplikacji. Przy tym podzbiorze bardzo trudno jest odpowiedzieć na najprostsze pytanie. Czy to normalne, że masz problem? Co to za transakcja? Gdzie w stosie aplikacji jest wąskie gardło? Spędzając cały ten czas, patrząc poziom po poziomie, nie będąc w stanie odpowiedzieć na te pytania, w końcu spędzasz dużo czasu i energii, dużo personelu, funduszy i energii.
Aby rozwiązać ten problem, w celu zapewnienia lepszego sposobu, Precise faktycznie bierze transakcję śledzenia użytkownika końcowego, przechwytuje metadane na jej temat, śledzi transakcję przez sieć, do serwera WWW, do warstwy logiki biznesowej i obsługujemy .NET i ABAP oraz PeopleCode i E-Business Suite, w aplikacjach wielowarstwowych, które ostatecznie wszystkie transakcje będą wchodzić w interakcje z systemem rejestracji. Niezależnie od tego, czy jest to przegląd zapasów, czy czas raportowania działał, zawsze wchodzą w interakcję z bazą danych. Baza danych staje się podstawą wydajności biznesowej. Z kolei baza danych opiera się na pamięci. Na co odpowiadają metadane dotyczące transakcji, kto, jaka transakcja, gdzie w stosie aplikacji, a następnie mamy głęboką widoczność na poziomie kodu, aby pokazać ci, co wykonuje. Informacje te są przechwytywane w sposób ciągły, umieszczane w bazie danych zarządzania wydajnością - która staje się pojedynczym kawałkiem muzyki, aby każdy mógł zobaczyć, co się dzieje. Istnieją różne osoby i organizacje, które dbają o to, co się dzieje: eksperci techniczni, właściciele aplikacji, a ostatecznie sama firma. Gdy pojawia się problem, chcesz mieć możliwość wyodrębnienia informacji o tej transakcji.
Zanim przejdziemy do transakcji inwestycyjnej, chcę pokazać, jak to może wyglądać dla różnych osób w organizacji. Na poziomie zarządzania może być potrzebny przegląd wielu aplikacji. Możesz chcieć wiedzieć o kondycji obliczanej na podstawie zgodności i dostępności umowy SLA. To zdrowie nie oznacza, że wszystko działa w 100 procentach idealnie. W tym przypadku jest miejsce, możesz zobaczyć, że transakcja inwestycyjna ma status ostrzeżenia. Teraz, nieco głębiej, być może w branży, chcesz uzyskać dodatkowe informacje na temat poszczególnych transakcji, gdy naruszają one umowy SLA, liczbę transakcji itp. Zespół operacyjny będzie chciał zostać o tym powiadomiony poprzez ostrzeżenie o niektórych sortować. Mamy wbudowane alerty wydajności. Rzeczywiście mierzymy wydajność w przeglądarce użytkownika końcowego. Niezależnie od tego, czy jest to Internet Explorer, Chrome, Firefox itp., Jesteśmy w stanie wykryć, to odpowiada na pierwsze pytanie: czy użytkownik końcowy ma problem?
Zanurzmy się i zobaczmy, co jeszcze możemy na ten temat pokazać. Ludzie zainteresowani wydajnością otworzą Precise. Oceniliby transakcje. Sprawdziliby kolumnę SLA, aby zidentyfikować transakcje, które nie były zgodne z SLA. Będą mogli zobaczyć użytkowników, których dotyczy, a także informacje o tym, co zrobiła ta transakcja podczas przepływu przez aplikację. Sposób, w jaki odszyfrowujesz te hieroglify, to przeglądarka, URL, U to URL, to jest punkt wejścia do JVM. Teraz ta konkretna maszyna JVM wywołuje serwer WWW do drugiej maszyny JVM, która następnie wykonuje instrukcję SQL. Jest to z pewnością problem bazy danych, ponieważ ta instrukcja SQL była odpowiedzialna za 72 procent czasu odpowiedzi. Jesteśmy skoncentrowani na czasie. Czas jest walutą wydajności. To, w jaki sposób użytkownicy końcowi odczuwają, czy wszystko działa wolno, czy nie, i jest to miara zużycia zasobów. To bardzo przydatne; to rodzaj pojedynczej miary, która jest najważniejsza dla oceny wydajności. Gdy ten problem jest przekazywany do DBA, nie jest to tylko problem bazy danych, to ta instrukcja SQL. To jest kontekst, o którym mówiłem.
Teraz uzbrojony w te informacje, mogę wejść i przeanalizować, co się stało. Widzę przede wszystkim, że oś Y to czas w ciągu dnia. Przepraszam, oś Y to czas reakcji, oś X to czas w ciągu dnia. Widzę, że występuje problem z bazą danych, są dwa wystąpienia, wróć do tego przepływu, podnieś instrukcję SQL i przejdź do widoku eksperta, w którym Precise jest w stanie pokazać, co się dzieje, jego kontrolę, czas trwania kodu wykonać. W warstwie bazy danych jest to plan wykonania. Zauważysz, że Precise wybrał prawdziwy plan wykonania, który został użyty w czasie wykonania, który różni się od planu szacunkowego, który miałby miejsce w momencie wydania planu, a nie w czasie wykonywania. Może, ale nie musi odzwierciedlać faktycznej bazy danych.
Poniżej znajduje się analiza czasu odpowiedzi dla instrukcji SQL. Dziewięćdziesiąt procent czasu spędzonego na przechowywaniu; dziesięć procent wykorzystano w procesorze. Widzę tekst instrukcji SQL oraz raport z ustaleń. Tekst instrukcji SQL faktycznie zaczyna ujawniać pewne problemy z kodowaniem. To jest wybrana gwiazda; który zwraca wszystkie wiersze - przepraszam, wszystkie kolumny z wierszy, które zostały zwrócone. Cofamy dodatkowe kolumny, których aplikacja może potrzebować lub nie. Te kolumny zajmują miejsce i zasoby do przetworzenia. Jeśli uruchomisz SAP, jedną z dużych zmian, ponieważ baza danych HANA jest kolumnowa, polega na tym, że przepisywanie SAP, aby nie wybierać gwiazdki, aby znacznie zmniejszyć zużycie zasobów. Jest to w zasadzie coś, co zdarza się dużo czasu również w aplikacjach domowych, takich jak Java, .NET itp.
Ten ekran pokazuje, kto, co, kiedy, gdzie i dlaczego. Dlaczego tak się dzieje, na przykład instrukcja SQL i plan wykonania, który pozwala rozwiązać problemy. Ponieważ Precise działa w sposób ciągły, możesz faktycznie mierzyć przed i po, na poziomie instrukcji SQL, na poziomie transakcji, więc albo możesz mierzyć dla siebie, jak również przez właścicieli aplikacji i zarządzania, czy problem został rozwiązany . Ta dokumentacja jest naprawdę pomocna. Stos aplikacji jest bardzo złożony. Z wielu aplikacji, tak naprawdę, wszyscy, z którymi rozmawialiśmy, uruchamiają przynajmniej część stosu aplikacji w VMware. W tym przypadku patrzą na aplikację obsługi klienta, patrzą na czas transakcji i korelują go ze spowolnieniem jest zdarzeniem wirtualizacji. Precyzyjne śledzi wszystkie zdarzenia wirtualizacji. Mamy wtyczkę do vCenter, aby to odebrać.
Jesteśmy również w stanie wykryć niezgodę. Spór jest inny niż wykorzystanie. Rzeczywiste pokazanie, kiedy hałaśliwy sąsiad wpływa na maszynę wirtualną gościa, w kontekście aplikacji serwera klienta. Teraz jestem w stanie drążyć i uzyskiwać informacje i faktycznie widzę dwie maszyny wirtualne, które w tym przypadku walczą o zasoby procesora. To pozwala mi mieć widoczność, dzięki czemu mogę patrzeć na harmonogram. Mogę umieścić maszynę wirtualną gościa na innym serwerze fizycznym. Wszystkie te rzeczy, na które możesz odpowiedzieć, a ponadto mogę spojrzeć na efektywność kodu, aby mógł zużywać mniej procesora. Myślę, że mam całkiem dobry przykład w tej prezentacji, w jaki sposób ktoś był w stanie zmniejszyć zużycie procesora o rząd wielkości.
To był VMware. Przejdźmy do samego kodu, kodu aplikacji. Precyzyjne będą w stanie pokazać ci, co dzieje się w Javie, .NET, kodzie ABAP, e-biznesie, PeopleCode itp. Są to punkty wejścia do, w tym przypadku, WebLogic. Na dole znajduje się raport z ustaleń, który mówi mi, że to te EJB, na które musisz spojrzeć, i powie, że również blokujesz się w tym systemie. Ponownie przejdź do poziomu logiki biznesowej, aby pokazać, co się dzieje. W tym przypadku patrzę na konkretne przypadki; Wspieram także klastrowanie. Jeśli masz wiele uruchomionych maszyn JVM, możesz albo spojrzeć na klaster jako całość, albo na wąskie gardła w poszczególnych maszynach JVM.
Gdy wchodzisz w zamykanie, mogę wpaść w wyjątki. Wyjątek jest trochę inny niż problem z wydajnością. Zazwyczaj wyjątki są uruchamiane bardzo szybko. Ponieważ wystąpił błąd logiczny i po trafieniu w błąd logiczny, kończy się. Byliśmy w stanie uchwycić ślad stosu w momencie wyjątku, to może zaoszczędzić dużo czasu, ponieważ przechodzi przez próbę ustalenia, co się dzieje, po prostu masz ślad stosu, właśnie tam. Jesteśmy również w stanie wychwycić wycieki pamięci. Rozwiązanie obejmuje również warstwę bazy danych, mogę wejść, mogę ocenić wystąpienie bazy danych. Ponownie, oś y to czas, w którym spędzono czas, oś x to czas w ciągu dnia. Istnieje raport ustaleń, który automatycznie mówi mi, co dzieje się w systemie i na co mogę spojrzeć.
Jedną z rzeczy w raporcie wyników Precise jest to, że nie tylko przegląda dzienniki lub stan oczekiwania - analizuje wszystkie stany wykonania, w tym procesor, a także zwraca informacje z pamięci. Pamięć masowa jest bardzo ważną częścią stosu aplikacji, szczególnie z nadejściem stanu półprzewodnikowego. Posługiwanie się tymi informacjami może być bardzo pomocne. W przypadku niektórych jednostek pamięci możemy dokładnie przeanalizować i pokazać, co dzieje się na poziomie poszczególnych urządzeń. Tego rodzaju informacje - po raz kolejny jest to głęboka widoczność; ma szeroki zakres - zapewnia wystarczającą ilość informacji, aby uzyskać większy wpływ na wydajność jako profesjonalisty w zakresie wydajności aplikacji, dzięki czemu można zoptymalizować aplikacje od końca do końca w celu spełnienia tych transakcji biznesowych.
Mam kilka studiów przypadków, którymi chciałem się z tobą podzielić. Płyniemy dość szybko; Mam nadzieję, że idę w dobrym tempie. Mówiąc o pamięci, wszyscy z czasem zmieniają sprzęt. Jest gwarancja na sprzęt. Czy naprawdę przyniosło to, co powiedział ci sprzedawca? Możesz to ocenić za pomocą Precise. Wchodzisz, a to, co się tutaj stało, w zasadzie umieściły nową jednostkę pamięci, ale kiedy administratorzy pamięci spojrzeli tylko na poziom jednostki pamięci, zobaczyli wiele sporów i pomyśleli, że może być problem z tą nową jednostką pamięci . Patrząc na wszystko z całościowej perspektywy, właśnie po to, aby pokazać, gdzie to się faktycznie stanie. W rzeczywistości przeszli z przepustowości około 400 megapikseli na sekundę, gdzie pamięć była odpowiedzialna za 38 procent czasu reakcji, więc jest dość wysoka. Dzięki nowej jednostce pamięci zwiększyliśmy przepustowość do sześciu, siedemset megapikseli na sekundę, czyli w zasadzie dwukrotnie, i jesteśmy w stanie zmniejszyć udział warstwy pamięci do czasu transakcji o połowę. Jestem w stanie zobrazować to wcześniej, to jest okres przejściowy, a potem później.
Po raz kolejny dokumentacja potwierdzająca, że warto było zainwestować w sprzęt i dostarczono go zgodnie z oczekiwaniami tego konkretnego dostawcy. Ze względu na złożoność, liczbę rzeczy istnieje wiele rzeczy, które mogą się wydarzyć. W tym przypadku faktycznie mieli sytuację, w której wszyscy obwiniali DBA, DBA było jak „Cóż, nie tak szybko”. Tutaj patrzymy na aplikację SAP, myślę, że ten typ scenariusza jest dość powszechny . Co się stało, opracowywali niestandardową transakcję dla użytkownika. Użytkownik mówi: „To jest takie wolne”. Koder ABAP - to język programowania w SAP - powiedział: „To jest problem z bazą danych”. W końcu otworzyli się Precise; mierzyli tego użytkownika końcowego przez 60 sekund, czyli przez ponad minutę. W zapleczu spędzono pięćdziesiąt trzy sekundy. Wwiercili się w zaplecze i byli w stanie odkryć instrukcję SQL przedstawioną w kolejności malejącej.
Ta najwyższa instrukcja SQL, która odpowiada za 25 procent zużycia zasobów, jej średni czas wykonania wynosi dwie milisekundy. Nie możesz winić bazy danych. Wiesz, hej, nie tak szybko, koleś. Pytanie brzmi: dlaczego jest tyle egzekucji? Cóż, odesłali go z powrotem do ABAP, wszedł do środka, zajrzał do zagnieżdżenia pętli, dowiedział się, że wzywają bazę danych w niewłaściwym miejscu, po prostu dokonali zmiany, przetestowali zmianę, a teraz nowy czas odpowiedzi to pięć sekund. Trochę wolno, ale mogliby z tym żyć. O wiele lepiej niż 60 sekund. Czasami, po prostu fretując, czy to kod aplikacji, czy baza danych, czy to pamięć? Są to obszary, w których Precise, dzięki kontekstowi kompleksowych transakcji, właśnie tam wchodzi w grę Precise. Zasadniczo kończysz te rzeczy.
Patrzę na czas, wygląda na to, że wciąż mamy trochę czasu, aby przejść przez kilka kolejnych. Przesyłam strumieniowo przez te. Ta aplikacja była rozwijana przez ponad rok. Kiedy weszli w kontrolę jakości, zauważyli, że serwery WWW zostały maksymalnie zmaksymalizowane w 100 procentach i wyglądało na to, że aplikacja nie może działać pod VMware. Pierwszą rzeczą, jaką wszyscy powiedzieli, było: „Połóż to na fizyce; nie może działać pod VMware. ”Precyzyjnie faktycznie zaoferowało im dodatkowe sposoby rozwiązania problemu. Przyjrzeliśmy się transakcjom, zobaczyliśmy wywołanie serwera WWW, pojawia się ono jako ASMX w IIS.NET. Faktycznie ujawnił podstawowy kod. Widzisz to, gdzie wskazuję? To jest 23 dni, 11 godzin. Wow, jak to możliwe? Cóż, każde wywołanie zajmuje 9, 4 sekundy, a ta rzecz jest wywoływana 215 000 razy. Do każdego wywołania używa 6 sekund procesora. To jest powód, dlaczego ten kod nigdy nie mógł się skalować. W rzeczywistości nie można go było skalować fizycznie.
To, co zrobili, to to, że wrócili do swoich programistów i powiedzieli: „Czy ktoś może coś zmienić?” W pewnym sensie mieli konkurs, przetestowali różne sugestie i wpadli na sugestię, która była w stanie uruchomić wiele wydajniej. Nowy zakończył jeden punkt, nieco mniej niż dwie sekundy, z dwiema setnymi sekundy procesora. Teraz to może się skalować i może działać na farmie VMware. Zasadniczo byliśmy w stanie udokumentować to zarówno na poziomie kodu, jak i na poziomie transakcji. To rodzaj wcześniej, a potem później. Teraz, gdy widzisz tutaj wykres słupkowy stosu, który pokazuje sieć, .NET i bazę danych, teraz wchodzisz w interakcję z bazą danych. Jest to profil, którego można się spodziewać po aplikacji, która działała normalnie.
W porządku, wybieram i wybieram pod względem dodatkowych rzeczy, które mogę ci pokazać. Wiele osób lubi to, ponieważ oszałamia wiele sklepów. Jeśli nie możesz spełnić SLA biznesowego, a wszyscy mówią: „Pomóż nam”. W tym sklepie sytuacja SLA biznesowego była realizowana w zamówieniach otrzymanych do godziny 15.00, wysyłana jest tego dnia. Bardzo ważne jest, aby wydali zamówienia, a magazyn jest bardzo zajęty. Ten ekran zamówienia sprzedaży JD Edwards był zawieszany i można bardzo dobrze zrozumieć, że jest to system zarządzania zapasami detalicznymi na czas. Puste półki są niedopuszczalne w sprzedaży detalicznej. Muszę mieć tam towary, żeby je sprzedać. Zanurkowaliśmy, w tym przypadku przeglądamy bazę danych serwera SQL. Wygląd jest taki sam, bez względu na to, czy jest to SQL, Oracle, DB2 czy Sybase.
Zidentyfikowaliśmy wybrane z PS_PROD i jesteśmy w stanie uchwycić czas trwania, fakt, że wykonują tak wiele. Ciemnoniebieski pasował do klucza, który powiedział, że nie czekają na jakiś stan oczekiwania, logowanie, a nawet przechowywanie - ta sprawa jest związana z procesorem. Śledziliśmy instrukcję SQL do 34301, więc za każdym razem, gdy jest wykonywana, zwiększamy nasze liczniki, aby ją śledzić. Oznacza to, że mamy szczegółową historię i mogę uzyskać do niej dostęp, klikając ten przycisk melodii. Oto karta historii. Ten ekran pokazuje średni czas trwania w porównaniu ze zmianami. W środę, czwartek, piątek średni czas trwania wynosił około dwóch dziesiątych sekundy. Bardzo mało zawiesza się ekranów, są w stanie spełnić warunki SLA dla biznesu. Nadchodzi 27 lutego, coś się zmienia i nagle czas wykonywania jest już dostępny, a to tak naprawdę wystarczająco długo, aby spowodować przekroczenie limitu czasu, co powoduje zawieszenie się ekranu. Precyzyjne, przechowując szczegółową historię, w tym plan wykonania i ogólne zmiany indeksów tabeli, jeśli ten SQL jest w użyciu. Udało nam się ustalić, że plan dostępu zmienił się 27 lutego. Od poniedziałku do piątkowego złego tygodnia. Już 5 marca plan dostępu ponownie się zmienił. To dobry tydzień. Ta różowa gwiazda informuje nas o zaktualizowanej głośności.
Widać tutaj, że liczba wierszy w tabelach bazowych rośnie i jest to typowe dla firmy. Chcesz, aby Twoje stoły rosły. Chodzi o to, że instrukcje są parsowane, przychodzą instrukcje SQL, optymalizator musi zdecydować, co zrobić i wybrać, kiedy plan wykonania jest szybki, wybrać inny plan wykonania, gdy jest wolny, powodując zawieszenie się ekranu. Na podstawie głębokiej technologii muszę wiedzieć, jaki jest plan wykonania, a Precise przechwytuje go wraz z datą i czasem. Ten był szybki i wydajny, ten był wolny i nieefektywny. To sprzężenie filtra po prostu używa dużo więcej procesora do uzgodnienia, aby wykonać tę konkretną instrukcję SQL. Nadal mają ten sam ostateczny efekt, ale ten w zasadzie ma wolniejszą, mniej wydajną recepturę na dostarczanie zestawu wyników. Więc przechodzimy. Hej, mamy jeszcze trochę czasu?
Eric Kavanagh: Tak, idź po to.
Bill Ellis: Dobra, przejdę dalej. Jedną rzecz, o której chciałbym pamiętać, rozmawialiśmy o sprzęcie, rozmawialiśmy o SAP, rozmawialiśmy o .NET, rozmawialiśmy o JD Edwards i środowisku Java-SQL Server. To jest SAP, tutaj patrzymy na PeopleSoft. Matryca wsparcia Precise jest szeroka i głęboka. Jeśli masz aplikację, bardziej niż prawdopodobne, możemy ją oprzyrządować, aby zapewnić ten poziom widoczności. Jedną z największych zmian, która się teraz dzieje, jest mobilność. PeopleSoft wprowadził mobilność dzięki interfejsowi Fluid UI. Interfejs Fluid korzysta z systemu zupełnie inaczej. Ta aplikacja ewoluuje. Fluid UI - z punktu widzenia zarządzania umożliwia użytkownikom końcowym korzystanie z telefonu i znacznie zwiększa produktywność. Jeśli masz setki, tysiące lub nawet więcej pracowników, jeśli możesz zwiększyć ich produktywność o 1–2 procent, możesz mieć ogromny wpływ na płace i wszystko inne. Co się stało, ten konkretny sklep wprowadził interfejs PeopleSoft Fluid. Mówiąc o złożoności, jest to stos PeopleSoft. Jedna aplikacja, minimum sześć technologii, wielu użytkowników końcowych. Jak to zacząć?
Po raz kolejny Precise będzie w stanie śledzić te transakcje. To, co tu pokazujemy, to ułożony wykres słupkowy pokazujący klienta, serwer WWW, Javę, bazę danych Tuxedo, stos aplikacji PeopleSoft. Zielona mapa do J2EE, co jest dość fantazyjnym sposobem powiedzenia WebLogic. To jest cutover. Użytkownicy końcowi zaczynają korzystać z Fluid UI, a czas reakcji może wynosić od półtora, dwóch sekund do około dziewięciu, dziesięciu sekund. To, czego nie pokazuje ten ekran, to liczba osób, które „nie reagują”. W rzeczywistości zawieszają się one w aplikacji. Rzućmy okiem na niektóre z widoczności, które Precise jest w stanie zapewnić temu klientowi.
Po pierwsze, kiedy patrzę na transakcje PeopleSoft, widzą, że w zasadzie widzieliśmy tego typu rzeczy na całym świecie. Wpływ na wszystkie transakcje, a także na wszystkie lokalizacje. Nawiasem mówiąc, kiedy na to spojrzysz, możesz faktycznie zobaczyć lokalizacje na całym świecie. Od Azji i Pacyfiku po Europę i Amerykę Północną. Problem wydajności nie został zlokalizowany w konkretnej transakcji lub konkretnej lokalizacji geograficznej, ma charakter systemowy. Jest to swego rodzaju sposób na stwierdzenie, że zmiana lub sposób, w jaki interfejs użytkownika płynów miał wpływ globalny. Widać tutaj z punktu widzenia skalowalności, ludzie próbują wykonać ten sam rodzaj aktywności, ale czas odpowiedzi w zasadzie po prostu się pogorszył i pogorszył. Widać, że rzeczy się nie skalują. Wszystko idzie bardzo, bardzo źle. Tutaj, kiedy patrzę na liczbę osi i równoczesne połączenia, widzicie coś, co jest bardzo interesujące pod względem liczby dostępu i połączeń. Tutaj skalujemy tylko do około 5000, a patrzysz na około, to kończy się na 100 równoczesnych połączeniach. Odbywa się to po; to jest wcześniej. Tak więc moje prawdziwe zapotrzebowanie na system, jeśli można by skalować, mieści się w zakresie 300 000. W dawnych czasach, z klasycznym interfejsem użytkownika, patrzysz na 30 jednoczesnych połączeń.
Mówi to teraz, że interfejs Fluid korzysta z co najmniej 10-krotnej liczby równoczesnych połączeń. Zaczynamy odsuwać to, co dzieje się pod przykryciem PeopleSoft, abyś mógł zobaczyć wpływ na serwery sieciowe, fakt, że umowy SLA zaczynają naruszać. Nie zamierzam wchodzić we wszystko, ale w końcu dzieje się tak, że w zasadzie polegają na wiadomościach. Zasadniczo ćwiczą to WebLogic i powodują kolejkowanie w Tuxedo. W rzeczywistości pojawił się problem zależności między wieloma warstwami, który pojawił się w interfejsie Fluid, ale Precise był w stanie wykazać, że przez całą masę różnych rzeczy, że możemy skupić się na tym, na czym polega problem. Okazuje się, że w samej bazie danych był także problem. W rzeczywistości istnieje plik dziennika przesyłania komunikatów, a ze względu na wszystkich współbieżnych użytkowników plik dziennika był blokowany. Zasadniczo miał coś do dostrojenia w każdej warstwie stosu aplikacji. Mówiąc o złożoności, tutaj w rzeczywistości jest warstwa Tuxedo pokazująca kolejkowanie. Widać również spadek wydajności w tej warstwie. Widziałem procesy; Widziałem domeny i serwery. W Tuxedo, aby ludzie z niego korzystali, zwykle otwierają się dodatkowe kolejki, domeny i serwery, tak jak w supermarkecie, aby zmniejszyć zatory i zminimalizować czas oczekiwania w kolejce. Ostatnia i ostatnia opcja, Precyzyjne pokazuje wiele informacji.
Jak wspomniałem wcześniej, każda znacząca transakcja wchodzi w interakcje z systemem ewidencji. Widoczność w bazie danych jest najważniejsza. Precise pokazuje, co dzieje się w bazie danych, w WebLogic, w Javie, .NET, w przeglądarce, ale miejsce, które Precise naprawdę wyróżnia, znajduje się w warstwie bazy danych. To właśnie jest słabość naszych konkurentów. Pozwól, że pokażę ci jeden ze sposobów, w jaki Precise może pomóc ci przez to przejść. Nie zamierzam spędzać czasu na trójkącie optymalizacji bazy danych, ale zasadniczo patrzymy na tanie, mało ryzykowne, na szeroko zakrojone, wysokie ryzyko, kosztowne zmiany typu. Później opublikuję tweeta, jeśli ludzie będą chcieli go obejrzeć. Myślę, że jest to dość duży przewodnik do rozwiązywania problemów. Oto widok eksperta Precise for Oracle. Najważniejsze w raporcie z ustaleń, to 60-procentowy wpływ to właśnie ta instrukcja SQL. Jeśli otworzysz ten ekran aktywności, zobaczysz go tam. Mogę spojrzeć na tę instrukcję select, jest jeden plan wykonania. Każde wykonanie zajmuje sekundę - 48 000 wykonań. To daje kolejne 48 000 godzin egzekucji.
Ciemnoniebieski, po raz kolejny, to procesor. Ta sprawa jest związana z procesorem, a nie stanem oczekiwania, a nie dziennikiem. Podkreślam, że ponieważ niektórzy z naszych konkurentów patrzą tylko na stany oczekiwania i rejestrowanie zdarzeń, ale ogólnie mówiąc, procesor jest najbardziej zajętym stanem wykonania i oferuje największy wykup. Przechodząc do tego eksperckiego widoku - i idę bardzo szybko - zrobiłem to, że spojrzałem na stół, 100 000 wierszy, 37 000 bloków. Robimy pełny stół, ale mamy sześć indeksów na ten temat. Co tu się dzieje? Cóż, kiedy patrzę na klauzulę where, to, co robi ta klauzula, to tak naprawdę konwertuje kolumnę na wielkie litery i mówi, gdzie jest ona równa dużej, znajdź zmienną. Za każdym razem, gdy to się dzieje, Oracle musi przekonwertować tę kolumnę na wielkie litery. Zamiast robić to prawie pięćdziesiąt tysięcy razy, o wiele bardziej wydajne jest budowanie tego indeksu wielkimi literami indeksu opartego na funkcjach i jest on dostępny nie tylko w pionie Oracle Enterprise, także w standardowym. Gdy to zrobisz, możesz wtedy zweryfikować plan wykonania, wydając nową wielkimi literami użytkownika indeksu, co było po prostu moją rzeczą.
Następnie, z pomiaru przed i po, patrzysz na sekundę wykonania, sumuje się do 9 godzin 54 minut, z tą samą dokładną instrukcją SQL, ale mając ten indeks wbudowany wielkimi literami dla 58 000 wykonań, odpowiedź czas spada do poniżej milisekund, zsumuje się, dochodzi do siedmiu sekund. Zasadniczo zaoszczędziłem dziesięć godzin procesora na moim serwerze. To jest ogromne. Ponieważ jeśli nie oczekuję odświeżenia serwera, mogę żyć na tym serwerze. Faktycznie zmniejszam użycie serwera o 20 procent i można zobaczyć przed i po. Taki rodzaj widoczności może zapewnić Precise. Jest też kilka dodatkowych rzeczy, na które moglibyśmy spojrzeć. Dlaczego masz te wszystkie indeksy, jeśli nie są używane? Mogą to kontynuować. Jest architektura, a ja ją podsumuję, ponieważ zbliżamy się do szczytu godziny. Jestem prawdziwym wyznawcą tego rozwiązania i chcemy, żebyś był prawdziwym wierzącym. W IDERA uważamy, że wersja próbna jest klientem, więc jeśli jesteś zainteresowany, jesteśmy w stanie dokonać oceny w Twojej witrynie.
Dzięki temu przekażę latarnię z powrotem.
Eric Kavanagh: Tak, to był niesamowity szczegół, który tam pokazałeś. To naprawdę bardzo fascynujące. Wydaje mi się, że w przeszłości wspominałem wam, że - i wiem, że w niektórych innych transmisjach internetowych, które zrobiliśmy z IDERA, wspomniałem o tym - faktycznie śledziłem Precise od czasu, gdy zostało przejęte przez IDERA, myślę, że aż do 2008 roku lub 2009. Byłem wtedy zafascynowany. Jestem ciekawy, ile pracy wymaga pozostawanie na bieżąco z nowymi wersjami aplikacji. Wspomniałeś o SAP HANA, co moim zdaniem było imponujące, że możesz w rzeczywistości zagłębić się w architekturę HANA i tam rozwiązać niektóre problemy. Ile masz osób? Ile to wysiłku z twojej strony i ile z tego można zrobić nieco dynamicznie, co oznacza, że kiedy narzędzie zostanie wdrożone, zaczniesz się czołgać i widzieć różne rzeczy? Ile z tego może być dynamicznie, niejako, ustalone przez narzędzie, aby pomóc ludziom w rozwiązywaniu skomplikowanych środowisk?
Bill Ellis: Zadałeś tam wiele pytań.
Eric Kavanagh: Wiem, przepraszam.
Bill Ellis: Podałem wiele szczegółów, ponieważ w przypadku tych aplikacji, patrząc na kod, diabeł tkwi w szczegółach. Musisz mieć taki poziom szczegółowości, aby naprawdę mieć coś, co da się zrealizować. Bez mierzalnych wskaźników wiesz tylko o objawach. W rzeczywistości nie rozwiązujesz problemów. IDERA polega na rozwiązywaniu problemów. Śledzenie nowych wydań i innych rzeczy jest dużym wyzwaniem. Pytanie, co trzeba zrobić, tak naprawdę dotyczy zarządzania produktem. Nie mam dużej widoczności w zespole, co w zasadzie pozwala nam być na bieżąco. Jeśli chodzi o HANA, to właściwie nowy dodatek do linii produktów IDERA; to jest bardzo ekscytujące. Jedną z rzeczy związanych z HANA jest - pozwól mi porozmawiać o tym zadaniu przez sekundę. W ramach zadania sklepy SAP wykonałyby replikację bazy danych na potrzeby raportowania. W takim razie ludzie musieliby pogodzić się z tym, co jest aktualnie aktualne. Miałbyś te różne bazy danych i nie byłyby zsynchronizowane na różnych poziomach. Jest tylko dużo czasu i wysiłku, a także sprzęt, oprogramowanie i ludzie, aby utrzymać to wszystko.
Idea HANA ma wysoce równoległą bazę danych w pamięci, aby w zasadzie uniknąć konieczności duplikowania baz danych. Mamy jedną bazę danych, jedno źródło prawdy, jest ona zawsze aktualna, w ten sposób unikasz konieczności wykonywania całego tego pojednania. Znaczenie wydajności bazy danych HANA rośnie - powiem 10-krotnie lub przynajmniej bardziej wartościowe niż suma wszystkich innych baz danych, sprzętu, zasobów, które można kupić. Będąc w stanie zarządzać HANA, teraz, gdy ten komponent jest obecnie w fazie testów beta, wkrótce pojawi się GA. To bardzo ekscytujące dla IDERA i dla nas w zasadzie obsługi platformy SAP. Nie jestem pewien, jakie inne części twojego pytania trochę zmieniłem, ale -
Eric Kavanagh: Nie, to nie wszystko. Rzuciłem w ciebie całą masą naraz, przepraszam za to. Jestem po prostu zafascynowany, naprawdę, mam na myśli, że nie jest to bardzo prosta aplikacja, prawda? Zagłębiasz się głęboko w te narzędzia i rozumiesz, w jaki sposób oddziałują one na siebie, i do rzeczy, musisz poskładać historię w głowie. Musisz połączyć fragmenty informacji, aby zrozumieć, co się dzieje i co sprawia ci problemy, abyś mógł tam wejść i rozwiązać te problemy.
Jeden uczestnik pyta, jak trudno jest wdrożyć Precyzyjne? Inna osoba zapytała, kim są ludzie - oczywiście DBA - ale jakie są inne role w organizacji, które mogłyby korzystać z tych narzędzi?
Bill Ellis: Precyzja jest nieco bardziej skomplikowana do wdrożenia. Musisz mieć trochę wiedzy na temat środowiska aplikacji, jeśli chodzi o to, że ta aplikacja działa na tej bazie danych, potrzebuje lub - serwerów WWW średniej warstwy itp. Myślę, że biorąc pod uwagę złożoność niektórych z tych aplikacji, jest to stosunkowo łatwe. Jeśli mogę instrumentować serwer sieciowy do twojej bazy danych, mogę to zrobić od początku do końca. Zauważasz, że nie mówiłem nic o instrumentowaniu klienta końcowego, a to dlatego, że to, co robimy, to tak naprawdę dynamicznie, więc nie musisz zmieniać kodu ani niczego innego. JavaScript wchodzi do ramki strony aplikacji. Bez względu na to, gdzie użytkownik jest na świecie, kiedy uzyskuje dostęp do adresu URL z aplikacji i sprowadza tę stronę, jest on wyposażony w funkcję Precise. To pozwala nam wybrać identyfikator użytkownika, jego adres IP, a także czas renderowania pierwszego bajtu czasu wykonania skryptu każdego ze składników strony w przeglądarce użytkownika końcowego.
Jeśli chodzi o transakcje, nie musisz mapować transakcji, ponieważ są one ściśle powiązane. Ten adres URL staje się punktem wejścia do JVM, a następnie wywołał tę wiadomość, w wyniku czego JVC został przechwycony z bazy danych. Zasadniczo jesteśmy w stanie złapać te naturalne punkty połączenia, a następnie przedstawić je na ekranie transakcji, który pokazałem wam, gdzie obliczyliśmy również, ile czasu lub procent czasu spędziliśmy na każdym kroku. Wszystko to odbywa się automatycznie. Mówiąc ogólnie, przeznaczamy na to 90 minut - w zasadzie instalujemy rdzeń Precise, a następnie rozpoczynamy wdrażanie aplikacji. W zależności od znajomości aplikacji, może upłynąć kilka dodatkowych sesji, zanim cała aplikacja zostanie oprzyrządowana. Wiele osób korzysta tylko z bazy danych Precise. W porządku. Możesz to po prostu zepsuć, podzielić na komponenty, które Twoim zdaniem potrzebują Twojej witryny. Zdecydowanie uważamy, że kontekst oprzyrządowania całego stosu aplikacji, aby można było zobaczyć, że zależność między warstwami faktycznie zwiększa wartość monitorowania pojedynczej warstwy. Jeśli ktoś chce dalej badać oprzyrządowanie swojego stosu aplikacji, odwiedź naszą stronę internetową - to chyba najłatwiejszy sposób na zażądanie dodatkowych informacji, a my omówimy to nieco dalej.
Eric Kavanagh: Pozwolę sobie zadać jedno lub dwa szybkie pytania. Zgaduję, że gromadzisz i budujesz repozytorium w czasie, zarówno dla klientów indywidualnych, jak i ogólnie jako całości korporacyjnej, interakcji między różnymi aplikacjami i różnymi bazami danych. Innymi słowy, chyba nawiązuję do modelowania scenariuszy. Czy tak jest w przypadku? Czy faktycznie prowadzisz rodzaj repozytorium typowych scenariuszy, abyś mógł przedstawiać sugestie użytkownikom końcowym, gdy pojawią się pewne rzeczy? Podobnie jak ta wersja E-Business Suite, ta wersja tej bazy danych itp. - czy dużo z tego robisz?
Bill Ellis: Cóż, tego rodzaju informacje są wbudowane w raport z ustaleń. Raport ustaleń mówi, jakie są wąskie gardła wydajności, i jest oparty na czasie wykonania. Część tego raportu ustaleń zawiera więcej informacji i dalsze czynności. Informacje lub doświadczenia klientów itd. Są zasadniczo włączone do tej biblioteki rekomendacji.
Eric Kavanagh: Dobra, to brzmi dobrze. No cóż, fantastyczna prezentacja dzisiaj. Bill, podobało mi się, ile szczegółów tam miałeś. Pomyślałem, że to naprawdę fantastyczna, ziarnista, szczegółowa informacja, pokazująca, jak to wszystko się robi. W pewnym momencie jest prawie jak czarna magia, ale tak naprawdę nie jest. To bardzo specyficzna technologia, którą wspólnie stworzyliście, aby zrozumieć bardzo, bardzo złożone środowiska i uszczęśliwiać ludzi, ponieważ nikt nie lubi, gdy aplikacje działają wolno.
Cóż, zarchiwizujemy ten webcast. Możesz wskoczyć online do Techopedia lub insideanalysis.com i wow, dzięki za poświęcony czas, dogonimy cię następnym razem. Trzymaj się, pa pa.
