Isu dan penyelesaian prestasi aplikasi kanvas biasa

Anda boleh membina aplikasi kanvas dengan menggunakan pelbagai tatasusunan sumber data. Pilih sumber data dan penyambung berdasarkan keperluan perniagaan dan senario yang anda mereka bentuk aplikasi. Untuk aplikasi perusahaan, Microsoft Dataverse adalah sumber data yang disyorkan kerana ia menyediakan beberapa faedah prestasi. Untuk aplikasi dengan beberapa transaksi, anda boleh menggunakan sebarang sumber data lain yang tersedia dalam persekitaran anda.

Untuk pertimbangan prestasi aplikasi, fikirkan tentang bilangan pengguna yang akan menggunakan aplikasi apabila ia telah diterbitkan, jumlah transaksi cipta, dapatkan semula, kemas kini, dan padam (CRUD); jenis interaksi data, akses geografi dan jenis peranti yang pengguna miliki.

Dalam artikel ini, anda akan mengetahui tentang beberapa isu prestasi paling biasa yang boleh membuatkan aplikasi kanvas berjalan dengan perlahan dan cara menyelesaikan isu tersebut. Maklumat ini akan membantu anda menambah baik prestasi aplikasi dengan rancangan dan pertumbuhan perniagaan anda dalam fikiran.

Kami akan mulakan dengan beberapa isu prestasi biasa yang berlaku tanpa mengira penyambung yang digunakan. Dalam bahagian kemudian, anda akan mengetahui tentang isu prestasi dan penyelesaian khusus untuk pelbagai penyambung.

Sebelum anda bermula, pastikan bahawa anda memahami fasa pelaksanaan dan aliran panggilan data aplikasi kanvas. Selain itu, baca Sumber biasa prestasi perlahan bagi aplikasi kanvas untuk mengetahui tentang perangkap biasa yang anda boleh mengelakkan apabila mereka bentuk atau mengemas kini aplikasi kanvas.

Set data besar yang memuatkan dengan perlahan pada platform yang berbeza

Prestasi apl mungkin berbeza-beza apabila memuatkan set data yang besar pada platform yang berbeza seperti atau iOS Android. Perubahan ini berlaku kerana had permintaan rangkaian yang berbeza pada setiap platform. Contohnya, bilangan permintaan rangkaian serentak yang dibenarkan mungkin berbeza mengikut platform. Perbezaan ini boleh memberikan kesan yang besar pada masa pemuatan data untuk set data yang besar.

Kami mengesyorkan agar anda hanya memuatkan data yang anda perlukan untuk dipaparkan pada skrin dengan serta-merta. Untuk data lain, penghalamanan dan cache data anda. Maklumat lanjut: Petua dan amalan terbaik untuk meningkatkan prestasi aplikasi kanvas

Terlalu banyak lajur didapatkan kembali

Kami mengesyorkan agar anda memilih hanya lajur yang diperlukan untuk aplikasi. Menambah lebih banyak (atau semua) lajur daripada sumber data akan memuat turun semua data dalam lajur tersebut. Tindakan ini mengakibatkan bilangan panggilan overhed rangkaian yang tinggi dan, oleh itu, penggunaan memori yang tinggi dalam peranti klien. Masalah ini boleh menjejaskan pengguna peranti mudah alih lebih-lebih lagi jika jalur lebar rangkaian dihadkan, atau jika peranti mempunyai memori terhad atau pemproses legasi.

Contohnya, jika anda menggunakan Dataverse sebagai sumber data untuk aplikasi anda, pastikan anda telah mendayakan ciri pilihan lajur eksplisit. Ciri ini membolehkan Power Apps untuk menyekat dapatan semula data untuk lajur yang hanya digunakan dalam aplikasi.

Untuk menghidupkan ciri pemilihan lajur tak tersirat pada aplikasi kanvas, pergi ke Tetapan > Ciri akan datang > Pratonton, kemudian hidupkan togol Pemilihan lajur tak tersirat

