Oleh Staf Techopedia, 6 September 2017
Takeaway: Host Eric Kavanagh membahas manajemen kinerja PeopleSoft dengan Matt Sarrel dan Bill Ellis dalam episode Hot Technologies ini.
Eric Kavanagh: Baiklah, tuan-tuan dan nyonya-nyonya. Halo dan selamat datang kembali sekali lagi. Ini hari Rabu jam 4 sore di Timur dan, selama beberapa tahun terakhir, itu berarti di dunia IT ini dan bisnis besar serta data, saatnya untuk Hot Technologies. Ya memang, nama saya Eric Kavanagh. Saya akan menjadi moderator Anda untuk acara hari ini.
Kita akan berbicara tentang sistem yang menjalankan bisnis, kawan; kita berbicara tentang PeopleSoft, bagaimana mengelola kinerja lingkungan yang kompleks. Saya selalu suka menyebutkan, Anda memainkan peran besar dalam acara-acara ini, jadi tolong jangan malu-malu. Ajukan pertanyaan Anda kapan saja; Anda dapat melakukannya menggunakan jendela obrolan atau T&J - dengan cara apa pun. Saya ingin mendengar apa yang ingin Anda ketahui dan itulah cara terbaik; Anda mendapatkan nilai terbaik untuk waktu Anda. Kami mengarsipkan semua webcast ini untuk didengarkan nanti, jadi ingatlah itu.
Jika sistem berjalan lambat, perlu diingat bagaimana kehidupan dulu. Foto ini sebenarnya dari tahun 1968, milik seorang wanita bernama Danelle, dan saya harus mengatakan ini benar-benar pengingat betapa banyak hal telah berubah. Dunia telah menjadi sangat kompleks dan tentu saja kebutuhan bisnis dan pengalaman pengguna cenderung berjalan seiring. Tapi hari ini, ada sedikit putuskan. Ada ketidakcocokan, seperti yang sering kita katakan, dan faktanya adalah para pebisnis selalu menginginkan hal-hal lebih cepat dan lebih cepat, tim TI yang harus memberikan adalah orang-orang yang mendapat tekanan untuk menyelesaikan pekerjaan dan itu adalah dunia yang intens di luar sana.
Saya harus mengatakan, kompetisi telah memanas di mana-mana. Jika Anda hanya melihat industri mana saja, Anda dapat melihat bahwa ada perkembangan besar akhir-akhir ini - Amazon membeli Whole Foods, misalnya. Anda dapat yakin bahwa industri bahan makanan sedang memperhatikan yang satu itu. Kami melihat ini di mana-mana, jadi sangat penting bagi para pemimpin bisnis untuk memastikan mereka menemukan cara - dan inilah kata kunci di akhir-akhir ini - mentransformasi secara digital, cara berpindah dari switchboard lama ke sistem yang jauh lebih baru dan lebih kuat. Itulah yang akan kita bicarakan hari ini.
Salah satu masalah yang dihadapi banyak organisasi, terutama yang telah ada selama beberapa waktu, adalah sistem warisan ini. Itu adalah mainframe IBM lama dari masa lalu. Ada sistem warisan di mana-mana. Salah satu lelucon adalah bahwa sistem warisan adalah sistem yang ada di produksi, artinya saat itu masuk ke produksi, secara teknis itu adalah sistem warisan. Akan selalu ada cara baru dalam melakukan sesuatu.
Dan ada beberapa perkembangan yang sangat menarik dalam beberapa tahun terakhir tentang menemukan cara untuk merekonsiliasi sistem secara virtual untuk tidak hanya meningkatkan kinerja satu sistem, tetapi untuk menemukan cara untuk membuat semacam cabang atau taktik pembebanan untuk menangani kinerja dengan cara lain. Hari ini, kita akan berbicara lebih banyak tentang cara meningkatkan kinerja sistem seperti PeopleSoft, yang tentu saja sangat kompleks. Tetapi ketika dilakukan dengan baik, ketika dimuat, ketika diimplementasikan, ketika dikelola dengan baik, itu dapat melakukan hal-hal indah. Tetapi ketika itu tidak dikelola dengan baik, saat itulah Anda memiliki semua jenis masalah.
Jadi apa yang terjadi? Anda harus realistis tentang hal-hal dan dalam lingkungan apa pun, jika pengguna tidak mendapatkan apa yang mereka inginkan, cepat atau lambat mereka pergi ke sistem bayangan. Itu terjadi setiap saat. Sistem bayangan bisa sangat produktif, mereka dapat membantu orang menyelesaikan pekerjaan. Tapi tentu saja ada banyak masalah. Tentu saja di seluruh area kepatuhan dan regulasi, sistem bayangan adalah hal yang tidak boleh. Tetapi mereka ada di luar sana dan saya pikir penting untuk diingat bahwa sistem Anda, jika sistem utama Anda tidak bekerja dengan cepat atau tidak bekerja secara efisien, cepat atau lambat akan ada solusi dan solusi tersebut bisa sangat sulit untuk digali, mereka dapat menjadi sulit untuk terbenam karena pada akhirnya menjadi kritis untuk bisnis. Mereka mungkin sulit untuk diintegrasikan, jadi perlu diingat itu ada di luar sana dan itu hanya alasan lain untuk meningkatkan kinerja.
Baru-baru ini saya mendengar ungkapan ini dan saya harus membuangnya di sana: "tirani urgensi." Saya pikir hanya mendengar bahwa Anda mungkin tahu apa yang saya bicarakan dan apa yang terjadi di sebagian besar organisasi adalah beban kerja mencapai massa kritis, dan orang-orang melakukan sebanyak yang mereka bisa, dan menjadi sangat sulit untuk mengubah apa pun. Anda akhirnya menderita “tirani urgensi” - semuanya harus dilakukan segera. Ya, meningkatkan sistem tidak langsung terjadi.
Siapa pun yang pernah hidup melalui peningkatan ERP dari satu versi ke versi lain tahu bahwa ini adalah proses yang relatif menyakitkan, jadi ingatlah ini: Jika Anda melihatnya di organisasi Anda, kenali itu. Mudah-mudahan Anda dapat menghubungi seseorang atau jika Anda adalah orang senior seperti CIO atau CTO atau CEO, mengakui bahwa ini adalah skenario yang sangat berbahaya karena begitu Anda berada di belakang bola delapan, sangat sulit untuk keluar dari belakang delapan bola.
Ini seperti keseluruhan teka-teki maraton: Jika Anda berakhir jauh di belakang dalam perlombaan semacam ini dan semua orang di depan Anda dan Anda semua masih berlari, akan sangat sulit untuk mengejar ketinggalan jika Anda tertinggal terlalu jauh. Jadi berhati-hatilah untuk itu dan ingatlah itu.
Dan dengan itu, saya akan memberikannya kepada Matt Sarrel untuk memberi kita wawasan tentang bagaimana menangani kompleksitas dengan lingkungan PeopleSoft. Matt, bawa pergi.
Matt Sarrel: OK, terima kasih, Eric. Halo semuanya. Jadi, mari kita lihat, saya akan mulai dengan memberi tahu Anda mengapa saya pikir saya orang yang tepat untuk berbicara dengan Anda tentang mengelola kinerja. Jadi saya memiliki pengalaman 30 tahun di bidang teknologi. Saya agak suka mengatakan bahwa saya bekerja keras dengan menjadi seorang, administrator jaringan, direktur IT, VP teknik di beberapa perusahaan baru. Kemudian saya membuat transisi ini menjadi direktur teknis di PC Mag. Ada fotoku di sana, tetapi pada dasarnya aku terlihat seperti anak kecil.
Dan kemudian melanjutkan dan menjadi jurnalis di berbagai publikasi berbeda seperti eWeek dan InfoWorld, menjadi analis di Gigahome, berjejaring dengan Bloor Group dan menjalankan konsultasi juga. Dan inilah saya: Gambar di sebelah kiri ini adalah seperti apa saya sekarang. Gambar di tengah ini adalah tempat di mana saya sangat bahagia - di ruangan yang penuh kabel dan lampu yang berkedip-kedip, dan di tempat yang dingin - pasti sangat dingin dan semua orang harus merasa tidak nyaman bagi saya untuk merasa nyaman dengan suhu- bijaksana. Dan ada info kontak saya, jika Anda memiliki pertanyaan tindak lanjut.
Saya ingin mengatur panggung di sini dan hanya berbicara tentang kinerja, seperti yang Eric bicarakan. Kami sekarang telah memasuki dunia ini di mana pengguna memiliki harapan ini yang telah ditetapkan oleh aplikasi dan situs web konsumen. Dan orang-orang biasanya mau pergi bekerja dan duduk di sana dan menunggu sistem mereka karena itulah yang mereka butuhkan, dan sekarang orang tidak benar-benar mau duduk di sana. Jadi ini adalah pertanyaan apakah mereka ingin motor ini terbang di trek. Mereka mungkin tidak ingin lelaki itu mengendarai sepedanya dan membawa putrinya ke sekolah. Tapi mana yang akan Anda berikan?
Dan itu sulit karena - saya benar-benar murah hati dengan satu hingga tiga detik ini sama baiknya - orang-orang menginginkan tanggapan langsung juga, dan mereka ingin akses dari mana saja. Di mana saja itu bisa di mana saja di gedung Anda atau di kampus Anda, atau itu bisa di mana saja di dunia kapan saja tergantung pada seberapa baik bisnis Anda bekerja. Dan saya kira apa yang saya bangun adalah ketika kita berbicara tentang kinerja, penting untuk memikirkan kinerja dari sudut pengalaman pengguna.
Penting untuk menentukan sasaran kinerja sebelum mengukur dan menyetel. Saya memiliki gambar seorang tuner dan kemudian seorang tuner. Pria yang sebenarnya adalah seorang tuner, dia perlu tahu untuk apa dia menyetel atau tidak ada gunanya meletakkan tangannya di atas piano dan menyetelnya. Jadi, menentukan tujuan sebelumnya, itu akan membuatnya tetap nyata alih-alih mengadaptasi tujuan agar sesuai dengan situasi saat ini. Sangat penting untuk memantau metrik dari waktu ke waktu dan menyadari bagaimana sistem berubah dengan kinerja aplikasi yang memuat pengguna, yang dipengaruhi oleh adegan sumber daya dan pola penggunaan.
Selalu penting untuk mengaitkan semua ini bersama-sama dengan pengalaman pengguna atau insiden dukungan, menetapkan garis dasar untuk kinerja yang Anda harapkan dapat disampaikan dan ketika Anda mendekati penyimpangan dari garis dasar itu, memiliki peringatan proaktif sehingga Anda dapat mengambil tindakan sebelum kita menekan status "gagal paus". Dan Anda tahu bahwa membutuhkan kemampuan untuk dapat menentukan dan mengatasi akar penyebab masalah kinerja sangat cepat dan mudah. Dan lagi, ini lebih awal, lebih baik, bukan?
Kami tahu, dari sejarah masa lalu melihat upaya pengembangan, semakin awal Anda dapat menemukan dan memperbaiki masalah kinerja, semakin baik Anda. Jika Anda menunggu sampai semua kode Anda atau sistem Anda hidup untuk memulai pengujian kinerja atau untuk mulai mengungkap masalah, saya tidak akan mengatakan itu sudah terlambat, tapi sekali lagi, sekarang Anda adalah orang yang mendapat awal yang buruk di maraton dan sekarang Anda bermain mengejar ketinggalan daripada melompat keluar dan maju. jadi bagaimana kamu melakukan ini? Apakah Anda mengantisipasi rata-rata dan beban puncak Anda?
Dan Anda melanjutkan dan mengukur server fisik Anda atau server virtual Anda atau contoh cloud Anda atau wadah Anda dan sumber daya kontainer Anda dan kemudian menjalankan bukti konsep dan menjalankan pilot? Ini adalah saat-saat seperti ini, akhir di mana Anda ingin menangkap sesuatu, meskipun masih lebih baik Anda menangkapnya dalam produksi daripada mengabaikannya dalam produksi. Tetapi sungguh, pada saat Anda berada di pilot Anda, Anda seharusnya sudah menetapkan metodologi dan prosedur Anda di sekitar pemantauan dan peningkatan berkelanjutan.
OK, begitu banyak perusahaan - kita berbicara tentang transformasi digital. DevOps, dalam revolusi DevOps memainkan peran besar dalam transformasi digital itu. Dan ini adalah proses ujung ke ujung yang benar-benar tidak pernah berhenti. Jadi seperti dua tangan saling menggambar, dan ini adalah hal yang baik. Ini adalah loop tak terbatas antara kedua tangan rencana, kode, build, test, release, deploy, operasikan, monitor, kembali ke rencana. Itu memberi makan dirinya sendiri dan kami mengotomatiskannya sehingga berjalan dengan cepat. Ini menciptakan loop umpan balik pemantauan kinerja produksi dan menggunakannya untuk secara proaktif mengungkap masalah kinerja dan memperbaikinya sebelum berdampak pada seluruh basis pengguna Anda.
Dan satu hal lagi, sekarang setelah Anda mendapatkannya, para pengembang TI dan staf operasi bergerak sangat cepat dan selaras, Anda juga dapat dengan mudah menyelaraskan upaya ini dengan staf bisnis juga. Kinerja perangkat lunak perusahaan adalah binatang yang kompleks. Orang mungkin menyamakannya dengan tim sepak bola yang duduk di depan papan tulis mengambil arah, dan semuanya bekerja secara terpisah dan semuanya bekerja bersama. Saya selalu menganggapnya sebagai cerita lama ketika saya mendapatkan mobil pertama saya dan saya memperbaiki satu hal. Saya memperbaiki pendingin udara dan kemudian yang terjadi kemudian sisa sistem pendingin gagal. Jadi, Anda mendapatkan poin rasa sakit dan semuanya berjalan bersama dan melakukan penyesuaian. Anda harus mengatur semuanya sedemikian rupa dan membangun proses sehingga ketika Anda membuat perubahan, Anda memahami bagaimana segala sesuatu berdampak pada yang lainnya.
Dan juga hati-hati dan periksa. Uji, batalkan, laksanakan. Dan lagi kita sampai pada masalah membangun pemantauan berkelanjutan dan program peningkatan kinerja. Dan ini, sebenarnya, slide terakhir saya. Sementara kami berbicara tentang kerumitan ini, dan ini adalah kerumitan yang indah seperti bagian dalam arloji ini, kami memiliki begitu banyak karya yang bergerak ke PeopleSoft. Setiap hal memengaruhi segala hal di atas dan ke bawah tumpukan. Dan ada begitu banyak tempat berbeda di mana Anda dapat mencari kunci untuk masalah kinerja yang Anda dapat dengan mudah tersesat tanpa alat yang tepat dan tanpa proses yang tepat. Dan lagi dalam segala hal, dalam banyak kasus apa yang saya pikir telah kita pelajari adalah Anda dapat memecahkan masalah infrastruktur, tetapi variabel besar akan menjadi kode aplikasi kustom Anda. Dan dengan demikian memiliki proses yang tepat untuk menguji dan terus meningkatkan kode aplikasi Anda adalah apa yang akan menjadi kuncinya.
Dan itulah akhir dari bagian saya, dan saya akan menyerahkannya kepada Bill.
Eric Kavanagh: Baiklah, Bill, izinkan saya memberi Anda kunci untuk WebEx di sini. Saya suka kompleksitas yang indah itu - itu bagus. Anda punya beberapa kutipan yang sangat bagus di sana, Matt. OK, Bill, bawa pergi. Buka "mulai cepat" jika Anda ingin berbagi layar. Kalian semua.
Bill Ellis: Terima kasih, Matt, dan terima kasih, Eric. Sekedar konfirmasi, bisakah kalian melihat layar saya sekarang?
Eric Kavanagh: Ya, tentu saja.
Bill Ellis: Jadi kita akan berbicara tentang produk IDERA Precise for PeopleSoft dan visibilitas yang dapat mereka berikan untuk membantu Anda berhasil mengelola tumpukan aplikasi yang kompleks. Cara untuk memposisikan kesulitan adalah bahwa satu aplikasi, minimal enam teknologi, banyak pengguna akhir dan sangat sulit untuk menjawab bahkan pertanyaan sederhana. Apakah pengguna akhir mengalami masalah? Siapa pengguna akhir, apa yang mereka lakukan, apa penyebabnya?
Apa yang biasanya kita lihat adalah situasi ini - dan ini dapat berlaku untuk PeopleSoft serta aplikasi lain atau PeopleSoft berinteraksi dengan aplikasi lain - ada di dalam kumpulan data, atau itu bisa menjadi cloud saat ini, pengguna akhir tidak terlalu peduli tentang kompleksitas itu. Mereka hanya ingin menyelesaikan transaksi, pendekatan, pencarian inventaris, pelaporan kartu waktu, hal-hal semacam itu. Jika hal-hal lambat atau tidak tersedia, biasanya semua orang yang cerdas dan bermaksud baik ini tidak menyadari sampai pengguna akhir mengeluh.
Itu semacam celah visibilitas di sana, dan kemudian apa yang bisa terjadi adalah itu dapat memulai proses yang memakan waktu dan membuat frustrasi di mana orang mungkin membuka alat dan mereka melihat, sayangnya, hanya sebagian dari tumpukan aplikasi. Begitu sulitnya menjawab pertanyaan-pertanyaan dasar itu.
Dan sering kali mungkin ada masalah dan Anda akan pergi ke administrator WebLogic dan dia akan berkata, “Ya, ingatannya, pengumpulan sampah semuanya tampak hebat. Saya benar-benar tidak berpikir itu WebLogic. "Anda pergi ke administrator DBA dan mereka berkata, " Yah database, itu berjalan seperti kemarin. Sepuluh teratas terlihat bagus. Mungkin administrator penyimpanan memukul Anda dengan beberapa metrik seperti I / Os per detik atau throughput, yang merupakan metrik tingkat bingkai dan mungkin tidak mencerminkan aplikasi khusus Anda, apalagi database atau proses tertentu. "
Jadi mereka semua memiliki metrik yang tampaknya menunjukkan bahwa masalahnya ada di tempat lain, namun pengguna akhir ini mengalami masalah atau telah melaporkan masalah, tetapi bagaimana kita bisa menyelesaikan masalah ini dengan cara yang lebih baik? Dan cara yang lebih baik, cara Precise - atau ini adalah salah satu cara yang kami tawarkan - adalah untuk mengukur transaksi pengguna mulai dari browser melalui jaringan, ke server web, ke Java Jolt, ke Tuxedo, ke dalam basis data termasuk DB2 dan akhirnya ke penyimpanan.
Dan apa ini menunjukkan bahwa waktu total mengatakan, "Nah, siapa yang punya masalah?" Dan kemudian kita dapat mengidentifikasi pengguna akhir dengan cara mereka masuk ke PeopleSoft dan kita juga dapat menangkap melalui terjemahan Tuxedo apa yang dieksekusi panel PeopleSoft mengeksekusi.
Jadi timing dimasukkan ke dalam repositori bersejarah yang kita sebut basis data manajemen kinerja dan ini menjadi satu bagian musik yang sangat menyederhanakan siapa, apa, kapan, di mana, mengapa. Tepat juga mencakup rekomendasi. Mungkin yang paling penting adalah karena kami menangkap semua informasi setiap saat - di tingkat staf teknis TI - Anda dapat mengukur sebelum dan sesudah. Jadi Anda dapat membawa pengukuran dengan pengukuran atau Six Sigma ke seluruh operasi kinerja.
Jadi mari kita lihat seperti "sehari dalam hidup." Pertama-tama, Anda mungkin membuka layar peringatan Precise dan di sinilah Anda akan mendapatkan peringatan dini. Lansiran paling atas adalah Anda memiliki lansiran aktivitas. Jadi itulah pengguna yang melakukan transaksi dan kami pada dasarnya tidak memenuhi SLA kami. Demikian juga, kami memiliki status saat ketersediaan - dan ini pada dasarnya mengatakan bahwa sebagian dari infrastruktur aplikasi kami tidak tersedia - sehingga kami dapat menelusuri dan kami benar-benar dapat melihat bagaimana Tuxedo membuat contoh dalam formulir dan Anda benar-benar dapat melihat bahwa salah satu contoh turun. Semua aktivitas didorong ke satu contoh ini dan itu harus berurusan dengan itu. Kami pada dasarnya telah membuat bottleneck.
Sekarang, seperti halnya, untuk aktivitas yang berjalan pada ini, Anda benar-benar dapat mulai untuk menemukan bahwa, meskipun kami memiliki masalah infrastruktur secara keseluruhan, ada cara untuk meningkatkan efisiensi pemrosesan dalam JVM khusus untuk WebLogic ini. Dan di sinilah ada hal yang benar-benar penting: Banyak kali orang-orang bergerak seperti ke awan dan mereka berkata, "Berapa banyak CPU dan berapa banyak memori yang Anda butuhkan?"
Nah, sisi lain dari koin yang dikenal sebagai kapasitas adalah efisiensi pemrosesan. Jika saya menggunakan lebih sedikit memori, jika saya menggunakan lebih sedikit CPU, saya hanya tidak perlu banyak. Dan seperti yang Matt katakan sebelumnya, semuanya terkait. Sekarang yang bisa saya lakukan adalah saya bisa membuka layar transaksi PeopleSoft dan di layar, sumbu y adalah waktu respons, sumbu x adalah waktu sepanjang hari.
Kami memiliki grafik batang stack di sini yang menunjukkan waktu klien. Itu sebenarnya browser, server web. Hijau adalah waktu Jawa, jenis merah muda adalah Tuxedo, biru tua adalah waktu basis data. Profil ini tidak terjadi dengan sendirinya; itu terjadi karena panel PeopleSoft tertentu - mereka telah dieksekusi dan mereka disajikan kepada Anda pada waktu tanggapan. Sebenarnya ada waktu dari setiap langkah dalam aplikasi serta grafik batang yang menunjukkan aplikasi di sini panel demi panel. Saya juga dapat menelusuri dan menemukan pengguna tertentu atau memberi peringkat pengguna saya.
Layar ini memungkinkan saya untuk menentukan pengguna tertentu dengan nama masuk. Pikirkan tentang betapa luar biasa atau betapa kuatnya ini. Banyak kali, ini bukan hanya tentang infrastruktur dan bagaimana pengaturannya, ini adalah bagaimana pengguna akhir menggunakan sistem. Anda mungkin memiliki karyawan baru atau seseorang memiliki fungsi pekerjaan baru: Mungkin tidak tahu cara menggunakan aplikasi dengan benar. Ini sebenarnya dapat membantu mengidentifikasi peluang pelatihan.
Sisi lain dari koin adalah jika saya dapat fokus pada pengguna tertentu - di sini saya melihat pengguna itu dalam transaksi khusus mereka dan waktu respons yang mereka alami - saya dapat langsung membahas pengalaman pengguna tertentu pengguna. Ini bukan lagi tentang metrik umum pada tingkat sistem, ini tentang pengalaman pengguna akhir dan itu sangat kuat. Bagian-bagian dari lingkungan Anda tentu saja internal, SDM, dll. Mungkin ada bagian lain yang dihadapi pelanggan. Apa pun itu, Anda ingin memberikan pengalaman pelanggan yang terbaik dan paling produktif.
Sekarang untuk panel tertentu, saya bisa masuk dan menelusuri untuk menjawab pertanyaan. Jadi ini semacam penyelaman dalam yang bisa kita lakukan untuk mengungkap apa yang terjadi dan Anda bisa melakukan penyelaman dalam ini sebelum Anda memanggil pengguna akhir atau jika pengguna akhir memanggil Anda, Anda dapat memulai proses untuk katakan, "Nah di mana tepatnya akar masalahnya?" Dan itu tidak akan seperti penggunaan CPU dan penggantian, itu akan berada pada kode aplikasi yang mereka gunakan.
Mari kita menelusuri dan kita akan melihat pada manajemen konten dan Anda benar-benar dapat melihat analisis transaksi itu: mulai browser, titik masuk ke server web ke Java Jolt dan kami benar-benar menunjukkan kode yang sedang dieksekusi ke dalam Panel Tuxedo, akhirnya ke pernyataan SQL di mana Precise mengungkapkan teks pernyataan SQL yang dijalankan oleh panel PeopleSoft khusus ini.
Setiap orang yang kita ajak bicara memiliki alat, tetapi yang tidak mereka miliki adalah konteks. Menghubungkan titik-titik atau mengikuti transaksi dari browser sampai ke pernyataan SQL adalah konteks. Apa gunanya ini, seperti DBA Anda, daripada melihat hal-hal pada tingkat contoh atau basis data, sekarang saya dapat menyelidiki pada tingkat pernyataan SQL.
Jadi saya bisa mengatakan, "Yah, apa hambatan untuk pernyataan SQL individu, " dan ini sangat kuat. Harap pertimbangkan bahwa transaksi ini tidak dapat berjalan lebih cepat daripada pernyataan SQL dan setiap transaksi bisnis yang signifikan berinteraksi dengan sistem catatan. Basis data, suka atau tidak, adalah fondasi kinerja, dan jika saya bisa begitu terperinci untuk fokus pada pernyataan SQL individual yang penting untuk transaksi bisnis, saya benar-benar dapat membawa permainan saya ke tingkat berikutnya.
Hal lain yang mungkin Anda perhatikan di sini adalah perhitungan persentase kontribusi yang diberikan Precise. Browser itu sendiri sebenarnya merupakan bagian penting dari tumpukan aplikasi. Anda memiliki eksekusi JavaScript, Anda memiliki waktu render, Anda memiliki komponen halaman, GIF, JPEG. Dan Anda sebenarnya menemukan bahwa aplikasi Anda mungkin berperilaku sangat berbeda di bawah Chrome versus IE dan versi yang berbeda. Precise akan dapat menunjukkan hal itu kepada Anda juga dan mungkin ada saat-saat di mana sebenarnya ada hambatan atau pertikaian dalam browser yang dapat menyebabkan hal-hal seperti pembekuan layar.
Mampu mengidentifikasi yang memungkinkan TI untuk tidak menggonggong pohon yang salah, tetapi untuk mengatasi akar penyebab dasar berbagai masalah yang dapat muncul. Sekarang apa yang dapat saya lakukan adalah untuk pernyataan SQL tertentu, kemudian saya bisa menganalisis apa yang terjadi pada pernyataan SQL itu. Jadi di sini kita beralih ke tampilan pakar basis data.
Salah satu hal yang membedakan Precise di tingkat basis data adalah bahwa kami mengambil sampel berdasarkan sub-detik. Ini dibandingkan dengan pesaing kami yang hanya terlihat sekali setiap 10, sekali setiap 15 menit. Sehingga pada tingkat granularity, tingkat resolusi adalah urutan besarnya lebih baik dari pesaing kita.
Dan sekali lagi, karena basis data adalah bagian dari yayasan kami, kami akan memungkinkan DBA Anda benar-benar membawa kinerja ke tingkat berikutnya. Jadi saya dapat melihat bahwa pernyataan SQL ini benar-benar menghabiskan 50 persen jika waktunya berlatih mengakses subsistem yang tersimpan, 50 persen waktunya menggunakan CPU. Klik tombol tune dan saya kemudian bisa masuk dan menelusuri rencana eksekusi dan apa yang mendorong pola penggunaan itu.
Sekarang kutipan dari salah satu pelanggan kami - jika mereka tidak ada di Oracle Shop mereka menggunakan alat Oracle yang disebut OEM dan OEM benar-benar jenis database atau contoh yang terfokus - itu adalah DBA yang terus mencari apa daftar 10 teratas? Tetapi dengan Precise kami dapat menghubungkan titik-titik ke pernyataan SQL individual dan sehingga granularity memungkinkan DBA untuk benar-benar menyesuaikan pada tingkat transaksi dan bukan hanya pada tingkat basis data yang jauh lebih tinggi.
Poin kedua yang sangat penting bagi pelanggan ini adalah Precise, dengan menerjemahkan apa yang rumit URL Anda menjadi nama panel PeopleSoft - jika saya di TI dan saya dapat berbicara tentang manajer pohon, manajer konten, halaman SDM tertentu, Dengan begitu orang yang saya coba bantu tahu bahwa saya sebenarnya mencari dan memahami apa yang mereka lihat karena bukan lagi hieroglif ini, itu nama yang mereka kenal.
Salah satu pertanyaan yang kami ajukan - sepertinya selalu, jadi saya pikir saya hanya akan secara proaktif menjawab pertanyaan - bagaimana Anda menangkap ID pengguna PeopleSoft itu? Biarkan saya melalui beberapa langkah. Ini adalah layar masuk PeopleSoft. Untuk mengaksesnya, saya harus menavigasi ke server web saya, dan layar ini muncul. Ketika aplikasi diinstrumentasi dengan Precise, layar ini sebenarnya mengandung skrip Precise dan saya dapat mengungkapkan dengan melakukan klik kanan, lihat sumber. Dan ini benar-benar akan menunjukkan kepada saya kode yang membentuk halaman yang mendasarinya dan di sini di bingkai halaman sebenarnya Precise untuk kode web dan ini memungkinkan saya untuk menangkap layar masuk, alamat IP, jenis browser, keseluruhan banyak informasi tentang rendering dan pengalaman pengguna akhir yang sebenarnya. Maka ketika saya memasukkan nama pengguna saya dan mengklik masuk, Precise kemudian dapat mengukur apa yang saya lakukan.
Saya membuka, pergi ke manajer pohon, saya ingin melakukan operasi pencarian, mengisi bidang dan saya klik pencarian. Set hasil disajikan kepada saya, jadi saya sudah jelas melintasi seluruh tumpukan aplikasi hingga ke basis data. Bagaimana Precise menunjukkan ini? Mari kita pergi dan melihat. Buka Precise, saya masuk, saya bisa melihat aktivitas, saya bisa mengklik tab aktivitas yang akan memunculkan layar ini. Ini adalah URL yang tidak diterjemahkan. Saya dapat menunjukkan kepada pengguna dan di sini adalah ID pengguna saya yang baru saja saya masuki dan inilah aktivitas saya.
Anda dapat melihat bahwa saya menggunakan Firefox versi 45 untuk membahas hal ini. Saya menjalankan aplikasi 12 kali dan meninggalkannya pada dasarnya ketika seseorang meninggalkan halaman web sebelum sepenuhnya merendernya, yang menunjukkan masalah bisnis. Jadi itulah bagaimana kami dapat mengambil ID pengguna akhir. Sangat bagus, orang-orang sangat menghargai ketika Anda tahu persis apa yang sedang terjadi.
Sekarang kami ingin menggeser persneling sedikit aneh. Kami sedang melihat transaksi nanti. Kami melakukan penyelaman mendalam pada transaksi tertentu dan melihat pernyataan SQL-nya. Sekarang saya ingin menggeser persneling dan melihat beberapa teknologi lain di dalam tumpukan aplikasi PeopleSoft dimulai dengan WebLogic.
Jadi di sini adalah contoh WebLogic dan Anda dapat melihat aktivitas dari waktu ke waktu. Anda memiliki laporan keuangan. Ini memberitahu saya langsung dari kelelawar, memori digunakan hampir maksimal. Salah satu hal yang kami temukan adalah kebanyakan orang menjalankan seluruh tumpukan aplikasi, atau setidaknya sebagian, di bawah lingkungan bersama, sangat sering itu adalah VMware. Anda harus menyeimbangkan berapa banyak sumber daya yang Anda minta dan berapa banyak yang Anda butuhkan. Anda tidak ingin menjadi babi sumber daya. Demikian juga, Anda tidak ingin menempatkan kendala pemrosesan dengan tidak meminta memori yang cukup dalam kasus ini.
Konfigurasi juga penting untuk manajemen kinerja. Jadi kita sebenarnya bisa masuk ke pengumpulan sampah memori dan semua penghitung JMX WebLogic jadi saya tahu persis kesehatan bentuk WebLogic saya.
Sekarang ke Tuxedo. Tuxedo di banyak toko adalah semacam kotak hitam dan itu adalah bagian yang sangat penting dari PeopleSoft. Ini semacam lem yang menyatukan semuanya jadi saya agak menganggapnya sebagai perpanjangan dari sistem operasi. Ini adalah sesuatu yang Anda gunakan dan konfigurasikan dengan sangat hati-hati. Kebetulan - ini adalah catatan kecil - dalam komentar pembukaan Eric telah menyebutkan "tirani urgensi, " dan saya pikir itu benar-benar berperan ketika toko PeopleSoft mempertimbangkan untuk pindah dari UI klasik ke UI cair karena Anda akan temukan bahwa Anda berada di belakang kurva karena cara UI yang cair melatih lingkungan PeopleSoft.
Sekarang Anda memiliki masalah di WebLogic, di Tuxedo, di database dan di penyimpanan di sini hanya karena HTML5 melakukan banyak sekali pengiriman pesan. Mungkin setidaknya 10x apa yang dilakukan UI klasik dan olahpesan tambahan berarti lalu lintas tambahan. Jadi konfigurasi Tuxedo harus dimodifikasi untuk mengakomodasi lalu lintas tambahan. Beberapa hal tentang layar ini berakhir di sebelah kanan kami memiliki grafik kelebihan waktu untuk waktu respons tertimbang, waktu respons rata-rata serta jumlah eksekusi.
Di sini kami memiliki informasi tentang semua domain Tuxedo di lingkungan. Kami membagi layanan, pengguna, proses server dan juga IP. Saya bisa menggeser ini ke jumlah eksekusi dan menyajikannya dalam urutan menurun sehingga saya bisa melihat apa yang paling sering dieksekusi. Saya juga dapat menggulir ke bawah untuk mengungkapkan domain; kebanyakan orang memiliki banyak domain di lingkungan mereka, untuk menyebarkan aktivitas, dan saya dapat mengatur kepatuhan SLA, oleh karena itu diperingatkan di lapisan Tuxedo.
Jika Anda memiliki antrian, Anda memiliki masalah berbeda yang muncul karena konfigurasi. Anda biasanya - karena ini bersifat global - Anda biasanya tidak akan melakukan perubahan saat itu juga. Anda agak ingin secara bertahap meningkatkan sistem sebagai bagian dari proses QA yang memantul kembali ke titik yang telah dibuat Matt sebelumnya tentang mengatasi masalah kinerja di awal proses. Jauh lebih baik untuk memiliki konfigurasi yang benar ketika Anda pergi ke produksi daripada pergi ke produksi dan mengetahui bahwa konfigurasi tidak cocok dengan pola penggunaan. Saya sangat suka perkenalan yang Eric dan Matt sediakan hari ini. Saya pikir mereka benar-benar tepat sasaran dalam hal tantangan yang Anda hadapi dalam mengelola dan mengembangkan lingkungan PeopleSoft.
Sekarang, saya mengatakan ini sekali sebelumnya - saya pikir itu layak untuk dikatakan lagi: Setiap transaksi bisnis yang signifikan berinteraksi dengan database. Jadi mari kita telusuri bagaimana Precise dapat memberikan informasi tambahan. Di sini adalah contoh Oracle tertentu. Pendekatan persis yang sama yang kita lihat - sumbu y adalah waktu eksekusi, sumbu x adalah waktu sepanjang hari, tetapi sekarang grafik batang stack adalah status eksekusi di dalam Oracle. Ini menunjukkan kepada kita apa saja kendala pemrosesan pada sistem. Di bawah sini sebenarnya ada laporan temuan yang memberi tahu saya bahwa Anda memiliki penyangga log redo tinggi ini.
Saya juga melihat versi pilih ini dari PSVersion. Ini sebenarnya menghabiskan banyak sumber daya. Secara kebetulan, karena kami sedang mengambil sampel dan kami memberikan tampilan resolusi tinggi ini tentang apa yang sebenarnya terjadi pada sistem, Anda mungkin akan terkejut dengan konsumen sumber daya yang sebenarnya di sistem Anda, karena jika Anda hanya mencari setiap 10 menit, itu bukan akan menunjukkan kepada Anda apa yang dimaksud dengan konsumen sumber daya tersebut. Dan dengan mengetahui apa yang menjadi konsumen sumber daya sejati, Anda dapat benar-benar mengatasi pemrosesan yang sebenarnya pada kemacetan atau pada sistem.
Sekarang di sini kita telah melompat ke tab aktivitas dan ini adalah aktivitasnya. Anda dapat melihat kita sedang melihat CPU, subsistem penyimpanan, kunci aplikasi, OS menunggu, RAC, komit, server Oracle, komunikasi, dan agregat internal secara bersamaan. Ini adalah sumbu y, ini adalah waktu eksekusi total.
Berikut adalah pernyataan SQL yang mendorong profil ini dan salah satu hal yang Anda lihat adalah latensi rendah ini - dua milidetik tetapi dengan hampir 4.500 eksekusi berarti pernyataan SQL sebenarnya adalah konsumen sumber daya nomor satu di sistem Anda, dan itu bagus untuk tahu. Itu juga tidak menunggu di kunci atau menunggu. Menggunakan CPU 100% dari waktu. Itu tidak berarti tidak ada hal-hal yang tidak dapat saya lakukan. Ada banyak hal yang bisa saya lakukan jika saya tahu pernyataan SQL dan objek apa yang sedang diakses. Dan inilah beberapa cara yang dapat kami bantu.
Sekarang di sini ada pencarian ini dan ini dapat menempatkan kita dalam konteks masing-masing program PeopleSoft dan masing-masing program ini melayani tujuan yang berbeda di dalam PeopleSoft. Anda benar-benar dapat mulai alamat di tingkat basis data bagaimana aplikasi tersebut digunakan.
Dan jika saya memilih program tertentu, saya kemudian dapat mengisolasi pernyataan SQL yang dikirimkan oleh program tersebut sehingga saya bisa sangat berfokus pada aplikasi daripada berfokus pada teknologi database ketika saya pada dasarnya mencari dan melihat optimasi database dan konfigurasi database. Saya hanya ingin membawa ini menjadi perhatian Anda. Seringkali banyak organisasi besar dibagi menjadi DBA infrastruktur dan DBA aplikasi. Tepat, dengan menunjukkan aplikasi serta konsumsi sumber daya, kami benar-benar dapat menjembatani kesenjangan dan solusi ini berguna untuk kedua jenis DBA pada sistem.
Sekarang, bagian ini benar-benar semacam pamer dari apa yang bisa kita lakukan di tingkat basis data. Dan apa yang terjadi di sini adalah kami memiliki layar yang membeku, ada pilihan dari PS_Prod dan apa yang kami lakukan adalah kami mengklik tombol ini dan apa yang dilakukannya adalah membawa kami ke ruang kerja SQL ini. Sekarang, bagi Anda yang bukan DBA, ini mungkin tidak terlihat menarik. Untuk orang-orang yang merupakan DBA, Anda mungkin menemukan ini sangat menarik. Apa yang kami tunjukkan di sini adalah durasi pernyataan SQL khusus ini versus perubahan pada sistem. Dan ini menunjukkan hari Rabu, Kamis, Jumat, durasinya sekitar 2/10 detik. Sabtu dan Minggu perusahaan ini tidak berfungsi - untung mereka. Datang Senin, ada perubahan: Rencana akses berubah. Rencana akses yang baru tiba-tiba muncul di sini. Itu sebenarnya cukup lambat sehingga mengakibatkan pembekuan layar.
Sekarang jika saya seorang DBA, saya perlu informasi tambahan untuk mengetahui akar penyebab sebenarnya. Saya perlu tahu pilihan pengoptimal database yang dibuat. Jadi Precise menawarkan perbandingan ini yang menunjukkan rencana eksekusi yang cepat dan efisien ketika semuanya berjalan dengan baik serta rencana eksekusi yang lambat dan tidak efisien. Gabung filter ini umum untuk DBA yang menjalankan PeopleSoft. Apa yang dilakukan filter adalah mencari setiap baris dalam satu tabel, terlihat pada setiap baris dalam tabel bergabung - yang membutuhkan banyak CPU. Ini sangat tidak efisien karena tidak ada penyaringan hanya dengan melihat bagian dari baris yang dibutuhkan, tetapi oleh pernyataan SQL dan bahwa inefisiensi menghasilkan waktu eksekusi yang lebih lambat. Oleh karena itu, mereka akhirnya memperlambat panel PeopleSoft dalam pembekuan layar dan Precise dapat mencapai akar penyebab yang benar yang tidak akan pernah Anda ketahui kecuali Anda memiliki alat yang mengungkapkan kode aplikasi, pernyataan SQL, dan sebagainya.
Itu semacam penyelaman yang dalam. Kami sekarang akan menarik tampilan hingga 10.000 kaki persegi dashboard. Di Precise, dasbor benar-benar bukan untuk tim teknis - itu benar-benar untuk Anda gunakan untuk berbagi informasi dengan operasi, mungkin dengan tim aplikasi, mungkin dengan rantai komando Anda. Dan satu set dasbor mungkin menampilkan panel PeopleSoft dan waktu klien sehingga Anda tahu apa pengalaman pengguna akhir. Dasbor lain mungkin telah dikonfigurasi untuk operasi dan dasbor ini mungkin terlihat apakah ada peringatan yang dibekukan? Kami sebenarnya memiliki peringatan di OS, web, WebLogic, Tuxedo, dan tingkat basis data. Tidak ada peringatan di sini, waktu respons rata-rata. Anda dapat melihat bahwa kami menjalankan sekitar sepertiga detik. Di sini saya benar-benar dapat melihat infrastruktur saya menunjukkan semua VM di lingkungan saya dan saya bisa mulai masuk ke pemrosesan, load balancing dan saya juga bisa melihat domain Tuxedo saya. Lingkungan khusus ini memiliki enam domain berbeda sehingga saya dapat melihat domain tersebut dan saya benar-benar bisa masuk ke web balancing.
Sekarang, repositori bersejarah Precise yang PMDB, database manajemen kinerja, memiliki banyak metrik. Dan kadang-kadang seseorang ingin tahu tentang jumlah akses browser atau Anda bisa melakukan hitungan akses berdasarkan jenis browser atau kinerja berdasarkan jenis browser. Ada banyak hal yang dapat dilakukan untuk memberikan visibilitas tambahan pada sistem Anda.
Di sini, yang ini, kita benar-benar melihat penggunaan memori WebLogic dan Anda melihat pola gigi gergaji yang bagus, penggunaan memori. Ada pengumpulan sampah, itu mengambil un-referensi. Ini naik kembali dan jadi ini adalah pola yang sangat bagus yang Anda suka lihat. Jadi ini semacam memandang lingkungan PeopleSoft sebagai kumpulan subsistem dan ini akan sesuai untuk operasi. Pertanyaan paling mendasar adalah, "Apa yang terjadi di server?" Precise memiliki semua visibilitas ini. Ini juga menyediakan metrik server juga. Jadi di sini Anda sebenarnya dapat mengukur CPU, memori, I / O, server, pengguna pada sistem dan Anda memiliki visibilitas penuh. Dan itulah cara - yang dikombinasikan dengan tren jangka panjang - adalah bagaimana orang menggunakan Precise untuk perencanaan kapasitas.
Dan saya hanya ingin melemparkan sedikit catatan di sana. Biasanya sebuah toko akan memiliki begitu banyak anggaran untuk perangkat keras, untuk server, begitu banyak anggaran untuk staf. Bagaimana Anda akan berinvestasi, di mana Anda akan menempatkan taruhan Anda? Menggunakan Precise, Anda mendapatkan keunggulan karena Anda melihat bagaimana subsistem penyimpanan digunakan. Jika Anda melakukan banyak I / O acak, Precise akan menunjukkan kepada Anda itu. Ini akan membantu membenarkan investasi dalam penyimpanan solid-state. Itu mungkin lebih penting bagi toko Anda daripada membeli CPU tambahan jika utilisasi CPU rendah.
Anda ingin berinvestasi di tempat kemacetan pemrosesan yang sebenarnya, di mana Anda benar-benar dapat memperoleh hasil. Dan dengan Precise menangani semuanya mulai dari efisiensi pemrosesan kode aplikasi hingga kapasitas, kami memungkinkan Anda untuk menilai dan mendokumentasikan di mana kebutuhan itu ada dalam angka.
Sekarang bagian terakhir isyarat dan peringatan sebenarnya adalah cara ini dimulai. Ingat bahwa? Kami melihat peringatan bahwa ada SLA kinerja dan kami melihat bahwa contoh WebLogic turun. Jadi mari kita lihat antarmuka peringatan. Dan sekali lagi, apa yang terjadi? Salah satu hal yang ingin saya tunjukkan pada tampilan ini adalah Precise tidak hanya memiliki lansiran kinerja dan lansiran status tentang ketersediaan, kami juga memiliki lansiran yang sedang tren. Alasan bahwa tanda tren penting adalah bahwa jika sistem Anda menganggur atau memiliki satu atau dua pengguna, mungkin semuanya berjalan dengan baik. Tidak sampai Anda mulai menambahkan pengguna dan mereka mulai melakukan lebih banyak aktivitas yang Anda mulai pertengkarkan untuk data, untuk sumber daya di tingkat Tuxedo, di tingkat WebLogic, di tingkat jaringan, di tingkat basis data. Dan pertikaian itu menghasilkan penurunan kinerja dan akhirnya Anda bisa melewati batas dan itu peringatan kinerja, dan pada dasarnya Anda tidak memenuhi sasaran SLA untuk organisasi. Dan set peringatan ini sangat bagus.
Tingkat web, di sebelah kiri, tingkat web sebenarnya mengukur pengalaman pengguna akhir dan kemudian Anda masuk ke teknologi dalam tumpukan aplikasi yang mendasarinya. Ini adalah semacam layar arsitektur kita tentang bagaimana kita melakukan semua ini. Idealnya Anda ingin memiliki server Precise yang independen terhadap lingkungan atau lingkungan yang dipantau. Satu server Precise dapat menangani banyak aplikasi.
Untuk PeopleSoft dan untuk database Oracle dan DB2, kami memang membutuhkan agen lokal. Jika lingkungan PeopleSoft Anda didukung oleh SQL Server, ada opsi untuk melakukan agentless. Kami juga memiliki agen untuk Sybase. Inti dari model keamanan kami adalah bahwa data dikumpulkan di sini, sedangkan pengguna Precise mengautentikasi ke Precise. Ini benar-benar proses yang terpisah, kredensial terpisah, otentikasi terpisah, dan itulah bagian dari model keamanan kami. Dan ada detail tambahan.
Saya pikir ini sudah cukup untuk pengenalan arsitektur untuk saat ini. Jika ada pertanyaan yang membara, silakan tanyakan, seperti yang Eric katakan.
Sama seperti rekap cepat, solusi ini dirancang untuk 24 oleh 7 dalam produksi. Sangat disarankan agar Anda menggunakan kami di QA. Jika Anda melakukan pengembangan in-house, mulailah menggunakan kami dalam pengembangan. Kami akan menerjemahkan URL yang rumit, URI menjadi nama panel PeopleSoft. Ketika saya berbicara tentang produksi, biaya overhead kami sangat rendah sehingga Anda memiliki visibilitas, Anda selalu tahu apa yang terjadi, Anda mengidentifikasi pengguna akhir.
Saya tidak harus masuk dan mendefinisikan transaksi ini - hanya ada titik koneksi alami dari browser, URL, titik masuk, koneksi server web ke WebLogic, konteks undangan hingga yang menyediakan pernyataan SQL. Kemudian kita dapat menangkap pernyataan SQL dan apa yang dilakukannya. Precise adalah basis data yang cerdas dan saya pikir ini adalah faktor pembeda bagi kami dan memungkinkan DBA Anda untuk berkolaborasi, meningkatkan visibilitas aplikasi.
Poin terakhir adalah karena kami selalu aktif, kami selalu mengumpulkan, Anda selalu dapat mengukur sebelum dan sesudah dan mengukur peningkatan atau, dalam kasus yang jarang terjadi Anda mungkin telah mengubah kinerja, Anda akan tahu itu dan Anda bisa menggulungnya segera kembali. Sebagian besar pesaing kami, yang mereka lakukan adalah jika Anda perlu melihat informasi tambahan, Anda harus mengaktifkan visibilitas tambahan dan biasanya bahwa visibilitas tambahan membebani banyak overhead. Dengan Precise, Anda selalu memiliki visibilitas dan Anda selalu dapat memecahkan masalah. Jadi jika Anda pergi ke situs web Precise, silakan periksa salah satu produk Precise, apakah itu Precise untuk Oracle. Kami terdaftar sebagai Platform Kinerja Aplikasi Tepat dan ada tombol di sana untuk meminta demo.
Sebenarnya, jika saya membagikan layar saya, saya pikir saya mungkin hanya menavigasi ke sana untuk menunjukkan kepada Anda seperti apa itu supaya Anda dapat melihat ini dari awal. Inilah situs web IDERA. Anda pergi ke produk. Saya dapat memilih salah satu komponen Precise ini dan saya hanya ingin melihatnya dalam aksi. Ini akan memulai proses kami untuk berbagi informasi tambahan yang mungkin penting bagi situs Anda. Atau jika Anda ingin tahu lebih banyak tentang migrasi ke UI yang lancar, Anda dapat menghubungi kami.
Dan yang itu, Eric, aku ingin memberikan tongkat estafet padamu.
Eric Kavanagh: OK, bagus. Saya harus mengatakan sekali lagi - presentasi yang agak komprehensif dan mengesankan di sana, Bill. Anda menyebutkan banyak hal yang ingin saya tanyakan. Kami tidak punya banyak waktu - sekitar sembilan menit - dan saya ingin Matt mendapat kesempatan untuk mengajukan beberapa pertanyaan juga, dan memiliki setidaknya satu atau dua dari hadirin.
Tapi Anda menyebutkan sesuatu yang saya pikir sangat, sangat menarik sehubungan dengan bagaimana Precise dapat membantu dalam pengadaan untuk tim TI karena Anda dapat menunjukkan, Anda dapat membuat kasus kepada siapa pun yang membuat keputusan bahwa apa yang Anda butuhkan lebih solid penyimpanan, misalnya, atau yang Anda butuhkan adalah peningkatan jaringan atau apa pun masalahnya. Tapi itu masalah besar. Apakah Anda sering melihat perusahaan mengenali itu dan menggunakan itu atau Anda mencoba menginjili itu lagi?
Bill Ellis: Ya, sebenarnya keduanya, dan masalahnya adalah pola penggunaan, bahkan untuk aplikasi paket seperti PeopleSoft, pola penggunaannya berbeda di setiap situs. Saya beruntung melakukan migrasi PeopleSoft di bank, dan bank menggunakan sistem buku besar yang sangat berbeda dari kebanyakan organisasi. Anda sebenarnya dapat memiliki transaksi individual yang dilakukan di cabang, mereka semua memposting ke buku besar.
Dan alih-alih memposting lusinan atau ratusan buku besar, Anda sebenarnya memposting ratusan ribu. Jadi begitulah saya terlibat dalam Precise karena pola penggunaannya dan memungkinkan kami untuk mengatasinya, tetapi kebutuhan aplikasi baik pada level kode, level konfigurasi, maupun pada level infrastruktur. Jadi saya sangat percaya dan saya ingin menginjili itu juga karena Anda tidak boleh membuat keputusan perangkat keras hanya berdasarkan pemanfaatan. Anda harus mendasarkannya pada kebutuhan lingkungan Anda.
Eric Kavanagh: Dan ada pertanyaan dari seorang peserta, dan kemudian, Matt, saya akan menyerahkannya kepada Anda untuk satu atau dua pertanyaan. Yah, ini bagus dan itu lucu karena itu jawaban besar dan panjang yang bisa Anda berikan. Peserta bertanya: "Bagaimana Anda mengumpulkan metrik kinerja di ujung pengguna setelah penerapan dan selama pengujian?"
Saya pikir Anda melakukan pekerjaan yang cukup baik untuk menyelami seberapa dalam dan kaya metrik kinerja itu. Anda bahkan berbicara tentang sub-detik untuk beberapa hal ini dibandingkan dengan setiap lima menit atau 10 menit. Saat itulah Anda akan mendapatkan tingkat detail yang diperlukan untuk menemukan jawaban Anda, bukan?
Bill Ellis: Ya, jadi yang terpenting adalah bahwa pengumpul informasi kinerja berdasarkan teknologi. Jadi ketika kami melakukan penempatan, kami perlu tahu tentang bagaimana tumpukan aplikasi Anda dibangun, mulai dengan sistem operasi, versinya, versi Tuxedo apa, WebLogic, versi alat People apa yang Anda jalankan.
Dan memang benar-benar desain agen-agen yang melakukan itu, pengumpulan data yang memungkinkan kita untuk mengungkapkan bahwa tingkat visibilitas Precise menyediakan. Dan visibilitas itu, saya pikir, kadang-kadang bisa sedikit mengintimidasi orang. Tetapi jika tujuan Anda adalah untuk benar-benar masuk dan meningkatkan hal-hal dan membuat kinerja menjadi 11, itu benar-benar tingkat visibilitas yang ingin Anda miliki. Dan jika Precise dapat menyediakannya dan biaya overhead yang rendah, pertanyaannya adalah mengapa tidak? Jadi saya pikir itu pertanyaan yang bagus dan tolong hubungi kami jika Anda ingin membahasnya lebih lanjut.
Eric Kavanagh: Oke, bagus. Dan Matt, apakah Anda punya pertanyaan?
Matt Sarrel: Saya pikir saya baik-baik saja. Maksudku, aku sudah berurusan dengan WebEx yang crash di sini.
Eric Kavanagh: Oh tidak. Kita membutuhkan Precise untuk memahami dengan tepat mengapa.
Matt Sarrel: Ya, saya kira pertanyaan yang saya pikirkan ketika Anda berbicara, Bill, adalah jika Anda bisa membahas sedikit tentang bagaimana banyak tim bisa mendapatkan pada halaman yang sama ketika memecahkan masalah kinerja, karena saya tahu itu sesuatu yang muncul berulang kali adalah siapa yang bertanggung jawab untuk apa dan bagaimana semua orang bisa bekerja sama untuk memberikan kualitas terbaik kepada karyawan.
Bill Ellis: Ya, jadi staf TI cenderung mahal. Di sebagian besar toko, Anda dibagi menjadi beberapa tim yang didasarkan pada teknologi, mengingat kompleksitas teknologinya. Salah satu hal besar yang terjadi adalah ada masalah kinerja dan ada banyak kali konflik, ruang perang bersatu. Dan di situlah setiap orang memiliki metrik untuk entah bagaimana membebaskan tingkat mereka karena mereka tidak memiliki konteks. Mereka melihat apa yang terjadi di tingkat WebLogic daripada apa yang terjadi di tingkat kode transaksi. Atau mereka melihat level database daripada pernyataan SQL individual transaksi.
Dan dengan mampu menentukan tingkat masalah dan kode masalah di dalam tingkat itu, apa yang dilakukannya adalah membebaskan tim lain untuk tidak pergi atau menghabiskan waktu dalam sumber daya mencari masalah yang tidak ada dalam wilayah mereka. Jika ini adalah masalah basis data, pergilah ke DBA dengan informasi yang mereka butuhkan untuk menyelesaikan masalah. Mereka akan senang melakukannya.
Namun demikian, jangan sia-siakan Tuxedo, tim bantuan WebLogic yang berfokus pada masalah dalam basis data. Demikian juga, jika masalah terjadi pada konfigurasi WebLogic, jangan luangkan waktu DBA di semacam ruang perang mencoba untuk membela diri. Pergi dan perbaiki masalah di WebLogic.
Kami menemukan bahwa staf TI menghargai Precise karena penghematan waktu, karena biasanya ruang perang itu tidak dianggarkan ke dalam rencana waktu untuk setiap organisasi FTE. Ini seperti tambahan waktu. Dan dengan demikian dapat menangani masalah-masalah itu dengan lebih efisien sangat penting. Dan bagi organisasi yang meluncurkan UI lancar, mampu meningkatkan produksi dan menyelesaikan masalah yang sebenarnya mereka alami dalam produksi benar-benar penting bukan untuk staf atau tim individu, tetapi sebenarnya bagi manajemen TI secara keseluruhan karena itu akan menjadi berita yang sangat buruk jika mereka harus mundur. Jadi, pertanyaan yang bagus, karena bukan hanya teknologinya. Ini selalu tentang orang-orang.
Matt Sarrel: Benar, orang-orangnya dan prosesnya. Ya itu satu-satunya pertanyaan yang muncul untuk saya selama demo. Jika ada yang lain dari penonton?
Eric Kavanagh: Ya, saya hanya akan melemparkan yang terakhir kepada Anda, Bill, dan Matt membicarakan hal ini secara singkat dalam presentasinya. Kami sudah mulai melihat pemotongan ini. Ini masih sangat memandang ke depan, tetapi wadah dan penggunaan containerisasi dan Docker dan hal-hal semacam itu, seberapa besar bola curv yang melemparkan kalian?
Bill Ellis: Jadi kata itu berarti hal yang berbeda tergantung pada teknologi yang berbeda. Jadi kami mengembangkan produk kami untuk menjaga wadah di tingkat basis data dan di tingkat aplikasi. Dan sebagai bagian dari itu, ini adalah seluruh lingkungan dengan gerakan, awan, dan kami beroperasi di dalam awan. Tetapi ada proses penemuan dan tergantung pada bagaimana aplikasi ini - termasuk PeopleSoft - berkembang, kami mengembangkan solusi pemantauan kami sehingga kami dapat memberikan tingkat kedalaman yang sangat berharga di masa lalu.
Eric Kavanagh: Ya. Dan saya harus mengatakan, setiap kali saya melihat demo ini, saya hanya kagum pada granularitas yang Anda miliki dan itulah yang Anda butuhkan untuk dapat mengumpulkan pemahaman dan Anda perlu memiliki pendidikan tentang situasi yang normal., apa standar.
Dan kalian menawarkan banyak konten di sekitar itu - membantu orang mengidentifikasi apa yang normal, apa yang tidak normal. Anda berbicara tentang tanda tren, misalnya, ini semua mekanisme yang dapat Anda gunakan untuk lebih memahami adalah sesuatu yang salah, adalah sesuatu yang tidak salah, dan tentu saja dari sana harus menelusuri untuk menemukannya, tetapi Anda memiliki semua data.
Bill Ellis: Ya, dan itu hal yang sangat penting; Saya pikir Matt telah membicarakan hal itu. Apa yang normal Lingkungan yang berbeda memiliki tingkat normal yang berbeda. Jika Anda menjalankan dengan perangkat keras canggih, logika dan data Oracle, apa yang normal di toko Anda atau apa yang dapat dicapai di toko Anda akan berbeda daripada jika Anda menggunakan infrastruktur yang kurang kuat. Jadi hal pertama adalah mencari tahu apa yang normal, mulailah menghitung garis dasar itu dan dengan cara itu Anda bisa mulai melakukan perbaikan dari sana.
Eric Kavanagh: Oke, itu poin yang bagus. Kami punya satu pertanyaan terakhir yang masuk, sepertinya. Hanya satu pertanyaan terakhir yang akan saya sampaikan kepada Anda, Bill. Adakah perbedaan antara SQL dan pemantauan kinerja basis data dari sudut pandang data tingkat sistem dan tingkat aplikasi? Apa perbedaan antara pemantauan kinerja SQL dan database, dari perspektif Anda?
Bill Ellis : Ya, tidak ada yang terjadi dalam database sampai pernyataan SQL dijalankan. Pernyataan SQL pernyataan adalah apa - kontrol penguncian, menunggu, pertentangan untuk sumber daya di tingkat data dan di tingkat SQL Server. Dan jadi jika saya dapat melihat driver pernyataan SQL dan dampaknya pada sistem, saya telah menyebabkan efek; Saya dapat menautkan apa yang dipedulikan aplikasi DBA dengan apa yang dipedulikan infrastruktur DBA sampai saya benar-benar dapat memanfaatkan alat Precise secara maksimal.
Jika saya seorang DBA infrastruktur dan saya sedang melihat hal-hal seperti pemanfaatan, saya benar-benar baik mengelola dengan kuas yang luas dibandingkan jika saya dapat melihat pernyataan SQL individu dan saya benar-benar dapat meminimalkan sumber daya konsumsi - apakah itu CPU, memori, I / O - Saya dapat mengatasi kedua sisi dari koin yang sama.
Eric Kavanagh: Oke, semuanya. Kami membakar lebih dari satu jam. Besar, terima kasih banyak kepada teman-teman kami di IDERA. Terima kasih banyak kepada Matt Sarrel karena bergabung dengan kami hari ini. Kami mengarsipkan semua webcast ini untuk ditonton nanti, jadi silakan kembali dan biasanya hanya dalam beberapa jam arsip naik. Jadi periksa itu dan yang harus saya katakan adalah saya suka barang ini, saya suka Precise, saya suka bisa masuk ke dalam rumput liar. Dan saya tidak tahu alat lain yang memungkinkan Anda untuk menggali ke semua bagian dan bagian dari tumpukan aplikasi yang berbeda dari apa yang dimiliki orang-orang di IDERA dengan Precise.
Dengan itu, kami mengucapkan selamat tinggal, kawan. Terima kasih lagi, kami akan berbicara dengan Anda lain kali.
