Oleh Staf Techopedia, 2 November 2016
Takeaway: Host Eric Kavanagh membahas kinerja aplikasi dan cara meningkatkan efisiensi dengan Dr. Robin Bloor, Dez Blanchfield dan Bill Ellis dari IDERA.
Anda saat ini belum masuk. Silakan masuk atau daftar untuk melihat video.
Eric Kavanagh: Hadirin sekalian, halo dan selamat datang kembali ke Hot Technologies. Ya memang! Nama saya Eric Kavanagh, saya akan menjadi tuan rumah Anda untuk webcast lain hari ini di seri yang benar-benar menyenangkan dan mengasyikkan yang kami dapatkan sebagai pujian untuk seri Briefing Room kami. Judulnya adalah "Akselerasi Aplikasi: Kinerja Lebih Cepat untuk Pengguna Akhir." Ayolah, siapa yang tidak menginginkan itu? Jika saya orang di luar sana membantu aplikasi Anda berjalan lebih cepat, saya pikir saya orang yang membeli bir untuk saya di bar setelah bekerja. Itu harus menjadi hal yang cukup keren untuk masuk dan mempercepat aplikasi siapa pun.
Ada slide tentang dirimu yang sebenarnya, pukul aku di Twitter @Eric_Kavanagh. Saya selalu mencoba untuk mengikuti kembali dan saya selalu mengirim ulang tweet jika Anda menyebut saya, jadi silakan sebutkan saya.
Seluruh tujuan acara ini adalah untuk fokus pada berbagai aspek teknologi perusahaan dan sangat membantu mendefinisikan disiplin ilmu tertentu atau wajah-wajah tertentu, jika Anda mau. Banyak kali vendor akan mengambil syarat pemasaran tertentu dan berbicara tentang bagaimana mereka melakukan ini atau itu atau hal lain. Acara ini benar-benar dirancang untuk membantu audiens kami memahami apa yang harus dimiliki alat perangkat lunak agar menjadi pemimpin dalam ruangnya. Format ini menjadi dua analis. Masing-masing pergi dulu, tidak seperti Ruang Briefing tempat vendor pergi dulu. Masing-masing memberikan pendapat mereka tentang apa yang menurut mereka penting bagi Anda untuk mengetahui tentang jenis teknologi tertentu.
Hari ini kita berbicara tentang akselerasi aplikasi. Kita akan mendengar dari Dez Blanchfield dan juga Dokter Robin Bloor - kita di seluruh dunia hari ini - dan kemudian Bill Ellis menelepon dari wilayah Virginia yang lebih besar. Dengan itu, saya akan menyerahkannya kepada presenter pertama kami, Dr. Bloor. Kami men-tweet tagar #podcast, jadi jangan ragu untuk tweet. Bawa pergi.
Robin Bloor: Oke, terima kasih atas pengantar itu. Kinerja aplikasi dan tingkat layanan - ini adalah semacam bidang, saya telah melakukan banyak pekerjaan di bidang ini selama bertahun-tahun, dalam arti saya sebenarnya telah melakukan banyak pekerjaan dalam memantau kinerja dan bekerja dalam satu cara atau yang lain, bagaimana mencoba dan menghitung level tersebut. Harus dikatakan bahwa sampai - kita dulu memiliki era ini, beberapa waktu yang lalu, di mana orang membangun sistem dalam silo. Pada dasarnya, jumlah pekerjaan yang harus mereka lakukan untuk membuat sistem berkinerja cukup baik jika berada di silo sebenarnya tidak terlalu sulit karena ada sangat sedikit, sangat sedikit variabel yang harus Anda pertimbangkan. Segera setelah kami mendapat jaringan yang tepat, orientasi interaktif dan layanan masuk ke dalam persamaan. Agak sulit. Performanya bisa satu dimensi. Jika Anda hanya memikirkan aplikasi yang menjalankan jalur kode tertentu berulang kali, melakukannya secara wajar, tepat waktu, terasa seperti hal satu dimensi. Segera setelah Anda mulai berbicara tentang tingkat layanan, Anda sebenarnya berbicara tentang banyak hal yang bersaing untuk sumber daya komputer. Menjadi multi-dimensional dengan sangat cepat. Jika Anda mulai berbicara tentang proses bisnis, proses bisnis dapat disatukan bersama dari beberapa aplikasi. Jika Anda berbicara tentang arsitektur berorientasi layanan, maka aplikasi yang diberikan sebenarnya dapat mengakses kemampuan beberapa aplikasi. Maka itu menjadi hal yang sangat rumit.
Saya melihat - dulu sekali, saya menggambar diagram ini. Diagram ini setidaknya 20 tahun. Pada dasarnya, saya menyebutnya Diagram Segalanya karena ini adalah cara untuk melihat segala sesuatu yang ada di lingkungan TI. Ini benar-benar hanya empat bagian: pengguna, data, perangkat lunak, dan perangkat keras. Tentu saja mereka berubah seiring waktu, tetapi Anda benar-benar menyadari ketika Anda melihat ini bahwa ada ledakan hirarkis dari masing-masing bagian ini. Perangkat keras ya, perangkat keras bisa menjadi server tetapi server terdiri dari kemungkinan banyak CPU, teknologi jaringan dan memori, dan ini, semacam pengendali yang mengerikan, seperti yang terjadi. Jika Anda benar-benar melihat ini, semuanya akan hancur berkeping-keping. Jika Anda benar-benar berpikir untuk mencoba mengatur semua itu, sehubungan dengan data yang berubah, kinerja perangkat lunak berubah, karena perangkat kerasnya berubah, dan seterusnya, Anda benar-benar melihat situasi multi-variasi yang sangat sulit. Ini adalah kurva kompleksitas. Tentu saja kurva kompleksitas untuk hampir semua hal, tetapi saya telah melihatnya berulang kali ketika berbicara tentang komputer. Pada dasarnya, jika Anda meletakkan node pada satu sumbu dan koneksi penting pada sumbu lainnya, Anda berakhir dengan kurva kompleksitas. Hampir tidak masalah apa node dan koneksi dan yang akan dilakukan jika Anda ingin representasi dari pertumbuhan volume di jaringan telepon.
Pada kenyataannya, ketika berbicara tentang node di lingkungan komputer, Anda berbicara tentang hal-hal individual yang saling peduli. Kompleksitas, ternyata, soal struktur variasi dan berbagai kendala yang Anda coba patuhi. Juga, angkanya. Ketika angkanya naik, mereka menjadi gila. Saya memiliki obrolan yang menarik kemarin, saya sedang berbicara dengan seseorang - saya tidak bisa menyebutkan siapa dia, tetapi tidak terlalu penting - mereka berbicara tentang sebuah situs yang memiliki 40.000 - itu adalah empat-nol, 40.000 - contoh database di situs. Coba pikirkan - 40.000 basis data berbeda. Tentu saja satu-satunya yang kami miliki - mereka jelas memiliki banyak, ribuan aplikasi. Kita berbicara tentang organisasi yang sangat besar, tetapi saya tidak dapat menyebutkannya. Anda benar-benar melihat itu, dan Anda benar-benar mencoba, dengan satu atau lain cara, mendapatkan tingkat layanan yang akan mencukupi untuk beberapa pengguna, dengan beberapa harapan yang berbeda, jika Anda suka. Ini adalah situasi yang kompleks, dan yang ingin saya katakan hanyalah, kompleks ini. Jumlahnya selalu bertambah. Kendala ditentukan oleh proses bisnis dan tujuan bisnis. Anda akan melihat perubahan harapan.
Saya ingat segera setelah Gmail, dan Yahoo mail, dan Hotmail, semua sistem surat itu muncul, orang-orang mulai memiliki harapan sistem surat internal mereka di dalam organisasi akan pantas tingkat layanan dari operasi besar ini dengan peternakan server besar di luar organisasi dan mulai ditekan untuk membuat semua hal semacam itu terjadi. Sebenarnya, perjanjian tingkat layanan adalah satu hal, tetapi harapan adalah hal lain dan mereka saling bertarung dalam suatu organisasi, hal yang aneh. Ini hanya perspektif bisnis. Dalam beberapa sistem, waktu respons optimal adalah sepersepuluh detik dari waktu respons manusia. Sepersepuluh detik adalah waktu yang dibutuhkan seekor kobra untuk menggigit Anda. Jika Anda berdiri di depan ular kobra, dan itu memutuskan untuk menggigit Anda, sudah terlambat, itu akan terjadi karena Anda tidak dapat merespons dalam sepersepuluh detik. Sepersepuluh detik adalah waktu yang dibutuhkan bola untuk meninggalkan tangan pelempar untuk mencapai lelaki dengan kelelawar. Pada dasarnya, ketika dia melihat bola dilemparkan, dia harus merespons tepat pada saat itu. Respon manusia, semacam hal yang menarik. Perangkat lunak-ke-perangkat lunak, jelas dapat memiliki harapan yang lebih tinggi.
Kemudian Anda masuk ke beberapa situasi yang saya pikir adalah situasi pasar itu, di mana yang pertama adalah di mana nilai bisnis berada. Ini seperti jika Anda ingin menjual saham tertentu di pasar saham mungkin kurang, misalnya, karena Anda pikir itu akan turun dan banyak orang lain berpikir itu akan turun, Anda mendapatkan harga terbaik jika Anda mendapatkan pasar pertama. Ada banyak situasi, penayangan iklan dan hal-hal seperti itu, situasi yang sangat mirip. Anda mendapatkan pergerakan ini dalam hal ekspektasi tingkat layanan. Anda punya satu hal yaitu semacam langit-langit kaca untuk respons manusia. Setelah perangkat lunak-ke-perangkat lunak, jika Anda punya situasi langit-langit ini, maka tidak ada tingkat layanan terbaik. Lebih cepat daripada orang lain adalah yang terbaik.
Oke, ini, saya pikir, slide terakhir yang saya lakukan, tetapi ini hanya untuk memberi Anda gambaran besar tentang kerumitan, begitu Anda benar-benar melihat persyaratan organisasi, layanan. Anda punya, naik ke sisi kiri di sini, Anda punya manajemen sistem, yang merupakan seperangkat perangkat lunak yang berfungsi dalam manajemen layanan, yang mencoba mengelola tingkat layanan. Di atas itu Anda punya manajemen kinerja bisnis. Kemudian jika Anda melihat bagian bawah di sini, area otomatisasi manajemen layanan, Anda memiliki layanan terfragmentasi yang berevolusi menjadi layanan standar, jika Anda benar-benar peduli untuk berinvestasi dalam hal semacam ini, yang berevolusi menjadi layanan terintegrasi, yang berevolusi menjadi layanan yang dioptimalkan . Kebanyakan yang dilakukan orang adalah, hanya di sudut kiri bawah ini. Mungkin sedikit manajemen layanan. Manajemen kinerja bisnis, sangat jarang. Terfragmentasi, hampir semuanya. Dunia yang sempurna akan mengisi grid itu. Instrumentasi - Saya menyebutkan masalah sub-optimasi. Anda dapat mengoptimalkan bagian-bagian suatu sistem dan itu tidak baik untuk keseluruhan sistem. Jika Anda membuat jantung optimal, maka darah Anda mungkin beredar terlalu cepat untuk sisa organ Anda. Itu masalah dengan organisasi besar dan tingkat layanan. Jelas tidak ada yang akan dicapai tanpa alat-alat canggih karena variabel baru saja didapat - yah ada terlalu banyak variabel untuk dicoba dan dioptimalkan.
Karena itu, saya akan menyampaikan kepada Dez yang akan berbicara tentang hal lain sepenuhnya, semoga.
Dez Blanchfield: Terima kasih, Robin. Seperti Dr. Robin Bloor, saya telah menghabiskan waktu bertahun-tahun untuk memikirkan kinerja sistem yang sangat kompleks pada skala yang sangat besar. Mungkin bukan skala yang sama dengan Robin, tetapi kinerja adalah topik sehari-hari dan itu bagian dari DNA kami untuk menginginkan kinerja, untuk mendapatkan yang terbaik dari segalanya. Faktanya, saya telah menggunakan grafik dari salah satu hal favorit saya di dunia, balap mobil Formula I, di mana seluruh planet ini diam untuk sementara waktu dan menonton mobil berputar cepat dengan sangat cepat. Setiap aspek, tidak ada aspek Formula I yang tidak khusus tentang mendapatkan kinerja. Banyak orang membuang-buang olahraga karena mereka pikir itu buang-buang uang. Ternyata mobil yang kami kendarai setiap hari untuk mengantar anak-anak bermain sepak bola di akhir pekan dan sekolah pada hari-hari lainnya, berasal dari pengembangan dan penelitian berbasis kinerja. Ini semacam kehidupan balap mobil Formula I. Teknologi sehari-hari, sains sehari-hari, sering datang dari orang-orang seperti sesuatu yang telah difokuskan murni pada kinerja tinggi.
Kenyataannya, bagaimanapun, adalah bahwa dunia "selalu ada" baru kami, yang menuntut waktu aktif 100 persen - seperti yang disebutkan Robin sebelumnya - dengan hal-hal seperti pengenalan webmail dan layanan lain yang kami terima begitu saja dalam ruang yang terus menerus, dan kami sekarang berharap bahwa di perusahaan dan lingkungan kerja kami. Kenyataannya adalah bahwa bangun tidak selalu berarti Anda memenuhi perjanjian tingkat layanan Anda. Saya telah mengambil ini tentang kebutuhan untuk mengelola kinerja aplikasi dan ketersediaan perjanjian tingkat layanan telah mengalami perubahan mendasar dalam dekade terakhir. Kami tidak hanya berusaha khawatir tentang kinerja satu sistem lagi. Ketika dunia sedikit lebih sederhana, kita mungkin memiliki situasi di mana satu server yang menjalankan beberapa layanan dapat dimonitor secara langsung dan itu relatif mudah untuk didukung. Kita bisa - dan ini kecil saya, hal-hal yang biasa kita khawatirkan ketika saya menjadi administrator sistem misalnya, bertahun-tahun lalu - kita akan melihat-lihat, apakah layanannya biasanya merespons dan merespons? Bisakah saya masuk ke terminal misalnya? Apakah sistem operasi merespons dan dapatkah saya mengetik perintah? Apakah aplikasi aktif dan berjalan? Dapatkah saya melihat proses dan memori dalam melakukan sesuatu dan I / O di seluruh jaringan dan sebagainya? Pada hari-hari mainframe Anda bisa mendengar kaset menjadi zip-zip-zip dan kertas terlepas dari mereka.
Apakah aplikasi merespons dan dapatkah kita masuk dan melakukan sesuatu pada mereka? Apakah pengguna dapat terhubung ke beberapa server itu? Ini berlanjut. Mereka cukup mendasar, Anda tahu. Lalu beberapa yang lucu - apakah help desk berwarna hijau? Karena jika tidak, maka semuanya berjalan dengan baik, dan siapa yang akan mendapatkan donat? Hidup benar-benar sederhana pada masa itu. Bahkan pada masa itu, dan kemudian saya berbicara dengan 20-30 tahun yang lalu, kompleksitasnya masih sangat tinggi. Kita bisa, dengan cara yang relatif mudah, mengelola perjanjian tingkat layanan dan mengawasi kinerja. Kita tidak bisa melakukannya dengan tangan lagi, seperti yang disinggung Robin. Tantangannya terlalu besar. Faktanya adalah saat ketika beberapa aplikasi, admin, jaringan sistem dan basis data yang baik, admin dapat memantau dan memenuhi SLA kinerja. SLA begitu jauh hilang sekarang sehingga saya berjuang semalam ketika saya sedang menyusun catatan akhir saya bersama-sama untuk memikirkan tahun ketika saya terakhir berhasil melihat sebuah sistem tumpukan yang sangat kompleks, dan masuk akal dan bahkan memahami apa yang ada. terjadi di bawah tenda, dan saya berasal dari latar belakang yang sangat teknis. Saya tidak bisa membayangkan bagaimana rasanya menghadapi hal itu sehari-hari sekarang secara administratif.
Apa yang terjadi? Nah, pada tahun 1996, aplikasi berbasis database ditransformasikan dengan booming internet. Banyak dari kita telah melalui itu. Bahkan jika Anda tidak berada di sekitar booming internet, Anda dapat dengan mudah melihat-lihat dan menyadari bahwa dalam kehidupan sehari-hari, kita menghubungkan semuanya ke internet sekarang. Saya percaya kami punya pemanggang roti yang tampaknya datang dengan opsi untuk mendapatkan Wi-Fi yang konyol, karena saya tidak perlu pemanggang roti saya terhubung ke internet. Pada tahun 2000-an, terutama awal tahun 2000-an, kami harus menghadapi pertumbuhan yang sangat besar dalam putaran kompleksitas yang memberikan kinerja layanan dalam booming dot-com. Kemudian percikan canggung konyol lain di web 2.0, di mana smartphone muncul dan sekarang aplikasi ada di tangan kami 24/7 dan selalu aktif.
Sekarang tahun 2016, kami dihadapkan dengan rawa lain dalam bentuk cloud dan big data serta mobilitas. Ini adalah sistem yang begitu besar sehingga seringkali sulit untuk dipahami dan dimasukkan ke dalam bahasa Inggris. Ketika kita berpikir tentang fakta bahwa beberapa unicorn besar yang kita bicarakan memiliki puluhan ratusan petabyte data. Ini adalah seluruh lantai ruang penyimpanan dan penyimpanan hanya untuk menampung email, gambar, dan media sosial Anda. Atau dalam beberapa kasus, dalam transportasi dan pengiriman logistik, semuanya ada di perbankan, di mana uang Anda, atau di mana pos Anda berada, atau di mana barang yang Anda beli di eBay berada. Gelombang besar berikutnya yang akan kita hadapi adalah tantangan internet yang sangat berat ini.
Jika ini tidak cukup buruk, kami akan membangun kecerdasan buatan dan komputasi kognitif menjadi hampir segalanya. Kami berbicara dengan mesin Siri dan Google hari ini. Saya tahu Amazon punya sendiri. Baidu memiliki salah satu perangkat yang dapat Anda ajak bicara, mereka mengubahnya menjadi teks yang masuk ke sistem normal, database membuat kueri dan kembali dan membalikkan proses. Pikirkan tentang kompleksitas yang masuk ke dalamnya. Kenyataannya adalah bahwa kompleksitas tumpukan aplikasi standar saat ini jauh melampaui kemampuan manusia. Ketika Anda memikirkan segala sesuatu yang terjadi ketika Anda menekan tombol pada perangkat ponsel cerdas atau tablet Anda, Anda berbicara dengannya, mengonversinya menjadi teks, menjalankan semua itu ke internet ke sistem back-end, front-end menerima itu, mengubahnya menjadi kueri, menjalankan kueri melalui tumpukan aplikasi, melewati database, hits disc, keluar kembali, dan di tengah ada jaringan operator, ada pusat status jaringan area lokal. Kompleksitasnya gila.
Kami secara efektif menyatakan ini sebagai hyperscale. Kompleksitas dan kecepatan hyperscale hanyalah penyiraman mata. Aplikasi dan basis data telah menjadi sangat besar dan kompleks, sehingga mengelola kinerja sebenarnya adalah ilmu itu sendiri. Banyak yang menyebutnya sebagai ilmu roket. Kami memiliki teknologi di tempat, kami memiliki teknologi di luar lokasi, kami memiliki beragam pilihan pusat data; fisik dan virtual. Kami memiliki server fisik dan virtual, kami memiliki cloud, kami memiliki infrastruktur sebagai layanan dan platform sebagai layanan dan perangkat lunak sebagai layanan adalah hal yang sekarang kami terima begitu saja. Yang terakhir, perangkat lunak sebagai layanan, menjadi menakutkan untuk sementara waktu beberapa tahun yang lalu ketika CFO dan bagian dari organisasi menyadari bahwa mereka dapat mengambil kartu kredit mereka dan hanya membeli barang sendiri dan berkeliling CIO dan secara efektif kami menyebutnya "bayangan" IT ”dan CIO sekarang mencoba untuk memutar balik ini dan bergulat kembali.
Dalam infrastruktur kami memiliki jaringan yang ditentukan oleh perangkat lunak, virtualisasi fungsi jaringan, di bawah yang kami miliki, mungkin sudah berakhir, sekarang kami memiliki layanan mikro dan aplikasi layanan aktif. Ketika Anda mengklik URL, ada sekelompok logika bisnis yang berada di akhir URL yang menjelaskan apa yang sebenarnya diperlukan untuk mengirimkannya. Itu tidak selalu memiliki logika prebuilt menunggu untuk itu. Kami memiliki database tradisional di satu sisi yang memiliki skala sangat, sangat besar. Kami memiliki infrastruktur dan ekosistem Hadoop di spektrum lain yang sangat besar sehingga, seperti yang saya katakan, Anda tahu, orang-orang membicarakan ratusan petabyte data sekarang. Kami memiliki kerumitan mobilitas sejauh perangkat yang digunakan untuk bepergian, laptop, ponsel, dan tablet.
Kami memiliki BYOD di beberapa lingkungan tertutup dan semakin meningkat sekarang, karena orang-orang berpengalaman Gen Y membawa perangkat mereka sendiri. Kami hanya membiarkan mereka berbicara kepada mereka tentang antarmuka web. Baik melalui internet atau melalui Wi-Fi, kami memiliki Wi-Fi gratis di kafe di lantai bawah saat mereka sedang minum kopi. Atau Wi-Fi internal kami. Mesin-ke-mesin selalu hadir sekarang. Itu bukan bagian langsung dari internet, tetapi juga terkait. Internet segala sesuatu adalah permainan yang sepenuhnya baru dengan kompleksitas yang membingungkan. Kecerdasan buatan, dan jika Anda berpikir bahwa apa yang kami mainkan sekarang, dengan semua Siri dan perangkat terkait lainnya yang kami ajak bicara rumit, tunggu sampai Anda sampai pada situasi di mana Anda melihat sesuatu yang disebut Olli yang merupakan 3-D bus cetak yang memakan waktu sekitar enam orang dan dapat mengemudi sendiri di sekitar kota dan Anda dapat berbicara bahasa Inggris dengan jelas, dan itu akan berbicara kembali kepada Anda. Jika itu mengenai lalu lintas, itu akan memutuskan untuk belok kiri atau langsung dari area utama di mana ada lalu lintas. Ketika berbelok dan Anda menjadi khawatir tentang mengapa belokan itu berbelok ke kiri atau langsung dari jalan utama, ia akan berkata kepada Anda, “Jangan khawatir, saya akan belok kiri. Ada lalu lintas di depan dan saya akan mengatasinya. "
Mengelola kinerja semua sistem di sana dan semua kerumitannya, melacak ke mana data itu pergi, apakah itu masuk ke dalam basis data, semua interkoneksi dan semua bit yang relevan hanya membingungkan. Kenyataannya adalah bahwa mengelola kinerja dan SLA pada kecepatan dan skala saat ini membutuhkan alat dan sistem, dan secara default ini bukan lagi sesuatu yang menurut Anda akan menyenangkan jika memiliki alat - ini merupakan prasyarat; itu mutlak diperlukan. Berikut adalah contohnya, daftar diagram desain aplikasi tingkat tinggi untuk OpenStack, cloud yang ditentukan oleh perangkat lunak sumber terbuka. Ini hanya sebagian besar. Ini bukan hanya server dan basis data. Di sinilah setiap gumpalan biru kecil mewakili kelompok benda. Dalam beberapa kasus file dan server atau ratusan database atau tentu saja tidak lebih dari puluhan ribu potongan kecil aplikasi logika berjalan. Itu versi kecil. Benar-benar sangat membingungkan ketika Anda mulai berpikir tentang kompleksitas yang muncul dalam hal ini. Hari ini, bahkan hanya dalam ruang data besar, saya hanya akan menempatkan beberapa tangkapan layar dari merek saja. Ketika Anda memikirkan semua bagian yang harus kami kelola di sini, kami tidak hanya berbicara tentang satu merek saja, ini semua adalah merek dalam lanskap data besar dan merek teratas, bukan hanya setiap kecil atau open source. Anda melihat dan Anda pikir itu bagan yang sangat membingungkan.
Mari kita lihat beberapa vertikal. Mari kita ambil pemasaran, misalnya. Berikut bagan yang sama tetapi dari tumpukan teknologi yang tersedia dalam teknologi pemasaran saja. Ini adalah grafik 2011. Ini versi 2016. Coba pikirkan, ini hanya sejumlah merek produk yang dapat Anda jalankan untuk teknologi yang berkaitan dengan teknologi pemasaran. Bukan kompleksitas sistem di dalam sana, bukan aplikasi dan web yang berbeda dan pengembangan serta jaringan dan yang lainnya. Hanya mereknya. Ada yang sebelumnya, lima tahun yang lalu dan ini hari ini. Itu hanya akan menjadi lebih buruk. Kita berada pada titik sekarang di mana kenyataannya, manusia tidak bisa memastikan semua perjanjian tingkat layanan. Kita tidak bisa menyelami cukup detail, cukup cepat, dan pada skala yang kita butuhkan. Berikut ini contoh tampilan konsol pemantauan sekarang. Ini seperti hampir dua puluh layar yang direkatkan berpura-pura seolah-olah mereka adalah satu layar proyeksi besar yang diproyeksikan setiap potongan kecil. Sekarang menarik di sini, saya tidak akan menyebut mereknya, tetapi platform pemantauan ini memantau satu aplikasi dalam lingkungan logistik dan pengiriman. Hanya satu aplikasi. Jika Anda memikirkan apa yang Robin bicarakan di mana organisasi dapat memiliki 40.000 basis data sekarang di lingkungan produksi. Bisakah Anda memvisualisasikan 40.000 versi dari kumpulan layar yang memantau satu aplikasi ini? Kita hidup di dunia yang sangat berani. Seperti yang dikatakan Robin dan saya benar-benar, 100 persen menggemakan bahwa, tanpa alat yang tepat, tanpa dukungan yang tepat dan orang-orang di atas meja menggunakan alat-alat itu, kinerja aplikasi adalah permainan yang hilang bagi manusia dan itu harus dilakukan oleh alat dan perangkat lunak.
Dengan itu saya akan meneruskan ke teman-teman kami di IDERA.
Eric Kavanagh: Baiklah, Bill.
Bill Ellis: Terima kasih. Bagikan layar saya di sini. Saya kira dapatkah seseorang mengonfirmasi bahwa Anda dapat melihat layar saya?
Robin Bloor: Ya.
Eric Kavanagh: Kelihatannya baik-baik saja.
Bill Ellis: Terima kasih. Satu hal yang dia maksudkan adalah, saya benar-benar tidak sabar untuk menunggu adalah mobil self-driving. Satu hal yang belum pernah saya dengar dari siapa pun adalah, apa yang terjadi ketika salju turun? Saya agak heran jika para insinyur di California menyadari bahwa di bagian lain negara ini salju turun cukup banyak.
Dez Blanchfield: Saya suka itu, saya akan mengingat yang itu.
Eric Kavanagh: Rata -rata satu mil per jam.
Bill Ellis: Kami di sini untuk berbicara tentang manajemen kinerja aplikasi di lingkungan yang kompleks. Satu hal yang saya suka bicarakan adalah, banyak orang, ketika mereka berbicara tentang kinerja, sifat reaksinya adalah, hei lebih banyak server, lebih banyak CPU, lebih banyak memori, dll. Sisi lain dari koin itu adalah efisiensi pemrosesan. Sungguh, itu dua sisi dari koin yang sama dan kita akan melihat keduanya. Tujuan utamanya adalah untuk memenuhi perjanjian tingkat layanan untuk transaksi bisnis. Pada akhirnya semua teknologi ini ada untuk bisnis. Kami berbicara tentang memiliki database manajemen kinerja yang pertama di industri. Cita-cita itu adalah agar sesuai dengan cetakan kinerja yang ideal dan mengelolanya dari awal siklus hidup aplikasi.
Topiknya benar-benar diringkas menjadi empat bagian; satu adalah proses mengelola kinerja. Kami berbicara dengan semua orang, dan semua orang memiliki alat. Jika mereka tidak memiliki alat, mereka memiliki skrip atau perintah, tetapi yang mereka lewatkan adalah konteks. Konteksnya hanyalah menghubungkan titik-titik di seluruh tumpukan aplikasi. Aplikasi ini untuk - berbasis browser. Mereka sangat erat digabungkan dari tingkat ke tingkat. Bagaimana tingkatan berinteraksi juga penting. Kemudian, kita berbicara tentang transaksi bisnis. Kami akan memberikan visibilitas tidak hanya kepada orang-orang teknis, tetapi juga untuk pemilik aplikasi dan manajer operasi.
Saya punya beberapa studi kasus untuk berbagi dengan Anda bagaimana pelanggan menggunakannya. Ini adalah bagian yang sangat praktis dari presentasi di sini. Mari kita lihat apa yang biasanya terjadi. Saya suka diagram - itu seperti kolase teknologi yang luar biasa. Jumlah teknologi di pusat data baru saja tumbuh, dan tumbuh, dan tumbuh. Sementara itu, pengguna akhir tidak peduli tentang hal itu, dan tidak menghiraukannya. Mereka hanya ingin melakukan transaksi, memilikinya tersedia, menyelesaikannya dengan cepat. Apa yang biasanya terjadi adalah, para profesional di bidang TI tidak menyadari bahwa pengguna akhir bahkan memiliki masalah, sampai mereka melaporkan sendiri. Itu mengawali semacam proses yang memakan waktu, lambat, dan sering membuat frustrasi. Apa yang terjadi adalah, orang akan membuka alat mereka, dan mereka melihat sebagian dari tumpukan aplikasi mereka. Dengan subset itu, menjadi sangat sulit untuk menjawab pertanyaan yang paling sederhana. Apakah Anda biasa mengalami masalah? Transaksi apa itu? Di mana dalam tumpukan aplikasi adalah hambatannya? Dengan menghabiskan semua waktu ini, mencari tingkat demi tingkat, tidak mampu menjawab pertanyaan-pertanyaan ini, Anda akhirnya menghabiskan banyak waktu dan energi, banyak staf, dana, dan energi mencari tahu.
Untuk mengatasi ini, untuk memberikan cara yang lebih baik, apa yang Precise lakukan sebenarnya adalah mengambil transaksi pengguna akhir, menangkap metadata tentang hal itu, mengikuti transaksi melalui jaringan, ke server web, ke tingkat logika bisnis dan kami mendukung .NET dan ABAP serta PeopleCode dan E-Business Suite, dalam aplikasi multitier yang pada akhirnya semua transaksi akan berinteraksi dengan sistem catatan. Entah itu pencarian inventaris, waktu pelaporan berfungsi, mereka selalu berinteraksi dengan database. Basis data menjadi fondasi kinerja bisnis. Basis data, pada gilirannya, bergantung pada penyimpanan. Apa metadata tentang transaksi menjawab, siapa, transaksi apa, di mana di tumpukan aplikasi, dan kemudian kami memiliki visibilitas tingkat kode yang mendalam untuk menunjukkan kepada Anda apa yang sedang dieksekusi. Informasi ini ditangkap secara terus menerus, dimasukkan ke dalam database manajemen kinerja - yang menjadi satu lembaran musik untuk semua orang untuk melihat apa yang terjadi. Ada beberapa orang dan organisasi berbeda yang peduli dengan apa yang terjadi: para ahli teknis, pemilik aplikasi, akhirnya bisnis itu sendiri. Ketika masalah keluar, Anda ingin dapat mengekstraksi informasi tentang transaksi itu.
Sebelum kita melihat transaksi investasi, saya ingin menunjukkan kepada Anda bagaimana hal itu terlihat oleh orang-orang yang berbeda dalam organisasi. Pada tingkat manajemen, Anda mungkin ingin memiliki gambaran umum beberapa aplikasi. Anda mungkin ingin tahu tentang kesehatan yang dihitung oleh kepatuhan dan ketersediaan SLA. Kesehatan itu tidak berarti semuanya 100 persen bekerja dengan sempurna. Ada ruang dalam hal ini Anda dapat melihat transaksi investasi dalam status peringatan. Sekarang, sedikit lebih dalam, mungkin di lini bisnis, Anda ingin memiliki detail tambahan tentang transaksi individu, ketika mereka melanggar SLA, jumlah transaksi, dll. Tim operasi ingin diberitahu tentang hal itu melalui peringatan dari beberapa menyortir. Kami memiliki lansiran kinerja. Kami sebenarnya mengukur kinerja di peramban pengguna akhir. Apakah itu Internet Explorer, Chrome, Firefox, dll., Kami dapat mendeteksi, ini menjawab pertanyaan pertama: apakah pengguna akhir mengalami masalah?
Mari selami dan lihat apa lagi yang bisa kita tunjukkan tentang itu. Orang-orang yang tertarik dengan kinerja akan membuka Precise. Mereka akan mengevaluasi transaksi. Mereka akan melihat kolom SLA untuk mengidentifikasi transaksi yang tidak sesuai dengan SLA. Mereka akan dapat melihat pengguna akhir yang terkena dampak serta apa yang dilakukan transaksi saat mengalir di aplikasi. Cara Anda menguraikan hieroglif ini, ini adalah browser, URL, U adalah untuk URL, itulah titik masuk ke dalam JVM. Sekarang JVM khusus ini membuat panggilan server web ke JVM kedua yang kemudian mengeksekusi pernyataan SQL. Ini jelas merupakan masalah database karena pernyataan SQL ini bertanggung jawab atas 72 persen waktu respons. Kami fokus pada waktu. Waktu adalah mata uang kinerja. Begitulah pengalaman pengguna akhir apakah segalanya berjalan lambat atau tidak, dan ini merupakan ukuran konsumsi sumber daya. Ini sangat berguna; itu semacam metrik tunggal yang paling penting untuk mengevaluasi kinerja. Ketika masalah ini diserahkan ke DBA, itu bukan hanya masalah database, ini pernyataan SQL ini. Ini adalah konteks yang saya bicarakan.
Sekarang dengan informasi ini, saya dapat masuk dan menganalisis apa yang terjadi. Saya bisa melihat pertama-tama, sumbu y adalah waktu sepanjang hari. Maaf, sumbu y adalah waktu respons, sumbu x adalah waktu sepanjang hari. Saya bisa melihat ada masalah database, ada dua kejadian, kembali ke aliran itu, mengambil pernyataan SQL dan masuk ke tampilan ahli, di mana Precise dapat menunjukkan kepada Anda apa yang terjadi, kontrolnya, berapa lama kode itu diperlukan untuk menjalankan. Di tingkat basis data, ini adalah rencana pelaksanaannya. Anda akan perhatikan bahwa Precise memilih rencana eksekusi nyata yang digunakan pada waktu eksekusi, yang dibedakan dari perkiraan rencana, yang akan terjadi ketika rencana diberikan dan bukan selama waktu eksekusi. Ini mungkin atau mungkin tidak mencerminkan bahwa database benar-benar melakukannya.
Sekarang di sini, adalah analisis waktu respons untuk pernyataan SQL. Sembilan puluh persen dari waktu yang dihabiskan dalam penyimpanan; sepuluh persen digunakan dalam CPU. Saya bisa melihat teks pernyataan SQL serta laporan temuan. Teks pernyataan SQL sebenarnya mulai mengungkapkan beberapa masalah pengkodean. Itu adalah pilih bintang; yang mengembalikan semua baris - permisi, semua kolom dari baris yang dikembalikan. Kami memutar kembali kolom tambahan yang mungkin diperlukan aplikasi atau tidak. Kolom-kolom itu menghabiskan ruang dan sumber daya untuk diproses. Jika Anda menjalankan SAP, salah satu perubahan besar, karena database HANA adalah berbentuk kolom, adalah bahwa pada dasarnya menulis ulang SAP untuk tidak memilih pilih bintang sehingga mereka dapat sangat mengurangi konsumsi sumber daya. Ini pada dasarnya adalah sesuatu yang terjadi banyak waktu juga dalam aplikasi homegrown, apakah Java, .NET, dll.
Layar itu, ini menunjukkan siapa, apa, kapan, di mana, dan mengapa. Mengapa sampai, seperti pernyataan SQL dan rencana eksekusi yang memungkinkan Anda untuk menyelesaikan masalah. Karena Precise berjalan terus-menerus, Anda benar-benar dapat mengukur sebelum dan sesudah, pada tingkat pernyataan SQL, pada tingkat transaksi, sehingga Anda dapat mengukur sendiri, serta melalui pemilik aplikasi dan manajemen, bahwa Anda telah memecahkan masalah . Dokumentasi itu sangat membantu. Ada banyak kerumitan dalam tumpukan aplikasi ini. Dari banyak aplikasi, pada kenyataannya, semua orang yang kami ajak bicara, menjalankan setidaknya sebagian dari tumpukan aplikasi di bawah VMware. Dalam hal ini, mereka melihat aplikasi layanan pelanggan, mereka melihat waktu transaksi, dan menghubungkannya dengan perlambatan adalah peristiwa virtualisasi. Jejak yang tepat semua peristiwa virtualisasi. Kami memiliki plug-in ke vCenter untuk mengambilnya.
Kami juga dapat mendeteksi pertikaian. Kontensi berbeda dari pemanfaatan. Sebenarnya menunjukkan ketika mungkin tetangga berisik memengaruhi VM tamu Anda, dalam konteks aplikasi server pelanggan. Sekarang, saya dapat menelusuri dan mendapatkan informasi dan saya benar-benar dapat melihat dua VM yang bersaing, dalam hal ini, untuk sumber daya CPU. Ini memungkinkan saya untuk memiliki visibilitas sehingga saya bisa melihat penjadwalan. Saya dapat meletakkan VM tamu di server fisik yang berbeda. Semua jenis hal yang mungkin Anda respons dan kemudian, di samping itu, saya benar-benar dapat melihat efisiensi kode untuk mungkin menggunakan lebih sedikit CPU. Saya pikir saya punya contoh yang cukup bagus dalam presentasi ini tentang bagaimana seseorang dapat mengurangi konsumsi CPU dengan pesanan besar.
Itu adalah VMware. Mari kita masuk ke kode itu sendiri, kode aplikasi. Precise akan dapat menunjukkan kepada Anda apa yang terjadi di dalam Java, .NET, kode ABAP, E-Business, PeopleCode, dll. Ini adalah titik masuk ke, dalam hal ini, ke dalam WebLogic. Di sini, ada laporan temuan yang memberi tahu saya bahwa ini adalah EJB yang perlu Anda lihat, dan akan memberi tahu saya bahwa Anda juga mengalami penguncian pada sistem ini. Sekali lagi, telusuri dalam tingkat logika bisnis, untuk menunjukkan apa yang terjadi. Dalam hal ini, saya melihat contoh tertentu; Saya juga mendukung pengelompokan. Jika Anda memiliki banyak JVM yang sedang berjalan, Anda bisa melihat cluster secara keseluruhan, atau melihat kemacetan dalam JVM individu.
Saat Anda mengunci, saya bisa masuk ke pengecualian. Pengecualian sedikit berbeda dari masalah kinerja. Biasanya, pengecualian berjalan sangat cepat. Karena ada kesalahan logika dan sekali Anda menekan kesalahan logika itu, itu berakhir. Kami dapat menangkap jejak tumpukan di puncak pengecualian, ini bisa menghemat banyak waktu karena sedang mencoba mencari tahu apa yang terjadi, Anda hanya memiliki jejak tumpukan, di sana. Kami juga dapat menangkap kebocoran memori juga. Solusinya juga termasuk tingkat database, saya bisa masuk, saya bisa mengevaluasi contoh database. Sekali lagi, sumbu y adalah waktu yang dihabiskan, sumbu x adalah waktu sepanjang hari. Ada laporan temuan yang secara otomatis memberi tahu saya apa yang terjadi dalam sistem dan apa yang mungkin saya lihat.
Salah satu hal tentang laporan temuan Precise, tidak hanya melihat log atau menunggu negara - itu melihat semua kondisi eksekusi termasuk CPU, serta mengembalikan informasi dari penyimpanan. Penyimpanan adalah bagian yang sangat penting dari tumpukan aplikasi, terutama dengan munculnya solid state. Memiliki informasi seperti itu dapat sangat membantu. Untuk unit penyimpanan tertentu, kami benar-benar dapat menelusuri dan menunjukkan apa yang terjadi di tingkat perangkat individu. Jenis informasi itu - sekali lagi, visibilitasnya dalam; cakupannya luas - untuk memberi Anda informasi yang cukup agar memiliki daya ungkit yang lebih besar untuk menarik sebagai profesional kinerja aplikasi, sehingga Anda dapat mengoptimalkan aplikasi Anda secara end-to-end untuk memenuhi transaksi bisnis tersebut.
Saya punya beberapa studi kasus yang ingin saya bagikan dengan Anda. Kami berlayar cukup cepat; Saya harap saya berjalan dengan baik. Berbicara tentang penyimpanan, setiap orang dari waktu ke waktu mengubah perangkat keras. Ada garansi perangkat keras. Apakah itu benar-benar memberikan apa yang dikatakan vendor kepada Anda? Anda dapat mengevaluasi itu dengan Precise. Anda masuk, dan apa yang terjadi di sini, mereka pada dasarnya menempatkan unit penyimpanan baru, tetapi ketika administrator penyimpanan hanya melihat pada tingkat unit penyimpanan, mereka melihat banyak pertikaian dan mereka berpikir mungkin ada masalah dengan unit penyimpanan baru ini. . Melihat lebih banyak dari perspektif ujung ke ujung, tepatnya untuk menunjukkan di mana itu akan terjadi. Mereka benar-benar beralih dari throughput sekitar 400 mcg per detik, di mana penyimpanan bertanggung jawab atas 38 persen waktu respons, jadi ini cukup tinggi. Dengan unit penyimpanan baru kami benar-benar meningkatkan throughput menjadi enam, tujuh ratus mcg per detik, jadi pada dasarnya dua kali lipat, dan kami dapat memotong kontribusi tingkat penyimpanan hingga waktu transaksi menjadi setengahnya. Saya benar-benar dapat menggambarkan itu sebelumnya, ini adalah periode cutover, dan kemudian setelahnya.
Jadi sekali lagi, dokumentasi untuk membuktikan bahwa investasi perangkat keras sepadan dan mereka mengirimkannya sesuai harapan vendor tertentu. Ada semuanya, karena kerumitan, jumlah hal, ada segala macam hal yang bisa terjadi. Dalam hal ini, mereka benar-benar memiliki situasi di mana semua orang menyalahkan DBA, DBA seperti "Ya, tidak terlalu cepat." Di sini kita benar-benar melihat aplikasi SAP, saya pikir jenis skenario ini cukup umum . Apa yang terjadi adalah, mereka mengembangkan transaksi khusus untuk pengguna. Pengguna seperti, "Ini sangat lambat." ABAP coder - itu bahasa pemrograman dalam SAP - berkata, "Ini adalah masalah database." Mereka akhirnya membuka Precise; mereka mengukur pengguna akhir itu 60 detik, jadi lebih dari satu menit. Lima puluh tiga detik dihabiskan di bagian belakang. Mereka mengebor bagian belakang dan mereka benar-benar dapat mengungkapkan pernyataan SQL yang disajikan dalam urutan menurun.
Pernyataan SQL teratas ini yang bertanggung jawab atas 25 persen dari konsumsi sumber daya, waktu eksekusi rata-rata adalah dua milidetik. Anda tidak bisa menyalahkan basis data. Anda tahu, hei, tidak secepat itu, teman. Pertanyaannya adalah, mengapa ada begitu banyak eksekusi? Nah, mereka memantulkannya kembali ke ABAP, dia masuk, melihat ke dalam sarang, menemukan bahwa mereka memanggil database di tempat yang salah, mereka pada dasarnya membuat perubahan, menguji perubahan dan sekarang waktu respon baru adalah lima detik. Sedikit lambat, tetapi mereka bisa hidup dengan itu. Jauh lebih baik dari 60 detik. Kadang-kadang, hanya mencari tahu, apakah itu kode aplikasi, apakah itu database, apakah ini penyimpanan? Itulah area di mana Precise, dengan memiliki konteks transaksi end-to-end, di situlah Precise berperan. Anda pada dasarnya mengakhiri hal-hal itu.
Saya melihat pada saat itu, sepertinya kita masih punya sedikit waktu untuk membahas beberapa hal lagi. Saya streaming melalui ini. Aplikasi ini sedang dikembangkan selama lebih dari setahun. Ketika mereka masuk ke QA, mereka melihat bahwa server web di-maxed 100 persen dan sepertinya aplikasi tidak bisa berjalan di bawah VMware. Hal pertama yang dikatakan semua orang adalah, “Pakai ini secara fisik; itu tidak dapat berjalan di bawah VMware. ”Precise benar-benar menawarkan mereka cara-cara tambahan untuk menyelesaikan masalah. Kami melihat transaksi, kami melihat panggilan server web, itu datang sebagai ASMX di IIS.NET. Itu benar-benar mengungkapkan kode yang mendasarinya. Anda melihat ini di mana saya menunjuk? Ini 23 hari, 11 jam. Wow, bagaimana mungkin? Yah setiap doa membutuhkan 9, 4 detik dan hal ini dipanggil 215.000 kali. Untuk setiap doa, ia menggunakan CPU 6 detik. Inilah alasannya, kode ini adalah alasan mengapa benda ini tidak pernah bisa diukur. Faktanya, itu tidak bisa diukur secara fisik.
Apa yang mereka lakukan, adalah mereka kembali ke pengembang mereka dan mereka berkata, "Bisakah seseorang membuat perubahan?" Mereka semacam mengadakan kontes, dan mereka menguji saran yang berbeda dan mereka datang dengan saran yang dapat menjalankan banyak lebih efisien. Yang baru menyelesaikan satu poin, sedikit kurang dari dua detik, dengan dua per seratus detik dalam CPU. Sekarang ini bisa skala dan bisa berjalan di pertanian VMware. Kami pada dasarnya dapat mendokumentasikan hal itu baik pada level kode maupun level transaksi. Ini semacam sebelumnya, dan kemudian sesudahnya. Sekarang Anda dapat melihat di sini di grafik batang stack yang menunjukkan web, .NET, dan basis data, sekarang Anda berinteraksi dengan basis data. Ini adalah profil yang Anda harapkan untuk aplikasi yang berjalan lebih normal.
Baiklah, saya memilih dan memilih dalam hal hal-hal tambahan yang dapat saya perlihatkan kepada Anda. Banyak orang seperti ini karena ini banyak toko yang berbeda. Jika Anda tidak dapat memenuhi SLA bisnis, dan semua orang seperti, "Bantu kami." Toko ini memiliki situasi di mana bisnis SLA dalam pesanan diterima pada jam 3 sore, dikirim pada hari itu. Sangat penting bahwa mereka mendapatkan pesanan, dan gudang sangat sibuk. Layar pesanan penjualan JD Edwards ini, membeku dan Anda bisa mendapatkan ide yang sangat bagus bahwa ini adalah sistem manajemen persediaan ritel tepat waktu. Rak kosong tidak dapat diterima di ritel. Harus punya barang dagangan di sana untuk menjualnya. Apa yang kami lakukan adalah kami menyelam, dalam hal ini, kami sedang melihat database SQL server. Tampilan dan nuansa adalah sama apakah itu SQL, Oracle, DB2 atau Sybase.
Kami mengidentifikasi pilih dari PS_PROD dan kami dapat menangkap durasi, fakta bahwa mereka mengeksekusi begitu banyak. Biru tua cocok dengan kunci yang mengatakan mereka tidak menunggu pada keadaan tunggu atau penebangan atau penyimpanan - hal ini terikat oleh CPU. Kami melacak pernyataan SQL pada 34301 sehingga setiap kali ini dieksekusi, kami menambah penghitung kami untuk melacaknya. Itu berarti bahwa kami memiliki riwayat terperinci dan saya dapat mengaksesnya dengan mengklik tombol tune itu. Inilah tab histori. Layar ini di sini menunjukkan durasi rata-rata versus perubahan. Rabu, Kamis, Jumat, durasi rata-rata sekitar dua persepuluh detik. Sangat sedikit layar membeku, mereka dapat memenuhi SLA bisnis. Datang tanggal 27 Februari, sesuatu berubah dan tiba-tiba, waktu eksekusi di sini, dan itu sebenarnya cukup lambat untuk menyebabkan waktu habis, yang mengakibatkan layar membeku. Precise, dengan menyimpan riwayat terperinci, termasuk rencana eksekusi dan perubahan umum pada indeks tabel jika SQL tersebut digunakan. Kami dapat mengetahui bahwa rencana akses berubah pada tanggal 27 Februari. Senin sampai minggu buruk Jumat. Datang 5 Maret, rencana akses berubah lagi. Ini minggu yang baik. Bintang merah muda ini memberi tahu kami volume yang diperbarui.
Anda dapat melihat di sini jumlah baris dalam tabel yang mendasarinya bertambah dan ini tipikal untuk bisnis. Anda ingin meja Anda tumbuh. Masalahnya adalah bahwa pernyataan diuraikan, pernyataan SQL masuk, pengoptimal harus memutuskan apa yang harus dilakukan dan memilih ketika rencana eksekusi cepat, memilih rencana eksekusi lain ketika lambat, menyebabkan layar membeku. Atas dasar teknologi yang mendalam, saya perlu tahu apa rencana pelaksanaannya dan Precise menangkapnya untuk saya lengkap dengan cap tanggal dan waktu. Ini adalah yang cepat dan efisien, ini lambat dan tidak efisien. Bergabung dengan filter ini hanya menggunakan lebih banyak CPU untuk melakukan rekonsiliasi, untuk melakukan pernyataan SQL khusus ini. Mereka masih memiliki efek pamungkas yang sama, tetapi yang satu ini pada dasarnya memiliki resep yang lebih lambat dan kurang efisien untuk menghasilkan rangkaian hasil. Jadi, kami melangkah. Hei, kita punya waktu untuk pasangan lagi?
Eric Kavanagh: Ya, lakukanlah.
Bill Ellis: Oke, saya akan lanjutkan. Satu hal yang saya ingin Anda perhatikan, kami berbicara tentang perangkat keras, berbicara tentang SAP, kami berbicara tentang .NET, kami berbicara tentang JD Edwards dan lingkungan Java-SQL Server. Ini SAP, di sini kita melihat PeopleSoft. Matriks dukungan Precise luas dan dalam. Jika Anda memiliki aplikasi, lebih dari kemungkinan, kami dapat menggunakannya untuk memberikan tingkat visibilitas ini. Salah satu perubahan terbesar yang terjadi saat ini adalah mobilitas. PeopleSoft memperkenalkan mobilitas dengan UI Fluid-nya. UI Fluid menggunakan sistem yang sangat berbeda. Aplikasi ini berkembang. Fluid UI - apa yang dilakukan dari perspektif manajemen adalah memungkinkan pengguna akhir untuk menggunakan telepon mereka dan itu sangat meningkatkan produktivitas. Jika Anda memiliki ratusan atau ribuan atau bahkan lebih banyak karyawan, jika Anda dapat meningkatkan produktivitas mereka, 1-2 persen, Anda dapat memiliki dampak besar pada penggajian dan yang lainnya. Apa yang terjadi adalah, toko khusus ini meluncurkan PeopleSoft Fluid UI. Sekarang, berbicara tentang kompleksitas, ini adalah tumpukan PeopleSoft. Satu aplikasi, minimal enam teknologi, banyak pengguna akhir. Bagaimana Anda memulainya?
Sekali lagi Precise akan dapat mengikuti transaksi ini. Apa yang kami tunjukkan di sini adalah grafik batang bertumpuk yang menunjukkan klien, server web, Java, basis data Tuxedo, tumpukan aplikasi PeopleSoft. Peta hijau ke J2EE, yang merupakan semacam cara mewah untuk mengatakan WebLogic. Ini adalah cutover. Pengguna akhir mulai menggunakan Fluid UI dan waktu respons berlangsung dari mungkin satu setengah, dua detik, hingga sekitar sembilan, sepuluh detik. Apa yang satu layar ini tidak perlihatkan adalah jumlah orang yang “tidak menanggapi.” Mereka benar-benar mendapat layar dibekukan dalam aplikasi. Mari kita lihat beberapa visibilitas yang Precise mampu berikan kepada pelanggan ini.
Pertama-tama, ketika saya melihat transaksi PeopleSoft, mereka pada dasarnya dapat melihat, kami melihat hal seperti ini di seluruh papan. Semua transaksi terkena dampak, serta semua lokasi. Kebetulan, ketika Anda melihat ini, Anda sebenarnya dapat melihat lokasi di seluruh dunia. Dari Asia Pasifik, ke Eropa serta Amerika Utara. Masalah kinerja tidak terletak pada transaksi tertentu, atau lokasi geografis tertentu, sistemnya luas. Ini semacam cara untuk mengatakan bahwa perubahan atau cara Fluid UI berdampak global. Anda dapat melihat di sini dari sudut pandang skalabilitas, orang-orang mencoba untuk melakukan jenis aktivitas yang sama, tetapi waktu respon pada dasarnya hanya terdegradasi dan terdegradasi. Anda dapat melihat bahwa berbagai hal tidak scaling. Semuanya berjalan sangat, sangat buruk. Di sini, ketika saya melihat jumlah sumbu dan koneksi bersamaan, Anda melihat sesuatu yang sangat menarik dalam hal jumlah akses dan koneksi. Di sini kami hanya meningkatkan hingga sekitar 5.000 dan Anda sedang melihat sekitar, ini teratas di 100 koneksi bersamaan. Ini dilakukan setelah; ini sebelumnya. Jadi apa permintaan saya yang sebenarnya pada sistem, jika hal ini dapat ditingkatkan, berada dalam kisaran 300.000. Di masa lalu, dengan UI klasik, Anda melihat 30 koneksi bersamaan.
Sekarang yang ingin Anda ketahui adalah bahwa Fluid UI menggunakan setidaknya 10x jumlah koneksi konkuren. Kami mulai menarik kembali apa yang terjadi di bawah penutup dengan PeopleSoft sehingga Anda dapat mulai melihat dampaknya pada server web, fakta bahwa SLA mulai melanggar. Tidak akan membahas segalanya, tetapi yang akhirnya terjadi adalah mereka pada dasarnya mengandalkan pesan. Mereka pada dasarnya berolahraga adalah WebLogic dan menyebabkan antrian di dalam Tuxedo. Sebenarnya ada masalah ketergantungan multitier yang muncul dengan Fluid UI, tetapi Precise mampu menunjukkan bahwa dengan sejumlah hal yang berbeda, bahwa kita dapat fokus pada apa masalahnya. Ternyata ada juga masalah dalam database itu sendiri. Sebenarnya ada file log perpesanan, dan karena semua pengguna secara bersamaan, file log itu terkunci. Pada dasarnya ada hal-hal untuk disetel, di setiap tingkatan dalam tumpukan aplikasi. Bicara tentang kompleksitas, inilah sebenarnya tier Tuxedo yang menunjukkan kepada Anda antrian dan Anda dapat melihat kinerja menurun dalam tier ini juga. Saya bisa melihat prosesnya; Saya bisa melihat domain dan server. Di Tuxedo, agar orang dapat menggunakannya, biasanya yang Anda lakukan adalah membuka antrian, domain, dan server tambahan, seperti di supermarket untuk mengurangi kemacetan, untuk meminimalkan waktu antrian. Opsi terakhir dan terakhir, Precise menunjukkan banyak informasi.
Seperti yang saya sebutkan sebelumnya, setiap transaksi yang signifikan berinteraksi dengan sistem catatan. Visibilitas ke dalam basis data adalah yang terpenting. Precise menunjukkan apa yang terjadi di dalam basis data, di dalam WebLogic, di dalam Java, .NET, di dalam peramban, tetapi tempat yang Precise benar-benar unggul ada di tingkat basis data. Ini adalah kelemahan dari pesaing kami. Biarkan saya menunjukkan kepada Anda salah satu cara yang Precise dapat membantu Anda melewati ini. Saya tidak akan menghabiskan waktu pada segitiga pengoptimalan basis data, tetapi pada dasarnya kami mencari perubahan berbiaya rendah, berisiko rendah, hingga cakupan luas, berisiko tinggi, dan berbiaya tinggi. Saya sebenarnya akan tweet slide ini setelah itu jika orang ingin mencoba dan melihatnya. Ini panduan yang cukup besar, saya pikir, untuk masalah penyetelan. Inilah tampilan pakar Precise untuk Oracle. Atas laporan temuan, dampak 60 persen adalah pernyataan SQL khusus ini. Jika Anda membuka layar aktivitas ini, ini menunjukkannya di sana. Saya bisa melihat pernyataan pilih ini, ada satu rencana eksekusi. Setiap eksekusi membutuhkan sedetik - 48.000 eksekusi. Itu menambah lebih dari 48.000 jam eksekusi.
Biru tua, sekali lagi, adalah CPU. Hal ini terikat CPU, bukan keadaan tunggu, bukan log. Saya menekankan bahwa karena beberapa pesaing kami hanya melihat status tunggu dan acara logging tetapi secara umum, CPU adalah kondisi eksekusi tersibuk dan menawarkan paling banyak pembelian kembali. Masuk ke pandangan ahli ini - dan saya akan sangat cepat - apa yang saya lakukan adalah saya melihat ke meja, 100.000 baris, 37.000 blok. Kami melakukan tabel penuh, namun kami memiliki enam indeks untuk hal ini. Apa yang terjadi di sini? Nah, ketika saya melihat di mana klausa, apa yang dilakukan klausa ini adalah sebenarnya mengubah kolom menjadi huruf besar dan mengatakan di mana itu sama dengan huruf besar, cari variabel. Apa yang terjadi adalah setiap kali hal ini dieksekusi, Oracle harus mengubah kolom ini menjadi huruf besar. Daripada melakukan hampir lima puluh ribu kali, itu jauh lebih efisien untuk membangun indeks itu dalam huruf besar dari indeks berbasis fungsi dan tersedia tidak hanya di divisi perusahaan Oracle, juga divisi standar. Ketika Anda melakukan itu, apa yang dapat Anda lakukan adalah memverifikasi rencana eksekusi mengeluarkan pengguna indeks perm huruf besar baru, itu hanya semacam hal saya.
Kemudian, dari pengukuran sebelum dan sesudah, Anda melihat waktu eksekusi satu detik, agregat hingga 9 jam 54 menit, dengan pernyataan SQL yang persis sama, tetapi memiliki indeks yang dibangun dalam huruf besar untuk 58.000 eksekusi, jawabannya waktu turun menjadi sub-milidetik, agregat bersama, waktu hingga tujuh detik. Saya pada dasarnya menghemat sepuluh jam CPU di server saya. Ini sangat besar. Karena jika saya bukan karena penyegaran server, saya dapat tinggal di server itu. Saya benar-benar menjatuhkan penggunaan server sebesar 20 persen dan Anda benar-benar dapat melihat sebelum dan sesudahnya. Itulah jenis visibilitas yang dapat diberikan Precise. Ada juga beberapa hal tambahan yang mungkin kita lihat, mengapa Anda memiliki semua indeks ini jika tidak digunakan? Mereka bisa menindaklanjutinya. Ada arsitektur, dan saya akan menyelesaikannya, karena kita sudah mencapai puncaknya. Saya seorang yang benar-benar percaya pada solusi ini dan kami ingin Anda menjadi orang yang benar-benar percaya. Di IDERA kami percaya bahwa percobaan membuat pelanggan, jadi jika Anda tertarik, kami dapat melakukan evaluasi di situs Anda.
Dengan itu, saya akan melewati suar kembali.
Eric Kavanagh: Ya ini detail luar biasa yang Anda perlihatkan di sana. Benar-benar sangat menarik. Saya pikir saya mungkin telah menyebutkan kepada Anda di masa lalu bahwa - dan saya tahu di beberapa webcast lain yang telah kami lakukan dengan IDERA, saya telah menyebutkan bahwa - Saya sebenarnya telah melacak Precise sejak sebelum diakuisisi oleh IDERA, sepanjang jalan kembali ke 2008, saya pikir, atau 2009. Saya terpesona olehnya saat itu. Saya ingin tahu berapa banyak pekerjaan yang harus dilakukan untuk tetap di atas rilis aplikasi baru. Anda menyebutkan bahwa SAP HANA, yang saya pikir cukup mengesankan sehingga Anda benar-benar dapat menggali arsitektur HANA dan melakukan pemecahan masalah di sana. Berapa banyak orang yang kamu miliki? Seberapa besar upaya yang Anda lakukan dan seberapa banyak yang dapat dilakukan secara dinamis, artinya ketika alat tersebut digunakan, Anda mulai merangkak dan melihat berbagai hal? Berapa banyak dari itu dapat secara dinamis, semacam, dipastikan oleh alat, sehingga Anda dapat membantu orang memecahkan masalah lingkungan yang kompleks?
Bill Ellis: Anda mengajukan banyak pertanyaan di sana.
Eric Kavanagh: Saya tahu, maaf.
Bill Ellis: Saya memang memberikan banyak detail karena untuk aplikasi ini, melihat kode, iblis ada di detail. Anda harus memiliki tingkat detail untuk benar-benar dapat memiliki sesuatu yang dapat ditindaklanjuti. Tanpa metrik yang dapat ditindaklanjuti, Anda hanya tahu tentang gejala. Anda sebenarnya tidak memecahkan masalah. IDERA adalah tentang menyelesaikan masalah. Tetap di atas rilis baru dan hal-hal adalah tantangan besar. Pertanyaan tentang apa yang diperlukan untuk melakukan itu, itu benar-benar untuk manajemen produk. Saya tidak memiliki banyak visibilitas ke dalam tim yang pada dasarnya membuat kami selalu terbarui. Dalam hal HANA, itu sebenarnya merupakan tambahan baru untuk lini produk IDERA; ini sangat menarik. Salah satu hal dengan HANA adalah - izinkan saya berbicara tentang tugas ini sebentar. Dalam tugasnya, toko SAP akan lakukan adalah mereka akan mereplikasi database untuk tujuan pelaporan. Maka Anda harus membuat orang berdamai dengan apa yang sebenarnya saat ini. Anda akan memiliki database yang berbeda ini dan mereka tidak akan sinkron dengan level yang berbeda. Hanya ada banyak waktu dan usaha, ditambah perangkat keras, perangkat lunak, dan orang-orang untuk mempertahankan semua itu.
Gagasan HANA untuk memiliki basis data dalam memori yang sangat paralel, pada dasarnya menghindari kebutuhan akan duplikat basis data. Kami memiliki satu basis data, satu sumber kebenaran, selalu terkini, dengan begitu Anda menghindari yang diperlukan untuk melakukan semua rekonsiliasi itu. Pentingnya kinerja database HANA naik - saya akan mengatakan 10x atau setidaknya lebih berharga daripada jumlah semua database lain, perangkat keras, sumber daya yang dapat dibeli. Mampu mengelola HANA, sekarang komponen itu sebenarnya dalam pengujian beta sekarang, itu adalah sesuatu yang akan segera GA. Jadi itu cukup menarik untuk IDERA dan bagi kami untuk pada dasarnya mendukung platform SAP. Saya tidak yakin apa bagian lain dari pertanyaan Anda yang saya agak pendek tapi -
Eric Kavanagh: Tidak, itu bagus di sana. Saya melemparkan sejumlah besar pada Anda sekaligus, sangat menyesal tentang itu. Saya hanya terpesona, sungguh, maksud saya ini bukan aplikasi yang sangat sederhana, bukan? Anda menggali jauh ke dalam alat-alat ini dan memahami bagaimana mereka berinteraksi satu sama lain dan sampai pada titik Anda, Anda harus menyatukan cerita di kepala Anda. Anda harus menggabungkan bit informasi untuk memahami apa yang sebenarnya terjadi dan apa yang menyebabkan Anda kesulitan, sehingga Anda bisa masuk ke sana dan menyelesaikan masalah tersebut.
Seorang peserta bertanya, seberapa sulit menerapkan Precise? Orang lain bertanya, siapa orang-orang - jelas DBA - tetapi siapa saja peran lain dalam organisasi yang akan menggunakan alat ini?
Bill Ellis: Precise sedikit lebih rumit untuk digunakan. Anda harus memiliki pengetahuan tentang lingkungan aplikasi, dalam hal, Anda tahu, aplikasi ini berjalan pada database ini, perlu atau - server web tingkat menengah, dll. Saya pikir mengingat kompleksitas beberapa aplikasi ini, sebenarnya relatif mudah. Jika saya dapat memasukkan server web ke basis data Anda, saya dapat melakukannya dari ujung ke ujung. Anda perhatikan bahwa saya tidak mengatakan apa-apa tentang menginstruksikan klien pengguna akhir dan itu karena apa yang kami lakukan adalah, kami benar-benar memasukkan secara dinamis, jadi Anda tidak perlu mengubah kode Anda atau apa pun. JavaScript masuk ke bingkai halaman aplikasi. Tidak masalah di mana pengguna berada di dunia, ketika mereka mengakses URL dari aplikasi Anda dan mereka menurunkan halaman itu, ia datang dengan instrumen Precise. Itu memungkinkan kita untuk memilih ID pengguna, alamat IP mereka, juga waktu rendering byte pertama dari setiap waktu eksekusi skrip komponen komponen dalam browser pengguna akhir.
Dalam hal transaksi, Anda tidak perlu memetakan transaksi karena mereka sangat erat. URL ini menjadi titik masuk ke JVM dan kemudian memohon pesan ini, menghasilkan JVC yang ditangkap dari database. Kami pada dasarnya dapat menangkap titik-titik koneksi alami dan kemudian menyajikannya kepada Anda di layar transaksi yang saya tunjukkan di mana kami juga menghitung berapa banyak waktu, atau persentase waktu yang dihabiskan di setiap langkah individu. Semua itu dilakukan secara otomatis. Secara umum, kami mengalokasikan 90 menit untuk melakukan - untuk dasarnya menginstal inti Precise dan kemudian kami mulai mengimplementasikan aplikasi. Bergantung pada pengetahuan aplikasi, mungkin diperlukan beberapa sesi tambahan untuk membuat seluruh aplikasi diinstrumentasi. Banyak orang hanya menggunakan komponen database Precise. Tidak apa-apa. Anda pada dasarnya dapat memecah ini, memecahnya menjadi komponen yang Anda merasa perlu situs Anda. Kami benar-benar percaya bahwa konteks agar seluruh tumpukan aplikasi diinstrumentasi sehingga Anda dapat melihat bahwa ketergantungan tier-ke-tier sebenarnya memperbesar nilai pemantauan tier individual. Jika ada yang ingin menjelajahi petunjuk tumpukan aplikasi mereka lebih lanjut, silakan kunjungi situs web kami - saya kira itu cara termudah untuk meminta informasi tambahan, dan kami akan membahasnya sedikit lebih jauh.
Eric Kavanagh: Biarkan saya mengajukan satu atau dua pertanyaan cepat kepada Anda. Saya menduga bahwa Anda mengumpulkan dan membangun repositori dari waktu ke waktu, baik untuk klien individu dan sebagai entitas korporasi secara keseluruhan, interaksi antara berbagai aplikasi dan berbagai database. Dengan kata lain, pemodelan skenario, saya kira, adalah apa yang saya singgung. Apakah itu masalahnya? Apakah Anda benar-benar memelihara semacam repositori skenario umum sehingga Anda dapat membuat saran kepada pengguna akhir ketika hal-hal tertentu ikut bermain? Seperti versi E-Business Suite ini, versi database ini, dll. - apakah Anda banyak melakukan itu?
Bill Ellis: Ya, jenis informasi itu dimasukkan ke dalam laporan temuan. Laporan temuan mengatakan apa hambatan kinerja, dan didasarkan pada waktu pelaksanaan. Bagian dari laporan temuan itu adalah belajar lebih banyak dan apa yang Anda lakukan selanjutnya. Informasi atau pengalaman dari pelanggan dan sebagainya pada dasarnya dimasukkan ke dalam perpustakaan rekomendasi tersebut.
Eric Kavanagh: Oke, kedengarannya bagus. Wah, presentasi hebat hari ini. Bill, aku suka betapa detailnya di sana. Saya hanya berpikir ini benar-benar fantastis, berpasir, informasi granular, menunjukkan bagaimana semua ini dilakukan. Pada titik tertentu itu hampir seperti ilmu hitam, tetapi sebenarnya tidak. Ini teknologi yang sangat spesifik yang kalian kumpulkan untuk memahami lingkungan yang sangat, sangat kompleks, dan membuat orang senang karena tidak ada yang suka ketika aplikasi berjalan lambat.
Baiklah teman-teman, kami akan mengarsipkan webcast ini. Anda dapat naik online ke Techopedia atau insideanalysis.com dan wow, terima kasih atas waktu Anda, kami akan mengejar Anda lain kali. Jaga dirimu, selamat tinggal.