Pelayar tidak disokong atau legasi

Pengguna yang menggunakan pelayar tidak disokong atau legasi, mungkin mengalami masalah prestasi. Pastikan bahawa pengguna hanya menggunakan pelayar yang disokong untuk menjalankan aplikasi kanvas.

Prestasi perlahan kerana jarak geografi

Lokasi geografi persekitaran dan jarak sumber data daripada pengguna boleh mempengaruhi prestasi.

Kami mengesyorkan agar persekitaran anda berada berdekatan dengan pengguna. Walaupun Power Apps menggunakan Penghantaran Kandungan Azure untuk kandungan, panggilan data masih mendapatkan data daripada sumber data. Sumber data yang berada di lokasi geografi yang lain mungkin menjejaskan prestasi aplikasi.

Jarak geografi yang berlebihan mempengaruhi prestasi dengan cara yang berbeza, seperti kependaman, daya pemprosesan yang berkurangan, jalur lebar yang lebih rendah atau kehilangan paket.

Senarai izin tidak dikonfigurasikan

Pastikan URL perkhidmatan yang diperlukan tidak disekat atau URL tersebut telah ditambahkan pada senarai izin tembok api anda. Untuk senarai lengkap semua URL perkhidmatan yang mesti dibenarkan untuk Power Apps, pergi ke Perkhidmatan yang diperlukan.

Penggunaan fungsi tidak boleh ditugaskan dan had baris data yang tidak sesuai untuk permintaan tidak boleh ditugaskan

Fungsi yang boleh ditugaskan menugaskan pemprosesan data pada sumber data, meminimumkan overhed di pihak klien. Apabila penugasan tidak dapat dilakukan, anda boleh mengehadkan had baris data untuk pertanyaan tidak boleh ditugaskan supaya bilangan baris yang dikembalikan daripada sambungan berasaskan pelayan kekal optimum.

Penggunaan fungsi tidak boleh ditugaskan dan tidak sesuai had baris data untuk pertanyaan tiak boleh ditugaskan menambah overhed tambahan untuk pemindahan data. Overhed ini menghasilkan manipulasi data yang diterima kepada timbunan JS di pihak klien. Pastikan untuk menggunakan fungsi boleh ditugaskan untuk aplikasi apabila tersedia dan menggunakan had baris data optimum untuk pertanyaan tidak boleh ditugaskan.

Maklumat lanjut: Gunakan penugasan, Gambaran keseluruhan penugasan

Peristiwa OnStart perlu penalaan

Peristiwa OnStart berjalan apabila aplikasi sedang dimuatkan. Memanggil jumlah data yang banyak dengan menggunakan fungsi dalam sifat OnStart aplikasi akan menyebabkan aplikasi itu dimuatkan dengan perlahan. Skrin yang banyak bergantung pada kawalan dan nilai yang ditakrifkan pada skrin lain akan terjejas oleh navigasi skrin perlahan.

Bahagian berikut menerangkan beberapa masalah paling biasa yang dialami dalam situasi ini.

Bilangan panggilan yang tinggi dalam peristiwa OnStart menyebabkan aplikasi bermula dengan perlahan

Dalam sesebuah perusahaan, jumlah panggilan data kepada sumber data pusat boleh memacu cerutan pelayan atau pertelagahan sumber.

Gunakan mekanisme cache untuk mengoptimumkan panggilan data. Aplikasi tunggal mungkin digunakan oleh ramai pengguna, yang menyebabkan berbilang panggilan data bagi setiap pengguna yang menjangkau titik akhir pelayan. Panggilan data ini boleh menjadi titik tempat cerutan atau pendikitan boleh berlaku.

Kependaman pada peristiwa OnStart kerana skrip yang berat

