Oleh Staf Techopedia, 31 Agustus 2016
Takeaway: Host Rebecca Jozwiak membahas pemecahan masalah database dan masalah efisiensi dengan analis Eric Kavanagh dan Dez Blanchfield serta Bill Ellis dari IDERA.
Anda saat ini belum masuk. Silakan masuk atau daftar untuk melihat video.
Rebecca Jozwiak: Hadirin sekalian, halo, dan selamat datang di Hot Technologies 2016. Topik hari ini, "Aplikasi Berjalan Perlahan? Waktunya untuk Mendapatkan Yang Tepat." Dan bukankah kita semua tahu betul masalah yang bisa terjadi ketika barang berjalan lambat? Ini adalah Rebecca Jozwiak, saya mengisi untuk Eric yang semacam melakukan peran baru di sini, hari ini. Ya, tahun ini panas dan, Anda tahu, ketika datang ke teknologi, seperti yang saya katakan, satu hal yang Anda benar-benar tidak inginkan adalah apa pun yang berjalan lambat, bagian mana pun dari sistem Anda. Dan hanya untuk menggunakan contoh konsumen, maksud saya jika Anda memiliki restoran, tidak masalah seberapa bagus makanannya, jika layanannya lambat, Anda mungkin tidak akan kembali lagi. Sekarang, mudah, agak, di sebuah restoran untuk mencari tahu mengapa sesuatu berjalan lambat. Mungkin dapurnya pendek atau ada kerusakan dengan beberapa peralatan, atau mungkin staf menunggu agak malas, dan agak mudah untuk mengidentifikasi dan memperbaikinya.
Tetapi ketika Anda berpikir tentang pusat data, itu adalah cerita yang sama sekali berbeda. Ini bisa menjadi masalah jaringan, permintaan buruk yang mengganggu, kinerja aplikasi, atau kabel yang salah bahkan dapat menyebabkan beberapa masalah. Dan pemecahan masalah dengan jenis kompleksitas itu bisa, Anda tahu, paling sulit. Itulah yang akan kita bicarakan hari ini. Dan kami punya, seperti yang saya katakan, Eric Kavanagh berdebat sebagai analis hari ini. Dez Blanchfield adalah ilmuwan data kami, dan kami memiliki Bill Ellis dari IDERA, yang akan berbicara tentang solusi perusahaannya yang membantu manajemen kinerja aplikasi. Dan dengan itu, saya akan memberikan bola kepada Eric. Eric, lantai adalah milikmu.
Eric Kavanagh: Alrighty, kedengarannya bagus, kawan. Dan itu analogi yang hebat, sebenarnya, karena Anda berbicara tentang kesulitan atau kemudahan pemecahan masalah yang dapat diselesaikan dan Anda langsung melakukannya. Masalah kinerja selalu dihasilkan dari beberapa jenis masalah yang ada di jaringan. Maksudku, itu bisa sesederhana perangkat keras lama misalnya, tetapi intinya adalah situasi seperti itu membutuhkan pemecahan masalah. Itulah yang akan saya bicarakan hari ini. Dan mari kita lanjutkan dan melompat pada slide di sini.
Di sinilah masalah. Pemecahan masalah - menyenangkan bagi orang-orang yang menyukainya, itu yang keren. Jika Anda menemukan seseorang yang suka melakukan pemecahan masalah, pegang orang itu, dapatkan mereka beberapa alat untuk menyelesaikan pekerjaan, karena hal-hal yang sangat bagus jika Anda dapat menemukan seseorang yang bisa mencapai bagian bawah dari sesuatu dan menyelesaikan sesuatu. Tetapi intinya adalah bahwa pemecahan masalah itu bermasalah dan selalu terjadi dan akan selalu terjadi, dan jika Anda mulai berbicara tentang pemecahan masalah, apa yang sebenarnya Anda dapatkan adalah analisis akar masalah. Apa yang menyebabkan masalah?
Nah, jika Anda hanya duduk dan berpikir sejenak tentang bahkan hari-hari mainframe, ada semua jenis masalah yang bisa terjadi. Dan saat itu Anda harus memiliki orang-orang yang benar-benar mengetahui barang-barang mereka karena bahkan tidak ada alat yang baik untuk melakukan pemecahan masalah, jadi Anda benar-benar harus tahu command prompt Anda, dan kami akan membicarakannya sebentar lagi. Dan saya benar-benar lupa memasukkan salah satu slide favorit saya, saya akan mencarinya saat kita berada di acara hari ini, mungkin selama presentasi Dez. Tapi saya ingin menunjukkan, bagi siapa pun yang belum melihatnya, salah satu acara TV Inggris paling lucu yang pernah ada, itu disebut "Kerumunan IT." Dan dalam hal pemecahan masalah, pria Irlandia, yang merupakan salah satu dari dua orang IT di seluruh perusahaan, selalu mengatakan hal yang sama setiap kali ada panggilan, "Sudahkah Anda mencoba mematikannya lagi?" Jadi, cobalah mematikannya lagi. Anda akan kagum betapa sering hal sederhana itu dapat menyelesaikan beberapa masalah.
Anda yang telah melakukan pemecahan masalah di rumah mungkin dengan orang tua atau teman Anda, mungkin tidak dengan anak-anak Anda karena mereka cenderung tahu apa yang harus dilakukan, matikan dan nyalakan lagi. Tapi bagaimanapun, pemecahan masalah itu tidak mudah, itu tidak akan pernah mudah, tetapi kita akan berbicara hari ini tentang beberapa hal yang dapat Anda lakukan untuk membuatnya lebih mudah. Jadi, command prompt - ya, memang, saya sudah cukup tua untuk mengingat hari-hari awal komputasi ketika yang Anda miliki hanyalah command prompt untuk melakukan DIR, Enter. Itu yang akan dilihat, direktori file dan merasa positif bahwa itu benar-benar menyelesaikan beberapa perintah, kan? Dez, tentu saja, ilmuwan data kami, ia tahu cara menggunakan command prompt. Dan jika Anda dapat menggunakan command prompt, itu adalah hal yang hebat karena kebanyakan dari kita hanyalah manusia biasa yang menggunakan semacam GUI, antarmuka pengguna grafis, tetapi selalu ada sesuatu, selalu ada beberapa pemutusan antara GUI dan baris perintah di bawahnya. Dan hanya untuk memberi Anda contoh acak, jika Anda ingin tahu berapa banyak kode beberapa program dasar di luar sana memanggang dokumen hari ini, masuk ke versi terbaru dari Microsoft Word, ketik "hello world" dan kemudian lakukan "save as HTML. ”Dan kemudian buka dokumen yang dihasilkan dalam editor teks, dan Anda mungkin akan melihat halaman dan halaman tag. Itu disebut kode mengasapi, dan kode mengasapi tidak benar-benar baik untuk pemecahan masalah, hanya untuk menjadi tumpul.
Tentu saja, client-server datang dan itu bagus sekali. Dan kita agak kembali ke arah itu, tetapi pikirkan saja kompleksitas yang menyertai situasi, sekarang di mana masalahnya, apakah itu pada klien, apakah di server, apakah di jaringan, apakah di jaringan? Dimana itu? Situs-situs yang hanya memikirkan virus, dan ketika virus bisa masuk ke dalam satu jaringan, apa yang bisa terjadi? Itu bisa pergi ke mana saja. Pelanggaran data gila hari ini. Mereka menyebabkan masalah kinerja. Kami memiliki peretas Rusia yang dapat kami identifikasi berdasarkan alamat IP. Kami cukup yakin mereka orang Rusia, atau mereka sangat dekat, atau mereka sangat pintar Ukraina atau Polandia atau bahkan orang Amerika, menggunakan proxy. Tapi kami sudah peretas masuk ke situs lama kami yang kecil, Inside Analysis, selama bertahun-tahun dan menyebabkan semua jenis masalah. Hal-hal berhenti bekerja, Anda tidak bisa menyelesaikannya. Hal-hal yang dulu bekerja tidak berhasil. Bagaimana Anda tahu? Bagaimana kamu tahu apa itu? Sama seperti contoh lain di sini, adalah lingkungan yang sangat kompleks, sangat sulit untuk masuk ke dalam gulma dan benar-benar memahami bagaimana hal-hal terjadi dan bekerja untuk kita, terutama jika Anda mendapatkan banyak plug-in. Banyak hal bisa menjadi sangat cepat gila. Aku agak terlalu terburu-buru.
Saya melemparkan di sini, selalu waspada dengan upgrade. Upgrade selalu membuatku takut pada siang hari. Sistem operasi pasti. Saya ingat hari-hari ketika Microsoft benar-benar menyarankan itu, ya, Anda dapat meningkatkan sistem operasi Anda dari versi ini ke versi itu. Yah, saya mencoba beberapa kali, dan itu tidak pernah berhasil. Ingat saja, semakin besar, semakin kompleks suatu lingkungan, semakin sulit situasi yang akan terjadi. Dan kemudian ada virtualisasi. Pikirkan tentang apa yang dilakukan VMware terhadap TI. Ini merevolusi IT, tetapi juga menciptakan lapisan abstraksi ini. Jika Anda memiliki lapisan abstraksi pada level dasar itu, itu adalah permainan bola yang benar-benar baru, bola lilin yang benar-benar baru dan Anda benar-benar harus menilai kembali apa yang Anda lakukan, dan semua alat lama harus berubah. Dan sekarang tentu saja itu awan, kan? Untuk pelanggan, cloud sangat bagus, karena sangat sederhana, antarmuka pengguna sangat mudah, tetapi tentu saja Anda tidak benar-benar memiliki banyak kendali atas cloud. Tetapi bagi orang-orang yang ada di belakang layar, ada banyak hal yang perlu mereka ketahui dan pahami akhir-akhir ini. Lingkungan menjadi jauh lebih kompleks. Dan tentu saja dengan e-commerce, dan Anda memikirkan semua uang yang diperdagangkan saat ini. Itu sebabnya Anda tidak akan menemukan saya dalam mendukung masyarakat tanpa uang dalam waktu dekat. Intinya di sini adalah bahwa situasinya semakin bermasalah dari hari ke hari.
Dan menjaga kinerja optimal selalu akan melibatkan beberapa elemen pemecahan masalah. Saya tidak peduli apa yang orang katakan kepada Anda, tidak ada alat yang sempurna, tidak ada peluru perak dan tidak akan pernah ada karena - dalam perspektif lain yang menarik di sini - kami masih belajar berbicara silikon. Kami masih belajar untuk memahami bagaimana bahkan jaringan bekerja di tingkat seluk beluk. Jika Anda melihat perangkat lunak manajemen sistem, ini menjadi cukup bagus akhir-akhir ini. Tapi tetap saja, Anda melihat garis naik dan turun dan Anda melihat representasi realitas, itu akan membawa orang yang tahu apa yang terjadi agar sesuai dengan petunjuk bahwa Anda bisa menatap alat yang optimal untuk dapat mengerti apa yang berhasil dan yang tidak dan itu banyak trial and error, hanya untuk berterus terang. Dengan itu, saya akan menyerahkannya kepada Dez Blanchfield dan kemudian kita akan mendengar dari Bill Ellis dari IDERA, siapa yang akan membuat kita malu dengan pengetahuannya. Dengan itu, Dez, bawa pergi.
Dez Blanchfield: Hei, terima kasih Eric. Terima kasih. Dipimpin dengan baik ke dalam segue kecilku. Judul saya, "Performance Art, " Saya pikir sangat tepat dalam konteks apa yang kita bicarakan hari ini, karena dalam banyak hal ketika kita berpikir tentang seni pertunjukan, kita berpikir tentang menari dan musik dan hal-hal kreatif lainnya. Dan terus terang lebih sering daripada tidak, jika kita memecahkan masalah dan dalam skala yang sangat besar lingkungan TI dan sistem bisnis memang ada unsur seni dan seringkali seni hitam, karena situasi dalam pengalaman saya dalam beberapa 25-plus tahun adalah bahwa tumpukan aplikasi modern, sangat cepat meningkatkan kompleksitas pada tingkat yang belum pernah kita lihat sebelumnya. Dan kami terus terang berjuang untuk mengimbangi dan ada organisasi seperti Uber misalnya, dan apa pun, dan tim pengembangan Pokémon Go, maksud saya mereka mengalami pertumbuhan dan kompleksitas dan peningkatan kompleksitas pada tingkat yang hanya astronomi. Bahkan tidak ada buku yang ditulis tentang itu karena kami belum memahami tingkat pertumbuhan itu. Pandangan saya adalah bahwa definisi inti dari tumpukan aplikasi telah berubah secara eksponensial dan saya akan menjelaskan mengapa saya pikir itulah masalahnya, dan kemudian mengarah ke tantangan yang ada, bahwa teman baik saya di IDERA tampaknya memiliki solusi untuk menyelesaikan .
Secara singkat, kita semua tahu ini tetapi hanya untuk merangkumnya, Anda tahu, pada hari-hari awal kita memiliki apa yang saya sebut, arsitektur aplikasi, versi 1.0. Itu adalah komputer server, dalam hal ini mainframe dengan banyak terminal yang terpasang, relatif mudah untuk mendiagnosis masalah jika Anda tidak melihat hal-hal di terminal - Anda dapat melacak kabel antara terminal dan kemudian komputer server, dan itu adalah nol kabel atau konektor atau beberapa masalah jika itu tidak terkait dengan terminal, dan Anda melihat sesuatu di layar, itu cukup mudah untuk mengetahui bahwa hal-hal yang menyebabkan masalah ada di mesin itu sendiri. Dan Anda bisa secara perlahan mendiagnosis di mana tumpukan itu berasal dari perangkat keras hingga lapisan perangkat lunak dan antarmuka pengguna. Dalam apa yang saya sebut versi 1.1, kami membuatnya sedikit lebih kompleks. Kami menempatkan perangkat di tengah sehingga kami dapat menempatkan lebih banyak terminal di tempatnya. Dan mereka semacam perangkat komunikasi dan sering kali mereka muxes atau multiplexer dan mereka akan menabrak jalur khusus atau garis dial-up dan jadi Anda memiliki mainframe di lokasi yang jauh - bisa antar negara atau internasional - dan beberapa perangkat terhubung melalui tautan SMA atau semacam konektivitas WAN dan terminal-terminal itu masih beroperasi dengan cara yang sama. Tetapi Anda memiliki sedikit lebih banyak kerumitan karena Anda harus mencari tahu apakah masalahnya ada di antara terminal dan perangkat comms atau perangkat comms dan mainframe. Tapi tumpukan tetap relatif sama di mainframe.
Versi 1.2, sedikit lebih kompleks lagi karena sekarang kami menambahkan lebih banyak perangkat, kami menambahkan printer dan hal-hal lain, dan kami mengelompokkan hal-hal ini, dan saya berpikir tentang prosesor front-end yang akan menangani semua masalah perangkat secara lokal, printer dan terminal dan sebagainya dengan mainframe yang ujungnya jauh. Sedikit lebih rumit. Tetapi sekali lagi, tema konsisten dari mainframe adalah aplikasi yang berjalan secara lokal, sehingga penyelesaian masalah tetap serupa di dalam tumpukan aplikasi. Dan kemudian kami memiliki orang-orang dengan keterampilan berlari memilah masalah dengan terminal dan printer dan pengontrol cluster. Tapi kemudian kami rumit dan kami membangun jaringan dan tiba-tiba jenis arsitektur yang sama memperkenalkan lapisan jaringan. Tiba-tiba kami memiliki saklar jaringan, dan workstation jauh lebih kompleks. Dan versi arsitektur ini kita sering memiliki aplikasi antarmuka pengguna grafis di workstation. Kami tidak hanya memiliki server yang menjalankan tumpukan aplikasi, tetapi kami juga memiliki setumpuk aplikasi lain yang berjalan secara lokal, dan tentu saja model dasar perangkat yang sama yang terhubung ke server. Kemudian kami mengambil lompatan kuantum ke model yang lebih baru dari apa yang saya sebut 2.1, yang merupakan tempat kami mengambil tumpukan aplikasi itu dan kami membuatnya jauh lebih kompleks, jauh lebih sulit untuk didiagnosis. Dan kami memperkenalkan lebih banyak perangkat di front-end, di browser web dan PC dan perangkat seluler, sebagainya. Dan di sini tumpukan aplikasi kemudian mulai menyelam sedikit lebih dalam ke integrasi sebagai sistem operasi dan hypervisor satu.
Gambar ini di sini di sebelah kanan kita punya seluruh tumpukan termasuk infrastruktur jaringan, server penyimpanan, mesin virtual, sistem operasi dan kemudian tiga tingkatan tradisional aplikasi basis data logam, dll., Di tangan kanan depan. Mendiagnosis masalah aplikasi dan masalah kinerja pada model ini menjadi jauh lebih sulit. Ada begitu banyak bagian yang bergerak dan mencoba menelusuri tumpukan itu hanya, Anda tahu, menjadi mimpi buruk dan Anda harus melibatkan keahlian tambahan dan organisasi untuk mengatasinya. Bukan hanya tim aplikasi Anda lagi, tiba-tiba sekarang Anda memiliki orang-orang infrastruktur, Anda memiliki spesialis basis data, murni hanya bekerja pada basis data dan tidak ada yang lain - sebagai lawan dari programmer sistem yang tahu jalan mereka di sekitar basis data. Sekarang kita punya skenario di mana departemen TI harus berurusan dengan kompleksitas “sebagai layanan” yang jauh lebih luas dan ini di mana dunia baru saja meledak dan tantangan pemecahan masalah kita menjadi, berubah dari mimpi buruk menjadi sesuatu yang hampir tidak dapat ditoleransi dalam beberapa hal.
Dan ini muncul sebagai skala yang dapat diatasi, kami mencoba memberikan layanan di. Versi 3 dari apa yang saya anggap tumpukan aplikasi - telah memperkenalkan ini sebagai model layanan, di mana model tradisional di sisi kiri, tumpukan IT perusahaan, di mana semuanya harus dikelola pada akhirnya sebagai konsumen dan pemasok layanan - dari basis data keamanan aplikasi, sistem operasi, penyimpanan layanan virtualisasi, pusat data jaringan - kami harus mengelola semuanya, tetapi kami memiliki akses ke semuanya dan sehingga kami dapat meningkatkan kemampuan dan keahlian teknis kami dan kami dapat menelusuri hingga saat ini melalui tumpukan itu dan kami dapat menemukan hal-hal. Tetapi ketika layanan infrastruktur dan layanan platform serta model layanan perangkat lunak muncul, tiba-tiba akses kami ke infrastruktur back-end, akses kami ke platform dan alat dari mana kami memberikan layanan, agak diambil dari kami. Ketika kami mulai mengkonsumsi layanan infrastruktur, kami hanya benar-benar memiliki empat bagian teratas dari sistem operasi, database, tumpukan aplikasi keamanan lingkungan dan di atas, tersedia untuk kami. Semua yang ada di bawahnya adalah ilmu hitam. Dan itu semakin menarik ketika Anda pindah ke layanan platform karena Anda juga hanya mengelola tumpukan aplikasi.
Ketika Anda mendapatkan perangkat lunak sebagai layanan, dan model tradisional dari itu adalah webmail atau internet banking, yang Anda miliki hanyalah akses ke browser web, jadi mencoba mendiagnosis apa yang ada di balik itu tidak dapat ditolerir, tentunya. Dan saya telah memecah ini menjadi zona waktu, ke dalam slot waktu atau area waktu jika Anda suka atau generasi, dari kiri ke kanan, kami telah beralih dari semacam pra-2000 dan tumpukan tradisional di mana kami memiliki akses ke seluruh lingkungan dan kita bisa menelusuri itu. Tetapi seiring berjalannya waktu itu menjadi semakin kompleks. Sampai awal 2000-an hingga pertengahan 2000, hingga akhir 2000 hingga saat ini, di mana kami telah beralih dari layanan infrastruktur, layanan platform, layanan perangkat lunak, hingga sekarang kami pada dasarnya merujuk pada layanan bisnis. Dan kompleksitasnya telah meningkat secara dramatis. Ada begitu banyak bagian yang bergerak. Tetapi ketersediaan keterampilan semakin sulit dan semakin sulit untuk memanfaatkan diri kita sendiri. Menemukan orang dengan keahlian yang tepat dengan akses yang tepat ke alat yang tepat untuk masuk dan terjun ke tumpukan ini dan mencari tahu, di mana ada sesuatu yang berjalan lambat. Apakah laptop saya atau desktop saya, apakah ponsel saya atau tablet saya, apakah konektivitas saya lebih dari 3 atau 4G, atau tautan khusus saya dengan ADSL, atau ISDN apa pun itu? Atau bahkan dial-up, meskipun itu kurang dan kurang terjadi hari ini. Apakah akhir server web, apakah ada sesuatu di dalam server web? Apakah ini server aplikasi? Apakah ada sesuatu di sekitar memori dan disk CPU dan kinerja jaringan di dalam server aplikasi? Apakah database berjalan di sana?
Dan Anda dapat membayangkan, Anda menggambar gambar ini dengan sangat cepat dari kerumitan yang mulai meluas seperti gambar big bang, dari gelembung yang terus meningkat ini yang kami coba luncurkan dan miliki keterampilan untuk menyelam dan pengetahuan dan sarana untuk membedah dan memisahkan. Dan kita sekarang berada di era di mana, Anda tahu, manusia tidak dapat mengatasi skala fisik, bahkan jika Anda memiliki kemampuan untuk memisahkan lingkungan basis data dan memisahkan basis data itu dan menyelam ke dalam detail dalam database itu. Jumlah database yang harus Anda kelola sekarang berkembang pesat. Semuanya sekarang didukung oleh database. Sangat sedikit aplikasi saat ini yang tidak didukung oleh database. Dan tipe-tipe basis data juga tumbuh dengan cepat. Ini bukan hanya database SQL tradisional lagi, kadang-kadang SQL-nya, kadang-kadang non-SQL, kadang-kadang database grafik, kadang-kadang itu adalah database dokumen. Dan ada semua jenis fungsi yang berbeda yang dimiliki oleh berbagai jenis database ini dan sebagai hasilnya masing-masing memiliki tantangan kinerja yang berbeda dan kriteria kinerja yang berbeda. Database pencatatan dan basis data dokumen berkinerja sangat, sangat berbeda dan melakukan fungsi yang berbeda dengan database SQL tradisional yang sesuai dengan ACID, ANSI 92-compliant. Dan jenis-jenis barang yang kami simpan di sana.
Kami berada di titik, dalam pikiran saya, di mana - dan saya pikir Eric menyinggung ini - bahwa manusia sedang berjuang untuk mengikuti kompleksitas dari apa yang kita sedang membangun dan kecepatan di mana kita sedang membangun, dan kita Sekarang pada titik di mana satu-satunya cara bagi kita untuk mengelola infrastruktur ini, dan satu-satunya cara untuk memantau dan menggali masalah yang kita hadapi, adalah dengan alat dan jenis alat yang tepat. Dan selalu, generasi alat yang tepat. Alat yang benar-benar memahami infrastruktur back-end. Tidak apa-apa lagi hanya dengan melempar monitor SQL, atau alat query SQL pada sesuatu dan mulai memisahkan permintaan dan melihat apa yang membuatnya bekerja. Kami benar-benar membutuhkan alat yang memahami pembentukan kueri dan cara yang tepat untuk membentuk kueri, dan cara yang tepat agar kueri berbicara dengan infrastruktur di back-end, dan bagaimana kinerjanya saat melakukan itu. Dan untuk melihat waktu dari interaksi tersebut dan urutan di mana mereka terjadi.
Dan itu adalah tantangan yang jauh lebih kompleks dan itu membawa saya ke titik pertanyaan roundup saya, dan itu adalah, ketika kompleksitas aplikasi menumpuk peningkatan, alat kinerja dan alat yang kami gunakan untuk mengelola itu, tentu perlu untuk menjadi semakin pintar dan lebih mampu melihat lebih banyak hal. Tetapi juga jauh lebih pintar tentang bagaimana mereka mempelajari apa yang berjalan di back-end dan apa yang dapat mereka temukan tentang hal itu dan bahkan berpotensi semacam analitik yang dilakukan untuk memahami bahwa interaksi dan kinerja, sedang disampaikan, dan mengapa kinerjanya lebih lambat atau lebih cepat.
Dan kemudian dengan itu saya akan menyampaikan kepada teman baik kita dari IDERA, Bill Ellis, dan lihat apa yang dia katakan hari ini tentang bagaimana mereka menyelesaikan masalah ini. Bill, ke arahmu.
Bill Ellis: Baiklah. Nama saya Bill Ellis dan terima kasih banyak. Kita akan berbicara tentang aplikasi saya berjalan lambat, saatnya untuk mendapatkan Precise. Mari kita lihat apa yang Precise, produk IDERA, dapat lakukan dan bagaimana itu dapat membantu Anda. Sering kali Anda hanya mengetahui bahwa ada masalah kinerja karena pengguna akhir telah menelepon Anda, dan itu benar-benar masalah besar. Dari semua orang di IT, tidak ada yang tahu sampai telepon berdering. Sekarang, masalah besar berikutnya adalah bagaimana kita membantu individu khusus ini, dan itu benar-benar bukan masalah sepele. Ada satu takeaway dari ini. Itu di atas dan di luar slide ini, itu di atas dan di luar yang lain. Dan saya ingin Anda melihat apakah Anda bisa mendapatkannya. Tetapi, seperti yang telah kami sebutkan, aplikasi membutuhkan, bergantung pada banyak teknologi yang berbeda, tumpukan aplikasi tinggi dan berkembang. Dan banyak orang mengakses aplikasi melalui browser, dan secara mengejutkan ada lebih banyak proses yang terjadi di browser dengan scripting, dll. Dan tentu saja Anda memiliki jaringan, server web, kode logika bisnis, dan database. Apa yang saya ingin Anda pertimbangkan adalah bahwa setiap transaksi bisnis yang signifikan berinteraksi dengan database, apakah itu pelaporan kartu waktu, pencarian inventaris, pesanan pembelian, database sedang diperbarui. Jadi, basis data benar-benar menjadi dasar kinerja. Dan database tentu saja dapat menyala, atau bergantung pada hilir pada penyimpanan. Masing-masing teknologi ini sangat erat dan dapat melihat apa yang terjadi. Anda harus tahu apa yang terjadi untuk dapat mengukur sangat penting.
Sekarang, satu hal yang kami temukan adalah bahwa banyak pelanggan kami memiliki alat, dan mereka memiliki alat untuk setiap teknologi, tetapi yang tidak mereka miliki adalah konteks. Dan konteks pada dasarnya adalah kemampuan untuk menghubungkan titik-titik antara setiap tingkatan dalam tumpukan aplikasi, dan ini sebenarnya relatif sederhana. Kami dulu memiliki batasan dua belas tingkatan, tetapi pada dasarnya mengubahnya, kami memiliki tingkatan yang tidak terbatas dan kami mendukung lingkungan campuran sehingga pada dasarnya kami dapat menjadi sangat rumit dengan solusi Precise.
Sekarang, pada level tinggi, ini adalah bagaimana kita menyelesaikan masalah dan berfokus pada transaksi, transaksi pengguna akhir dari klik ke disk, memberi tahu kita mana yang berjalan lambat, mana yang menghabiskan sumber daya, tetapi kuncinya adalah ini - kami memungkinkan Anda untuk mengambil dan ID pengguna lokasi mereka dan tidak hanya seluruh waktu transaksi, tetapi berapa banyak waktu yang dihabiskan pada setiap langkah individu. Waktu adalah mata uang kinerja, dan itu juga muncul di mana sumber daya dikonsumsi. Kami tidak tahu di muka di mana masalah akan terjadi, jadi kami harus memiliki metrik yang memadai dan analitik di setiap tingkatan untuk dapat mendiagnosis apa masalahnya, di mana masalahnya.
Sekarang, dalam presentasi hari ini saya akan fokus di bidang ini, saya ingin Anda yakin bahwa kami pada dasarnya memberikan tingkat visibilitas yang sama di setiap tingkatan dalam tumpukan aplikasi dan yang penting, apakah ini akan memberi tahu kami siapa, apa, di mana dan kemudian bagian ini, ini akan memberi tahu kita mengapa. Dan itu benar-benar alasan mengapa itu sangat penting untuk menyelesaikan masalah, tidak hanya mengetahui tentang mereka. Sekarang hal lain yang muncul dengan sangat jelas dalam presentasi adalah bahwa tidak mungkin untuk melakukan ini. Anda perlu otomatisasi. Dan otomatisasi berarti Anda memiliki peringatan, Anda memiliki sesuatu yang memberi tahu Anda, semoga sebelum komunitas pengguna akhir, bahwa Anda memiliki tren berkelanjutan, membangun penyimpangan dari peringatan tren. Dan kemudian kami juga menawarkan garis di pasir, Anda benar-benar melanggar SLA. Sekarang Anda menawarkan banyak informasi yang berbeda - tidak semua orang perlu mengkonsumsi prasmanan, beberapa orang hanya ingin memiliki makanan ringan, ini salad, dan dengan itu kami menawarkan portal kami dapat mengunggah informasi, itu hanya membutuhkan pengguna tertentu atau kebutuhan informasi komunitas tertentu tentang kinerja. Aplikasi berjalan lambat, saatnya untuk mendapatkan Precise. Kami benar-benar akan fokus pada empat hal. Salah satunya adalah lokasi, memasukkan pengguna akhir. Sekali lagi, konteks yang menghubungkan titik-titik tersebut, dan bagian ketiga dari penelitian menunjukkan bahwa hampir 90 persen masalah aplikasi ada dalam database dan karenanya benar-benar semacam parodi bahwa sebagian besar solusi kinerja mungkin memberi tahu Anda satu pernyataan SQL. Tapi mereka tidak memberi tahu Anda mengapa pernyataan SQL berjalan lambat.
Jadi, mengapa selalu menjadi hal yang penting dan Precise sangat baik dalam menunjukkan mengapa, untuk setiap tingkatan dan khususnya basis data, dan hanya untuk berbagi sedikit tentang matriks dukungan kami dengan Anda, yang kami dukung SQL Server, Sybase, DB2 dan / atau Massal. Tampilan dan nuansa solusinya sangat mirip, jadi jika Anda melihat beberapa aplikasi, tetapi arsitekturnya sedikit berbeda. Informasi yang saya bagikan di sini memiliki tampilan dan nuansa, pendekatannya, sama saja apa pun teknologi yang digunakan. Precise diaktifkan web. Kami masuk, kami mengautentikasi Precise, dan dengan itu kami masuk dan hal pertama yang mungkin ingin kami lihat adalah kinerja berdasarkan lokasi. Jadi Anda dapat benar-benar melihat di sini lokasi berbeda di mana orang-orang benar-benar mengakses eksekusi mereka. Anda dapat melihat apakah seseorang meninggalkan halaman sebelum sepenuhnya ditampilkan, atau jika ada kesalahan.
Sekarang, satu hal dengan aplikasi ini, adalah jaringan atau jarak dari server aplikasi memang berbeda. Sangat mudah untuk melihat di sini bahwa ada beberapa tingkat jaringan. Saya dapat melihat ketika orang-orang menjadi sibuk, dan kemudian hal menarik lainnya, kami berbicara tentang bagaimana ada pemrosesan di dalam browser, mereka benar-benar memperhatikan bahwa beberapa tipe browser yang berbeda memberikan lingkungan yang lebih baik untuk pemrosesan cepat. Dan dengan mengetahui jika orang mengakses oleh Chrome atau IE, atau apa pun yang terjadi, Anda sebenarnya dapat menemukan sangat sering bahwa satu jenis inversi peramban sebenarnya lebih unggul daripada yang lain. Sekarang, kadang-kadang Anda menghadapi publik, Anda tidak mengontrol browser, kadang-kadang aplikasi internal menghadap di mana Anda dapat merekomendasikan orang-orang tipe browser ke komunitas pengguna akhir Anda, dan ini adalah jenis visibilitas menyelam dalam dan analisis yang Precise mampu memberikan. Sekarang, kita melihat aplikasi.
Saya tidak yakin apakah kalian dapat melihat pointer saya, tetapi saya ingin menjelaskan kepada Anda, grafik teratas. Sumbu-y menunjukkan waktu respons rata-rata. Sumbu x adalah waktu sepanjang hari. Dan sebenarnya ada grafik batang bertumpuk dan grafik batang bertumpuk itu, totalnya menunjukkan kepada Anda apa kinerjanya dan kemudian menunjukkan tingkat berapa banyak waktu yang dihabiskan dalam setiap langkah individu atau setiap tingkatan aplikasi. Dari klien, melalui server web, hijau adalah Java, tempat ini kami menggunakan Tuxedo dan turun ke basis data. Sekarang bagian bawah layar menunjukkan menu web yang berbeda yang sedang diakses dan kami kemudian memilih hanya dengan sedikit panah hijau mengarah ke bawah. Ini dalam urutan menurun, dan itu gelembung ke atas, menu web mulai menunjukkannya. Kami benar-benar menunjukkan waktu eksekusi, waktu respons dari masing-masing teknologi individu dan kemudian sebenarnya ada grafik batang untuk masing-masing menu web tersebut dan kami mendapatkannya, mulai mendapatkan ide tentang apa yang terjadi. Sekarang ingat kita mengurutkan semua ini dengan pengguna akhir akan menelepon, tetapi bagaimana cara menemukan pengguna akhir? Saya datang ke sini, saya membuka menu, yang memungkinkan saya untuk memfilter pengguna tertentu, jadi saya mengatur pengguna itu ke Alex Net, klik OK, dan kemudian kita fokus hanya pada aktivitas dari Alex Net. Sekarang apa yang dilakukannya, apakah itu memungkinkan TI dan manajemen TI untuk secara langsung responsif terhadap pengguna akhir dan khususnya bahwa mereka melihat manajemen konten yang memiliki enam eksekusi dengan waktu respons sedikit lebih dari tiga detik. Ya, tiga detik cukup bagus, tidak buruk, tapi mungkin lebih lambat.
Apa yang dapat saya lakukan dengan ini, adalah saya dapat mengiris dan memotong informasi ini ke berbagai cara. Saya bisa mengatakan, apakah transaksi ini lambat untuk semua orang? Apakah hari ini lebih lambat untuk Alex daripada kemarin? Apakah lambat untuk setiap pengguna di lokasi tertentu? Atau, dan apa yang dilakukannya adalah memungkinkan saya untuk mengiris dan dadu dan mendapatkan gambaran tentang apa yang terjadi, seberapa universal masalahnya dan sangat penting untuk dapat mengidentifikasi pengguna akhir, karena ini bukan hanya tentang perangkat lunak, infrastruktur, ini juga tentang bagaimana pengguna akhir menjalankan aplikasi. Seringkali Anda mungkin memiliki karyawan baru atau seseorang dengan fungsi pekerjaan baru, dan mereka tidak terbiasa dengan layar SAP tertentu atau panel PeopleSoft tertentu dan mereka memerlukan penunjuk kecil, mungkin mereka meninggalkan bidang kosong atau memasukkan wildcard dan mereka ' kembali memaksa hasil besar untuk dikembalikan dari database. Tetapi memiliki ID pengguna, Anda sebenarnya dapat memanggil mereka sebelum mereka memanggil Anda. Hal lain yang kami temukan adalah bahwa begitu komunitas pengguna menyadari bahwa TI tahu apa yang mereka lakukan, sering kali mereka menjadi lebih baik dan banyak masalah, banyak hal yang menjadi masalah, hanya semacam menguap, karena orang berperilaku, hanya beroperasi sedikit lebih hati-hati. Mereka menggunakan sistem dengan lebih hati-hati.
Identifikasi pengguna akhir sangat penting. Pada akhirnya, sangat penting bagi TI untuk dapat membantu pengguna akhir tertentu. Sekarang, apa yang kita lakukan di sini, adalah kita telah pergi ke tab "Aliran". Anda dapat melihatnya di sudut kiri atas. Dan kami telah fokus pada satu komponen tertentu dari menu web. Dan di sisi kanan adalah analisis dari transaksi tertentu, dan di atas itu sebenarnya adalah browser dan kemudian View, hanya untuk membiasakan diri dengan sedikit ikon dalam GUI untuk server web, jadi kita bisa melihat titik atributnya. Dan kemudian "J" adalah untuk Java dan "T" adalah untuk Tuxedo dan tentu saja "Q" adalah SQL. Nah nilai tunai itu pada dasarnya mengidentifikasi pernyataan SQL tertentu. Pertimbangkan apa yang dilakukannya. Kami telah mengidentifikasi pengguna untuk transaksi, ke kode aplikasi yang mendasarinya, termasuk pernyataan SQL individual. Sekarang, ketika saya melihat masing-masing pernyataan SQL, saya dapat melihat bahwa dari total waktu respon, masing-masing bertanggung jawab untuk sekitar enam persen, dan ketika mereka menambahkan empat pernyataan SQL teratas, mereka mengambil sekitar seperempat dari transaksi waktu.
Sekarang seringkali, basis data adalah yang termudah untuk dimanipulasi. Biasanya paling mudah untuk mendapatkan kinerja yang murah dan jauh lebih unggul. Sekarang saya perlu sedikit lebih dalam untuk mencari tahu apa yang terjadi dan apa, saya ingin contoh dapat lakukan adalah benar-benar mengungkapkan pernyataan SQL individu, dan Anda tahu saya hampir dapat menjamin Anda hanya dengan setiap tembakan tunggal di telepon memiliki semacam alat basis data dan apa yang dilakukan oleh alat basis data tetapi hanya dengan melihat satu teknologi secara terpisah, apakah Anda melihatnya, fokus pada kesehatan teknologi itu. Dan sering kali orang melihat daftar sepuluh besar. Sekarang pernyataan SQL ini cukup cepat, itu tidak akan berada di daftar sepuluh besar, tetapi pernyataan SQL yang menjadi sandaran transaksi ini. Jadi apa yang dapat saya lakukan kembali pada kata itu, konteks, sekarang saya bisa membawa ini ke perhatian tatapan yang dalam tetapi dalam konteks pernyataan SQL individu.
Sekarang orang itu dapat membuka Precise dalam konteks pernyataan SQL individu, dan Precise menangkap rencana eksekusi aktual yang digunakannya, waktu eksekusi ini adalah hal penting bagi DBA, akan benar-benar menunjukkan, Anda dapat melihat bahwa 50 persen dari waktu dihabiskan menunggu penyimpanan. Lima puluh persen dari waktu digunakan dalam CPU, jadi Anda mulai mendapatkan ide-ide dari mana waktu itu dihabiskan, bagaimana saya mungkin menggoyangkan waktu itu, dan idenya adalah memberi orang pilihan, karena respons yang berbeda memiliki biaya yang berbeda dan risiko yang terkait . Idealnya kita mencari solusi yang berisiko rendah dan murah untuk suatu masalah. Sekarang pernyataan SQL dilacak oleh nilai hash dan ada, di bagian kiri tengah layar terdapat tombol "Tune" kecil ini, dan apa yang akan dilakukan, adalah akan membawa Anda ke tugas SQL. Dan tugas SQL ini adalah semacam meja kerja yang sudah dibangun sebelumnya dan apa yang dilakukannya, apakah ini memungkinkan saya untuk benar-benar menganalisis secara spesifik apa yang memengaruhi pernyataan SQL yang dimulai dengan rencana eksekusi. Rencana eksekusi dipilih oleh pengoptimal ketika pernyataan diuraikan, itu - kembali ke analogi makanan, itu adalah resep yang diikuti untuk menyelesaikan pernyataan SQL.
Dan beberapa resep lebih rumit daripada yang lain, jadi kami memberikan temuan. Dan itu benar-benar akan ditampilkan di sini, hei, banyak waktu melakukan sekuensial I / O pada indeks tertentu. Dan lihat sekarang, kapan, kembali ke oksigen, ikuti indeks ini. Apakah indeks itu telah didefragmentasi baru-baru ini, bagaimana kesehatannya? Apa ruang meja tempat tinggalnya? Apakah ruang tabel dipisahkan dari tabel yang dirujuk? Dan itu mulai memberi Anda segala macam ide tentang bagaimana Anda bisa menyelesaikan masalah. Sekarang jelas, Anda tahu, kami membuat indeks. Ini risiko yang jauh lebih rendah, jauh lebih mudah daripada mungkin memindahkan indeks dari satu ruang tabel ke ruang tabel lain, jadi apa yang ingin kita lakukan adalah jenis opsi membangun, sehingga kita dapat menggunakan biaya terendah, opsi risiko terendah untuk memecahkan masalah.
Precise juga dapat melakukan hal-hal seperti menangkap variabel terikat yang dilemparkan ke pernyataan SQL. Jelas variabel yang dilemparkan akan mengontrol ukuran hasil yang ditetapkan. Dan itu akan mengontrol berapa lama pernyataan SQL yang diperlukan untuk mengeksekusi dan berapa banyak data yang harus dilewati dan diproses oleh aplikasi melalui Java, melalui .NET, ke dalam server web ditambah jaringan, akhirnya dirender dalam browser pengguna akhir . Apa yang terjadi di database berdampak langsung pada waktu browser itu. Maka sangat penting untuk memiliki tingkat visibilitas ini sehingga kita dapat mengetahui dengan tepat apa yang sedang terjadi dan memberikan DBA opsi terbanyak sehingga mereka dapat memilih mana yang paling masuk akal, mengingat situasi tertentu.
Sekarang, ini adalah beberapa kutipan dan ini berasal dari toko PeopleSoft yang memiliki penyebaran global. Precise mendukung PeopleSoft dan SAP, Siebel, Oracle, E-Business Suite, aplikasi Java dan .NET buatan lokal. Kami mendukung sehingga jika Anda membuat panggilan layanan web ke beberapa JVM, dari Java ke .NET kembali ke Java, kami dapat melacak semua itu. Bisa saja di tempat, bisa di awan. Yang penting adalah bahwa hal-hal perlu diinstrumentasi.
Jadi, hanya beberapa kutipan dari salah satu pelanggan kami. "Sebelum Precise, DBA kami menggunakan OEM, " - itu hanya alat basis data, dan mereka pada dasarnya berkata, "Hei, contohnya terlihat hebat." Tapi mereka bisa membantu memberi tahu atau mengatasi masalah dengan transaksi tertentu. Precise memberikan visibilitas untuk melakukan itu. Dan memiliki informasi tentang pernyataan SQL sangat penting tentang memberikan DBA visibilitas untuk sepenuhnya memeras kinerja dari database. Dan itu sangat bagus. Jenis di atas dan di luar beberapa alat yang mungkin Anda lihat.
Dan kemudian manajemen TI sangat menyukai fakta bahwa Precise mampu menerjemahkan URL yang kompleks menjadi nama panel. Dan dengan cara itu jika pengguna akhir menelepon dan berkata, "Hei, saya mengalami masalah dengan ini, " Anda dapat mengisolasi dan melihat siapa pengguna itu, apa yang mereka jalankan, kinerja seperti apa, mereka sebenarnya mengukur rendering waktu di browser pengguna akhir. Ini adalah ukuran sebenarnya dari pengalaman pengguna akhir. Dan juga, memiliki ID pengguna itu sangat penting untuk membantu orang tertentu yang menelepon.
Bagaimana Precise melakukan ini? Jadi kami ingin berbagi arsitektur kami. Precise harus hidup di servernya sendiri, dan tinggal di VM, ia bisa hidup di cloud. Di ujung depan, Precise diaktifkan di web, apakah Anda menggunakan dasbor, antarmuka peringatan, atau GUI Ahli. Di sisi pengumpulan data, kita sebenarnya bisa melakukan agentless untuk beberapa teknologi berbeda. Namun, seringkali, kami akan membutuhkan agen, dan ada plus dan minus untuk memiliki agen. Nilai tambah yang besar adalah ini, adalah data yang dikumpulkan dapat diproses sebelum dikirim melalui LAN Anda. Dan itu berarti kita dapat meminimalkan dampak total dari solusi pemantauan pada lingkungan target.
Sekarang anggap saja sebagai alternatif, jika Anda memiliki "agen, " masih ada pengumpul data, itu hanya masalah di mana ia tinggal, dan itu membuat panggilan dan meneruskan data mentah tentang aplikasi target di LAN Anda. Dan itu sebenarnya cukup mahal. Jadi dengan preprocessing kita sebenarnya dapat meminimalkan jejak. Anda dapat memonitor fisik dan virtual. Dan satu hal yang ingin saya katakan tentang teknologi virtual adalah yang benar-benar fokus pada pemanfaatan. Apa yang Precise fokuskan adalah pertentangan. Kapan teknologi VMware sebenarnya meminimalkan sumber daya untuk VM tamu Anda? Dan itu menjadi sangat mudah. Jika Anda hanya melihat VM tamu, Anda hanya memiliki sebagian gambar. Mampu secara otomatis mendeteksi dan mengingatkan pada pertengkaran, itu sangat penting.
Precise dapat memonitor hingga 500 instance, jadi penyebaran yang sangat besar pada dasarnya memiliki beberapa server Precise. Dan untuk penyebaran global, biasanya itu akan menjadi server Precise di setiap pusat data. Secara kebetulan, untuk penyebaran yang sangat besar Anda dapat menggabungkan ini bersama-sama sehingga Anda dapat melihat secara luas apa yang sedang terjadi dan dapat menawarkan pelaporan, dll. Sekarang seperti yang telah saya sebutkan, kami memiliki banyak analitik teknis. Tidak semua orang perlu masuk ke GUI ahli, jadi kami menawarkan dasbor yang dapat disesuaikan. Dan masing-masing portlet atau widget ini, semuanya opsional. Dan seseorang mungkin hanya ingin pergi, “Hei, bagaimana Anda bisa membunyikan peringatan di tingkat mana pun di lingkungan kita? Bagaimana kinerja kelompok pengguna akhir dari perspektif kinerja? ”Atau mungkin Anda mungkin memiliki pertanyaan tentang infrastruktur, membahas bahkan mungkin kinerja Tuxedo. Atau bahkan load balancing. Agak menarik di bagian load balancing ini. Saya melihat portlet di tengah di sisi kiri. Anda dapat melihat bahwa jumlah eksekusi sangat mirip antara masing-masing server web. Tetapi waktu respon sangat berbeda pada yang teratas. Anda benar-benar dapat menelusuri dan mencari tahu persis alasan mengapa waktu respons pada server web itu jauh lebih lambat daripada yang lain.
Satu hal tentang load balancing, ini sangat penting, dan kebijakan load balancing, Anda tahu, tidak semua kebijakan load balancing sesuai untuk setiap aplikasi. Sebenarnya sangat membantu untuk memvalidasi kebijakan load balancing Anda. Kami sebenarnya melihat dengan beberapa aplikasi seperti PeopleSoft Fluid GUI baru, di mana sebenarnya beberapa server web akan offline. Dan itu adalah sesuatu yang sangat kritis. Jika Anda menggunakan PeopleSoft Fluid GUI, silakan hubungi kami. Kami dapat memberi Anda banyak wawasan dan banyak pengetahuan tentang apa yang dihadapi pelanggan lain. Masing-masing portlet ini bisa sangat detail. Seperti kanan tengah, dengan biru dan hijau, sebenarnya menunjukkan pola ujung pedang, itu semacam menunjukkan bahwa pengumpulan sampah Anda di tingkat WebLogic berjalan seperti yang Anda harapkan untuk dijalankan. Masing-masing portlet ini bisa sangat fokus atau bisa sangat tinggi. Dan alasan mengapa itu penting, atau bisa jadi penting, adalah banyak kali itu tidak cukup baik untuk hanya memiliki informasi ini dalam TI, kadang-kadang Anda harus berbagi informasi ini dengan pemilik aplikasi dan kadang-kadang dengan manajemen senior, tentang apa yang terjadi .
Saya ingin berbagi dengan Anda beberapa cerita, semacam, "Sukses di Datacenter." Dan ini adalah basis data yang terfokus dan saya punya cerita lain yang berfokus pada tingkat menengah. Tetapi untuk hari ini saya benar-benar ingin fokus pada tingkat basis data. Mari kita lihat layar membeku. Sekarang, apa yang terjadi di sini adalah bahwa toko khusus ini memiliki SLA bisnis, bahwa jika pesanan diterima pada pukul 3 sore, pesanan dikirimkan hari itu. Dan gudang sangat sibuk selama jangka waktu itu. Dan kemudian dengan membeku layar itu sangat frustasi. Dan pengawas - ini adalah perusahaan yang lebih kecil - pengawas benar-benar berjalan ke TI dan tentu saja pergi ke DBA dan berkata, "Sekarang, apa yang terjadi?" Dan apa yang kami lakukan, adalah kami dapat menunjukkan dengan tepat apa yang sedang terjadi. Sekarang ini adalah JD Edwards, aplikasi multi-tier, ini adalah layar pesanan penjualan. Anda bisa mendapatkan gambaran tentang apa bisnis itu, pada dasarnya inventaris tepat waktu, dan pada dasarnya Anda sedang melihat aplikasi gudang. Dan sekarang Anda pada dasarnya mengirim ke sejumlah situs pelanggan, toko yang berbeda. Dan apa yang kami lakukan adalah kami membuka Precise.
Sekarang dalam kasus ini, sebelum kita melihat Oracle, di sini kita melihat SQL Server, dan sekarang bagian atas menunjukkan kepada kita grafik batang bertumpuk di mana pernyataan SQL menghabiskan waktu mereka saat mengeksekusi. Setiap keadaan lemah dicatat dalam sumbu y. Sumbu x jika tentu saja lintas waktu dan Anda dapat melihat bahwa grafik batang bertumpuk berubah dari irisan waktu tergantung pada apa yang dieksekusi dan bagaimana ia menggunakan sistem. Sekarang dalam kasus khusus ini kami fokus pada urutan SQL ketiga dari atas. Ini SMS SELECT FROM PS_PROD dan Anda dapat melihat di kolom itu bahwa kami telah menangkap rencana eksekusi yang sebenarnya. Dan Anda dapat melihat seluruh jumlah eksekusi. Fakta bahwa pernyataan SQL tertentu bertanggung jawab atas 9, 77 persen dari konsumsi sumber daya selama jangka waktu yang kita lihat - dan itu poin penting, kerangka waktu, Precise menyimpan sejarah bergulir - dan pada dasarnya saya bisa menghubungi dan cari tahu apa yang terjadi pada suatu titik waktu tertentu atau dari waktu ke waktu. Saya dapat melihat tren.
Sekarang pernyataan SQL ini, Anda melihat bahwa grafik batang ditumpuk di sana, itu biru tua. Itu mengatakan kita menggunakan semua CPU. Mari kita lanjutkan dan fokus dengan mengklik tombol "TUNE" ini pada pernyataan SQL tertentu. Apa yang kita lakukan adalah kita membawanya ke bengkel itu, bengkel yang dibangun sebelumnya yang dirancang untuk mengatakan, "Apa yang akan diketahui DBA tentang pernyataan SQL khusus ini?" Dan Anda dapat melihat di sisi kanan ada tab yang disebut " Riwayat ”yang telah dipilih. Dan apa yang saya ingin Anda lakukan sekarang adalah jenis bergeser ke sisi kiri di mana dikatakan "Perubahan vs Durasi Rata-Rata, " durasi rata-rata. Dan masing-masing bar mewakili acara sehari.
Anda bisa lihat pada hari Rabu, Kamis, Jumat, waktu pelaksanaannya adalah, saya akan ke titik dua. Sumbu y menunjukkan titik empat detik, jadi koma dua. Layar sangat sedikit membeku, operasi berjalan hebat, di SLA. Sayangnya pada tanggal 27 Februari rencana eksekusi berubah dan itu menyebabkan perubahan langsung dalam waktu eksekusi. Tiba-tiba waktu eksekusi naik, empat X, mungkin lima X, dan semuanya berjalan sangat buruk. Sekarang Precise, dalam repositori sebenarnya membuat jurnal semua perubahan yang mungkin memengaruhi perilaku. Dan Anda dapat melihat di sini bahwa kami sebenarnya telah menangkap perubahan bidang sumbu. Yang di tengah mengatakan "Volume Tabel Berubah." Dan tabel-tabel itu bertambah dan kita berada tepat di puncak, ketika pernyataan SQL diuraikan, optimizer memilih satu rencana eksekusi atau rencana eksekusi berbeda.
Untungnya, pada minggu ini di sini pada hari Senin itu jatuh, jadi pada saat yang tepat. Sayangnya itu flip-flop lagi, dan Anda tahu, pengguna akhir mulai mengantisipasi pembekuan layar dan mereka mulai mengirimkan kembali layar itu dan mereka mendorong pelaksanaan eksekusi naik dan naik dan naik. Kami memiliki banyak detail, tetapi untuk menyelesaikan masalah ini dan kemudian menghindarinya di masa mendatang, kami membutuhkan satu informasi tambahan. Dan itu ditunjukkan kepada saya di bawah perbandingan rencana eksekusi tersebut. Pada 5 Maret ketika itu cepat dan efisien, di sisi kiri menunjukkan rencana eksekusi. Ketika lambat dan tidak efisien pada 12 Maret, Anda dapat melihatnya sedang melakukan join filter. Filter bergabung hanya memaksa lebih banyak konsumsi CPU, melakukan lebih banyak pekerjaan. Hasilnya identik, hanya melakukan lebih banyak pekerjaan. Ini seperti Anda pergi dan mendapatkan bahan baku satu per satu, daripada pergi ke dapur dan mendapatkan semua bahan sekaligus. Dan ada semacam ini cara yang lebih efisien untuk melakukan ini. Sekarang biasanya mengetahui hal ini, DBA dapat menggunakan rencana kueri untuk menghindari rencana eksekusi yang lambat ini dan mengunci kinerja tinggi yang cepat.
Sekarang jenis cerita perang berikutnya adalah "Laporan Terlambat." Saya pikir banyak orang dapat mengidentifikasi dengan skenario ini. Anda mungkin memiliki pelaporan ad hoc, Anda dapat menggunakan alat seperti NVISION, Anda mungkin memiliki beberapa alat pelaporan pihak ketiga. Dan yang terjadi adalah alat mengembangkan SQL. Dan seringkali SQL tidak benar-benar dikodekan dengan baik. Dan ini juga bisa berlaku untuk situasi di mana, Anda tahu, Anda memiliki beberapa aplikasi pihak ketiga, kan, di mana SQL tidak di rumah, dan sebagai DBA, "Saya tidak mengontrol SQL, apa apakah saya akan melakukan hal itu? ”Well Precise menyediakan sesuatu yang saya tidak tahu tentang alat database lain yang menyediakan dan itu adalah tampilan objek. Dikombinasikan dengan rekomendasi dan pemodelan. Jadi yang bisa kita lakukan adalah memutar visibilitas. Daripada hanya melihat aktivitas, mari kita selidiki, objek apa yang terberat pada sistem? Dan dalam jenis bagian bawah layar Anda dapat melihat baris perintah SQL dan Anda dapat melihat kolom "dalam MS-SQL". Dan tabel baris pesanan seperti sepuluh kali lebih sibuk daripada tabel lainnya dalam sistem. Saya pikir apa yang juga akan Anda perhatikan di bagian atas, alokasi ruang tumbuh dan Anda juga dapat melihat spesifikasi pada server versi perangkat lunak apa yang kami jalankan. Precise akan benar-benar memeriksa perubahan yang terlacak ke pengaturan utama. Sekali lagi, sebab dan akibat.
Sekarang, dengan fokus pada tabel baris pesanan, apa yang dapat saya lakukan dengan repositori historis terperinci saya adalah saya benar-benar dapat mengkorelasikan pernyataan SQL yang bertentangan dengan tabel baris pesanan. Dan Anda bisa mulai melihat klausa di mana dalam pernyataan SQL itu. Dan Anda mulai memperhatikan bahwa klausa di mana sangat mirip antara pernyataan SQL yang berbeda. Dan saya sarankan kepada Anda bahwa dalam sistem perekaman Anda, Anda akan menemukan hal yang sama. Karena para pengguna bisnis, analis bisnis akan ingin melakukan hal-hal seperti aktivitas bisnis agregat selama hari terakhir, minggu terakhir, bulan terakhir, kuartal terakhir, tahun lalu. Anda akan melihat sangat mirip di mana klausa, urutan oleh, kelompok oleh, dan itu berarti bahwa akan ada indeks tertentu yang masuk akal untuk pernyataan SQL tersebut.
Jadi Precise memiliki mesin rekomendasi, Anda dapat melihat bahwa di sudut kanan atas, dan apa yang dapat kita lakukan adalah benar-benar mendapatkan rekomendasi. Katakan, "Hei, saya menjalankan semua pernyataan SQL, indeks apa yang akan mengatasinya?" Indeks disajikan kepada Anda dan Anda benar-benar dapat melihat DBL. Sekarang Precise hanya baca, itu tidak menawarkan kemampuan untuk mengklik tombol dan membuat indeks, tapi itu cukup mudah dilakukan di luar Precise. Tapi inilah yang penting, Precise memungkinkan Anda untuk mengevaluasi dan memodelkan perubahan, jadi ada tombol Evaluate ini di sudut kiri bawah layar. Dan apa yang dilakukannya adalah menunjukkan pernyataan SQL sebelum dan sesudah.
Mari kita lihat pernyataan SQL ini. Apakah Anda melihat kolom ini di sini yang mengatakan "dalam MS-SQL, " dan dikatakan satu jam, empat menit? Pernyataan SQL teratas mengeksekusi atau menghabiskan sumber daya sekitar 64 menit. Dan peningkatan yang diproyeksikan adalah 98 persen. Perubahan ini akan menghemat waktu pemrosesan. Pernyataan SQL berikutnya adalah 27 menit dan pada dasarnya akan menghemat sepertiga. Itu sekitar sepuluh menit pemrosesan. Dengan dijumlahkan bersama, Anda sebenarnya akan menghemat waktu dan jam pemrosesan dengan perubahan yang diusulkan ini. Dan dengan demikian dapat mengetahui hal ini di muka, mampu memodelkan ini. Anda juga dapat menggunakan kemampuan "bagaimana-jika" untuk mengatakan, "Ya, saya tidak ingin membuat indeks itu, atau apa yang terjadi jika saya mengubah urutan kolom?" Jadi saya dapat menggunakan kemampuan pemodelan ini untuk mencari tahu apa yang akan terjadi.
Hal lain yang sangat penting adalah ketika saya melakukan perubahan saya benar-benar dapat mengukur untuk pernyataan SQL individu. Anda melihat riwayat pernyataan SQL dalam contoh sebelumnya, dan saya benar-benar dapat memverifikasi jika saya mencapai penghematan yang dimodelkan. Dan agar umpan balik itu, menyelesaikan putaran umpan balik itu sangat penting.
Baiklah, ini adalah contoh terakhir yang akan saya miliki untuk Anda. Ini adalah toko SAP dan, Anda tahu, mereka telah melakukan upgrade besar, mereka melakukan beberapa hal dengan transaksi khusus, dan pada dasarnya pengguna akhir tidak puas dengan kinerja. Jadi yang kami lakukan adalah kami bisa fokus pada apa yang dialami pengguna akhir itu. Dan Anda dapat melihat di bagian atas daftar, "CHOUSE" dan waktu responsnya sedikit lebih dari 61 detik. Hal ini membutuhkan waktu satu menit untuk dieksekusi. Sekarang Anda dapat melihat kami memiliki grafik batang bertumpuk yang diarahkan untuk SAP. Di sisi kanan menunjukkan waktu klien, waktu antrian. Yang biru adalah waktu aplikasi dan dalam lingkungan SAP, itu kode ABAP, dan kemudian database. Jadi database, Anda tahu, itu bisa Oracle, bisa SQL, bisa HANA. Kami pada dasarnya dapat menunjukkan itu.
Sekarang yang kita lakukan dengan Precise adalah kita fokus, untuk transaksi itu dan pengguna itu, pernyataan SQL apa yang keluar. Sekali lagi, konteks itu menghubungkan titik-titik. Sekarang pernyataan SQL teratas ini, Anda dapat melihatnya dilingkari, dieksekusi dalam dua milidetik. Anda benar-benar tidak dapat menyalahkan database jika dieksekusi dengan sangat cepat. Hitungan eksekusi sangat tinggi. Sebenarnya kami dapat kembali ke ABAP coder dan berkata, "Hei, apa yang terjadi?" Kami benar-benar menemukan bahwa kode dalam basis data diletakkan di tempat yang salah, bersarang di tempat yang salah dalam loop, membuat berubah dan kemudian kita bisa mengukur setelahnya. Anda benar-benar dapat melihat kinerja setelahnya. Tidak hanya di level pernyataan SQL tetapi juga di level kode kustom. Sehingga mereka bisa hidup dengan waktu eksekusi empat setengah detik. Jadi ini hanyalah beberapa contoh bagaimana Precise dapat dimanfaatkan, Anda dapat memanfaatkannya. Sama seperti rekap cepat, Precise menunjukkan kinerja berdasarkan lokasi, oleh ID pengguna akhir, ia menyediakan konteks melalui tumpukan aplikasi. Anda dapat menelusuri penyebab utama. Dan saya pikir salah satu pembeda besar adalah untuk bisa tahu, bukan hanya pernyataan SQL, tetapi mengapa pernyataan SQL berjalan lambat, dan mampu mengidentifikasi pertengkaran dan pada dasarnya menawarkan lebih banyak opsi untuk memecahkan masalah. Inilah yang ditawarkan Precise dan Anda dapat mengkonsumsi kami, Anda tahu, dengan cara yang ringan atau jika Anda memiliki masalah yang sangat dalam, sangat menantang, kami senang untuk menggunakannya juga.
Eric Kavanagh: Baiklah, saya harus mengatakan itu banyak detail yang fantastis, Bill. Terima kasih telah menunjukkan semua tangkapan layar itu. Dan dari sudut pandang saya, Anda benar-benar memenuhi apa yang saya jelaskan pada jam paling atas yaitu, nomor satu, Anda perlu memiliki alat yang tepat. Anda harus memiliki alat yang memungkinkan Anda jumlah konteks yang diperlukan untuk mengidentifikasi semua elemen dalam persamaan, seperti kata seseorang di film sekali, itu agak lucu. Tapi izinkan saya maju dan menyerahkannya kepada Dez karena saya yakin dia punya beberapa pertanyaan untuk Anda dan saya ingin mendorong satu lagi slide ini hanya untuk permen visual, jika Anda mau. Aku sebenarnya, tunggu sebentar, biarkan aku mengambil ini kembali. Tapi Dez, saya yakin Anda punya beberapa pertanyaan, bawa pergi.
Dez Blanchfield: Ya, saya tahu, wow. Alat ini datang jauh sejak saya awalnya tahu itu, dan saya tidak tahu Anda benar-benar sudah begitu jauh di tumpukan sekarang. Ini cukup membingungkan. Sangat cepat, beberapa hal. Model penyebaran, dapatkah Anda benar-benar cepat, dalam satu atau dua menit, hanya menguraikan model penyebaran tradisional atau khas. Anda menyebutkan itu tersedia sebagai mesin virtual. Itu bisa dijalankan di cloud. Dan saya kira salah satu pertanyaan yang mungkin akan muncul dan saya pikir ada beberapa pertanyaan yang muncul di bagian Tanya Jawab. Hanya untuk meringkasnya dalam ringkasan, sehingga model penyebaran normal dan jenis poros yang diperlukan, apakah secara tradisional ditempatkan di tempat atau dihosting atau di awan? Apa saja model penyebaran yang biasa Anda lihat? Dan jenis sumbu apa yang diperlukan untuk membuatnya bekerja? Apakah kita harus mengubah hal-hal pada tingkat keamanan di sekitar akses jaringan, dan sebagainya? Atau bisakah ini berperilaku sebagai pengguna akhir?
Bill Ellis: Ya, jadi saat ini sebagian besar instalasi sedang on-prem. Semakin banyak orang yang memasukkan komponen-komponen aplikasi stack ke cloud sehingga kami dapat mengatasinya juga. Penyebaran yang kami perlukan untuk menjalankan server, itu akan memenuhi spesifikasi tertentu. Kita perlu memiliki database untuk menyimpan repositori bersejarah, jadi memenuhi prasyarat itu adalah langkah pertama. Hal berikutnya adalah bahwa kita pasti perlu memiliki pengetahuan tentang aplikasi itu sendiri dan instalasi adalah penyihir didorong dan pada dasarnya mengisi kekosongan. Karena kedalaman informasi yang kami peroleh, Anda tahu, dari tingkat proses web hingga kode yang dieksekusi, kami perlu memiliki beberapa hak istimewa. Kami memiliki model data yang aman, atau model keamanan, saya harus katakan, karena agen berjalan di bawah kredensial yang benar-benar terpisah dari orang-orang yang menggunakan metadata tentang transaksi, dll? Precise memang berkomunikasi melalui TCP melalui IP dan karenanya kami memerlukan port tertentu untuk terbuka. Sebagai contoh cepat, seperti port default kami adalah 2702. Jenis detail itu adalah sesuatu jika orang tertarik, kami bisa membahasnya lebih detail. Tetapi biasanya kami sangat cepat menilai waktu. Jika seseorang menghadapi masalah besar, kita sering dapat memasang benda itu dan menyinari situasi dalam hitungan jam.
Dez Blanchfield: Ya, saya juga merasakan hal itu. Dalam model penyebaran Anda berbicara tentang skala yang sangat besar dan hingga 500 contoh dan bagaimana hal itu dapat disatukan. Pada level paling awal, seperti apa rasanya jika seseorang ingin - karena saya tahu IDERA sangat besar dalam memberikan akses ke uji coba gratis, demo gratis, dan saya ingat melihat di situs web hampir semuanya bisa dimainkan. Untuk orang-orang di sini, dan saya pikir saya melewatkannya sebelumnya, tapi saya pikir ada pertanyaan yang muncul di sekitar seperti apa bentuk situs yang khas dan bagaimana orang mendapatkan akses ke ini dan mulai bermain dengannya dan mendapatkan tipe itu pengalaman di mana mereka dapat melihat apakah mereka punya cara untuk mengatasi beberapa masalah kinerja? Dapatkah mereka mengunduh ODS dan memutarnya di hypervisor, Hyper-V atau laptop atau apakah mereka memerlukan mesin khusus untuk menjalankannya? Anda telah menguraikan arsitektur sebelumnya, tetapi hanya sebentar, dalam satu atau dua menit, seperti apa penyebaran tingkat awal hanya untuk melakukan pembuktian konsep misalnya?
Bill Ellis: Ya, jadi model kami sedikit berbeda dari alat IDERA. Kami lebih cocok dengan skenario Embarcadero di mana Anda ingin menghubungi salah satu tenaga penjualan kami. Kami ingin mendiskusikan dengan Anda apa saja tantangannya dan kemudian kami biasanya akan, Anda tahu, salah satu UK akan ditugaskan dan pada dasarnya akan bekerja melalui instalasi dengan seseorang. Biasanya Anda tidak akan menjalankan Precise di laptop Anda. Anda ingin memiliki VM atau server di dalam pusat data tempat aplikasi tinggal, untuk melakukan pengumpulan. Tapi kami akan membantu Anda melalui setiap langkah itu. Jika ada yang tertarik untuk mengejar itu, Anda pasti ingin menghubungi IDERA.
Dez Blanchfield: Salah satu hal lain yang mengejutkan saya adalah, maksud saya, banyak hal yang telah kita bahas hari ini adalah tentang bereaksi terhadap masalah kinerja. Tetapi bagi saya tampaknya, dan pada lingkungan hidup ketika orang menggunakannya, seperti pada peragaan slide pertama Anda, seseorang mengangkat telepon dan berkata, "Aplikasi berjalan lambat, tolong." upgrade atau tambalan dan perbaikan baru, Anda bisa melalui banyak perencanaan kapasitas dan pengujian stres dan memiliki Precise melihat seluruh lingkungan dan benar-benar menemukan masalah sebelum Anda bahkan menempatkan pengguna akhir di lingkungan. Apakah itu use case yang pernah Anda lihat sebelumnya atau apakah orang-orang juga melakukan hal itu, atau bukan case use tipikal?
Bill Ellis: Tentu saja, kami ingin menggunakan Precise di seluruh siklus hidup pengembangan aplikasi atau siklus hidup peningkatan juga. Precise menawarkan tampilan skalabilitas, itu akan menunjukkan jumlah eksekusi yang disandingkan dengan waktu respons. Tentunya, jika jumlah eksekusi dan waktu respons bertambah, Anda tidak melakukan scaling dan Anda perlu melakukan sesuatu. Jenis hal itu sangat membantu. Saya pikir itu sedikit kurang benar sekarang, tetapi ketika orang-orang mulai menempatkan aplikasi produksi ke VMware mereka agak ragu-ragu dan itu seperti, Anda tahu, pada hal pertama mereka akan seperti, "Oh kita perlu memindahkan ini ke fisik. ”Dan yang sebenarnya dapat kita lakukan adalah menunjukkan konsumsi sumber daya sehingga Anda dapat membuat aplikasi lebih efisien. Pada setiap langkah siklus hidup aplikasi Anda pasti ingin menggunakan Precise. Tetapi saya harus mengatakan bahwa produksi adalah hal yang paling penting bagi kinerja dan Precise diarahkan untuk memantau produksi 24/7 dan jadi Anda benar-benar tidak ingin menjalankan aplikasi produksi Anda tanpa visibilitas.
Dez Blanchfield: Tentu saja. Satu pertanyaan singkat lainnya hanya pada tes spec - kedalaman, imigrasi, UAT dan sebagainya - Maksud saya, sangat bagus untuk memiliki alat ini dan saya membayangkan pengembang aplikasi akan benar-benar senang memiliki akses ke ini melalui siklus hidup dari siklus hidup pengembangan . Dengan arsitektur yang lebih kompleks yang Anda lihat sekarang, jadi kami telah beralih dari layanan khusus ke virtualisasi dan virtualisasi, kami sekarang bergerak untuk mengurutkan, Anda tahu, adopsi outsourcing untuk hosting awan dan kami juga melihat transisi untuk kontainerisasi. Pernahkah Anda melihat banyak orang menyebarkan ini dan memodelkan jenis kawasan atau zona, sehingga seseorang mungkin memiliki - dan di Australia kami memiliki masalah yang sangat besar tentang privasi dan saya tahu di Eropa itu adalah hal yang sama dan saya pikir ini menjadi kasus yang lebih besar. di AS tempat data yang dapat mengidentifikasi saya secara pribadi sering kali harus berada dalam lingkungan yang lebih aman ke lapisan aplikasi aktual ke lapisan web. Dan jadi kami memiliki penyebaran ini sekarang di mana orang mungkin menyimpan basis data dan aplikasi mereka secara internal, tetapi mereka dapat meletakkan lapisan web dan akhir pengiriman serta aplikasi mereka dan sebagainya di penyedia cloud seperti Azure atau, atau Layanan Web Amazon dan perangkat lunak . Bagaimana cara kerjanya dengan penyebaran normal Anda? Apakah itu kasus bahwa Anda baru saja memiliki satu set pengumpul di wilayah tersebut dan mereka hanya mengumpulkan lebih banyak lagi? Seperti apa itu di dunia Precise dalam semacam pendekatan bimodal saat ini dalam menjalankan TI barang-barang warisan lama di satu tempat dan barang-barang Anda terkadang berada di awan?
Bill Ellis: Ya, jadi kami mendukung lingkungan campuran. Satu hal yang perlu dipertimbangkan adalah bahwa ada kontrak yang berbeda dengan penyedia cloud. Beberapa dari mereka tidak akan mengizinkan segala jenis agen atau segala jenis pemantauan dari luar di dalam cloud. Untuk menginstal dan memantau dengan Precise, Anda harus memiliki jenis kontrak yang memungkinkan jenis akses itu. Pasti ada beberapa batasan yang kadang-kadang harus kita selesaikan dan karenanya itu adalah kriteria penting yang Anda pertimbangkan ketika Anda, saya kira, pertama-tama menandatangani kontrak itu dan kemudian dan / atau jika Anda perlu menggunakan Precise.
Dez Blanchfield: Ya, saya telah melihat sejumlah contoh di mana bahkan dengan lingkungan basis data tradisional jika Anda mendapatkan itu sebagai bagian dari layanan, terutama dengan orang-orang seperti Azure, saat Anda mendapatkan orang-orang seperti HDInsight atau SQL sebagai layanan, sebagai platform, alat biasa Anda hanya bisa menyelam begitu dalam karena mereka tidak begitu tertarik untuk melihat apa yang ada di balik tudung. Dan jadi Anda berakhir dengan level atau kedalaman tertentu yang dapat Anda monitor dan tiba-tiba Anda tidak bisa melihat di balik tirai ajaib. Apakah swalayan adalah suatu hal? Apakah ini secara tradisional sesuatu yang akan berjalan di dalam pusat operasi jaringan di mana tim teknis, orang-orang di bawah CIO hanya akan mendapatkan akses, atau apakah ini juga sesuatu yang dapat Anda berikan tingkat akses kepada pengguna akhir? Mungkin belum tentu meja resepsionis dan SDM tradisional dan orang keuangan, tetapi lebih banyak pengguna cerdas yang melakukan, Anda tahu, seperti misalnya, ilmuwan data, aktuaris, ahli statistik, orang yang melakukan beban kerja yang sangat berat. Apakah ini suatu kasus bahwa mereka dapat memperoleh akses ke semacam akses swalayan untuk melihat apa yang terjadi ketika mereka menjalankan pertanyaan-pertanyaan berat ini dan di mana rasa sakit itu terjadi sehingga mereka dapat mengurutkan bagaimana beban kerja mereka berjalan?
Bill Ellis: Ada keamanan yang cukup baik di Precise sehingga Anda dapat mengatur pengguna yang memiliki tingkat akses berbeda. Pada tingkat yang sangat mendasar, dasbor hanya menyediakan pengawasan. Dan kemudian di dalam, Anda tahu, jika seseorang memang ingin masuk ke Expert GUI Anda dapat membatasi apa yang dapat mereka lihat dan apa yang dapat mereka lakukan. Dan semacam berputar kembali ke pertanyaan Anda sebelumnya yang, Anda tahu, dalam perawatan kesehatan Anda memiliki semua undang-undang HIPAA dan jadi pasti ada beberapa pertimbangan dan sebenarnya ada beberapa opsi penempatan sehingga kami dapat bekerja dengannya di kedua lingkungan. Satu hal yang perlu dipertimbangkan dengan data yang Anda lihat dalam presentasi ini adalah itu semua metadata tentang kinerja, bukan konten tabel, Anda tahu, dan itu benar-benar, itu tidak akan masuk ke, semacam, jenis-jenis masalah privasi.
Dez Blanchfield: Ya, saya suka itu. Saya memiliki momen eureka tentang slide layar keempat atau kelima Anda dan saya menyadari Anda hanya menarik kinerja, baik bukan hanya, tetapi Anda menarik data kinerja, Anda menarik barang, seperti yang Anda katakan, metadata keluar dari berbagai tingkat tumpukan, Anda tidak benar-benar melihat kontennya. Dan saya pikir ini adalah hal yang menarik karena ini adalah salah satu alat di mana Anda bisa menggunakannya untuk jangka pendek dan melihat apa yang terjadi di lingkungan, tetapi Anda tidak harus memiliki akses ke data itu sendiri. Anda bahkan dapat melihat cara kru dijalankan. Hal terakhir, saya kira, hanya cepat, dan kemudian saya akan kembali ke Eric jadi jika Anda punya pertanyaan, lalu minta Rebecca untuk menyelesaikannya, Anda sebutkan sebelumnya bahwa biaya overhead adalah nominal, itu adalah kasus bahwa itu bahkan overhead yang terlihat dari sisi pemantauan hal-hal dan hanya menonton latar belakang atau itu adalah jumlah overhead yang dapat diabaikan sehingga tidak layak untuk dipertimbangkan?
Bill Ellis: Ya, jadi saya pikir di tingkat basis data, Anda tahu, setiap teknologi sedikit berbeda. Pada tingkat database Precise cukup terkenal untuk mengalahkan overhead terendah. Di tingkat menengah ada, Anda tahu, ada semacam tindakan menyeimbangkan, Anda tahu, itu bukan hanya Precise, itu berlaku untuk semua orang, dalam hal visibilitas dan overhead. Dan salah satu hal adalah kami menawarkan sejumlah alat canggih untuk mengontrol apa overhead itu. Kami dirancang untuk produksi dan, Anda tahu, sangat berguna untuk mengatasi banyak masalah dalam pengembangan dan QA, tetapi, Anda tahu, tidak ada yang tahu mengetahui apa yang terjadi dalam produksi.
Dez Blanchfield: Eric, di seberang Anda, apakah Anda punya pertanyaan terakhir?
Eric Kavanagh: Ya, saya hanya akan mengatakan bahwa saya pikir Anda telah melakukan pekerjaan besar dengan menunjukkan bahwa konteks benar-benar adalah kuncinya dan hampir seperti jika kita bergerak menuju era internet ini, Anda ingin semuanya diinstrumentasi. Dan saya pikir standar sekarang di bidang manufaktur adalah melakukan itu, yang merupakan kabar baik, bukan? Karena Anda ingin dapat menarik informasi dari semua lingkungan yang berbeda ini dan menjahitnya bersama-sama. Dan saya kira saya hanya akan memberikannya kepada Anda untuk beberapa komentar tindak lanjut. Itulah yang menjadi fokus kalian adalah menyediakan antarmuka visual yang dengannya beberapa analis, seorang analis TI pada dasarnya, dapat memantau dan menganalisis apa yang terjadi di lingkungan yang kompleks ini dan kemudian mencari tahu apa yang harus diubah. Karena itu bukan hanya alat. Anda harus memiliki alat tetapi Anda membutuhkan orang yang akan menggali detail itu dan menemukan jawabannya, bukan?
Bill Ellis: Ya, saya agak melihatnya mendidih ke atas dan memprioritaskan mana yang paling banyak dibeli kembali, Anda tahu? Jika ternyata situasinya berbeda karena tidak setiap masalah ada di database. Jika basis datanya, Anda tahu, segala sesuatunya berjalan dalam sepersepuluh detik tetapi pada tingkat aplikasi hal-hal memakan waktu tiga detik, di situlah paling banyak pembelian kembali. Dan jenis kemampuan untuk mengisolasi tingkat masalah dan kemudian apa yang terjadi dalam tingkat untuk benar-benar fokus pada di mana pembelian kembali. Itu benar-benar mempercepat resolusi dan optimalisasi aplikasi dan itu jauh lebih cepat dan jauh lebih baik dan jauh lebih menyenangkan daripada orang-orang yang berkumpul di ruang konferensi, "Yah, bukan saya, itu pasti orang lain."
Eric Kavanagh: Benar. Saya melihat meme besar di hari lain yang mengatakan sesuatu seperti, "Diberitahu, bukan hanya berpendapat." Anda berjalan ke rapat, Anda memiliki informasi, Anda dapat menunjuk ke data. Itulah kuncinya dan kita akan sampai di sana, syukurlah. Oke orang-orang kita akan pergi ke depan dan menyelesaikan, tapi kami arsip semua webcast ini untuk dilihat nanti. Jangan ragu untuk memeriksanya kapan saja. Kami mendaftar semua webcast kami sekarang, seri Hot Tech dan seri Briefing Room di Techopedia.com, jadi lompat online dan lihat orang-orang itu. Dengan itu kami akan mengucapkan selamat tinggal kepada Anda. Terima kasih atas waktu Anda hari ini, Bill. Terima kasih untuk Anda dan semua kerja keras Anda, Dez. Dan kami akan berbicara dengan Anda lain kali, kawan. Hati hati. Sampai jumpa.
