Techopedia Staff tarafından, 2 Kasım 2016
Paket Servisi: Sunucu Eric Kavanagh uygulama performansını ve Dr. Robin Bloor, Dez Blanchfield ve IDERA'dan Bill Ellis ile verimliliği nasıl artıracağını tartışıyor.
Şu anda giriş yapmadınız. Lütfen videoyu görmek için giriş yapın veya üye olun.
Eric Kavanagh: Bayanlar ve baylar, merhaba ve Hot Technologies'e tekrar hoş geldiniz. Evet kesinlikle! Benim adım Eric Kavanagh, Briefing Room serimize iltifat ettiğimiz bu gerçekten eğlenceli, heyecan verici dizide bugün başka bir web yayınına ev sahipliği yapacağım. Başlık “Uygulama Hızlandırma: Son Kullanıcılar için Daha Hızlı Performans”. Haydi millet, kim istemez ki? Eğer uygulamanızın daha hızlı çalışmasına yardımcı olan biriysem, işten sonra barda bira satın almış olduğumu düşünüyorum. İçeri girmek ve hızlandırmak için oldukça havalı bir şey olmalı.
Seninki hakkında bir slayt var, beni Twitter'da @Eric_Kavanagh vur. Ben hep takip etmeye çalışırım ve benden bahsedersen hep tweet atarım, bu yüzden benden bahsetmekten çekinmeyin
Bu şovun amacı, kurumsal teknolojinin farklı yönlerine odaklanmak ve eğer istersen belirli disiplinleri veya belirli yüzleri tanımlamaya gerçekten yardımcı olmaktır. Çoğu zaman satıcılar belirli pazarlama terimlerini öğrenecek ve bunu ya da bunu ya da başka bir şeyi nasıl yaptıkları hakkında konuşacaklardır. Bu şov, kitlemizin alanında lider olabilmek için bir yazılım aracının neye ihtiyacı olduğunu anlamalarına yardımcı olmak için gerçekten tasarlandı. Bunun biçimi iki analisttir. Her biri önce, satıcının ilk gittiği Brifing Odası'nın aksine gidiyor. Her biri, belirli bir teknoloji hakkında bilmeniz için önemli olduğunu düşündükleri şeyleri ele alır.
Bugün uygulama hızlandırmasından bahsediyoruz. Dez Blanchfield ve ayrıca Doktor Robin Bloor'u duyacağız - bugün tüm dünyadayız - ve sonra Bill Ellis büyük Virginia bölgesinden içeri giriyor. Bununla ilk sunumcumuz Dr. Bloor'a vereceğim. Bu arada #podcast hashtagini tweetledik, bu yüzden tweet atmaktan çekinmeyin. Götürün.
Dr. Robin Bloor: Tamam, bu tanıtım için teşekkürler. Uygulama performansı ve hizmet seviyeleri - bu bir tür alan, yıllar boyunca bu alanda çok fazla iş yaptım, aslında performansı izlemek ve bir arada çalışmak için çok fazla iş yaptım. ya da başka bir şekilde, nasıl bu seviyeleri denemek ve hesaplamak için. Şunu söylemeliyiz ki - bir süre önce, insanların silolarda sistem kurduğu bu döneme sahiptik. Temel olarak, bir sistemin bir silodaysa makul bir şekilde iyi performans göstermesi için yapmaları gereken iş miktarı aslında çok zor değildi çünkü dikkate almanız gereken çok az, çok az miktarda değişken var. Doğru bir şekilde ağa bağlanır bağlanmaz, etkileşimli ve servis odaklılık denkleme girdi. Biraz zor oldu. Performans tek boyutlu olabilir. Belirli bir kod yolunu tekrar tekrar yürüten bir uygulamayı düşünüyorsanız, bunu makul bir şekilde, zamanında yapmak, tek boyutlu bir şey gibi hissettirir. Hizmet düzeyleri hakkında konuşmaya başlar başlamaz, aslında bilgisayar kaynağı için rekabet eden birçok şeyden bahsediyorsunuz. Çok hızlı bir şekilde çok boyutlu hale gelir. İş süreçleri hakkında konuşmaya başlarsanız, iş süreçleri birden fazla uygulamadan birbirine geçirilebilir. Hizmet odaklı mimari hakkında konuşuyorsanız, belirli bir uygulama aslında birden fazla uygulamanın özelliklerine erişiyor olabilir. Sonra çok karmaşık bir şey haline gelir.
Baktım - uzun zaman önce bu diyagramı çizdim. Bu diyagram en az 20 yaşında. Temel olarak, her şeyin şeması diyorum çünkü BT ortamında var olan her şeye bakmanın bir yolu. Gerçekten sadece dört parça: kullanıcılar, veriler, yazılım ve donanım. Elbette zamanla değişirler, ama aslında buna baktığınızda bu parçaların her birinin hiyerarşik bir patlaması olduğunu fark edersiniz. Bir donanım evet, bir donanım bir sunucu olabilir, ancak bir sunucu muhtemelen birden fazla CPU, ağ teknolojisi ve bellek içerir ve bu, olduğu gibi çok fazla sayıda denetleyiciden oluşur. Aslında buna bakarsanız, hepsi parçalara ayrılır. Aslında tüm bunları düzenlemeye çalışmayı düşünüyorsanız, değişen veriler açısından yazılımın performansı değişir, çünkü donanım değişir, vb., Aslında inanılmaz derecede zor bir çok değişkenli duruma bakıyorsunuz. Bu karmaşıklık eğrisidir. Tabii ki hemen hemen her şey için karmaşıklık eğrisi, ama bilgisayarlar hakkında konuşurken defalarca çizildiğini gördüm. Temel olarak, bir eksene düğümler ve diğer eksendeki önemli bağlantıları koyarsanız, bir karmaşıklık eğrisi ile sonuçlanırsınız. Nodların ve bağlantıların ne olduğu neredeyse önemli değil ve telefon şebekesindeki hacim artışının bir gösterimini istiyorsanız bunu yapacak.
Aslında, bilgisayar ortamındaki düğümler hakkında konuşurken, birbirinize önem veren bireysel şeyler hakkında konuşuyorsunuz. Karmaşıklık, ortaya çıkıyor, çeşitli yapı meselesi ve uymaya çalıştığınız çeşitli kısıtlamalar. Ayrıca, sayılar. Sayılar arttığında deliriyorlar. Dün ilginç bir sohbetim oldu, birisiyle konuşuyordum - kim olduğunu söyleyemem, ama gerçekten önemli değil - 40.000 olan bir siteden bahsediyorlardı - bu dört sıfır, 40.000 - veri tabanı örnekleri sitede. Bunu bir düşünün - 40.000 farklı veritabanı. Tabii ki sahip olduğumuz tek şey - açıkçası çok, binlerce uygulaması vardı. Çok büyük bir organizasyondan bahsediyoruz, ama adlandıramam. Aslında buna bakıyorsunuz ve aslında, şu ya da bu şekilde, bazı çoklu kullanıcılar için yeterli olacak servis seviyelerini elde etmeye çalışıyorsunuz. Bu karmaşık bir durum ve gerçekten söylediğim tek şey, bu şeyler karmaşık. Sayılar her zaman artar. Kısıtlamalar iş süreçleri ve iş hedefleri tarafından belirlenir. Beklentilerin değiştiğini fark etmiş olacaksınız.
Gmail ve Yahoo postası ve Hotmail'in tüm bu posta sistemleri ortaya çıktığında hatırlıyorum, insanlar kuruluş içindeki dahili posta sistemlerinden dışarıdaki geniş sunucu çiftlikleri ile bu devasa operasyonların hizmet seviyelerini hak edecekleri beklentisine sahip olmaya başladılar. ve bu tür şeylerin gerçekleşmesi için baskı altına alınmaya başlandı. Aslında, hizmet düzeyi anlaşmaları bir şeydir, ancak beklenti başka bir şeydir ve bir organizasyon içinde garip bir şeyle birbirleriyle savaşırlar. İşte sadece bir iş perspektifi. Bazı sistemlerde, optimal tepki süresi, insan tepki süresinin bir saniyesinin onda biridir. Saniyenin onda biri, sizi ısırmak için bir kobra sürmesidir. Bir kobranın önünde duruyorsanız ve sizi ısırmaya karar verirse, çok geç, çünkü bir saniyenin onda birinde cevap veremezsiniz. Saniyenin onda biri, topun sürahinin elini sopayla adama ulaşması için geçen süredir. Temel olarak, atılan topu gördüğünde, tam olarak o noktada cevap vermelidir. İnsan tepkisi, biraz ilginç bir şey. Yazılımdan yazılıma, açıkçası daha yüksek bir beklentiye sahip olabilir.
O zaman ilk olarak iş değerinin olduğu pazar durumları olduğunu düşündüğüm bazı durumlara girersiniz. Mesela borsada belirli bir hisse senedi satmak istiyorsanız muhtemelen daha azdır, çünkü aşağı ineceğini ve birçok insanın aşağı gittiğini düşünürseniz, önce pazara girerseniz en iyi fiyatı alırsınız. Birçok durum, reklam sunumu ve bunun gibi şeyler var, çok benzer bir durum. Bu hareketi hizmet düzeyi beklentisi açısından elde edersiniz. İnsanların tepkisi için bir çeşit cam tavan var. Bir kez yazılımdan yazılıma, bu tavan durumunuz varsa, en iyi servis seviyesi yoktur. Herkesten daha hızlı en iyisidir.
Tamam, sanırım, yaptığım son slayt, ama bu aslında bir organizasyonun gereksinimlerine, hizmete baktığınızda size karmaşıklığın büyük bir resmini vermek. Buradaki sol tarafa çıktığınızda, bir hizmet seviyesini yönetmeye çalışan hizmet yönetimine hizmet eden bir dizi yazılım olan sistem yönetiminiz var. Bunun üstünde iş performans yönetiminiz var. O zaman buradaki en aşağıya bakarsanız, hizmet yönetimi otomasyon alanı, standartlaştırılmış hizmetlere dönüşen parçalanmış hizmetleriniz var, eğer aslında bu tür bir şeye yatırım yapmak istiyorsanız, bu da optimize edilmiş hizmetlere dönüşen entegre hizmetlere dönüşüyor . Çoğunlukla insanların yaptığı, bunun sadece sol alt köşesinde. Belki biraz hizmet yönetimi. İş performansı yönetimi, çok nadir. Parçalanmış, neredeyse hepsi. Mükemmel bir dünya bu ızgarayı dolduracaktır. Enstrümantasyon - Bir alt optimizasyon probleminden bahsettim. Bir sistemin parçalarını optimize edebilirsiniz ve tüm sistem için iyi değildir. Kalbi en uygun hale getirirseniz, kanınız diğer organlarınız için çok hızlı dolaşabilir. Bu büyük organizasyonlar ve hizmet seviyeleriyle ilgili bir konudur. Açıkçası, sofistike araçlar olmadan hiçbir şey elde edilemeyecektir, çünkü değişkenler yeni kazanmıştır - iyi denemek ve optimize etmek için çok fazla değişken var.
Bunu söyledikten sonra, tamamen, umarım başka bir şey hakkında konuşacak olan Dez'e geçeceğim.
Dez Blanchfield: Teşekkürler, Robin. Dr. Robin Bloor gibi ben de çok karmaşık sistemlerin performansını büyük ölçekte düşünmek için çok uzun yıllar harcadım. Muhtemelen Robin ile aynı ölçekte değil, ancak performans günlük bir konudur ve performans isteyen, her şeyden en iyi şekilde yararlanmak için DNA'mızın bir parçasıdır. Aslında, dünyadaki en sevdiğim şeylerden birinin, tüm gezegenin bir süre durduğu ve arabaların çok hızlı bir şekilde çevrelerde döndüğünü izlediği Formula I araba yarışının bir grafiğini kullandım. Her yönüyle, Formül I'in özellikle performans elde etmekle ilgili bir yönü yoktur. Birçok insan sporu poo-poo çünkü para kaybı olduğunu düşünüyorlar. Çocukları hafta sonları futbolda bırakmak için her gün sürdüğümüz araba, diğer günler ise okul performansa dayalı geliştirme ve araştırmadan kaynaklanıyor. Formula I araba yarışlarının hayatı gibi. Gündelik teknoloji, günlük bilim, genellikle yalnızca yüksek performansa odaklanmış bir şeyin beğenilerinden gelir.
Gerçek şu ki, Robin'in daha önce bahsettiği gibi, yüzde 100 kesintisiz çalışma gerektiren yeni "her zaman açık" dünyamız, web postasının ve sürekli alanda aldığımız diğer hizmetlerin sunulması gibi şeylerle ve şimdi kurumsal ve çalışma ortamımız. Gerçek şu ki, kalkmak her zaman hizmet seviyesi sözleşmenizi karşıladığınız anlamına gelmez. Son on yılda uygulama performansı ve kullanılabilirlik hizmet düzeyi sözleşmelerinin yönetilmesi ihtiyacını benimsiyorum. Artık sadece bir sistemin performansı hakkında endişelenmeye çalışmıyoruz. Dünya biraz daha basit olduğunda, birden çok hizmeti çalıştıran tek bir sunucunun canlı olarak izlenebildiği ve desteklenmesi nispeten basit bir durum olabilir. Yapabiliriz - ve işte benim küçüküm, örneğin bir sistem yöneticisi olduğum zaman, endişelendiğimiz şeyler, yıllar önce - etrafa bakardık, hizmet genellikle hazır ve yanıt veriyor mu? Örneğin bir terminale giriş yapabilir miyim? İşletim sistemi yanıt veriyor mu ve komut yazabilir miyim? Uygulamalar çalışıyor mu? Ağ genelinde bir şeyler ve G / Ç işlemleri yaparken süreçleri ve hafızayı görebilir miyim? Ana çerçeve günlerinde, zip-zip-zip ve kağıtların düştüğünü duyabilirsiniz.
Uygulamalar yanıt veriyor mu ve giriş yapıp bunlarda bir şeyler yapabilir miyiz? Kullanıcılar bu sunucuların bazılarına bağlanabiliyor mu? Devam ediyor. Bunlar oldukça basit, biliyorsunuz. Sonra birkaç komik olanlar - yardım masası yeşil mi? Çünkü eğer değilse, o zaman her şey yolunda gidiyor ve donutları kim alacak? O günlerde hayat gerçekten çok basitti. O günlerde bile ve sonra 20-30 yıl önce konuşuyorum, karmaşıklık hala çok yüksekti. Nispeten açık bir şekilde, hizmet düzeyi sözleşmelerini yönetebilir ve performansı izleyebiliriz. Robin'in söylediği gibi artık el ile yapamayız. Zorluk çok büyük. Gerçek şu ki, birkaç iyi uygulama, yönetici, sistem ağı ve veritabanı, yöneticiler performans SLA'larını izleyebilir ve karşılayabilir. SLA şimdiye kadar gitti, dün gece son notlarımı bir araya getirirken çok karmaşık bir yığın sistemine bakmayı ve onu anlamayı ve hatta ne olduğunu kavramayı başardığım yılı düşünmek için mücadele ettim. kaputun altından geçiyorum ve ben derin bir teknik altyapıdan geliyorum. Şimdi idari bir tarzda günlük olarak bununla yüzleşmenin nasıl bir şey olduğunu hayal edemiyorum.
Ne oldu? 1996'da, veritabanına dayalı uygulamalar internet patlamasıyla dönüştürüldü. Birçoğumuz bunu yaşadık. İnternet patlamasının etrafında olmasanız bile, etrafınıza kolayca bakabilir ve günlük hayatta her şeyi internete bağladığımızı fark edebilirsiniz. Görünüşe göre çok saçma olan Wi-Fi'ye binme seçeneğiyle gelen bir ekmek kızartma makinemiz olduğuna inanıyorum, çünkü internete bağlı ekmek kızartma makineme ihtiyacım yok. 2000'lerde, özellikle 2000'lerin başında, karmaşıklık turundaki bu devasa büyümeyle uğraşmak zorunda kaldık ve nokta-com patlamasında hizmet performansı sağladık. Daha sonra akıllı telefonların geldiği ve şimdi uygulamaların 7/24 elimizde olduğu ve her zaman açık modda olduğu web 2.0'da başka bir saçma garip kıvılcım.
Şimdi 2016, bulut ve büyük veri ve hareketlilik şeklinde başka bir bataklıkla karşı karşıyayız. Bunlar o kadar büyük sistemlerdir ki, anlaşılması ve sade İngilizceye yerleştirilmesi genellikle zordur. Bahsettiğimiz bazı büyük tek boynuzlu atların yüzlerce petabayt veriye sahip olduğunu düşündüğümüzde. Bu, e-postanızı, resimlerinizi ve sosyal medyanızı tutmak için tüm disk alanı ve depolama alanıdır. Veya bazı durumlarda, nakliye ve nakliye lojistiğinde, hepsi bankacılıktır, paranızın olduğu yer veya postanızın olduğu yer veya eBay'den satın aldığınız şeyin olduğu yerdir. Karşılaşacağımız bir sonraki büyük dalga, şeylerin interneti ile ilgili bu çok zorlu mücadeledir.
Bu yeterince kötü değilse, yapay zeka ve bilişsel hesaplamayı hemen her şeye dönüştürmek üzereyiz. Bugünlerde Siri ve Google motorlarıyla konuşuyoruz. Amazon'un kendine ait olduğunu biliyorum. Baidu, konuşabileceğiniz bu cihazlardan birine sahip, normal bir sisteme giden metne dönüştürüyor, veritabanı bir sorgu yapıyor ve geri geliyor ve işlemi tersine çeviriyor. Bunun içine giren karmaşıklığı düşünün. Gerçek şu ki, günümüzün standart uygulama yığınının karmaşıklığı insan kabiliyetlerinin çok ötesindedir. Akıllı telefon cihazınızda veya tabletinizde bir düğmeye bastığınızda gerçekleşen her şeyi düşündüğünüzde, onunla konuşursunuz, bunu metne dönüştürür, İnternet'e kadar bir arka uç sistemine çalışır, bir ön uç alır Bu, onu bir sorguya dönüştürür, sorguyu bir uygulama yığını üzerinden çalıştırır, bir veritabanından geçer, diske çarpar, geri döner ve ortada bir taşıyıcı ağ vardır, bir yerel alan ağı durum merkezi vardır. Karmaşıklık delidir.
Bunu etkili bir şekilde hiper ölçek olarak savunuyoruz. Hiper ölçeğin karmaşıklığı ve hızı sadece göz sulamadır. Uygulamalar ve veritabanları o kadar büyük ve karmaşık hale geldi ki, performansı yönetmek aslında kendi başına bir bilimdir. Birçoğu bunu roket bilimi olarak adlandırıyor. Yerinde teknolojimiz var, tesis dışı teknolojimiz var, bir dizi veri merkezi seçeneğimiz var; fiziksel ve sanal. Fiziksel ve sanal sunucularımız var, bulutumuz var, hizmet olarak altyapımız ve hizmet olarak platformumuz var ve hizmet olarak yazılım artık kabul ettiğimiz bir şey. İkincisi, bir hizmet olarak yazılım, birkaç yıl önce CFO'lar ve örgütün bazı bölümleri kredi kartlarını alıp sadece kendileri satın alıp CIO'ya gidebileceklerini fark ettiklerinde korkutucu hale geldi ve etkili bir şekilde buna “gölge” adını verdik. IT ”ve CIO'lar artık bunu geri sarmaya ve kontrolü yeniden ele geçirmeye çalışıyor.
Altyapıda yazılım tanımlı ağ, ağ işlevi sanallaştırması var, aşağıda muhtemelen bitti, şimdi mikro hizmetler ve aktif hizmetlerin uygulamaları var. Bir URL'yi tıkladığınızda, o URL'nin sonunda, onu gerçekten iletmek için neye ihtiyaç duyduğunu açıklayan bir grup iş mantığı vardır. Önceden önceden oluşturulmuş bir mantığı olması gerekmez. Bir tarafta çok, çok büyük ölçeklenen geleneksel veritabanlarımız var. Diğer spektrumda Hadoop altyapısı ve ekosistemlerin beğenisine sahibiz, o kadar büyük ki, dediğim gibi, insanlar şimdi yüzlerce petabayt veri hakkında konuşuyorlar. Hareket eden cihazlara, dizüstü bilgisayarlara, telefonlara ve tabletlere kadar karmaşıklık hareketliliğimiz var.
Bazı kapalı ortamlarda ve giderek artan bir şekilde BYOD var, çünkü Gen Y deneyimli insanlar kendi cihazlarını getiriyorlar. Onlarla web arayüzleri hakkında konuşmasına izin veriyoruz. Ya internet üzerinden ya da Wi-Fi üzerinden kahve içerken alt katta kafede ücretsiz Wi-Fi var. Veya dahili kablosuz ağımız. Makineden makineye şimdiki zaman var. Bu, şeylerin internetinin doğrudan bir parçası değil, aynı zamanda ilgili. Nesnelerin interneti, akıllara durgunluk veren yeni bir karmaşıklık oyunudur. Yapay zeka ve şu anda oynadığımız şeyin, konuştuğumuz tüm Siri ve diğer ilgili cihazlarla karmaşık olduğunu düşünüyorsanız, 3-B Olli adı verilen bir şey görene kadar bekleyin. yaklaşık altı kişi süren ve şehir etrafında kendi kendini sürdürebilen basılı otobüs ve ona İngilizce konuşabiliyorsunuz ve size geri dönecek. Trafiğe çarparsa, trafiğin olduğu ana alanı sola veya sağa döndürmeye karar verir. Dönerken ve neden ana yoldan sola veya sağa döndüğünden endişe duyduğunuzda size “Endişelenme, sola dönmek üzereyim. Önümüzde trafik var ve ben etrafta dolaşacağım. ”
Oradaki tüm sistemlerin ve tüm karmaşıklığın performansını yönetmek, verilerin nereye gittiğini, veritabanına girip girmediğini, tüm ara bağlantıları ve tüm ilgili bitleri izlemek akıl karıştırıcıdır. Gerçek şu ki, performans ve SLA'ları bugünün hızında ve ölçeğinde yönetmek, araçlar ve sistemler gerektiriyor ve varsayılan olarak bu artık sadece bir araca sahip olmanın güzel olacağını düşündüğünüz bir şey değil - bu bir önkoşul; sadece kesinlikle gerekli. İşte küçük bir örnek olarak, OpenStack, açık kaynaklı yazılım tanımlı bulut için üst düzey uygulama tasarım diyagramlarının bir listesi. Bu sadece büyük bir yığın. Bu sadece sunucular ve veritabanı değil. Her küçük mavi damla, şeylerin kümelerini temsil eder. Bazı durumlarda dosyalar ve sunucular veya yüzlerce veritabanı veya elbette on binlerce küçük uygulama mantığından fazla değildir. Bu küçük bir versiyon. Bu konuda ortaya çıkan karmaşıklığı düşünmeye başladığınızda gerçekten akıl almaz. Bugün, sadece büyük veri alanında bile, sadece markaların bazı ekran görüntülerini koyacağım. Burada yönetmemiz gereken tüm parçaları düşündüğünüzde, sadece bir markadan bahsetmiyoruz, bunların hepsi sadece küçük veri veya açık kaynaklardan değil, büyük veri ortamındaki ve en iyi markadaki markalardır. Bakın ve bunun oldukça akıl almaz bir grafik olduğunu düşünüyorsunuz.
Birkaç dikey konuya bakalım. Mesela pazarlamayı ele alalım. İşte benzer bir grafik ama sadece pazarlama teknolojisinde bulunan teknoloji yığınlarından. Bu 2011 grafiği. İşte 2016 sürümü. Sadece düşünün, bu sadece pazarlama teknolojisi ile ilgili olarak teknoloji için çalıştırabileceğiniz ürün sayısıdır. İçindeki sistemlerin karmaşıklığı değil, farklı uygulama ve web ve geliştirme ve ağ ve diğerleri değil. Sadece marka. Daha önce, beş yıl önce var ve bugün burada. Sadece daha kötüye gidecek. Şu anda gerçekliğin olduğu noktadayız, insanlar tüm servis seviyesi anlaşmalarını sağlayamazlar. Yeterince ayrıntılı, yeterince hızlı ve ihtiyacımız olan ölçekte dalamayız. Aşağıda bir izleme konsolunun nasıl göründüğüne bir örnek verilmiştir. Bu, her küçük parçada büyük, büyük bir projeksiyon ekranı gibi davranarak birbirine yapıştırılmış yaklaşık yirmi tek ekran gibi. Şimdi burada ilginç, markadan bahsetmeyeceğim, ancak bu izleme platformu lojistik ve nakliye ortamında tek bir uygulamayı izliyor. Sadece bir uygulama. Robin'in organizasyonların şu anda üretim ortamlarında 40.000 veritabanına sahip olabileceği hakkında ne düşündüğünü düşünüyorsanız. Sadece bir uygulamayı izleyen bu ekran koleksiyonunun 40.000 versiyonunun nasıl olabileceğini hayal edebiliyor musunuz? İçinde yaşadığımız çok cesur bir dünya. Robin'in dediği gibi, kesinlikle yüzde 100, doğru araçlar olmadan, doğru araçları ve masadaki bu araçları kullanan halk olmadan, uygulama performansının insanlara ve araç ve yazılım ile yapılmalıdır.
Bununla IDERA'daki arkadaşlarımıza geçeceğim.
Eric Kavanagh: Tamam Bill.
Bill Ellis: Teşekkür ederim. Ekranımı burada paylaşıyorum. Sanırım birisi ekranımı görebildiğini doğrulayabilir mi?
Dr. Robin Bloor: Evet.
Eric Kavanagh: İyi görünüyor.
Bill Ellis: Teşekkür ederim. Bahsettiği tek şey, gerçekten bekleyemediğim, kendi kendine giden otomobildi. Kimsenin konuştuğunu duymadığım tek şey, kar yağdığında ne olur? Kaliforniya'daki mühendislerin ülkenin diğer bölgelerinde biraz kar yağdığını fark edip etmediklerini merak ediyorum.
Dez Blanchfield: Bunu beğendim, hatırlayacağım.
Eric Kavanagh: Tipik bir saatte bir mil.
Bill Ellis: Karmaşık bir ortamda uygulama performansı yönetimi hakkında konuşmak için buradayız. Bahsetmek istediğim bir şey, bir çok insan, performans hakkında konuştuklarında, reaksiyonun doğası, hey daha fazla sunucu, daha fazla CPU, daha fazla bellek, vb. Bu madalyonun diğer tarafı verimliliği işlemektir. Gerçekten, bu aynı madalyonun iki yüzü ve ikisine de bakacağız. Nihai hedef, ticari işlemler için hizmet düzeyi anlaşmalarını karşılamaktır. Sonuçta bu teknolojinin tamamı işletme için var. Sektörde bir ilk performans yönetimi veri tabanına sahip olmaktan bahsettik. Bunun ideali, ideal performans kalıbına uymak ve uygulamaların yaşam döngüsünün başından itibaren yönetilmesidir.
Konular gerçekten dört parçaya kadar kaynar; birincisi performansı yönetme sürecidir. Herkesle konuştuk ve herkesin araçları var. Araçları yoksa, komut dosyaları veya komutları vardır, ancak eksik oldukları şey bağlamdır. Bağlam, noktaları uygulama yığınlarına bağlar. - için bu uygulamalar tarayıcı tabanlıdır. Katmandan katmana çok sıkı bir şekilde bağlıdırlar. Katmanların nasıl etkileştiği de çok önemlidir. Ardından, ticari işlemden bahsediyoruz. Görünürlüğü sadece teknik kişilere değil, uygulama sahiplerine ve operasyon yöneticilerine de sağlayacağız.
Müşterilerin bunları nasıl kullandıklarını sizinle paylaşmak için birkaç örnek olayım var. Buradaki sunumun çok pratik bir kısmı. Tipik olarak ne olduğuna bir bakalım. Diyagram çizmeyi seviyorum - tıpkı inanılmaz bir teknoloji kolajı gibiydi. Veri merkezindeki teknoloji sayısı arttı, büyüdü ve büyüdü. Bu arada, bir son kullanıcı bunu umursamıyor ve bundan habersiz. İşlemi gerçekleştirmek, hazır bulundurmak, hızlı bir şekilde tamamlamak istiyorlar. Tipik olarak, BT uzmanları son kullanıcıların kendi kendilerini rapor edene kadar bir sorun yaşadıklarının farkında değillerdir. Bu biraz zaman alıcı, yavaş bir süreç ve genellikle sinir bozucu. Olan şey, insanlar araçlarını açacak ve uygulama yığınlarının bir alt kümesine bakacaklar. Bu alt kümeyle, en basit soruyu cevaplamak çok zorlaşır. Sorunu yaşamanız normal mi? Hangi işlem? Darboğaz uygulama yığınında nerede? Tüm bu zamanı harcayarak, katmanlara göre bakarak, bu soruları cevaplayamayarak, çok fazla zaman ve enerji, çok fazla personel, fon ve enerji türünü bulmakla sonuçlanırsınız.
Bunu çözmek için, daha iyi bir yol sağlamak amacıyla, Precise'ın yaptığı şey aslında son kullanıcı izleme işlemini almak, bu konudaki meta verileri yakalar, işlemi ağ üzerinden, web sunucusuna, iş mantığı katmanına ve sonuçta tüm işlemlerin kayıt sistemiyle etkileşime gireceği çok katmanlı uygulamalarda .NET ve ABAP ile PeopleCode ve E-Business Suite'i destekliyoruz. İster bir envanter araması olsun, ister çalışılan raporlama süresi, her zaman veritabanıyla etkileşim halindedir. Veritabanı iş performansının temeli haline gelir. Veritabanı da depolamaya dayanır. İşlemlerle ilgili meta veriler neye cevap veriyor, kim, hangi işlem, uygulama yığınında nerede ve sonra neyin yürütüldüğünü göstermek için derin kod düzeyinde görünürlüğe sahibiz. Bu bilgiler sürekli olarak yakalanır, performans yönetimi veritabanına konur - bu, herkesin neler olduğunu görmesi için tek bir müzik sayfası haline gelir. Olanları önemseyen farklı kişi ve kuruluşlar var: teknik uzmanlar, uygulama sahipleri, nihayetinde işletmenin kendisi. Bir sorun ortaya çıktığında, söz konusu işlem hakkında bilgi elde etmek istersiniz.
Yatırım işlemine bakmadan önce, bunun kuruluştaki farklı kişilere nasıl göründüğünü göstermek istiyorum. Bir yönetim katmanında, birden çok uygulamaya genel bir bakış atmak isteyebilirsiniz. SLA uyumluluğu ve kullanılabilirliği ile hesaplanan sağlık hakkında bilgi edinmek isteyebilirsiniz. Bu sağlık her şeyin yüzde 100 mükemmel çalıştığı anlamına gelmez. Bu durumda yatırım işleminin uyarı durumunda olduğunu görebilirsiniz. Şimdi, biraz daha derin, belki de iş kolunda, SLA'ları, işlem sayılarını vb. İhlal ettiklerinde bireysel işlemler hakkında bazı ek ayrıntılara sahip olmak istersiniz. Operasyon ekibi bu konuda bazılarının uyarısı ile bilgilendirilmek isteyecektir çeşit. Dahili performans uyarılarımız var. Aslında son kullanıcının tarayıcısındaki performansı ölçüyoruz. Internet Explorer, Chrome, Firefox, vb. Tespit edebiliyoruz, bu ilk soruyu cevaplıyor: bir son kullanıcının sorunu mu var?
Gelin ve bunun hakkında başka neler gösterebileceğimize bakalım. Performansla ilgilenen insanlar Precise'ı açacaklardı. İşlemleri değerlendirirdi. SLA uyumlu olmayan işlemleri belirlemek için SLA sütununa bakarlar. Etkilenen son kullanıcıları ve bu işlemin uygulama boyunca akarken neler yaptığını görebilirler. Bu hiyeroglifleri deşifre etmenin yolu, bu tarayıcı, URL, U URL içindir, JVM'ye giriş noktasıdır. Şimdi bu özel JVM, ikinci bir JVM'ye bir web sunucusu çağırır ve SQL ifadesini çalıştırır. Bu SQL veritabanı yanıt süresinin yüzde 72'sinden sorumlu olduğu için bu açıkça bir veritabanı sorunudur. Zamana odaklandık. Zaman performansın para birimidir. Son kullanıcılar işlerin yavaş çalışıp çalışmadığını bu şekilde deneyimler ve kaynak tüketiminin bir ölçüsüdür. Çok kullanışlı; bu, performansı değerlendirmek için en önemli olan tek bir metriktir. Bu sorun DBA'ya dağıtıldığında, sadece bir veritabanı sorunu değil, bu SQL ifadesidir. Bahsettiğim bağlam bu.
Şimdi bu bilgilerle donanmış, içeri girip neler olduğunu analiz edebiliyorum. Her şeyden önce görebiliyorum, y ekseni gün boyunca zaman. Affedersiniz, y ekseni tepki süresi, x ekseni gün boyunca geçen süredir. Bir veritabanı sorunu olduğunu görebilirim, iki olay var, bu akışa geri dönün, SQL ifadesini alın ve Precise'ın neler olduğunu, kontrollerini, kodun ne kadar sürdüğünü gösteren uzman görünümüne gidin. yürütün. Veritabanı katmanında, yürütme planıdır. Precise'ın, yürütme sırasında kullanılan ve uygulama sırasında değil planın verildiği zaman olan tahmini plandan farklı gerçek yürütme planını seçtiğini göreceksiniz. Veritabanının gerçekten yaptığını yansıtabilir veya yansıtmayabilir.
Şimdi burada, SQL deyimi için bir yanıt süresi analizidir. Depolamada harcanan sürenin yüzde doksanı; CPU'da yüzde on kullanıldı. SQL deyiminin metnini ve bulgular raporunu görebiliyorum. SQL deyiminin metni aslında bazı kodlama sorunlarını ortaya çıkarmaya başlar. Bu yıldız seçer; tüm satırları döndüren - afedersiniz, döndürülen satırlardaki tüm sütunlar. Uygulamanın ihtiyaç duyabileceği veya gerektirmeyeceği ek sütunları geri çeviriyoruz. Bu sütunlar işlenecek alan ve kaynakları tüketir. SAP'yi çalıştırırsanız, HANA veritabanı sütunsal olduğu için büyük değişikliklerden biri, SAP tüketimini büyük ölçüde azaltabilmek için SAP'yi seçili yıldızı seçmeyecek şekilde yeniden yazmasıdır. Bu temelde, Java, .NET, vb.Gibi ev uygulamalarında da çok zaman meydana gelen bir şeydir.
Bu ekran size kim, ne, ne zaman, nerede ve neden olduğunu gösterir. Neden, sorunları çözmenize izin veren SQL deyimi ve yürütme planı gibi. Precise sürekli çalıştığından, SQL deyimi düzeyinde işlem düzeyinde önce ve sonra ölçebilirsiniz, böylece hem kendiniz, hem de uygulama sahipleri ve yönetim için sorunu çözdüğünüzü ölçebilirsiniz. . Bu dokümantasyon gerçekten faydalı. Bu uygulama yığınında çok fazla karmaşıklık var. Aslında birçok uygulamadan bahsettiğimiz herkes VMware altında uygulama yığınının en azından bir kısmını çalıştırıyor. Bu durumda, müşteri hizmetleri uygulamasına bakıyorlar, işlem zamanına bakıyorlar ve yavaşlama ile ilişkilendiren bir sanallaştırma olayı. Hassas tüm sanallaştırma olaylarını izler. Bunu almak için vCenter'a bir eklentimiz var.
Ayrıca çekişmeyi de tespit edebiliyoruz. İçerik kullanımdan farklıdır. Aslında, müşteri sunucusunun uygulaması bağlamında belki de gürültülü bir komşu misafir VM'nizi etkilediğinde gösterilir. Şimdi detaylara girip bilgi alabiliyorum ve aslında bu durumda CPU kaynakları için yarışan iki VM'yi görebiliyorum. Bu, zamanlamaya bakabilmem için görünürlüğe sahip olmamı sağlıyor. Farklı bir fiziksel sunucuya konuk VM koyabilirim. Tüm bu tür şeyleri yanıtlayabilir ve daha sonra buna ek olarak, aslında daha az CPU kullanmasını sağlamak için kod verimliliğine bakabilirim. Sanırım bu sunumda birisinin CPU tüketimini büyüklük derecelerine göre nasıl azaltabildiğine dair oldukça iyi bir örneğim var.
Bu VMware idi. Kodun kendisine, uygulama koduna girelim. Precise size Java, .NET, ABAP kodu, E-Ticaret, PeopleCode, vb. İçerisinde neler olduğunu gösterebilecektir. Bunlar, bu durumda WebLogic'e giriş noktalarıdır. Burada, bakmanız gereken bu EJB'lerin olduğunu söyleyen bir bulgu raporu var ve bana bu sistemde de kilitlenme olduğunu söyleyecek. Bir kez daha, neler olduğunu göstermek için iş mantığı katmanında detaya inin. Bu durumda, belirli örneklere bakıyorum; Kümelemeyi de destekliyorum. Çok sayıda JVM'niz varsa, kümeye bir bütün olarak bakabilir veya bağımsız JVM içindeki darboğazlara bakabilirsiniz.
Kilitlemeye başladığınızda, istisnalara girebilirim. İstisna, bir performans probleminden biraz farklıdır. Genellikle istisnalar çok hızlı gerçekleşir. Çünkü bir mantık hatası var ve o mantık hatasını vurduğunuzda bitiyor. İstisna başlangıcında bir yığın izlemesi yakalayabildik, bu da neler olduğunu anlamaya çalışırken çok zaman kazandırabilir, sadece yığın izine sahip olursunuz. Ayrıca bellek sızıntılarını da yakalayabiliriz. Çözüm ayrıca veritabanı katmanı içerir, ben gidebilir, veritabanı örneği değerlendirebilirsiniz. Bir kez daha, y ekseni zamanın harcandığı yerdir, x ekseni gün boyunca süredir. Bana otomatik olarak sistemde neler olduğunu ve neye bakabileceğimi söyleyen bir bulgu raporu var.
Precise'ın bulguları raporuyla ilgili şeylerden biri, yalnızca günlüklere veya bekleme durumuna bakmakla kalmaz, aynı zamanda CPU'dan tüm yürütme durumlarına ve depolamadan bilgi döndürmeye bakar. Depolama, özellikle katı halin ortaya çıkmasıyla birlikte uygulama yığınının çok önemli bir parçasıdır. Bu hatlar boyunca bilgi sahibi olmak çok yardımcı olabilir. Belirli depolama birimleri için, ayrı ayrı cihaz düzeyinde neler olup bittiğini gösterebiliriz. Bu tür bilgiler - bir kez daha derin görünürlük; kapsamı geniştir - bir uygulama performansı uzmanı olarak daha fazla kaldıraca sahip olmanız için yeterli bilgi sağlamak, böylece uygulamalarınızı bu iş işlemlerini karşılamak için uçtan uca optimize edebilirsiniz.
Sizinle paylaşmak istediğim birkaç örnek olay var. Biz oldukça hızlı birlikte seyir; Umarım iyi bir hızda giderim. Depolama hakkında konuşmak, zamanla herkes donanım değiştirir. Bir donanım garantisi var. Satıcının size söylediklerini gerçekten iletti mi? Bunu Precise ile değerlendirebilirsiniz. İçeri giriyorsunuz ve burada olanlar temelde yeni bir depolama birimine yerleştirdiler, ancak depolama yöneticileri sadece depolama birimi düzeyine baktıklarında, çok fazla çekişme gördüler ve bu yeni depolama birimiyle ilgili bir sorun olabileceğini düşündüler . Daha fazlasını uçtan uca perspektiften bakmak, tam olarak bunun gerçekte nerede olacağını göstermek için. Aslında saniyede yaklaşık 400 megabaytlık bir verimden çıktılar, burada depolama, yanıt süresinin yüzde 38'inden sorumluydu, bu yüzden oldukça yüksek. Yeni depolama birimi ile, aslında verimi saniyede altı, yedi yüz megavat seviyesine çıkardık, temelde iki katına çıkardık ve depolama katmanının işlem süresine katkısını yarıya indirebildik. Aslında bunu daha önce çizebiliyorum, bu bir kesme dönemi ve sonra.
Böylece, bir kez daha, donanım yatırımının buna değdiğini ve söz konusu tedarikçinin beklediği gibi teslim ettiklerini kanıtlayan belgeler. Her şey var, karmaşıklık, şeylerin sayısı nedeniyle, olabilecek her türlü şey var. Bu durumda, aslında herkesin DBA'yı suçladığı bir durum vardı, DBA “Çok hızlı değil” gibiydi. Burada aslında bir SAP uygulamasına bakıyoruz, bence bu tür bir senaryo oldukça yaygın . Olanlar, bir kullanıcı için özel bir işlem geliştiriyorlardı. Kullanıcı, “Bu çok yavaş.” Gibidir. ABAP kodlayıcısı - SAP'nin programlama dili - “Bu bir veritabanı sorunudur” dedi. son kullanıcıyı 60 saniyede ölçtüler, bir dakika içinde çok iyi. Arka uçta elli üç saniye geçti. Arka uca girdiler ve aslında azalan sırada sunulan SQL ifadesini gösterebildiler.
Kaynak tüketiminin yüzde 25'inden sorumlu olan bu üst SQL deyimi, ortalama yürütme süresi iki milisaniyedir. Veritabanını suçlayamazsınız. Biliyorsun, hey, o kadar hızlı değil, adamım. Soru, neden bu kadar çok infaz var? ABAP'a geri döndüler, içeri girdi, döngünün yuvalarına baktılar, veritabanını yanlış yere çağırdıklarını öğrendiler, temelde değişikliği yaptılar, değişikliği test ettiler ve şimdi yeni tepki süresi beş saniye. Biraz yavaş, ama bununla yaşayabilirlerdi. 60 saniyeden daha iyi. Bazen, sadece ferreting, uygulama kodu, veritabanı mı, depolama mı? Bunlar, Hassas'ın, uçtan uca işlemler bağlamına sahip olarak, Hassas'ın devreye girdiği alanlardır. Temelde bu şeyleri bitiriyorsunuz.
O zamana bakıyorum, hala bunlardan birkaç tane daha geçmek için biraz zamanımız var gibi görünüyor. Bunların içinden geçiyorum. Bu uygulama bir yılı aşkın bir süredir geliştirilmektedir. KG'ye girdiklerinde, web sunucularının yüzde 100'ü aştığını ve uygulamanın VMware altında çalışamadığını görüyorlardı. Herkesin söylediği ilk şey şuydu: “Bunu fiziksel yapın; VMware altında çalışamaz. ”Kesinlikle onlara sorunu çözmek için ek yollar sundu. İşlemlere baktık, bir web sunucusu çağrısı gördük, IIS.NET'te ASMX olarak geliyor. Aslında altta yatan kodu ortaya çıkardı. Bunu işaret ettiğim yerde görüyor musun? Bu 23 gün 11 saat. Vay canına, bu nasıl mümkün olabilir? Her çağırma 9.4 saniye sürer ve bu şey 215.000 kez çağrılır. Her çağırma için 6 saniyelik CPU kullanır. Bu yüzden, bu kod bu şeyin asla ölçeklenememesinin nedenidir. Aslında, fiziksel olarak ölçeklenemedi.
Yaptıkları şey, geliştiricilerine geri döndükleri ve “Birileri değişiklik yapabilir mi?” Dediler. Bir tür yarışma düzenlediler ve farklı önerileri test ettiler ve çok çalışabilecek bir öneri buldular daha verimli. Yenisi CPU'da bir saniyenin yüzde ikisi kadar olan bir noktayı iki saniyeden biraz daha kısa bir sürede tamamladı. Şimdi bu ölçeklenebilir ve VMware çiftliğinde çalışabilir. Bunu hem kod düzeyinde hem de işlem düzeyinde belgeleyebildik. Bu önce ve sonra sonra. Artık burada web, .NET ve veritabanını gösteren yığın çubuk grafiğinde görebildiğinize göre, artık veritabanıyla etkileşime giriyorsunuz. Bu, daha normal çalışan bir uygulama için görmeyi beklediğiniz bir profildir.
Pekala, size gösterebileceğim ek şeyler açısından seçiyorum ve seçiyorum. Birçok insan böyle çünkü birçok dükkana göz kamaştırıyor. Bir işletme SLA'sı ile karşılaşamıyorsanız ve herkes "Bize yardım edin" gibi bir şeyse. Bu mağazada işletme SLA'sının saat 15: 00'e kadar alınan siparişlerde olduğu bir durum vardı. Siparişleri çıkarmaları çok önemlidir ve depo çok meşgul. Bu JD Edwards'ın müşteri siparişi ekranı donuyordu ve bunun tam zamanında perakende envanter yönetim sistemi olduğu konusunda çok iyi bir fikir edinebilirsiniz. Boş raflar perakende satışta kabul edilemez. Orada satmak için mal var. Yaptığımız şey şu ki, bu durumda SQL sunucu veritabanına bakıyoruz. Görünüm, his SQL, Oracle, DB2 veya Sybase ile aynıdır.
PS_PROD'dan seçimi belirledik ve süreyi, çok fazla yürüttükleri gerçeği yakalayabiliyoruz. Koyu mavi, bazı bekleme durumlarında, bazı günlük kayıtlarında ve hatta depolamada beklemediklerini söyleyen anahtarla eşleşti - bu şey CPU tarafından bağlı. SQL ifadesini 34301'e kadar izledik, böylece her yürütüldüğünde sayaçlarımızı takip etmek için artırıyoruz. Bu, ayrıntılı bir geçmişimiz olduğu ve bu ayar düğmesine tıklayarak erişebileceğim anlamına gelir. İşte geçmiş sekmesi. Bu ekran, değişikliklere göre ortalama süreyi gösterir. Çarşamba, Perşembe, Cuma, ortalama süre saniyenin onda biri civarındaydı. Çok az ekran donuyor, işletme SLA'sı ile tanışabiliyorlar. 27 Şubat gel, bir şeyler değişti ve aniden, yürütme süresi burada ve bu ekran donmalarına neden olan zaman aşımlarına neden olacak kadar yavaş. SQL kullanımdaysa, yürütme planı ve tablonun dizinlerindeki genel değişiklikler de dahil olmak üzere ayrıntılı bir geçmiş tutarak kesin. Erişim planının 27 Şubat'ta değiştiğini tespit ettik. Pazartesiden cumaya kötü hafta. 5 Mart'ta erişim planı tekrar değişti. Bu iyi bir hafta. Bu pembe yıldız bize güncellenen hacmi anlatıyor.
Burada temel tablolardaki satır sayısının arttığını görebilirsiniz ve bu bir işletme için tipiktir. Masalarınızın büyümesini istiyorsunuz. Mesele şu ki, ifadeler ayrıştırılıyor, SQL ifadeleri geliyor, optimize edici yürütme planı hızlı olduğunda ne yapacağına karar vermeli ve yavaş olduğunda başka bir yürütme planı seçmeli ve ekranın donmasına neden olmalı. Derin bir teknoloji temelinde, yürütme planının ne olduğunu bilmem gerekiyor ve Precise benim için tarih ve zaman damgasıyla tamamlıyor. Hızlı ve verimli olan bu, yavaş ve verimsiz olan bu. Bu filtre birleştirme, bu SQL deyimini yapmak için mutabakat sağlamak için çok daha fazla CPU kullanır. Hala aynı nihai etkiye sahiptirler, ancak bu temel olarak sonuç kümesini vermek için daha yavaş, daha az verimli bir tarife sahiptir. Böylece adım adım ilerliyoruz. Birkaç tane daha vaktimiz var mı?
Eric Kavanagh: Evet, devam et.
Bill Ellis: Tamam, ileri atlayacağım. Not almanızı istediğim bir şey, donanım hakkında konuştuk, SAP hakkında konuştuk, .NET hakkında konuştuk, JD Edwards ve Java-SQL Server ortamından bahsettik. Bu SAP, işte PeopleSoft'a bakıyoruz. Precise'ın destek matrisi geniş ve derindir. Bir uygulamanız varsa, büyük olasılıkla, bu görünürlük düzeyini sağlamak için uygulayabiliriz. Şu anda gerçekleşen en büyük değişikliklerden biri hareketlilik. PeopleSoft, Akışkan Kullanıcı Arayüzü ile mobiliteyi tanıttı. Akışkan kullanıcı arayüzü sistemi çok farklı kullanır. Bu uygulama gelişiyor. Fluid UI - yönetim açısından yaptığı şey, son kullanıcıların telefonlarını kullanmalarına izin vermek ve üretkenliği büyük ölçüde arttırmasıdır. Yüzlerce veya binlerce veya daha fazla çalışanınız varsa, verimliliklerini yüzde 1-2 oranında artırabiliyorsanız, bordro ve diğer her şey üzerinde büyük bir etkisi olabilir. Olanlar, bu dükkan PeopleSoft Fluid UI'yi piyasaya sürdü. Şimdi, karmaşıklıktan bahsetmişken, bu PeopleSoft yığını. Bir uygulama, en az altı teknoloji, çok sayıda son kullanıcı. Nasıl başlıyorsunuz?
Precise bu işlemleri bir kez daha takip edebilecek. Burada size gösterdiğimiz, istemci, web sunucusu, Java, Smokin veritabanı, PeopleSoft uygulama yığınını gösteren yığılmış bir çubuk grafik. Yeşil, WebLogic'i söylemenin süslü bir yolu olan J2EE ile eşleşir. Kesinti bu. Son kullanıcılar Sıvı Kullanıcı Arayüzünü kullanmaya başlar ve yanıt süresi belki bir buçuk, iki saniye, yaklaşık dokuz, on saniyeye kadar sürer. Bu tek ekranın göstermediği "yanıt vermeyen" kişi sayısıdır. Aslında uygulamada ekran donuyor. Precise'ın bu müşteriyi sağlayabildiği bazı görünürlüklere göz atalım.
Her şeyden önce, PeopleSoft işlemlerine baktığımda, temelde görebiliyorlar, bu tür şeyleri tahtada gördük. Tüm işlemler ve tüm lokasyonlar etkilendi. Bu arada, buna baktığınızda, dünyanın dört bir yanındaki yerleri görebilirsiniz. Asya Pasifik'ten Avrupa'ya ve Kuzey Amerika'ya kadar. Performans sorunu belirli bir işleme veya belirli bir coğrafi konuma bağlı değildi, sistem geneli. Bu, Akışkan Kullanıcı Arayüzü'nin değişimin veya yolun etki alanında küresel olduğunu söylemenin bir yolu. Burada ölçeklenebilirlik açısından bakabilirsiniz, insanlar aynı türde etkinlik yapmaya çalışıyorlar, ancak yanıt süresi temelde azalmış ve bozulmuş. Bir şeyin ölçeklenmediğini görebilirsiniz. Her şey çok ama çok kötü gidiyor. Burada, eksen sayısına ve eşzamanlı bağlantılara baktığımda, erişim sayısı ve bağlantılar açısından çok ilginç bir şey görüyorsunuz. Burada sadece yaklaşık 5.000'e kadar ölçeklendiriyoruz ve bakıyorsunuz, bu 100 eşzamanlı bağlantıda öne çıkıyor. Bu daha sonra yapılır; bu daha önce. Yani sistemdeki gerçek talebim, eğer bu şey ölçeklenebilirse, 300.000 aralığındadır. Eski günlerde, klasik kullanıcı arayüzü ile 30 eşzamanlı bağlantıya bakıyorsunuz.
Bunun size söylediği şey, Akışkan Kullanıcı Arabirimi'nin en az 10x eşzamanlı bağlantı kullanmasıdır. PeopleSoft ile kapakların altında neler olduğunu geri çekmeye başlıyoruz, böylece web sunucuları üzerindeki etkiyi, SLA'ların ihlal etmeye başladığını görmeye başlayabilirsiniz. Her şeye girmeyecek, ama sonuçta olan şey, temel olarak mesajlaşmaya güvenmeleridir. Temel olarak WebLogic egzersiz yaparlar ve smokin içinde kuyruğa neden olurlar. Aslında, Akışkan UI ile ortaya çıkan çok katmanlı bir bağımlılık sorunu vardı, ancak Precise, bir dizi farklı şeyle, sorunun ne olduğuna odaklanabileceğimizi gösterebildi. Veritabanında da bir sorun olduğu ortaya çıktı. Aslında bir mesajlaşma günlük dosyası var ve tüm eşzamanlı kullanıcılar nedeniyle bu günlük dosyası kilitleniyordu. Temel olarak, uygulama yığını içindeki her bir katmanda ayarlanması gereken şeyler vardı. Karmaşıklık hakkında konuşun, aslında size sıralamayı gösteren Smokin katmanı ve bu katmandaki performansın da düştüğünü görebilirsiniz. Süreçleri görebiliyordum; Etki alanlarını ve sunucuları görebiliyordum. Tuxedo'da, insanların bunu kullanması için, tipik olarak yaptığınız şey, kuyruktaki zamanı en aza indirmek için süpermarkette olduğu gibi tıkanıklığı gidermek için ek kuyruklar, etki alanları ve sunucular açmaktır. Son ve son seçenek olan Precise çok fazla bilgi gösterir.
Daha önce de belirttiğim gibi, her önemli işlem kayıt sistemi ile etkileşime girer. Veritabanında görünürlük çok önemlidir. Precise, veritabanında, WebLogic'te, Java, .NET'te, tarayıcıda neler olduğunu gösterir, ancak Precise'ın gerçekten başarılı olduğu yer veritabanı katmanındadır. Bu rakiplerimizin zayıflığı oluyor. Size, Precise'ın bu sorunu çözmenize yardımcı olabileceği yollardan birini göstereyim. Veritabanı optimizasyonu üçgeni üzerinde zaman geçirmeyeceğim, ancak temelde düşük maliyetli, düşük riskli, geniş kapsamlı, yüksek riskli, yüksek maliyetli tür değişikliklerine bakıyoruz. Eğer insanlar denemek ve bir göz atmak isterse aslında bu slaytı tweet atacağım. Bence sorunları ayarlamak için oldukça büyük bir rehber. İşte Precise for Oracle uzman görüşü. Bulgular raporunun en üstünde, yüzde 60 etkisi bu özel SQL ifadesidir. Bu etkinlik ekranını açarsanız, orada gösterir. Bu seçme ifadesine bakabilirim, bir yürütme planı var. Her infaz ikinci - 48.000 infaz. Bu, 48.000 saat daha yürütme sağlar.
Koyu mavi bir kez daha CPU. Bu şey CPU'ya bağlı, bir bekleme durumu değil, bir günlük değil. Bazı rakiplerimizin sadece bekleme durumlarına ve günlük olaylarına baktıklarından, genel olarak konuşursak, CPU'nun en yoğun yürütme durumu olduğunu ve en fazla geri alım sunduğunu vurgulamak isterim. Bu uzman görüşüne giriyorum - ve çok hızlı gidiyorum - yaptığım şey masaya, 100.000 sıraya, 37.000 bloğa baktım. Tam tablo yapıyoruz, ancak bu konuda altı dizinimiz var. Burada neler oluyor? Nerede cümleye baktığımda, bu cümlenin yaptığı şey aslında bir sütunu büyük harfe dönüştürmek ve büyük harfe eşit olduğu yerde değişken bulmak. Ne oluyor bu şey her çalıştırıldığında, Oracle'ın bu sütunu büyük harfe dönüştürmesi gerekiyor. Bunu neredeyse elli bin kat yapmak yerine, bu indeksi fonksiyon tabanlı bir endeksin büyük harfinde oluşturmak çok daha verimlidir ve sadece Oracle girişiminin bölümünde değil, standart bölümde de kullanılabilir. Bunu yaptığınızda, daha sonra yapabileceğiniz şey, yeni dizin kullanıcı izni büyük harfini veren yürütme planını doğrulamaktır.
Ardından, bir önceki ve sonraki ölçümden, bir saniyelik yürütme süresine bakıyorsunuz, 9 saat 54 dakikaya kadar toplanıyor, aynı SQL ifadesiyle toplanıyor, ancak bu dizinin 58.000 yürütme için büyük harfle oluşturulmuş olması, yanıt zaman milisaniyenin altına düşer, birlikte toplanır, yedi saniyeye kadar gelir. Temel olarak sunucuma on saatlik CPU kaydettim. Bu cok büyük. Çünkü bir sunucunun yenilenmesi gerekmiyorsa, o sunucuda yaşayabilirim. Aslında bu sunucu kullanımını yüzde 20 oranında düşürüyorum ve aslında önce ve sonrasını görebilirsiniz. Precise'ın sağlayabileceği görünürlük türü budur. Ayrıca bakabileceğimiz bazı ek şeyler de var, kullanılmıyorsa neden bu dizinlerin hepsine sahipsiniz? Bunu takip edebilirler. Mimari var ve bunu tamamlayacağım, çünkü saatin zirvesine ulaşıyoruz. Ben bu çözüme gerçek bir inananım ve sizin gerçek bir inanan olmanızı istiyoruz. IDERA'da bir denemenin müşteri oluşturduğuna inanıyoruz, bu yüzden ilgileniyorsanız sitenizde değerlendirmeler yapabiliyoruz.
Bununla birlikte, ışığı geri vereceğim.
Eric Kavanagh: Evet, burada gösterdiğiniz muazzam bir ayrıntı oldu. Gerçekten çok etkileyici. Sanırım geçmişte size bundan bahsetmiş olabilirim - ve IDERA ile yaptığımız diğer bazı web yayınlarında biliyorum, bahsetmiştim - IDERA tarafından satın alınmadan önce tam olarak Kesinliği izliyorum, sanırım 2008'e kadar. O zamanlar bundan çok etkilendim. Yeni uygulama sürümlerinin üstünde kalmak için ne kadar iş yapıldığını merak ediyorum. Gerçekten HANA mimarisini inceleyip orada sorun giderme yapabileceğinizi düşündüğüm SAP HANA'dan bahsettiniz. Kaç kişiniz var? Ne kadar çaba harcamanız ve bunun ne kadar dinamik bir şekilde yapılabileceği, yani araç dağıtıldığında, etrafta gezinmeye ve farklı şeyler görmeye başlarsınız? Bunların ne kadarı araç tarafından dinamik olarak algılanabilir, böylece insanların karmaşık ortamlarda sorun gidermesine yardımcı olabilirsiniz?
Bill Ellis: Orada birçok soru sordunuz.
Eric Kavanagh: Biliyorum, üzgünüm.
Bill Ellis: Çok fazla ayrıntı verdim çünkü bu uygulamalar için koda bakarak şeytan ayrıntıda. Gerçekten eyleme geçirilebilir bir şeye sahip olabilmek için bu ayrıntı düzeyine sahip olmalısınız. Eyleme geçirilebilir metrikler olmadan, yalnızca belirtileri bilirsiniz. Aslında problem çözmüyorsunuz. IDERA problemleri çözmekle ilgilidir. Yeni çıkanların ve şeylerin üstünde kalmak büyük bir zorluktur. Bunu yapmak için ne gerekiyor sorusu, bu gerçekten ürün yönetimi için. Bizi temelde her şey hakkında güncel tutan çok fazla görünürlük yok. HANA açısından, bu aslında IDERA ürün serisine yeni bir ektir; çok heyecan verici. HANA ile ilgili şeylerden biri - bir saniye için görev hakkında konuşmama izin verin. Görevde SAP dükkanlarının yapacağı raporlama amaçlı veritabanı çoğaltmalarıdır. O zaman insanların gerçekte olanlarla uzlaştırılması gerekir. Bu farklı veritabanlarına sahip olacaksınız ve farklı düzeylerde senkronize olmayacaklardı. Tüm bunları sürdürmek için çok fazla zaman ve çaba ile donanım, yazılım ve insanlar var.
HANA'nın temelde yinelenen veritabanlarına olan ihtiyacı önlemek için oldukça paralel bir bellek içi veritabanına sahip olma fikri. Tek bir veritabanımız, tek bir gerçek kaynağımız var, her zaman güncel, bu şekilde tüm bu mutabakatı yapmak için gerekenlerden kaçınıyorsunuz. HANA veritabanının performansının önemi artar - 10x veya en azından diğer tüm veritabanlarının, donanımın, kaynakların satın alabileceğinden daha değerli olduğunu söyleyeceğim. HANA'yı yönetebilmek için, bu bileşen aslında şu anda beta testinde, yakında GA'ya geçecek bir şey. Bu IDERA ve SAP platformunu temelde desteklememiz için oldukça heyecan verici. Sorunuzun diğer bölümlerinin nasıl değiştiğinden emin değilim ama -
Eric Kavanagh: Hayır, hepsi orada iyi şeyler. Sana bir kerede bütün bir demet attım, bunun için çok üzgünüm. Sadece büyülendim, yani, bu çok basit bir uygulama değil, değil mi? Bu araçlara derinlemesine bakıyorsunuz ve birbirleriyle nasıl etkileşime girdiklerini anlıyorsunuz, hikayeyi kafanızda bir araya getirmelisiniz. Gerçekte neler olduğunu ve soruna neyin neden olduğunu anlamak için bilgi parçalarını birleştirmeniz gerekir, böylece oraya gidebilir ve bu sorunları çözebilirsiniz.
Bir katılımcı soruyor, Hassas'ı uygulamak ne kadar zor? Başka bir kişi sordu, insanlar kim - tabii ki DBA'lar - ama kuruluşta bu aracı kullanacak başka roller kim?
Bill Ellis: Precise'ın konuşlandırılması biraz daha karmaşık. Uygulama ortamı hakkında biraz bilgi sahibi olmanız gerekir, bilirsiniz, bu uygulama bu veritabanında çalışır, ihtiyaç duyar veya - orta katmanlı web sunucuları, vb. Bu uygulamaların bazılarının karmaşıklığı göz önüne alındığında, aslında nispeten kolay. Web sunucusunu veritabanınıza kadar yapabilirsem, bunu uçtan uca yapabilirim. Son kullanıcı istemcisini enstrümantasyon hakkında hiçbir şey söylemediğimi fark ettiniz ve bunun nedeni, yaptığımız şeyin aslında dinamik olarak dahil olduğumuzdan, kodunuzu veya başka bir şeyi değiştirmek zorunda kalmamanız. Uygulama sayfası çerçevesine bir JavaScript girer. Kullanıcı dünyanın neresinde olursa olsun, uygulamanızdan URL'ye erişip sayfayı aşağı indirdiklerinde, Precise ile birlikte gelir. Bu, kullanıcı kimliğini, IP adreslerini ve ayrıca son kullanıcı tarayıcısında sayfa bileşenleri komut dosyası yürütme sürelerinin her birinin ilk bayt oluşturma süresini seçmemizi sağlar.
İşlemler açısından, sıkı sıkıya bağlı oldukları için işlemleri haritalamak zorunda değilsiniz. Bu URL, JVM'nin bir giriş noktası olur ve daha sonra bu iletiyi çağırır ve veritabanından bir JVC yakalanır. Temel olarak bu doğal bağlantı noktalarını yakalayabilir ve her bir adımda ne kadar zaman veya harcanan sürenin yüzdesini de hesapladığımız bu işlem ekranında size sunabiliriz. Tüm bunlar otomatik olarak yapılır. Genel olarak, temel çekirdeği kurmak için 90 dakika ayırıyoruz ve daha sonra uygulamayı uygulamaya başlıyoruz. Uygulamanın bilgisine bağlı olarak, tüm uygulamayı araç haline getirmek için bazı ek oturumlar gerekebilir. Birçok kişi sadece Precise'ın veritabanı bileşenini kullanır. Bu iyi. Temel olarak bunu kırabilir, sitenizin ihtiyacı gibi hissettiğiniz bileşenlere ayırabilirsiniz. Katmanlar arası bağımlılığın aslında tek bir katmanı izlemenin değerini büyüttüğünü görebilmeniz için tüm uygulama yığınını araç haline getirme bağlamının kesinlikle olduğuna inanıyoruz. Birisi uygulama yığınlarını daha ayrıntılı bir şekilde incelemek isterse, lütfen web sitemize gidin - Sanırım ek bilgi istemenin en kolay yolu bu ve biraz daha tartışacağız.
Eric Kavanagh: Size bir veya iki kısa soru atayım. Zaman içinde hem bireysel müşteriler hem de genel olarak kurumsal bir varlık olarak çeşitli uygulamalar ve çeşitli veritabanları arasındaki etkileşimleri topladığınızı ve oluşturduğunuzu tahmin ediyorum. Diğer bir deyişle, senaryo modellemesi, sanırım, bahsettiğim şey bu. Durum böyle mi? Aslında, belirli şeyler yürürlüğe girdiğinde son kullanıcılara önerilerde bulunabileceğiniz bir tür ortak senaryo deposunu tutuyor musunuz? E-Business Suite'in bu sürümü gibi, bu veritabanının bu sürümü vb. - Bunların çoğunu yapıyor musunuz?
Bill Ellis: Bu tür bilgiler bulgular raporunda yer alıyor. Bulgular raporu performans darboğazlarının neler olduğunu söylüyor ve yürütme süresine bağlı. Bu bulgular raporunun bir kısmı daha fazla bilgi ve bundan sonra ne yapacaksınız. Müşterilerden gelen bilgi veya deneyim, temelde bu öneri kütüphanesine dahil edilmiştir.
Eric Kavanagh: Tamam, kulağa hoş geliyor. Peki millet, bugün harika sunum. Bill, orada ne kadar ayrıntıya sahip olduğunu sevdim. Ben sadece tüm bu şeylerin nasıl yapıldığını gösteren, gerçekten fantastik, cesur, ayrıntılı bilgi olduğunu düşündüm. Belli bir noktada neredeyse kara büyü gibi, ama gerçekten değil. Çok, çok karmaşık ortamları anlamak ve insanları mutlu etmek için bir araya getirdiğiniz çok özel bir teknoloji çünkü uygulamalar yavaş çalıştığında kimse sevmiyor.
Millet, bu web yayınını arşivleyeceğiz. Techopedia veya insideanalysis.com'a çevrimiçi olarak atlayabilir ve vay canına, zaman ayırdığınız için teşekkürler, bir dahaki sefere size yetişeceğiz. Kendine iyi bak bay bay.