Skrip berat pada peristiwa OnStart adalah salah satu kesalahan yang paling biasa semasa mereka bentuk aplikasi kanvas. Anda harus mendapatkan data yang diperlukan sahaja untuk aplikasi bermula.

Optimumkan formula dalam peristiwa OnStart. Contohnya, anda boleh memindahkan beberapa fungsi kepada sifat OnVisible. Dengan cara ini, anda boleh membiarkan aplikasi bermula dengan cepat dan langkah lain boleh diteruskan semasa aplikasi dibuka.

Maklumat lanjut: Optimumkan sifat OnStart

Petua

Kami mengesyorkan anda menggunakan sifat App.StartScreen kerana ia memudahkan pelancaran aplikasi dan meningkatkan prestasi aplikasi.

Tekanan memori di pihak klien

Penting untuk menyemak penggunaan memori aplikasi kanvas kerana pada kebanyakan masa, aplikasi berjalan pada peranti mudah alih. Pengecualian memori dalam timbunan kemungkinan besar punca di sebalik aplikasi kanvas yang ranap atau tidak bergerak ("tergantung") pada peranti tertentu.

Timbunan JavaScript (JS) mungkin menjangkau had kerana skrip yang berat berjalan di pihak klien untuk penambahan, pencantuman, penapisan, pengisihan atau pengelompokan lajur. Dalam kebanyakan keadaan, pengecualian kehabisan memori pada timbunan dalam klien boleh mencetuskan aplikasi menjadi ranap atau tergantung.

Apabila menggunakan data daripada sumber seperti Dataverse atau Pelayan SQL, anda boleh menggunakan Pandangan objek untuk memastikan bahawa pencantuman, penapisan atau pengisihan berlaku di bahagian pelayan dan bukannya di pihak klien. Pendekatan ini mengurangkan overhed penskripan klien untuk tindakan tersebut.

Jika operasi klien yang berat seperti CANTUM atau Kelompok Mengikut berlaku di pihak klien dengan set data yang mempunyai 2,000 rekod atau lebih, objek dalam timbunan akan meningkat, menyebabkan objek melebihi had memori.

Alat pembangun untuk kebanyakan pelayar membolehkan anda untuk membuat ingatan. Ini membantu anda menggambarkan saiz timbunan, dokumen, nod dan pendengar. Profilkan prestasi aplikasi dengan menggunakan pelayar, seperti yang diterangkan dalam Gambaran keseluruhan Alat Pembangun Microsoft Edge (Chromium). Semak senario yang melebihi ambang memori timbunan JS. Maklumat lanjut: Betulkan masalah memori

Pertimbangan prestasi untuk penyambung Pelayan SQL

Anda boleh menggunakan penyambung Pelayan SQL untuk Power Apps menyambung kepada Pelayan SQL di premis atau Pangkalan Data SQL Azure. Bahagian ini menerangkan masalah berkaitan prestasi umum dan penyelesaian bagi menggunakan penyambung ini untuk aplikasi kanvas. Maklumat lanjut: Sambung kepada Pelayan SQL daripada Power Apps, Cipta aplikasi kanvas daripada Pangkalan Data SQL Azure

Nota

Walaupun bahagian ini merujuk kepada penyambung Pelayan SQL untuk isu dan penyelesaian prestasi, kebanyakan pengesyoran juga terpakai untuk penggunaan sebarang jenis pangkalan data —seperti MySQL atau PostgreSQL—sebagai sumber data.

Mari kita lihat masalah dan penyelesaian prestasi umum bagi penggunaan penyambung Pelayan SQL untuk aplikasi kanvas.

Pertanyaan N+1

Galeri yang menjana terlalu banyak permintaan untuk pelayan menyebabkan masalah pertanyaan N+1. Masalah pertanyaan N+1 adalah salah satu masalah yang paling biasa dialami dengan menggunakan kawalan Galeri.

