Evaluasi kinerja dan perkiraan
Tugas utama setelah implementasi sistem Informasi adalah cepat, stabil dan waktu aktif yang memuaskan pengguna.
Namun, seringkali dengan peningkatan jumlah pengguna, jumlah data, intensitas input, kinerja program turun drastis. Operasi dan waktu respons sistem meningkat secara kritis.
Semua ini menyebabkan ketidakpuasan pengguna sistem di semua tingkatan, dan pekerjaan yang tidak efisien.
Terlepas dari kenyataan bahwa perilaku sistem seperti itu dapat diprediksi, banyak yang tidak siap untuk skenario ini.
Sejumlah besar kasus diketahui ketika pembuatan sistem akuntansi direncanakan dan dilakukan tanpa analisis rinci awal tentang caranya sistem ini akan berperilaku dengan data dalam jumlah besar (misalnya, dengan pekerjaan intensif paralel lebih dari seribu orang). Proyek semacam itu menghabiskan banyak uang untuk membuat sistem. Tetapi setelah diperkenalkan, masa pakai sistem ini adalah satu setengah tahun. Kemudian dinyatakan bahwa sistem tidak mengatasi tugas, anggaran baru dialokasikan dan proyek baru dimulai untuk memperkenalkan sistem yang "lebih baik", yang membawa konsekuensi yang sama.
Saat ini, hanya ada satu solusi masalah ini- Tes Stres.
Tes Stres
Pengujian beban adalah analisis perilaku sistem saat meniru beban pengguna nyata.
Tujuan utama pengujian beban:
- Uji kinerja pada berbagai konfigurasi perangkat keras dan perangkat lunak
- Periksa kinerja sistem dengan jumlah data yang berbeda
- Tentukan perilaku sistem di bawah beban tegangan
Dengan demikian, uji beban harus memungkinkan penilaian sistem berikut:
- penilaian kinerja sistem informasi atau bagian individualnya dengan parameter model perusahaan yang diberikan untuk:
- pilihan peralatan;
- perumusan persyaratan operasional;
- menilai penerapan sistem informasi;
- penilaian skalabilitas sistem informasi ketika mengubah:
- volume basis informasi;
- jumlah pengguna bersamaan;
- memuat pada sistem;
- penilaian perubahan indikator kinerja sistem saat mengubah:
- fungsionalitas sistem (peningkatan sistem atau algoritme individual);
- konfigurasi perangkat keras.
- mengidentifikasi masalah yang muncul hanya selama pekerjaan multi-pengguna (konflik kunci, dll.).
Uji beban membantu tidak hanya untuk mengevaluasi karakteristik tertentu. Tetapi yang paling penting, ini memungkinkan Anda untuk mengidentifikasi hambatan dalam sistem terlebih dahulu dan menyelesaikan masalah dengan cara yang paling efektif.
Operasi wajib untuk setiap implementasi atau modifikasi sistem informasi yang ada adalah untuk menilai kecepatan sistem yang diperlukan dan merencanakan sumber daya komputasi yang diperlukan untuk implementasinya. Saat ini, tidak ada solusi yang tepat untuk masalah ini di pandangan umum, dan jika, terlepas dari kerumitan dan biayanya, algoritme semacam itu diusulkan oleh pabrikan mana pun, maka perubahan kecil pada perangkat keras, versi perangkat lunak, konfigurasi sistem, atau jumlah atau perilaku standar pengguna akan menyebabkan kesalahan yang signifikan.
Namun demikian, ada cukup banyak cara untuk mengevaluasi konfigurasi perangkat lunak dan perangkat lunak yang diperlukan untuk mencapai kinerja yang diperlukan. perangkat keras. Semua metode ini dapat digunakan dalam proses pemilihan, tetapi konsumen harus memahami ruang lingkup dan batasannya.
Mayoritas metode yang ada evaluasi kinerja didasarkan pada jenis pengujian tertentu.
Ada dua jenis pengujian utama: komponen dan integral.
Dengan pengujian komponen, masing-masing komponen solusi diuji, mulai dari kinerja prosesor atau subsistem penyimpanan informasi hingga pengujian kinerja server secara keseluruhan, tetapi tanpa muatan dalam bentuk aplikasi bisnis tertentu.
Pendekatan integral ditandai dengan penilaian kinerja solusi secara keseluruhan, baik bagian perangkat lunak maupun perangkat kerasnya. Dalam hal ini, aplikasi bisnis yang akan digunakan dalam solusi akhir, dan beberapa aplikasi model yang meniru beberapa proses bisnis standar dan beban kerja dapat digunakan.
Warna hijau pada grafik, bersama dengan beberapa indikator di sebelah kanan, yang dipilih secara kondisional sebagai tolok ukur, memungkinkan kami membuat penilaian umum lintas platform tentang kinerja yang "baik".
Cara menikmati hasil ujian
Hasilnya, Anda telah menerima indeks kinerja (kecepatan). Tidak masalah apakah hasilnya baik atau buruk, itu adalah hasil dari PLATFORM yang berjalan di perangkat keras Anda. Dalam kasus klien versi server ini adalah hasil dari rangkaian permintaan yang rumit yang melewati berbagai situs. Anda mendapatkan hasil aktual keseluruhan, yang ditentukan oleh hambatan dalam sistem. Selalu ada kemacetan.
Dengan kata lain, pengaturan DBMS, pengaturan OS, dan peralatan memengaruhi hasil tim secara keseluruhan.
Server mana yang lebih baik
Tes ini, dilakukan pada server tertentu, memberikan hasil pada kombinasi pengaturan perangkat keras, sistem operasi, subd, dll. Namun, skor tinggi pada perangkat keras server tertentu berarti bahwa, dalam kondisi normal, hasil yang sama akan diperoleh pada perangkat keras server yang identik. Tes ini adalah bantuan gratis untuk membandingkan instalasi 1C:Enterprise di bawah Windows dan Linux, tiga DBMS berbeda yang didukung oleh platform 1C:Enterprise 8.
Uji keamanan
Tes ini benar-benar aman. Itu tidak menyebabkan "jatuhnya" server (tidak ada algoritme "stres") dan tidak memerlukan tindakan awal bahkan pada server "pertempuran". Data rahasia juga tidak dicatat dalam hasil tes. Mengumpulkan informasi tentang parameter CPU, RAM, HDD. Nomor serial perangkat tidak dirakit. Semua ini dapat dengan mudah diverifikasi - kode uji 100% terbuka. Tidak ada transfer informasi tanpa sepengetahuan Anda yang mungkin dilakukan.
Klasifikasi TPC-A-Throughput lokal/ TPC-1C-GILV-A
Tes ini termasuk dalam bagian tes lintas platform integral universal. Selain itu, ini berlaku untuk varian file dan server-klien dari 1C: operasi Perusahaan. Tes bekerja untuk semua DBMS yang didukung oleh 1C.
Universalitas memungkinkan Anda membuat penilaian kinerja secara umum tanpa terikat pada penilaian kinerja tertentu. konfigurasi tipikal platform.
Di sisi lain, ini berarti bahwa untuk perhitungan proyek kustom yang akurat, pengujian memungkinkan Anda membuat penilaian awal sebelum pengujian beban khusus.
Unduh tes
Tes ini tidak komersial dan dapat diunduh gratis untuk 8.2 dan gratis untuk 8.3.
Detail teknis
Apa yang terjadi dalam pengujian dalam siklus "satu" operasi?
Fitur menggunakan tes pada subd PostgreSQL
Tetapkan nilai parameter standard_conforming_strings ke file konfigurasi postgresql.conf ke 'mati'
Cara mengukur beban kerja besi
Perlu dicatat bahwa tes itu sendiri sudah melakukan sebagian pengukuran. Untuk gambaran yang lebih detail, saya sarankan menggunakan utilitas Process Explorer milik Mark Rusinovich.
Angka tersebut menunjukkan contoh pengukuran untuk versi file.
Setiap spesialis dukungan memiliki pengalaman dalam menerima keluhan abstrak dari pengguna. Semua orang akrab dengan kata-kata: "dia berpikir untuk waktu yang sangat lama", "Saya memiliki jendela merah", "sistem bekerja entah bagaimana salah", dan juga "ini sudah lama tidak terjadi, dan ini dia lagi ”.
Dalam situasi seperti itu, sangat sulit untuk segera mencari tahu di mana letak kesalahannya dan apa yang harus dilakukan terlebih dahulu. Pada artikel ini, kami akan mempertimbangkan apa yang bergantung pada kinerja 1C, mis. sistem beban tinggi dibuat berdasarkan 1C: Perusahaan, dalam situasi di mana gejalanya tidak sepenuhnya dipahami dan tidak mungkin untuk membuat diagnosis spesifik.
Alasan utama yang mempengaruhi kinerja 1C
Di lebih dari 60% kasus, alasan kinerja yang buruk adalah:
- kueri suboptimal dan kode pemrograman konfigurasi (26% kasus);
- Pengindeksan tabel objek yang kurang optimal (19% kasus);
- Beban suboptimal pada subsistem disk (16% kasus).
Pengembang Microsoft terkemuka bersolidaritas dengan ini.
Dengan demikian, untuk mendapatkan peningkatan kinerja aplikasi basis data yang signifikan, dimungkinkan untuk mengoptimalkan area akses data, termasuk desain basis data logis dan fisik (sejauh mungkin dalam 1C), serta dengan membuat kueri yang tepat dan menggunakan pengindeksan yang optimal. Bagian dari masalah kinerja database dapat diselesaikan dengan meningkatkan kapasitas perangkat keras, tetapi tidak selalu: desain yang salah dari solusi yang diterapkan tidak dapat dikompensasi oleh server yang lebih kuat. Tidak jarang, tanpa memahami penyebab masalah kinerja, perusahaan pengguna menghabiskan banyak biaya dengan membeli peralatan baru, dan masalahnya tetap tidak terselesaikan.
Diagnostik kinerja 1C berkualitas tinggi menggunakan seluruh jajaran alat yang ada adalah kunci keberhasilan pemecahan masalah dan optimalisasi biaya
Langkah pertama untuk mengidentifikasi dan memperbaiki masalah kinerja yang buruk adalah dengan menulis daftar lengkap operasi bermasalah utama, menunjukkan kecepatan yang tepat dari eksekusi mereka saat ini dan kecepatan yang diharapkan dari eksekusi mereka di masa depan.
Contoh:
Salah: Program macet saat membuat laporan. Saya ingin membangun lebih cepat.
Kanan: Pembuatan laporan “Debt Statement” membutuhkan waktu 5 menit 10 detik. Kecepatan yang diharapkan untuk menghasilkan laporan ini tidak lebih dari 20 detik.
Setelah daftar masalah disusun dan didigitalkan, perlu dilakukan analisis penyebabnya, dimulai dengan pencarian kode yang bermasalah, jika ada (misalnya, permintaan "berat", menunggu lama pada kunci, kebuntuan, dll.).
Alat untuk mengidentifikasi kode yang bermasalah
- 1C:Pusat Manajemen Kinerja (modul yang disertakan dalam 1C:Perangkat perusahaan yang diproduksi oleh 1C);
- layanan awan Gilev;
- Alat biasa, dibangun ke dalam DBMS vendor terkemuka.
Efektivitas penggunaan alat ini dijamin oleh kualifikasi pengembang "1C: Pakar Teknologi", yang menyiratkan partisipasinya dalam implementasi 1C skala besar. Pada saat yang sama, pakar yang berbeda, berdasarkan pengalaman masing-masing, dapat memberikan preferensi pada satu atau beberapa alat/metode.
Sejalan dengan penggunaan salah satu alat yang disajikan, alat pemantauan beban peralatan standar juga digunakan (penghitung "Monitor kinerja").
Berdasarkan pengukuran yang diperoleh, kelas penyebabnya terungkap:
- Masalahnya ada di kode;
- Dan/atau masalah pada perangkat keras;
- Masalahnya ada pada program intensif sumber daya lain yang digunakan pada server produksi.
Load testing 1C - metodologi untuk mengevaluasi perangkat keras server
Seperti yang telah disebutkan, di antara faktor-faktor yang dapat mempengaruhi kinerja 1C, baik secara positif maupun negatif, perangkat keras server dan konfigurasinya menempati tempat yang penting. Pertimbangkan opsi untuk mengukur, menilai beban, dan menguji kinerja sistem dalam kondisi berikut:
- Server 1C tersedia dan berlokasi:
- Bersama dengan DBMS;
- Di server terpisah.
Untuk menilai kepatuhan parameter perangkat keras server yang ada dengan persyaratan sistem, perlu mengumpulkan data tentang beban pada perangkat keras, termasuk prosesor, mis. pengujian beban 1C. Untuk ini, "Monitor Kinerja" digunakan - alat yang memungkinkan Anda mengukur peralatan di sirkuit kerja dan menghapus penghitung kinerja.
Berikut ini adalah seperangkat penghitung dasar yang perlu Anda atur untuk memantau kinerja perangkat keras di Windows. Koleksi dibuat dari semua server tempat server 1C diinstal.
Jika penghitung persentase prosesor untuk tampilan "Prosesor" tinggi, Anda harus mengidentifikasi proses yang dapat dihentikan tanpa memengaruhi pengoperasian server, dan juga ditransfer ke server lain.
Tampilan "Proses" akan memungkinkan Anda mengatur pemantauan untuk setiap proses individual, serta menentukan proses mana yang paling banyak memakan waktu CPU. Jika hanya server 1C yang diinstal di server, maka untuk memahami beban apa yang diberikannya ke perangkat keras, Anda perlu mengonfigurasi kumpulan penghitung berikut:
| \Process("1cv8*")\% Waktu Prosesor |
| \Process("ragent*")\% Waktu Prosesor |
| \Process("ragent*")\Private Bytes |
| \Process("ragent*")\Virtual Bytes |
| \Process("rmngr*")\% Waktu Prosesor |
| \Process("rmngr*")\Byte Pribadi |
| \Process("rmngr*")\Byte Virtual |
| \Process("rphost*")\% Waktu Prosesor |
| \Process("rphost*")\Private Bytes |
| \Process("rphost*")\Byte Virtual |
| \Process("1cv8*")\Byte Pribadi |
| \Process("1cv8*")\Byte Virtual |
Jika sistem saat ini dalam keadaan tidak memuaskan, maka berdasarkan pengukuran yang dikumpulkan, berlaku ketergantungan linier, Anda harus menghitung parameter peralatan untuk memasang sistem target.
Jika akuisisi perangkat keras server hanya direncanakan, parameternya dapat dihitung dengan meniru pengoperasian sistem yang direncanakan, tetapi dalam skala yang lebih kecil, pada peralatan yang ada. Untuk ini, "1C: Test Center" digunakan, yang termasuk dalam 1C Corporate Toolkit. Berdasarkan pengukuran yang diperoleh, dengan menggunakan metode perhitungan, parameter sistem yang direncanakan dan, dengan demikian, persyaratan peralatan ditentukan. Tes ini dapat digunakan berulang kali untuk pengukuran yang berbeda, setelah menambahkan dan memperluas fungsionalitasnya. Teknik ini memiliki akurasi yang tinggi dan kemudahan perhitungan.
Akuntansi dan Manajemen akunting Perusahaan 1C paling umum di Federasi Rusia. Ribuan perusahaan menjalankan bisnis mereka berdasarkan konfigurasi 1C standar dan khusus. Dengan penggunaan yang begitu masif, sejumlah pertanyaan sering muncul tentang pengoptimalan anggaran untuk perangkat lunak dan penggunaan sumber daya yang wajar. Perselisihan seputar bagian server dari kompleks ini tidak mereda, khususnya, sistem operasi mana yang menjadi basis server 1C dan DBMS mana yang mempercayakan pemrosesan database 1C. Selama pengujian kami, kami akan mencoba menjawab pertanyaan-pertanyaan ini.
Peserta tes
sistem operasi MS Server dan MS SQL DBMS
- Perusahaan 1C secara terbuka memposisikan bundel ini sebagai model kerja utama, masing-masing, produk 1C dibuat terutama untuknya.
- Kehadiran protokol pertukaran informasi berkecepatan tinggi langsung SharedMemory
- Ada petugas dukungan teknis dan kontrak layanan
- Ada basis pengetahuan dan banyak informasi tentang instalasi dan mencari setelan 1C+MS SQL
Sistem operasi Unix dan DBMS PostgreSQL
- Sistem ini sepenuhnya gratis (kecuali lisensi untuk 1C: server Perusahaan)
- Dimungkinkan untuk secara fleksibel mengonfigurasi banyak parameter yang meningkatkan kinerja DBMS
- Menyatakan dukungan untuk DBMS PostgreSQL oleh produk 1C
- Kemungkinan replikasi database
Tentu saja, biaya proyek, toleransi kesalahan, dan dukungan teknis merupakan kriteria penting saat memilih sistem informasi untuk 1C. Namun, ada faktor yang dalam banyak kasus secara dramatis memengaruhi pengambilan keputusan - ini adalah kecepatan.
Karena literatur teknis tentang kedua sistem ini di Internet sangat bagus, orang dapat berdebat lama tentang tabel perbandingan panjang yang, tergantung pada tujuannya, menekankan manfaat dari produk ini atau itu. Anda dapat mendiskusikan parameter ini atau itu di antara ratusan parameter sejenis lainnya - betapa uniknya jenisnya dan bagaimana pengaruhnya terhadap pencapaian hasil. Tetapi teori tanpa praktik sudah mati - kami menyarankan dalam artikel ini untuk menghilangkan teori dan langsung ke fakta untuk menguji kinerja kedua sistem informasi dalam praktik dengan tingkat pengaturan yang direkomendasikan dan dalam berbagai pilihan arsitektur server (lihat tabel 2).
Metode tes
Dalam pengujian kami, kami akan mengandalkan dua metode pembuatan beban sintetik dan meniru pekerjaan pengguna di 1C. Ini adalah tes Gilev (TPC-1C) dan tes khusus 1C "Test Center" dari 1C: toolkit KIP dengan skenario pengguna khusus.
Tes Gilev (TPC-1C)
Tes Gilev termasuk dalam bagian uji beban lintas platform universal. Ini dapat digunakan untuk file dan client-server 1C: Arsitektur perusahaan. Tes ini mengukur jumlah pekerjaan per unit waktu dalam satu utas dan cocok untuk menilai kecepatan beban kerja utas tunggal, termasuk kecepatan menggambar antarmuka, dampak biaya sumber daya, pengeposan ulang dokumen, prosedur akhir bulan, penggajian , dll. Universalitas memungkinkan Anda membuat ringkasan penilaian kinerja tanpa terikat pada konfigurasi platform tunggal. Hasil pengujian merupakan penilaian total terhadap sistem 1C terukur yang dinyatakan dalam satuan konvensional.
Tes khusus dari toolkit Test Center 1C: KIP
Pusat Tes- alat untuk pengujian beban multi-pengguna sistem berdasarkan 1C: Perusahaan 8 (lihat Gambar 1). Dengan bantuannya, Anda dapat mensimulasikan pekerjaan perusahaan tanpa partisipasi pengguna nyata, yang memungkinkan Anda mengevaluasi penerapan, kinerja, dan skalabilitas sistem informasi dalam kondisi nyata. Sistem adalah konfigurasi yang menyediakan mekanisme untuk mengelola proses pengujian. Untuk menguji sebuah infobase, perlu mengintegrasikan konfigurasi Test Center ke dalam konfigurasi database yang diuji dengan membandingkan dan menggabungkan konfigurasi. Sebagai hasil dari penggabungan, objek dan modul umum yang diperlukan untuk pengoperasian Test Center akan ditambahkan ke metadata database yang sedang diuji.
Gambar 1 - Skema kerja "Test Center" 1C: instrumentasi
Jadi, dengan menggunakan 1C: toolkit instrumentasi, berdasarkan data yang tersedia di basis produksi 1C nyata, pemrogram membuat skenario pengujian otomatis lengkap berdasarkan daftar dokumen dan buku referensi yang merupakan kunci untuk dari jenis ini konfigurasi (permohonan pembelanjaan dana, order ke supplier, penjualan barang dan jasa, dll). Saat Anda menjalankan skenario, Test Center akan secara otomatis memutar aktivitas multi-pengguna yang dijelaskan dalam skenario. Untuk melakukan ini, Pusat Tes akan membuat jumlah pengguna virtual yang diperlukan (sesuai dengan daftar peran) dan memulai eksekusi tindakan.
Opsi Tes
Saat menyiapkan skenario pengujian untuk mensimulasikan pekerjaan simultan sejumlah besar pengguna secara andal, parameter pengujian tertentu ditetapkan untuk setiap jenis dokumen (lihat Tabel 1):
- Dokumen - menunjukkan dokumen tertentu dalam database kerja, yang menjadi dasar pengujian beban akan dilakukan
- Jalankan prioritas - membentuk urutan di mana pengujian dijalankan untuk setiap jenis dokumen
- Jumlah dokumen - menentukan volume dokumen uji yang dihasilkan
- Jeda, detik - tunda saat memulai serangkaian pengujian dalam jenis dokumen yang sama
- Jumlah baris dalam dokumen adalah penunjuk informasi yang melaporkan "kebesaran" dokumen uji, yang memengaruhi waktu pemrosesan dan beban sumber daya
Pengujian dilakukan dalam 3 iterasi, hasilnya dicatat dalam tabel. Dengan demikian, hasil tes yang diperoleh, diukur dalam hitungan detik, paling realistis dan obyektif mencerminkan tingkat kinerja basis 1C dalam kondisi sedekat mungkin dengan yang sebenarnya (lihat Tabel 3.1 dan 3.2).
Tabel 1. Parameter skrip uji
| Dokumen | Mulai Prioritas | Jumlah dokumen | Jeda, detik | Jumlah baris dalam dokumen | |
| Peran 1 | Faktur pembeli | 1 | 25 | 51 | 62 |
| Tanda terima barang | 2 | 25 | 80 | ||
| Penjualan barang | 3 | 25 | 103 | ||
| Wesel | 4 | 25 | 1 | ||
| Pengembalian Pembeli | 5 | 25 | 82 | ||
| Peran 2 | Faktur pembeli5 | 10 | 65 | 79 | |
| Tanda terima barang | 1 | 22 | 80 | ||
| Penjualan barang | 2 | 25 | 103 | ||
| Wesel | 3 | 25 | 1 | ||
| Pengembalian Pembeli | 4 | 25 | 75 | ||
| Peran 3 | Faktur pembeli | 4 | 15 | 45 | 76 |
| Tanda terima barang | 5 | 26 | 80 | ||
| Penjualan barang | 1 | 52 | 103 | ||
| Wesel | 2 | 26 | 1 | ||
| Pengembalian Pembeli | 3 | 32 | 90 | ||
| Peran 4 | Faktur pembeli | 3 | 45 | 38 | 70 |
| Tanda terima barang | 4 | 30 | 80 | ||
| Penjualan barang | 5 | 30 | 103 | ||
| Wesel | 1 | 20 | 1 | ||
| Pengembalian Pembeli | 2 | 20 | 86 | ||
| Peran 5 | Faktur pembeli | 2 | 30 | 73 | 76 |
| Tanda terima barang | 3 | 30 | 80 | ||
| Penjualan barang | 4 | 30 | 103 | ||
| Wesel | 5 | 18 | 1 | ||
| Pengembalian Pembeli | 1 | 18 | 91 | ||
| Peran 6 | Faktur pembeli | 1 | 40 | 35 | 86 |
| Tanda terima barang | 2 | 40 | 80 | ||
| Penjualan barang | 3 | 40 | 103 | ||
| Wesel | 4 | 40 | 1 | ||
| Pengembalian Pembeli | 5 | 40 | 88 | ||
| Peran 7 | Faktur pembeli | 5 | 25 | 68 | 80 |
| Tanda terima barang | 1 | 25 | 80 | ||
| Penjualan barang | 2 | 25 | 103 | ||
| Wesel | 3 | 25 | 1 | ||
| Pengembalian Pembeli | 4 | 25 | 90 | ||
| Peran 8 | Faktur pembeli | 3 | 25 | 62 | 87 |
| Tanda terima barang | 4 | 25 | 80 | ||
| Penjualan barang | 5 | 25 | 103 | ||
| Wesel | 1 | 25 | 1 | ||
| Pengembalian Pembeli | 2 | 25 | 92 | ||
| Peran 9 | Faktur pembeli | 2 | 20 | 82 | 82 |
| Tanda terima barang | 4 | 20 | 80 | ||
| Penjualan barang | 5 | 20 | 103 | ||
| Wesel | 1 | 20 | 1 | ||
| Pengembalian Pembeli | 3 | 20 | 98 | ||
| Peran 10 | Faktur pembeli | 4 | 50 | 2 | 92 |
| Tanda terima barang | 1 | 50 | 80 | ||
| Penjualan barang | 2 | 50 | 103 | ||
| Wesel | 5 | 50 | 1 | ||
| Pengembalian Pembeli | 3 | 50 | 98 |
Meja 2. Spesifikasi dudukan uji
| №p\p | Peran sistem | CPU\vCPU | RAM, GB | Sistem Disk I/O |
| 1 | Server Terminal – mesin virtual untuk manajemen tes | 4 core 2,9GHz |
16 GB | Serangan SSD Intel Sata1 |
| 2 | Skenario 1. Server 1C + perangkat keras DBMS | Intel Xeon E5-2690 16 core |
96 GB | Serangan SSD Intel Sata1 |
| 3 | Skenario 2. Server 1C + DBMS virtual | 16 core 2,9GHz |
64 GB | Serangan SSD Intel Sata1 |
| 4 | Skenario 3. Server 1C maya | 16 core 2,9GHz |
32 GB | Serangan SSD Intel Sata1 |
| 5 | Skenario 4. Server DBMS virtual | 16 core 2,9GHz |
32 GB | Serangan SSD Intel Sata1 |
| 6 | Perangkat lunak |
|
||
| 7 | Konfigurasi 1C |
|
||
Tabel 3.1 Hasil pengujian dengan Gilev's test (TPC-1C). Nilai tertinggi dianggap optimal.
Tabel 3.2 Hasil Uji Menggunakan Uji Khusus 1C: KIP. Nilai terkecil dianggap optimal.
| sistem operasi ServerMicrosoft | Sistem operasi kelas Unix | |||||
| Daftar tes (nilai rata-rata berdasarkan hasil rangkaian 3 tes) | Server perangkat keras 1C + DBMS, protokol SharedMemory | Server virtual 1C + DBMS, protokol SharedMemory | Server perangkat keras 1C dan server perangkat keras DBMS, protokol TCP-IP | Server virtual 1C dan server virtual DBMS, protokol TCP-IP | ||
| Melakukan pengujian 1C: KIP pada database yang sudah ada, konfigurasi Accounting Enterprise | ||||||
| Neraca perputaran | 1,741 dtk | 2,473 dtk | 2,873 dtk | 2,522 dtk | 13,866 dtk | 9,751 dtk |
| Melaksanakan pengembalian barang dari pembeli | 0,695 detik | 0,775 detik | 0,756 detik | 0,781 detik | 0,499 dtk | 0,719 detik |
| Memproses pesanan pembayaran | 0,048 detik | 0,058 detik | 0,063 detik | 0,064 detik | 0,037 detik | 0,065 detik |
| Melakukan PTIS | 0,454 detik | 0,548 dtk | 0,535 detik | 0,556 detik | 0,362 detik | 0,568 dtk |
| Melaksanakan penjualan barang dan jasa | 0,667 detik | 0,759 detik | 0,747 detik | 0,879 detik | 0,544 detik | 0,802 detik |
| Memposting invoice untuk pembayaran | 0,028 detik | 0,037 detik | 0,037 detik | 0,038 detik | 0,026 detik | 0,038 detik |
| Perhitungan perkiraan biaya | 3,071 dtk | 3,657 dtk | 4,094 dtk | 3,768 dtk | 15,175 dtk | 10,68 dtk |
| Melaksanakan uji 1C: KIP pada basis eksisting, konfigurasi Manajemen Perdagangan | ||||||
| Melakukan dan kembali dari klien | 2,192 dtk | 2,113 dtk | 2,070 dtk | 2,418 dtk | 1,417 dtk | 1,494 dtk |
| Melaksanakan dan mengembalikan barang ke pemasok | 1,446 dtk | 1.410 dtk | 1,359 dtk | 1,467 dtk | 0,790 dtk | 0,849 detik |
| Memposting pesanan penjualan | 0,355 detik | 0,344 detik | 0,335 detik | 0,361 detik | 0,297 detik | 0,299 dtk |
| Melakukan penghitungan ulang barang | 0,140 detik | 0,134 detik | 0,131 detik | 0,144 detik | 0,100 detik | 0,097 detik |
| Melaksanakan penerimaan spesifikasi | 1.499 dtk | 1,438 dtk | 1,412 dtk | 1,524 dtk | 1,097 dtk | 1,189 dtk |
| Melaksanakan pelaksanaan TS | 1.390 dtk | 1,355 dtk | 1,308 dtk | 1,426 dtk | 1,093 dtk | 1,114 dtk |
| Melaksanakan RKO | 0,759 detik | 0,729 detik | 0,713 detik | 0,759 detik | 0,748 detik | 0,735 detik |
- Dalam pengujian khusus 1C, operasi "membaca data dan perhitungan kompleks", seperti "Perputaran neraca" dan "Perhitungan perkiraan biaya" beberapa kali lebih cepat pada MS SQL DBMS dari Microsoft.
- Dalam operasi "menulis data dan memposting dokumen" di sebagian besar pengujian, DBMS PostgreSQL, yang dioptimalkan untuk 1C, menunjukkan hasil terbaik.
- Tes sintetik Gilev juga menunjukkan keunggulan PostgreSQL. Fakta ini terkait dengan fakta bahwa uji sintetik didasarkan pada pengukuran kecepatan pembuatan dan pengiriman jenis dokumen tertentu, yang juga dianggap sebagai operasi "perekaman data dan pengiriman dokumen".
Mari selesaikan dengan perbandingan lintas platform, mari beralih ke perbandingan dalam setiap sistem:
- Seperti yang diharapkan, tes 1C pada platform perangkat keras menunjukkan hasil yang lebih baik daripada virtual. Perbedaan hasil tes 1C khusus pada kedua kasus kecil, yang menunjukkan pengoptimalan bertahap dari pabrikan hypervisor virtual.
- Penggunaan teknologi memori bersama (SharedMemory) juga diharapkan dapat mempercepat proses pertukaran data antara server 1C dan DBMS. Dengan demikian, hasil pengujian sedikit lebih baik daripada skema dengan interaksi jaringan dari kedua layanan ini melalui protokol TCP-IP.
Kami dapat menyimpulkan bahwa dengan pengaturan 1C dan DBMS yang benar, Anda dapat mencapai hasil yang signifikan bahkan dengan gratis perangkat lunak. Oleh karena itu, saat mendesain struktur TI baru untuk 1C, perlu mempertimbangkan tingkat beban pada sistem, jenis operasi yang ada di database, anggaran yang tersedia, keberadaan spesialis dalam DBMS non-standar, kebutuhan untuk integrasi dengan layanan eksternal, dll. Berdasarkan data ini, sudah dimungkinkan untuk memilih solusi yang diperlukan.
Baca terus untuk pengujian.
Selamat siang, sayang.
Catatan ini adalah petunjuk bagi saya, dan lainnya.
Informasi ini berguna bagi pemula untuk membuat dan mengoptimalkan database 1C di server SQL
Ketika Anda tidak memiliki pengalaman dengan bagian server 1C, maka ketika keinginan dan / atau kebutuhan seperti itu muncul, ada beberapa nuansa dan bukan hal yang jelas.
Sangat menyedihkan bahwa pencarian sederhana seperti memilih server untuk 1C tidak menjamin kesuksesan, dan Anda mungkin mengalami kinerjanya yang sangat lambat.
Di sini, pada tahap mencari tahu apa yang salah, dan mungkin perlu dipahami dalam urutan apa dan apa yang harus dilakukan.
Mulai. Jangan lupa untuk mem-backup data Anda.
Server saya didasarkan pada standar Windows Server 2012 R2, dan SQL 2012.
Anda mungkin memiliki kotak masuk lain, tidak masalah (untuk saat ini).
Kami mengambil pengiriman USP Terintegrasi (termasuk 10 lisensi klien, server (hanya 32 bit), dan konfigurasi ZUP, UT, Akuntansi, dan USP itu sendiri. Patut dicatat bahwa pewaralaba ingin menyertakan pengiriman terpisah secara penuh, dan CORP lebih baik segera.Analisis menunjukkan bahwa ini berlebihan, dan lebih murah untuk mengambil konfigurasi yang rumit.
Saat memilih perangkat keras, penting bagi Anda untuk mengingat bahwa dalam versi 1C klien-server, Anda memerlukan frekuensi prosesor maksimum, serta frekuensi memori (ingat ini saat memilih perangkat keras). (yaitu, perdagangan Hyper dan semua jenis status C1-2-3 sebaiknya dinonaktifkan di BIOS).
Penting juga untuk "secara fisik" menyebarkan file dasar (MDF) dan file log (LDF) untuk memisahkan hard drive, bukan drive logis.
Dan jika untuk versi file akan optimal untuk merekomendasikan SSD, maka di sini, tidak semuanya begitu jelas.
Buka forum Gilev untuk mengenal "misteri" yang muncul dalam upaya meningkatkan kinerja 1C. Banyak yang menarik.
Dalam kasus saya, sesama admin memberi saya blade di server blade, dengan 2 prosesor fisik AMD Quad-Core Opteron (tm) Processor 2354, dengan 16 GB (667 MHz). Sistem pada 2 disk di cermin. Disk untuk pangkalan dialokasikan oleh Fibre chanel, di HP EVA.
Sekarang saya sedang mencari konfigurasi lain, tetapi untuk saat ini saya harus hidup dengan ini.
Dan pada tahap implementasi, saat analisis sedang dilakukan tentang cara mentransfer data dari sistem ERP lain, pemrogram 1C menarik perhatian saya ke pekerjaan yang lambat dan dokumen yang panjang. Artinya, sistem belum dieksploitasi, tetapi sudah melambat dan sekarat, dan melakukan kembali 3 kali lebih lambat daripada orang di laptop, dan orang juga harus bekerja dengan ini (3-4 yang utama, dan 25-40 pengatur waktu).
Bukan pesanan.
Dia merekomendasikan menggunakan tes Gilev (situsnya mudah untuk google), yang penuh dengan layanan dukungan dan informasi. Apa yang dia gunakan.
Pengujian menunjukkan bahwa semuanya buruk, dan jumlah pengguna yang disarankan tidak ada.
Melihat lebih dekat, saya menyadari bahwa basis dan log setidaknya ada di disk yang berbeda - tetapi yang logis.
Dan untuk memperbaikinya, saya membuat tangkapan layar dan memo ini untuk masa depan untuk saya sendiri dan orang lain:
Membuat database di Server SQL studio manajemen. Kami menyebarkan database dan log ke disk fisik yang berbeda.
Pilih metode pemulihan sederhana
Kami membuat basis baru melalui klien 1C di komputer
Pilih untuk menambahkan basis info. Dalam kasus kami, tidak ada konfigurasi.
Tetapkan nama. Ada di sini. Lebih baik daripada di server.
Kami mengisi data. Saat ditunjukkan di server, nama server menunjukkan 127.0.0.1 - jika tidak, tidak berfungsi.
jangan ubah apa pun di sini
Kami memuat basis informasi kami (sebelumnya tersedia atau baru, misalnya, tes)
Sebenarnya pilihan basis. Saya memuat tes Gilev untuk platform 8.3
Kami konfirmasi
Kami konfirmasi
Hasil tes. Semuanya masih buruk, tetapi jumlah pengguna yang disarankan lebih dari yang dibutuhkan, itu bagus.
P.S. Jangan lupa untuk membuat cadangan.
P.P.S saat menjalankan tes Gilev di database tes, yang terletak di lokasi penyimpanan yang sama dengan database pertempuran mana pun - perlu diingat bahwa setidaknya file Log cenderung mengambil semuanya tempat bebas, yang penuh dengan menghentikan pangkalan tempur dan tidak lulus ujian !!!
P.P.P.S juga ingat bahwa SQL berjalan menggunakan database TEMP yang terletak di tempat yang sama di mana SQL diinstal (secara default di C).
Oleh karena itu, diharapkan untuk meningkatkan akses ke database ini juga.
Juga informasi untuk membantu - Penghemat Efek memungkinkan Anda menyimpan 1 detik dari basis
Tidak masuk akal untuk mencadangkan yang lainnya, karena dalam kasus saya lisensinya adalah perangkat lunak dan ketika ditransfer ke perangkat keras lain, lisensinya hilang.
Dari tambahan.
Jika Anda ingin memberikan kebebasan kepada pengguna domain untuk membuat database apa pun menggunakan 1C, maka akun Layanan server 1C untuk membuat akun domain yang memiliki hak untuk membuat database tanpa administrator sistem pun sudah cukup,
pada saat yang sama, Anda tidak perlu menulis login dan kata sandi di properti infobase ...
Memuat...