Habra panas Halo semuanya!Hari ini perusahaan kami berusia 28 tahun, dan untuk menghormati acara yang menyenangkan ini, kami memutuskan untuk berbagi materi baru dengan Anda.Terima kasih atas bantuan Anda dengan terjemahan penulis reguler kami Yuri PonomarevDukungan OBIEES.Penulis artikel ini adalah Michelle Scamin, pendiri dan mitra pengelola perusahaan yang menyediakan layanan Reading Rewards. Kembali pada tahun 2009, Michelle menderita kenyataan bahwa putranya, berusia 8 dan 9 tahun, membaca terlalu sedikit. Buku sama sekali tidak dapat bersaing dengan komputer dan permainan video, jadi Michelle dan suaminya memutuskan untuk mengembangkan sistem di mana anak-anak memperoleh waktu bermain game komputer dengan membaca buku.Sebagai konsultan TI dan pengembang aplikasi web, Michelle telah mengembangkan perangkat lunak yang memungkinkan anak-anak untuk merekam waktu mereka membaca dan menonton TV, dan orang tua untuk melacak waktu ini. Ini adalah awal dari layanan Reading Rewards.Dan sekarang, sebenarnya, sebuah artikel.
Jadi, Anda telah memilih aplikasi Oracle APEX yang luar biasa untuk kecepatan rekaman - Anda tidak perlu banyak menulis. Dan, seperti kata pepatah lama, apa yang terjadi - itu tidak bisa dihindari!Pada 2010, saya membuat aplikasi untuk mencoba membacakan dua putra kecil saya. Saya akui, pada saat itu saya tidak memikirkan kinerja, dan memiliki beberapa “count count (*) from big table” yang sangat menarik yang tersebar secara strategis di seluruh kode.Hei, anak-anak lelaki saya tidak terlalu banyak membaca, jadi meja-meja ini cukup kecil pada saat itu ...Katakan saja saya cukup naif ketika saya merilis aplikasi ke publik, dan saya tidak berharap untuk memuatnya ribuan pengguna setiap hari, menghasilkan 150.000 tampilan halaman per hari.
Statistik dari Google AnalyticsSelain fakta bahwa semua minat ini sangat menarik bagi saya, saya sama sekali tidak siap untuk banyak klik. Saya punya masalah kinerja. Anda hanya harus mengakui bahwa saya menjadi mahasiswa yang rajin melakukan tuning kinerja Oracle APEX dan berpikir bahwa saya hanya akan membagikan beberapa hal yang saya pelajari selama bertahun-tahun.Bagaimana cara mengidentifikasi bottleneck?
Ada banyak hal yang perlu Anda perhatikan ketika mengevaluasi kinerja aplikasi Anda. Anda akan ingin mempertimbangkan masalah yang terkait dengannya, browser. Masalah jaringan. Konfigurasi ORDS. Konfigurasi basis data, termasuk kemungkinan indeks yang hilang. Apakah ada kunci basis data dalam game? Harapan?Segera setelah Anda merasa bahwa infrastruktur mendasar Anda dalam kondisi baik dan tidak bersalah, mungkin sudah waktunya untuk mengalihkan perhatian Anda ke aplikasi itu sendiri, mengingat frontend Anda (Javascript dan CSS) dan backend (SQL dan PL / SQL).1. Frontend: hal-hal urutan file
Pertama-tama, jika Anda memasukkan CSS khusus dan komponen JS, pastikan CSS Anda ada di bagian atas halaman dan JavaScript ada di bagian bawah .Ini memastikan bahwa pengguna Anda setidaknya mendapatkan komponen antarmuka pengguna, bahkan jika beberapa file logika bisnis belum dimuat.2. Lihat monitor aktivitas
Ini selalu merupakan tempat yang bagus untuk memulai. Jika semuanya tampak lambat dan Anda tidak tahu ke mana harus mencari, monitor aktivitas di lingkungan pengembangan APEX dapat memberikan informasi yang berharga.
Tautan ke monitor aktivitas dari konsol pengembangan APEX
Setiap tampilan halaman di ruang kerja dan aplikasi Anda dicatat, termasuk informasi tentang pengguna, cap tanggal / waktu, aplikasi, page_id, dan yang paling penting, waktu aplikasi berjalan.Laporan tampilan halaman favorit saya adalah "Dengan Kinerja Halaman Tertimbang."
Lihat contoh dari monitor aktivitas APEX
Perhatikan baik-baik setiap halaman yang memiliki banyak Acara Halaman (yang berarti sering dikunjungi), dan tingginya nilai runtime aplikasi rata-rata. Saya ingat bagaimana Joel Kalman pernah berkata bahwa segala sesuatu di atas 0,5 detik harus ditinjau. Tentu saja, ini adalah generalisasi yang agak kasar dan mungkin (tidak) berhubungan dengan kasus spesifik Anda menggunakan APEX.Monitor aktivitas memudahkan untuk bekerja dengan IR, tetapi jika Anda perlu sedikit lebih detail dan Anda ingin menjalankan laporan di ruang kerja yang berbeda, Anda dapat menggunakan kueri berikut dalam SQL Developer untuk membuatnya sedetail mungkin:select workspace
, application_name
, application_id, page_id
, count(*) total_page_events
, avg(elapsed_time) avg_elapsed_time
, sum(elapsed_time) elapsed_time
from apex_workspace_activity_log
where view_date between to_date('201911190900','RRRRMMDDHH24MISS') and to_date('201911191200','RRRRMMDDHH24MISS')
group by workspace, application_name, application_id, page_id
order by 6, 7 asc
3. # WAKTU # variabel pencarian
Jadi, Anda mungkin menemukan halaman yang lambat. Dan sekarang apa?Nah, Anda dapat menggunakan variabel pencarian # TIMING # di bagian bawah wilayah laporan Anda jika Anda ingin mengambil dan menampilkan waktu yang telah berlalu. Ini dapat membantu Anda mengidentifikasi area laporan paling lambat di halaman yang dapat Anda perhatikan. Ini sangat berguna pada halaman dasbor di mana Anda dapat memiliki banyak pekerjaan.
Menggunakan baris substitusi # TIMING # di bagian bawah laporanMenjalankan laporan kemudian akan memberikan hasilnya:
Satu hal yang saya sukai dari fungsi ini belum tentu menentukan daerah mana yang membutuhkan banyak waktu untuk berjalan (saya bisa mendapatkan ini dari saya debug windows, lihat di bawah), tetapi ia menawarkan informasi kepada pengguna akhir.Seringkali saya menemukan bahwa mereka akan meminta data yang saya tahu akan divisualisasikan selama berabad-abad. Paling tidak, itu memberi mereka beberapa gagasan tentang apa yang mungkin terjadi dan mengapa mereka harus menunggu sedikit lebih lama dari yang diharapkan.4. Jalankan halaman dalam mode debug
Lebih baik lagi, jalankan di Debug LEVEL9 untuk mengakses rencana eksekusi untuk laporan Anda.Jendela debug akan menampilkan semua yang terjadi pada halaman Anda, dan itu akan menampilkan runtime untuk setiap komponen. LEVEL9 akan menghasilkan banyak baris, tetapi Anda dapat mengurutkannya dalam urutan waktu yang menurun untuk menunjukkan bahwa halaman Anda membutuhkan waktu paling banyak untuk di-render.5. Waspadalah terhadap panggilan v (”)
Jika Anda menemukan laporan yang berkinerja buruk, Anda dapat memeriksa apakah Anda menggunakan notasi v (") ketika Anda bisa menggunakan variabel bind.select task_name
from tasks
where assigned_to=:APP_USER
atauselect task_name
from tasks
where assigned_to=v('APP_USER')
Dalam tabel besar, perbedaan antara dua pernyataan bisa sangat besar, karena v (") sebenarnya adalah panggilan fungsi. Ini berarti bahwa Anda tidak akan memanfaatkan indeks apa pun dan kueri akan menghasilkan pemindaian tabel penuh.Kiat: jika Anda perlu merujuk keadaan sesi APEX dalam tampilan (di mana Anda tidak dapat menggunakan variabel yang mengikat), pertimbangkan untuk menggunakan subquery skalar yang dapat bekerja hampir seperti halnya variabel mengikat Anda. Lihat:select task_name
from tasks
where assigned_to = (select v('APP_USER') from dual)
Terima kasih kepada John Scott karena menawarkan ini di salah satu acara yang saya hadiri.6. Hindari Substitusi String dalam Pertanyaan, jika memungkinkan
Waspadai string pencarian dalam kueri.Pertimbangkan, misalnya, situasi di mana Anda mungkin perlu mendekodekan atau pernyataan kasus dalam kueri untuk menentukan halaman yang ingin Anda percabangi:select case when dept_no=20 then
'f?p=&APP_ID.:3:&SESSION.::::P3_DEPTNO:'||deptno
else
'f?p=&APP_ID.:2:&SESSION.::::P2_DEPTNO:'||deptno
end as link
, deptno
, dname
from dept
Menggunakan variabel bind: SESSION, bukan string & SESSION lookup. dapat membuat perbedaan besar dan menghemat banyak waktu penguraian Oracle. Versi variabel mengikat memungkinkan Oracle untuk menggunakan kembali permintaan.select case when dept_no=20 then
'f?p=&APP_ID.:3:'|| :SESSION ||'::::P3_DEPTNO:'||deptno
else
'f?p=&APP_ID.:2:'|| :SESSION ||'::::P2_DEPTNO:'||deptno
end as link
, deptno
, dname
from dept
Jika Anda tertarik untuk mempelajari lebih lanjut tentang ini, lihat video indah Jorge Rimblas tentang string wildcard, variabel yang mengikat, dan tautan APEX.7. Gunakan parameter deklaratif dalam kondisi Anda jika memungkinkan
Saat menggunakan kondisi pada komponen halaman, selalu gunakan parameter deklaratif bila memungkinkan. Mereka akan jauh lebih efektif.8. Gunakan pengaturan pagination secara rasional
Dalam laporan besar, opsi pagination yang dipilih dapat memiliki efek signifikan. Terlepas dari kenyataan bahwa sejak versi 18.1 APEX telah secara signifikan meningkatkan pemrosesan pagination (baca posting indah ini oleh Karsten Charsky), Anda dapat menonaktifkan parameter "rentang garis dari X ke Y dari Z" di salah satu dari mereka jika Anda memiliki masalah kinerja dalam laporan yang sangat besar.9. Hindari HTML dalam kueri dan gunakan ekspresi HTML
Jika memungkinkan, gunakan atribut ekspresi HTML untuk kolom laporan untuk menyertakan atribut HTML / CSS yang mungkin Anda perlukan.10.
Dengan demikian, Anda telah mengidentifikasi area laporan yang sangat lambat yang telah Anda konfigurasikan sebaik mungkin.Apakah saya perlu memperbarui data setiap kali saya melihat halaman? Pikirkan laporan dasbor, khususnya data penjualan, dll. Bahkan data transaksi yang diterima 1 menit yang lalu dapat cukup lengkap dalam banyak kasus.Jika demikian, Anda dapat menggunakan opsi caching wilayah.
Pengaturan cache server di wilayah APEX.Secara default, caching dinonaktifkan, tetapi jika Anda mengaktifkannya, Anda dapat memilih opsi batas waktu cache, dimulai dengan hanya 10 detik. Bahkan 10 detik akan membantu kinerja dasbor, yang digunakan oleh sejumlah besar pengguna! Dan jelas bahwa meningkatkan parameter ini akan membantu lebih banyak lagi.Perhatian, jika Anda memiliki data sensitif yang bergantung pada pengguna, Anda dapat memilih opsi "cache oleh pengguna" atau bahkan "cache per sesi".
Pengaturan yang tersedia saat mengaktifkan caching regionalJika Anda memutuskan untuk mengaktifkan caching, Anda dapat memberi tahu pengguna Anda tentang pembaruan data terbaru. Jika demikian, Anda dapat menggunakan fungsi APEX_UTIL.CACHE_GET_DATE_OF_REGION_CACHE .11. Pindahkan PL / SQL ke paket
Pastikan Anda memindahkan kode ke paket. Mereka sudah dikompilasi dalam database, yang berarti akan ada lebih sedikit overhead untuk analisis dinamis.Proses halaman Anda harus hanya paket panggilan bila memungkinkan.Stephen Feuerstein telah menulis artikel yang sangat rinci tentang penulisan PL / SQL untuk Oracle Application Express , yang mungkin ingin Anda baca. Dia sudah berusia beberapa tahun, tetapi dia masih relevan!12. Luncurkan Advisor!
Saya jarang melihat orang menggunakan fitur hebat ini, tetapi ini adalah sesuatu yang harus kita semua lakukan secara teratur. Setiap kali saya bertanya-tanya apa lagi yang dia temukan.13. Gunakan opsi bangun untuk menonaktifkan dan mengaktifkan komponen
Nah, Anda sudah mencoba SEMUA HAL INI, tapi tetap macet tidak jelas apa. Jika Anda akan "menggambar kembali halaman Anda lagi," Anda harus mempertimbangkan untuk menggunakan opsi build untuk berbagai komponen halaman Anda.Jangan letakkan kondisi yang tidak terbatas pada komponen, jika tidak, Anda akan kehilangan semua kondisi berharga Anda! Selain itu, komponen abadi memiliki fitur yang tidak menyenangkan untuk tinggal di aplikasi Anda selamanya ...Buat parameter build baru menggunakan Status: Kecualikan.Terapkan secara bergantian ke berbagai komponen halaman Anda. Mulai halaman Anda dengan setiap perubahan dan lihat apakah itu bekerja lebih baik. Jika halaman Anda tiba-tiba berjalan lebih cepat, Anda mungkin telah menemukan penyebabnya.14. Memahami bagaimana berbagai pengaturan IR dapat memengaruhi kinerja APEX.
Dengan laporan interaktif yang dijalankan dengan buruk, berbagai pengaturan, parameter, atau filter yang diterapkan oleh pengguna Anda dapat memperburuk pekerjaan yang buruk (ya, memang benar).Seperti yang disebutkan sebelumnya, yang terbaik adalah memulai dengan menggunakan mode debug LEVEL9 dan mengkonfigurasi permintaan nyata yang terpisah. Periksa rencana eksekusi, periksa indeks, sesuaikan jika memungkinkan. Ingat bahwa setiap tampilan (tabel, pengelompokan, bagan, ringkasan) adalah permintaan terpisah yang mungkin memerlukan penyesuaian. Kemudian itu berubah lagi saat menggunakan filter pencarian atau filter tajuk kolom!Pengaturan MaxRowCount Anda juga ikut berperan, dan Anda harus membuatnya sekecil mungkin. Tidak ada jawaban yang tepat untuk ini, dan Anda mungkin harus bermain dengan nomor yang berbeda sebelum Anda mendapatkan sesuatu yang berfungsi untuk pengguna Anda.Pada dasarnya, pertimbangkan untuk menghapus atau mengubah beberapa skenario perilaku default. Pengembang memiliki banyak kontrol ketika datang ke fitur yang diaktifkan untuk pengguna. Perlu mencoba berbagai pengaturan, dan jangan lupa untuk berkonsultasi dengan pengguna Anda untuk memastikan bahwa Anda sepenuhnya memahami persyaratan mereka.Akhirnya, jika Anda menemukan bahwa IR Anda masih terlalu lambat, Anda dapat mempertimbangkan 2 alternatif:- Fungsi-fungsi tabel pipeline (pilih * dari tabel (my_rpt_pipelined)) -> mereka dapat bekerja lebih baik di query kompleks.
- Hasilkan Laporan Koleksi (APEX_COLLECTION)
Terima kasih kepada Karen Cannell untuk tips IR yang sangat berguna ini.15. Melacak
Ketika semuanya gagal, Anda dapat menambahkan "& p_trace = YA" ke akhir URL Anda untuk membuat file jejak yang dapat dianalisis dengan menggunakan utilitas TKPROF.Informasi lebih lanjut tentang penelusuran SQL dapat ditemukan di sini .Masih macet? Saya selalu kagum dengan respon dari komunitas Oracle APEX . Bantu, minta bantuan di berbagai forum atau di Twitter, seseorang pasti akan mengarahkan Anda ke arah yang benar. Saya telah menerima tanggapan yang tak terhitung jumlahnya untuk meminta bantuan. Anda akan menemukan jawabannya! Ingat saja: ini bukan APEX, paling sering Anda, Anda sendiri :-)