Untuk mengelakkan masalah tersebut, gunakan pandangan objek di bahagian belakang SQL atau tukar senario antara muka pengguna.

Imbasan jadual dan bukannya pencarian indeks

Aplikasi mungkin menjadi perlahan jika fungsi yang digunakan oleh aplikasi menjalankan pertanyaan dalam pangkalan data yang menghasilkan imbasan jadual dan bukannya pencarian indeks. Maklumat lanjut: Petua, IMBASAN jadual dan Indeks MENCARI

Untuk menyelesaikan masalah tersebut, gunakan StartsWith dan bukannya IN dalam formula. Dengan sumber data SQL, operator StartsWith menghasilkan pencarian indeks, tetapi IN menghasilkan imbasan indeks atau jadual.

Pertanyaan perlahan

Anda boleh memprofilkan dan menyesuaikan pertanyaan dan indeks yang perlahan pada pangkalan data SQL. Sebagai contoh, jika formula mendapatkan data dengan tertib menurun (DESC) pada lajur tertentu, lajur pengisihan tersebut sepatutnya mempunyai Indeks dengan tertib menurun. Kunci indeks mencipta tertib menaik (ASC) secara lalai.

Anda juga boleh menyemak alamat URL permintaan data. Contohnya, cebisan (panggilan OData separa) permintaan data berikut meminta SQL untuk mengembalikan 500 rekod lajur yang sepadan dengan Nilai dan urutan mengikut ID dalam tertib menurun.

Items? \$filter=Column eq 'Value' & Orderby = ID desc & top 500

Ini membantu dalam memahami keperluan indeks untuk menampung syarat permintaan sedemikian. Dalam contoh ini, jika lajur ID mempunyai indeks dengan tertib menurun, pertanyaan akan dilaksanakan dengan lebih cepat.

Semak pelan pelaksanaan pertanyaan perlahan untuk melihat sama ada sebarang imbasan jadual atau indeks wujud. Pantau sebarang kos carian utama yang berlebihan dalam pelan pelaksanaan.

Maklumat lanjut:

• Pantau dan tala prestasi
• Memantau prestasi dengan menggunakan Gedung Pertanyaan
• Gambaran keseluruhan Peristiwa Lanjutan

Sumber pertikaian pangkalan data

Pastikan bahawa sumber data—pangkalan data SQL—tidak mempunyai sebarang pertelagahan sumber seperti cerutan pemproses, pertelagahan I/O, tekanan memori atau pertelagahan tempDB. Juga semak tamat masa kunci, menunggu, kebuntuan dan pertanyaan.

Petua

Gunakan penalaan automatik untuk wawasan ke dalam masalah prestasi pertanyaan yang berpotensi, penyelesaian yang disyorkan dan untuk menetapkan masalah yang dikenal pasti secara automatik.

Klien yang tebal atau permintaan berlebihan

Aplikasi menjalankan operasi Kelompok Mengikut, Tapis Mengikut atau CANTUM di pihak klien yang menggunakan pemproses dan sumber memori daripada peranti klien. Bergantung pada saiz data, operasi ini mungkin mengambil lebih banyak masa penskripan di pihak klien, meningkatkan saiz timbunan JS pada klien. Masalah ini meningkat untuk sumber data di premis, kerana setiap panggilan data carian bergerak ke sumber data melalui get laluan data.

Dalam situasi sedemikian, gunakan objek Pandangan dalam pangkalan data SQL untuk operasi Kumpul Mengikut,Tapis Mengikut, atau JOIN . Pandangan boleh menggunakan lajur terpilih dan mengalih keluar lajur yang tidak perlu dengan jenis data besar seperti NVARCHAR(MAX), VARCHAR(MAX) dan VARBINARY(MAX).

Petua

Pendekatan ini juga membantu menangani masalah pertanyaan N+1.

Saiz data yang dipindahkan kepada klien

Secara lalai, aplikasi kanvas menunjukkan data dengan menggunakan jadual atau pandangan, daripada objek pangkalan data yang tersedia. Mendapatkan semula semua lajur daripada jadual boleh menyebabkan respons yang perlahan, terutamanya apabila menggunakan jenis data besar seperti NVARCHAR(MAX).

Memindahkan jumlah data yang besar kepada klien akan mengambil masa. Pemindahan ini juga menyebabkan lebih banyak masa penskripan apabila terdapat sejumlah besar data dalam timbunan JS di pihak klien, seperti yang diterangkan lebih awal dalam artikel ini.

Untuk mengurangkan saiz data yang dipindahkan kepada klien, gunakan pandangan dengan lajur khusus yang diperlukan untuk aplikasi dan pastikan pilihan lajur yang eksplisit didayakan, seperti yang diterangkan lebih awal dalam artikel ini.

Pertimbangan khusus untuk Pelayan SQL di premis

Prestasi aplikasi kanvas yang menggunakan penyambung Pelayan SQL dengan get laluan data di premis mungkin terjejas dalam pelbagai cara. Bahagian ini menyenaraikan isu prestasi umum dan penyelesaian resolusi khusus untuk menggunakan sumber pangkalan data di premis.

Urus get laluan data di premis yang tidak baik

Organisasi boleh mentakrifkan nod berganda untuk get laluan data di premis. Jika salah satu nod tidak dapat dicapai, permintaan data pada nod tidak sihat tidak akan mengembalikan hasil dalam rangka masa yang boleh diterima, atau mungkin menyebabkan mesej ralat "tidak dapat dicapai" selepas menunggu untuk sementara waktu.

Pastikan bahawa semua nod get laluan data di premis sihat dan dikonfigurasikan dengan kependaman rangkaian minimum antara nod dan tika SQL.

Lokasi get laluan data di premis

Get laluan data memerlukan panggilan rangkaian untuk sumber data di premis mentafsirkan permintaan OData. Sebagai contoh, gerbang data perlu memahami skema jadual data untuk menterjemah permintaan OData ke dalam pernyataan bahasa manipulasi data SQL (DML). Overhed tambahan ditambah apabila get laluan data dikonfigurasikan di lokasi berasingan dengan kependaman rangkaian tinggi antara get laluan data dan tika SQL.

Dalam persekitaran perniagaan, yang mempunyai kelompok get laluan data boleh skala yang disyorkan apabila permintaan data berat dijangkakan. Semak berapa banyak sambungan yang diwujudkan antara nod get laluan data dan tika SQL.

Dengan menyemak sambungan serentak dalam get laluan data di premis atau tika SQL, organisasi anda boleh mengenal pasti titik tempat get laluan data perlu dikecilkan dan dengan berapa jumlah nod.

Kebolehskalaan get laluan data

Jika anda menjangkakan untuk mengakses jumlah data yang besar daripada get laluan data di premis, hanya nod tunggal bagi get laluan data di premis boleh menjadi cerutan untuk mengendalikan jumlah permintaan yang besar.

Nod tunggal get laluan di premis mungkin mencukupi untuk berurusan dengan 200 atau lebih sedikit sambungan serentak. Walau bagaimanapun, jika semua sambungan serentak ini melaksanakan pertanyaan secara aktif, permintaan lain akhirnya menunggu sambungan yang tersedia.

Untuk mendapatkan maklumat tentang memastikan bahawa skala get laluan data di premis anda mengikut jumlah data dan permintaan, pergi ke Pantau dan optimumkan prestasi get laluan data di premis.

Pertimbangan khusus untuk Pangkalan data Azure SQL

Aplikasi kanvas boleh disambungkan kepada Pangkalan Data SQL Azure dengan menggunakan penyambung Pelayan SQL. Punca biasa masalah prestasi apabila menggunakan Pangkalan Data SQL Azure ialah memilih tingkat yang salah untuk keperluan perniagaan anda.

Pangkalan data SQL Azure tersedia dalam peringkat perkhidmatan yang berbeza, dengan pelbagai keupayaan untuk memenuhi keperluan perniagaan yang berbeza. Untuk mendapatkan maklumat lanjut tentang peringkat, pergi ke Dokumentasi Pangkalan data Azure SQL.

Dengan permintaan data yang berat, sumber pada tingkat yang dipilih mungkin mengalami pendikitan sebaik sahaja nilai ambang dicapai. Pendikitan sedemikian akan menjejaskan prestasi set pertanyaan seterusnya.

Semak tahap perkhidmatan Pangkalan data SQL Azure. Tingkat lebih rendah akan mempunyai beberapa pengehadan dan kekangan. Dari perspektif prestasi, CPU, daya pemprosesan I/O dan kependaman adalah penting. Oleh itu, kami mengesyorkan agar anda menyemak prestasi pangkalan data SQL secara berkala dan menyemak sama ada penggunaan sumber melebihi ambang. Contohnya, Pelayan SQL di premis biasanya menetapkan ambang penggunaan CPU kepada kira-kira 75 peratus.

Pertimbangan prestasi untuk penyambung SharePoint

Anda boleh menggunakan penyambung SharePoint untuk mencipta aplikasi dengan menggunakan data daripada Microsoft Lists. Anda juga boleh mencipta aplikasi kanvas terus daripada pandangan senarai. Mari kita lihat masalah dan penyelesaian prestasi umum untuk penggunaan sumber data SharePoint dengan aplikasi kanvas.

Terlalu banyak lajur carian dinamik

SharePoint menyokong pelbagai jenis data, termasuk carian dinamik seperti Orang, Kumpulan dan Dikira. Jika senarai mentakrifkan terlalu banyak lajur dinamik, lebih banyak masa diambil untuk memanipulasi lajur dinamik ini dalam SharePoint sebelum mengembalikan data kepada klien yang menjalankan aplikasi kanvas.

Jangan terlampau guna lajur carian dinamik dalam SharePoint. Penggunaan berlebihan ini boleh menyebabkan overhed boleh elak dan tambahan pada bahagian SharePoint untuk manipulasi data. Sebaliknya, anda boleh menggunakan lajur statik untuk menyimpan alias e-mel atau nama orang lain, sebagai contoh.

Lajur dan lampiran gambar

Saiz imej dan fail yang dilampirkan boleh menyumbang kepada respons yang perlahan semasa mendapatkan semula untuk klien.

Semak senarai anda dan pastikan hanya lajur yang diperlukan telah ditakrifkan. Bilangan lajur dalam senarai mempengaruhi prestasi permintaan data. Ini kerana rekod yang dipadankan atau rekod sehingga had baris data yang ditakrifkan akan didapatkan semula dan dihantar kembali kepada klien dengan semua lajur yang ditakrifkan dalam senarai—walaupun jika aplikasi tidak menggunakan semua lajur tersebut.

Untuk pertanyaan hanya lajur yang digunakan oleh aplikasi, dayakan ciri pemilihan lajur yang eksplisit, seperti yang diterangkan lebih awal dalam artikel ini.

Senarai besar

Jika anda mempunyai senarai besar dengan ratusan ribu rekod, pertimbangkan untuk pemetakan senarai atau membahagikan senarai kepada beberapa senarai berdasarkan parameter seperti kategori atau tarikh dan masa.

Sebagai contoh, data anda mungkin disimpan dalam senarai yang berbeza pada setiap tahun atau setiap bulan. Dalam keadaan sedemikian, anda boleh mereka bentuk aplikasi untuk membenarkan pengguna memilih tetingkap masa dan mendapatkan semula data dalam julat tersebut.

Dalam persekitaran terkawal, penanda aras prestasi telah membuktikan bahawa prestasi permintaan OData terhadap Microsoft Lists atau SharePoint sangat berkaitan dengan bilangan lajur dalam senarai dan bilangan baris yang didapatkan semula (dihadkan oleh had baris data untuk pertanyaan tidak boleh diwakilkan). Mempunyai lajur yang lebih sedikit dan tetapan had baris data yang lebih rendah boleh membuat aplikasi kanvas berfungsi dengan lebih baik.

Namun, dalam dunia sebenar, aplikasi direka bentuk untuk memenuhi keperluan perniagaan tertentu. Mungkin tidak cepat atau mudah untuk mengurangkan had baris data atau bilangan lajur dalam senarai. Walau bagaimanapun, kami mengesyorkan agar anda memantau permintaan OData di pihak klien dan menyesuaikan had baris data untuk pertanyaan tidak boleh ditugaskan dan bilangan lajur dalam senarai .

Pertimbangan prestasi untuk penggunaan Dataverse seperti sumber data

Apabila anda menggunakan Microsoft Dataverse sebagai sumber data, permintaan data pergi ke tika persekitaran secara langsung, tanpa melalui pengurusan API Azure. Maklumat lanjut: Aliran panggilan data apabila disambungkan ke Microsoft Dataverse

Petua

Apabila jadual tersuai digunakan dalam Dataverse, konfigurasi keselamatan tambahan mungkin diperlukan untuk pengguna dapat melihat rekod dengan aplikasi kanvas. Maklumat lanjut: Konsep keselamatan dalam Dataverse, Konfigurasi keselamatan pengguna kepada sumber dalam persekitaran dan Peranan keselamatan dan kelayakan

Aplikasi kanvas yang bersambung kepada Dataverse mungkin berfungsi dengan perlahan jika ia menjalankan penskripan klien yang berat seperti Tapis Mengikut atau CANTUM di pihak klien dan bukannya bahagian pelayan.

Gunakan Pandangan Dataverse apabila boleh. Pandangan dengan kriteria yang dikehendaki menyertai atau penapis membantu mengurangkan overhed menggunakan keseluruhan jadual. Sebagai contoh, jika anda perlu menyertai jadual dan menapis data mereka, anda boleh mentakrifkan pandangan dengan menyertai mereka dan mentakrifkan hanya lajur yang anda perlukan. Kemudian anda boleh menggunakan pandangan ini dalam aplikasi anda, yang mencipta overhed ini di pihak pelayan untuk cantum/tapis dan bukannya di pihak klien.Kaedah ini mengurangkan bukan sahaja operasi tambahan, tetapi juga penghantaran data. Untuk maklumat mengenai pengeditan penapis dan Isih kriteria, pergi ke Edit kriteria penapis.

Pertimbangan prestasi untuk penyambung Excel

Penyambung Excel menyediakan kesambungan daripada aplikasi kanvas kepada data dalam jadual dalam fail Excel. Penyambung ini mempunyai had berbanding dengan sumber data lain—contohnya, fungsi boleh ditugaskan yang terhad—yang mengehadkan aplikasi kanvas untuk memuatkan data daripada jadual sehingga 2,000 rekod sahaja. Untuk memuatkan lebih daripada 2,000 rekod, petakkan data anda dalam jadual data berbeza sebagai sumber data lain.

Mari kita lihat masalah prestasi umum dengan menggunakan sumber data Excel untuk aplikasi kanvas dan cara menyelesaikan masalah tersebut.

Jadual data terlalu banyak dan saiz data yang besar

Aplikasi dapat berfungsi dengan perlahan apabila ia menggunakan fail Excel yang mempunyai terlalu banyak jadual data atau jadual data yang mengandungi jumlah data yang banyak dalam beberapa lajur. Fail Excel bukan pangkalan data hubungan atau sumber data yang menyediakan fungsi boleh ditugaskan. Power Apps perlu memuatkan data daripada jadual data yang ditakrifkan terlebih dahulu, kemudian menggunakan fungsi seperti Tapis, Isih, CANTUM, Kumpulkan Mengikut dan Cari.

Mempunyai jadual data yang terlalu banyak dengan baris dan lajur yang banyak mempengaruhi prestasi aplikasi dan overhed di pihak klien kerana setiap jadual data perlu dimanipulasi dalam timbunan JS. Kesan ini juga menyebabkan aplikasi menggunakan lebih banyak memori di pihak klien.

Untuk memastikan bahawa aplikasi anda tidak terjejas oleh masalah ini, takrifkan lajur yang anda perlukan sahaja pada jadual data dalam fail Excel.

Transaksi yang banyak

Excel bukan sistem pangkalan data hubungan. Sebarang perubahan daripada aplikasi diuruskan oleh Excel dengan cara yang sama seolah-olah pengguna mengubah data dalam fail Excel. Jika aplikasi mempunyai bilangan bacaan yang tinggi, tetapi operasi CRUD yang lebih kurang, ia mungkin berfungsi dengan baik. Walau bagaimanapun, jika aplikasi membuat transaksi yang banyak, ia boleh memberikan kesan negatif terhadap prestasi aplikasi.

Tiada nilai ambang khusus untuk bilangan transaksi, kerana ia juga bergantung pada data yang dimanipulasi. Beberapa aspek lain juga menjejaskan prestasi aplikasi, seperti overhed rangkaian atau peranti pengguna.

Jika anda mempunyai data baca sahaja, anda boleh mengimport data tersebut ke dalam aplikasi tempatan dan bukan pemuatan daripada sumber data. Untuk aplikasi perusahaan, sebaliknya, gunakan sumber data seperti Dataverse, Pelayan SQL atau SharePoint.

Saiz fail

Anda boleh memilih daripada pelbagai pilihan storan awan dengan kapasiti storan yang berbeza-beza—atau dapat dikonfigurasikan—untuk fail Excel. Walau bagaimanapun, mempunyai fail Excel besar tunggal dengan semua jadual ditakrifkan dalam fail tersebut akan menambahkan overhed tambahan untuk aplikasi semasa ia memuat turun fail dan membaca data untuk dimuatkan di pihak klien.

Daripada menggunakan satu fail besar, bahagikan data ke dalam beberapa fail Excel dengan jadual data minimum. Kemudian sambung kepada setiap fail apabila anda memerlukannya sahaja. Dengan cara ini, memuatkan data daripada jadual data berlaku dalam pecahan, mengurangkan overhed daripada mempunyai jadual yang banyak atau set data yang besar.

Lokasi fail

Lokasi geografi sumber data dan jaraknya daripada lokasi klien boleh menyebabkan cerutan prestasi untuk aplikasi dan menyebabkan kependaman rangkaian. Kesan ini dapat diperkuat apabila klien mudah alih mempunyai lebar jalur yang terhad untuk kesambungan.

Lebih baik untuk menyimpan fail berhampiran pengguna anda (atau kebanyakan pengguna, jika anda mempunyai khalayak global) supaya fail boleh dimuat turun dengan cepat.

Langkah seterusnya

Petua dan amalan terbaik untuk mempertingkatkan prestasi aplikasi kanvas

Lihat juga

Fahami fasa pelaksanaan dan aliran panggilan data aplikasi kanvas
Sumber biasa prestasi perlahan untuk aplikasi kanvas
Isu dan penyelesaian biasa untuk Power Apps
Menyelesaikan masalah permulaan untuk Power Apps

Nota

Adakah anda boleh memberitahu kami tentang keutamaan bahasa dokumentasi anda? Jawab tinjauan pendek. (harap maklum bahawa tinjauan ini dalam bahasa Inggeris)

Tinjauan akan mengambil masa lebih kurang tujuh minit. Tiada data peribadi akan dikumpulkan (pernyataan privasi).