Bagaimana cara menggunakan antrian online kami mencegah situs yang macet dan situs web crash - berapa banyak pengguna bersamaan yang dapat ditangani oleh server web?

Mengapa menggunakan Ruang Tunggu Virtual berbasis tarif?

Berbasis tarif atau satu keluar, satu masuk? Kami menimbang pro dan kontra.

Kami tidak dapat benar-benar menemukan pro untuk satu-keluar, satu-dalam. Singkatnya, masalah dengan pendekatan itu adalah ketika pengguna adalah pengunjung situs web e commerce, server web tidak tahu berapa banyak pengguna bersamaan yang dimilikinya setiap saat. Ini adalah showstopper. Inilah alasannya.

Nanti dalam artikel ini, kami juga memberi tahu Anda cara menggunakan ruang virtual berbasis tarif untuk melindungi situs Anda juga.



Ruang Tunggu Virtual dengan nilai tertinggi di G2

Apa yang Klien kami katakan tentang Queue-Fair


pengujian beban permintaan http berapa banyak permintaan yang dapat dilakukan server web tanpa sumber daya server tambahan

Berapa banyak pengguna bersamaan yang bisa ditangani oleh server web?

Jika Anda tahu berapa banyak pengguna bersamaan yang ditangani server web, dan waktu transaksi rata-rata atau durasi kunjungan, dari halaman pertama dalam alur transaksi Anda ke halaman konfirmasi pesanan, Anda dapat mengubahnya menjadi Tingkat Antrian menggunakan Hukum Little dengan membagi jumlah pengguna dengan durasi, seperti ini:

Tingkat antrian = Pengguna bersamaan / Waktu transaksi

Seberapa akuratkah sistem antrian berbasis tarif?

Queue-Fair akan mengantarkan pengunjung ke situs web Anda pada tingkat yang Anda tentukan - kami memiliki AI Antrian yang paling akurat dalam bisnis ini untuk memastikan bahwa jumlah pengunjung yang Anda inginkan setiap menit adalah jumlah pengunjung yang Anda dapatkan setiap menit, menghitung secara otomatis untuk orang-orang yang tidak hadir ketika giliran mereka dipanggil, serta orang-orang yang datang kembali terlambat.

Bagaimana ini diterjemahkan ke dalam jumlah Pengguna Bersamaan? Tentu saja, tidak setiap pengunjung yang mencapai situs Anda akan membutuhkan waktu transaksi rata-rata yang tepat untuk menyelesaikan transaksi mereka, tetapi Anda akan mendapatkan jumlah Pengguna Konkuren yang sangat stabil dengan Queue-Fair, karena Hukum Bilangan Besar.

Sebagai contoh, katakanlah Anda memiliki Tingkat Antrian 100 pengunjung per menit. Kami akan mengirim 100 pengunjung ke situs Anda setiap menit dalam aliran yang stabil - itulah yang kami lakukan dan kami sangat ahli dalam hal itu. Katakanlah juga bahwa orang-orang menggunakan situs web Anda selama rata-rata (rata-rata) lima menit, dengan 70% dari mereka membutuhkan waktu antara 4 dan 6 menit dari saat mereka dilewati antrian hingga saat mereka membuat permintaan halaman terakhir mereka (apakah mereka menyelesaikan transaksi atau tidak). Itu adalah Standar Deviasi satu menit di kedua sisi rata-rata. Secara statistik, itu berarti untuk setiap pengunjung yang membutuhkan waktu lima setengah menit, akan ada pengunjung lain yang membutuhkan waktu empat setengah menit, dan variasi dalam durasi kunjungan individu di beberapa sesi karena itu cenderung membatalkan satu sama lain ketika Anda menghitung banyak dari mereka dengan cara apa pun. Hukum Bilangan Besar mengatakan bahwa pembatalan ini menjadi semakin tepat semakin besar jumlah orang yang terlibat.

sistem operasi jumlah maksimum sumber daya server web
perhitungan angka rata-rata untuk pengguna bersamaan dengan interval kepercayaan

Seberapa tepat, tepatnya? Kita bisa mengatasinya dengan sedikit statistik. Ada ukuran sampel 5 * 100 = 500, yang merupakan Angka Besar yang terlibat di sini. Itu adalah berapa banyak orang yang Anda hitung. Ini berarti Kesalahan Standar dalam Rata-rata untuk waktu transaksi adalah 1 (deviasi standar, 1 menit) dibagi dengan akar kuadrat dari ukuran sampel (jadi akar kuadrat dari 500) sesuai dengan rumus statistik untuk Kesalahan Standar dalam Rata-rata, yang memberikan Kesalahan Standar dalam Rata-rata untuk waktu transaksi 0,044 menit, atau hanya 2,7 detik, yang kurang dari satu persen.

Ini berarti dengan Tingkat Antrian 100, dan waktu transaksi 5 menit atau kurang satu menit untuk setiap pengunjung individu, Anda harus mengharapkan antara 495 dan 505 pengguna bersamaan di situs Anda sekitar 70% dari waktu, sehingga matematika mengatakan menggunakan antrian berbasis tingkat akan memberikan beban yang sangat stabil pada server web Anda seperti yang diinginkan.

Tetapi apakah perhitungannya akurat? Ada beberapa kehalusan di sini - sebagai contoh, ukuran sampel yang kita hitung tidak selalu tepat 500 setiap kali Pengguna Bersamaan dihitung (yaitu pada saat tertentu dalam waktu), dan juga distribusi normal (Gaussian) dapat memberikan waktu transaksi negatif yang tidak terjadi dalam kehidupan nyata. Jadi, kami menggunakan simulator pengunjung-demi-pengunjung, detik-demi-detik untuk melakukan pengukuran untuk memeriksa perhitungan semacam ini, dan itu memberi tahu kami bahwa dengan angka-angka di atas, Anda harus mengharapkan antara 493 dan 507 pengunjung 70% dari waktu, jadi perhitungannya bertahan dengan sangat baik! Mengukur data juga memberi tahu kami bahwa situs Anda akan memiliki 500 ± 15 Pengguna Bersamaan setidaknya 95% dari waktu.

Itu mungkin lebih stabil daripada akurasi server web Anda yang dapat mengukur jumlah orang yang menggunakan situs Anda! Bahkan lebih baik lagi, hal yang benar-benar rapi di sini adalah bahwa bahkan jika Anda tidak tahu berapa rata-rata waktu transaksi atau deviasi standar untuk pengunjung Anda, jumlah matematis ini ada baik Anda mengetahuinya atau tidak, dan Anda tetap akan mendapatkan beban yang stabil.

Hasilnya adalah Queue-Fair akan memberikan jumlah pengunjung per menit yang Anda inginkan dengan akurasi yang cukup sempurna, menghasilkan jumlah pengguna bersamaan yang sangat stabil di situs Anda, dan beban server web yang stabil di mana Anda memiliki kendali penuh.

Hore!


servers capacity can be exceeced with inaccurate queues Dan sekarang sebuah peringatan. Perlu dicatat bahwa stabilitas jumlah pengguna bersamaan di situs Anda - dan oleh karena itu stabilitas beban server Anda - sangat bergantung pada seberapa akurat penyedia Ruang Tunggu Virtual Anda mengirimkan jumlah pengunjung yang Anda inginkan setiap menitnya, dan oleh karena itu ini adalah faktor kunci ketika Anda memilih platform Ruang Tunggu Virtual. Karena kami menyediakan Ruang Tunggu Virtual yang paling akurat di dunia, tidak ada yang menghentikan server Anda membanjiri lebih baik daripada Queue-Fair.

Cara Mudah Menghitung Tingkat Antrian

Bagaimana jika Anda tidak tahu berapa banyak Pengguna Bersamaan yang dapat ditangani server, atau Waktu Transaksi? Anda dapat melihat halaman yang kemungkinan menjadi bottleneck Anda - biasanya halaman yang merupakan hasil dari mengklik tombol "Beli Sekarang". Gunakan Google Analytics untuk menemukan pengunjung unik bulanan ke halaman itu, atau hitung pesanan bulanan Anda. Bagilah ini dengan 30 * 24 * 60 = 43.200 yang merupakan jumlah menit dalam sebulan (kira-kira). Itulah rata-rata pengunjung per menit Anda selama sebulan penuh. Kalikan ini dengan tiga. Itulah rata-rata pengunjung per menit selama jam kerja (kurang lebih). Gandakan ini. Itu mungkin angka yang aman untuk Tingkat Antrian untuk digunakan.

Misalnya, katakanlah Anda memproses 100.000 pesanan per bulan - itu berarti 100.000 klik tombol "Beli Sekarang". Itu berarti 100.000 / 43.200 = 2,31 pesanan per menit. Anda akan mengharapkan sebagian besar pesanan ini terjadi pada siang hari, dan server Anda menjadi lebih tenang di malam hari, jadi kalikan ini dengan 3 dan itu adalah 7 pesanan per menit sebagai perkiraan kasar tentang seberapa sibuk server Anda selama jam kerja. Jika angka yang dihasilkan kurang dari 50: akan ada puncak dan palung dalam permintaan, jadi jika server Anda tidak terasa lambat pada jam sibuk, kalikan ini dengan 2 untuk mendapatkan 14 pengguna aktif per menit. Jika angkanya lebih dari 50: puncak dan palung menit ke menit akan lebih kecil jika dibandingkan, dan tidak aman untuk menggandakannya. Angka yang Anda dapatkan mungkin merupakan angka yang aman untuk Tingkat Antrian untuk memulai dan sesuai dengan berapa banyak permintaan per detik yang dapat Anda kelola dengan aman; Anda selalu dapat meningkatkannya jika Anda menemukan sistem Anda masih responsif untuk kinerja pengguna akhir pada tingkat itu.

menghitung tingkat maksimal pengguna aktif untuk aplikasi web Anda

Jika pesanan Anda dicap waktu, Anda juga dapat melihat pesanan maksimum yang Anda ambil dalam satu menit dalam satu bulan terakhir - tetapi gunakan dengan hati-hati karena Anda tidak akan tahu berapa banyak pesanan yang mungkin Anda jatuhkan selama menit ini karena server Anda melambat, jadi kurangi ini sebesar 20%.

Bagian selanjutnya dari artikel ini membahas beberapa cara lain untuk mengetahui Tingkat Antrian.

kebingungan tentang pengguna bersamaan koneksi bersamaan sesi bersamaan dan durasi sesi rata-rata

Gotcha #1: Pengguna Bersamaan vs Permintaan Bersamaan vs Koneksi Bersamaan vs Sesi Bersamaan

Perlu ditunjukkan bahwa setidaknya ada dua definisi "Concurrent Users" dalam penggunaan umum.

Kami menggunakan definisi, 'jumlah orang yang terlibat dalam aliran transaksi pada satu waktu'. Itulah angka kunci yang perlu Anda ketahui untuk menetapkan Tingkat Antrian. Itulah berapa banyak pengguna yang melihat situs Anda sekarang. Jumlah Sesi Bersamaan biasanya agak lebih besar daripada jumlah koneksi bersamaan atau pengguna bersamaan, karena beberapa sesi sedang dalam proses waktu habis, meningkatkan durasi sesi rata-rata.

Bandingkan ini dengan berapa banyak Concurrent Requests, yang merupakan jumlah permintaan HTTP yang sedang diproses oleh server web Anda pada satu waktu. Sangat membingungkan, banyak orang teknologi akan mengartikan berapa banyak Permintaan Bersamaan ketika mereka mengatakan berapa banyak Pengguna Bersamaan.

Kemudian ada Concurrent Connections (atau koneksi TCP bersamaan ke port server yang sama pada kartu antarmuka jaringan Anda), yang merupakan jumlah TCP/IP Sockets yang terbuka pada port server atau layanan backend Anda pada satu waktu. Ketika membuat permintaan halaman, browser secara default akan membiarkan koneksi terbuka jika ada permintaan lebih lanjut yang dibuat oleh halaman, atau pengguna pergi ke halaman lain. Hal ini mengurangi jumlah permintaan per detik untuk membuka koneksi TCP/IP baru, membuat proses server lebih efisien. Batas waktu untuk koneksi bersamaan ini bervariasi menurut browser, dari 60 detik hingga tidak pernah ditutup. Server Anda mungkin secara otomatis menutup koneksi setelah periode tidak ada aktivitas juga. Pada webserver Linux, Anda bisa mendapatkan hitungan Concurrent Connections ke port server yang sama dengan perintah ini:

netstat -aenp | grep ":80 \|:443 " | wc -l

yang dapat Anda coba jika Anda penasaran. Sekali lagi, beberapa orang menyebutnya "Concurrent Users" juga, padahal yang dimaksud adalah koneksi bersamaan.

Memang jika Anda meminta penyedia hosting Anda untuk memberi tahu Anda jumlah maksimum Pengguna Bersamaan yang ditangani server web Anda (berapa banyak lalu lintas puncak), mereka mungkin akan benar-benar memberi Anda angka untuk Sesi Bersamaan, Permintaan Bersamaan, atau Koneksi Bersamaan, karena alasan sederhana bahwa mereka tidak tahu waktu transaksi rata-rata Anda, jumlah halaman dalam aliran transaksi Anda, atau informasi lain yang memungkinkan mereka memberi tahu Anda berapa banyak pengguna simultan yang ditangani server web Anda. Semua angka-angka ini memiliki nilai yang berbeda.

Jika Anda menanyakan informasi tentang tingkat lalu lintas maksimum kepada penyedia hosting atau tim teknis Anda, sangat penting bagi Anda untuk mengklarifikasi apakah yang mereka maksud adalah Pengguna Bersamaan, Sesi Bersamaan, Permintaan Bersamaan, atau Koneksi Bersamaan.

Kesalahan ini bisa merusak situs web Anda!

Inilah alasannya. Setiap halaman adalah permintaan HTTP tunggal, tetapi semua gambar, skrip, dan file lain yang berasal dari aplikasi web Anda yang digunakan browser untuk menampilkan halaman juga merupakan permintaan HTTP.

Bayangkan Anda telah diberitahu oleh tim teknis Anda bahwa server mendukung 500 Pengguna Bersamaan, tetapi yang sebenarnya mereka maksudkan adalah 500 Permintaan Bersamaan. Dengan waktu transaksi 5 menit, Anda menggunakan rumus di atas dan berasumsi bahwa situs Anda dapat mendukung 100 pengunjung per menit.

Bisakah? Tidak.

Saat orang melewati alur transaksi, mereka hanya benar-benar membuat permintaan dari server Anda saat setiap halaman dimuat. Hal ini mempengaruhi berapa banyak lalu lintas per detik atau pengguna aktif yang dapat ditangani server Anda. Dari waktu transaksi lima menit, itu hanya beberapa detik untuk pengguna rata-rata. Oleh karena itu, Anda mungkin berpikir bahwa 500 Permintaan Konkuren berarti Anda dapat menangani lebih banyak Pengguna Konkuren, tetapi Anda mungkin salah. Dapatkah Anda melihat sekarang bagaimana memahami kapasitas situs web Anda dalam hal berapa banyak lalu lintas atau jumlah total pengguna aktif adalah bisnis yang rumit?

Utamakan keamanan sumber daya server Anda ketika menghitung berapa banyak permintaan yang mungkin didapat halaman web Anda untuk pengalaman yang baik bagi setiap pengguna

Mengubah Permintaan Bersamaan ke Pengguna Bersamaan

Untuk mengetahui jumlah maksimum Pengguna Konkuren Anda dari jumlah total maksimum Permintaan Konkuren Anda, Anda juga perlu mengetahui

  1. Jumlah halaman dalam alur transaksi Anda
  2. Rata-rata waktu transaksi pengunjung dari halaman pertama hingga halaman terakhir dalam alur Anda
  3. Berapa banyak permintaan yang membentuk setiap halaman, rata-rata
  4. Waktu rata-rata yang dibutuhkan server Anda untuk memproses satu permintaan HTTP

Anda mungkin sudah tahu 1) dan 2) - dalam contoh kami, 6 halaman dan 5 menit. Anda dapat dengan mudah menghitung halaman yang Anda lihat saat melakukan transaksi. Jika Anda tidak tahu waktu transaksi rata-rata, Google Analytics dapat memberi tahu Anda, atau Anda dapat memeriksa log server web Anda.

Untuk 3) dan 4), peramban Firefox dapat membantu. Klik kanan pada halaman di situs Anda, pilih Inspect Element, dan tab Network. Kemudian tekan CTRL-SHIFT-R untuk menyegarkan halaman sepenuhnya. Anda akan melihat waktu muat jaringan untuk setiap elemen halaman dalam daftar. Anda ingin memastikan bahwa Anda dapat melihat ukuran transfer di kolom Transferred, karena jika tidak, file mungkin disajikan dari cache yang dapat mengacaukan perhitungan Anda. Anda mungkin melihat beberapa skrip dan sumber daya lainnya berasal dari server selain situs Anda, jadi Anda bisa mengetikkan nama domain untuk situs Anda dalam kotak filter di sebelah kiri. Untuk melihat kolom Durasi, klik kanan setiap tajuk kolom dan pilih Timings -> Duration dari menu pop up. Layar Anda akan terlihat seperti ini:

google memproses nginx yang dikonfigurasi dengan benar dengan google analytics untuk unggahan gambar

Tab Jaringan Firefox untuk halaman ini, menunjukkan Durasi dan jumlah Permintaan dari queue-fair.com

File yang digunakan dalam tampilan halaman Anda bisa berasal dari sejumlah situs yang berbeda, jadi Anda juga ingin menggunakan filter di kiri atas untuk hanya menampilkan yang berasal dari situs Anda - tetapi hanya jika Anda yakin bahwa file-file dari situs lain tersebut bukan alasan lambatnya pemuatan halaman, atau bagian dari hambatan Anda.

Firefox menghitung permintaan untuk Anda di bagian kiri bawah tampilan, dan menunjukkan 36 permintaan HTTP hanyauntuk satu halaman ini.

Anda perlu melakukan ini untuk setiap halaman dalam alur transaksi Anda - hitung totalnya dan bagi dengan jumlah halaman untuk menemukan jumlah rata-rata permintaan HTTP untuk setiap halaman, nomor 3) dalam daftar kami. Anda dapat melihat sekarang mengapa jumlah permintaan anak untuk setiap halaman HTML merupakan faktor kunci untuk berapa banyak lalu lintas yang dapat ditangani server web Anda.

Untuk nomor 4), Anda perlu melihat kolom Durasi dan menemukan rata-rata untuk semua permintaan HTTP untuk semua halaman Anda. Jika Anda tidak yakin, asumsikan setengah detik - ada banyak ketidakpastian dalam hal ini (lihat di bawah).

melakukan perhitungan untuk mengetahui berapa banyak sesi pada saat yang sama, berapa banyak pengguna dan berapa banyak permintaan per detik pada aplikasi web Anda baik itu server tunggal atau konten statis

Melakukan perhitungan

Mari kita berikan beberapa contoh angka. Kita sudah mengatakan ada enam halaman dinamis dalam contoh alur proses server, yaitu 1), dan bahwa waktu transaksi rata-rata adalah lima menit, yaitu 2). Mari kita asumsikan 36 permintaan HTTP per halaman untuk 3), dan setengah detik untuk waktu pemrosesan server untuk setiap permintaan HTTP, yaitu 4).

Dengan angka-angka tersebut, server yang dapat menangani 500 Permintaan Konkuren dapat menangani 500 / (0,5 detik) = 1000 permintaan HTTP per detik, yang berarti 60.000 permintaan HTTP per menit, ketika benar-benar maksimal.

Selama waktu transaksi lima menit, ini dapat menangani 5 * 60.000 = 300.000 permintaan HTTP. Sepertinya banyak, bukan?

Tetapi, untuk setiap pengunjung, ada enam halaman dengan rata-rata masing-masing 36 permintaan HTTP, jadi itu 6 * 36 = 216 permintaan

Jadi, kapasitas 300.000 permintaan HTTP secara teori dapat menangani 300.000 / 216 = 1.389 Pengguna Bersamaan

Gotcha #2: Server Web Menjadi Lebih Lambat Dengan Beban

Hei, itu bagus! Kami pikir kami hanya bisa memiliki tingkat antrian 100, tetapi 1.389/5 menit = 278 pengunjung per menit, jadi kami bisa memiliki tingkat antrian yang lebih tinggi!

Mungkin tidak. Pertama, pengunjung Anda tidak akan mengirim permintaan dengan rapi pada interval tepat setengah detik, seperti yang diasumsikan oleh perhitungan di atas. Lebih penting lagi, Anda akan mengukur data masukan Anda ketika situs tidak sibuk. Sampah masuk, sampah keluar.

Ketika situs sedang sibuk, server membutuhkan waktu lebih lama untuk memproses permintaan - Anda akan memperhatikan hal ini di situs lain ketika sedang sibuk, bahwa Anda menunggu lebih lama untuk halaman. Hal ini meningkatkan waktu rata-rata yang dibutuhkan server Anda untuk memproses satu permintaan HTTP (4), yang mengurangi throughput maksimum. Jadi ambil 278 pengunjung per menit dan bagi dua. Kemudian bagi dua lagi. Anda mungkin secara realistis melihat sekitar 70 pengunjung baru per menit pada beban maksimum.

semakin berat beban dari lonjakan lalu lintas Anda, semakin lambat mesin menjadi

Faktor-faktor pengganggu lainnya termasuk caching, yang berarti browser pengunjung Anda mungkin tidak perlu membuat setiap permintaan untuk setiap halaman - ini cenderung berarti server membutuhkan sumber daya yang lebih sedikit dan dapat meningkatkan jumlah pengunjung baru per menit yang dapat ditangani server Anda. Penyeimbang beban yang mendistribusikan beban di beberapa server, dan menyajikan konten statis daripada halaman dinamis juga dapat mempercepat proses server Anda, karena setiap server membutuhkan sumber daya yang lebih sedikit.

Anda juga akan menemukan bahwa tidak semua halaman membutuhkan waktu yang sama untuk diselesaikan, karena beberapa halaman membutuhkan sumber daya yang lebih sedikit daripada yang lain untuk diproduksi dan disajikan. Pencarian basis data, permintaan pencarian, dan pembaruan membutuhkan waktu paling lama, sehingga Anda akan memiliki hambatan di suatu tempat dalam proses Anda di mana orang menumpuk, menunggu detail kartu kredit diproses dan pesanan disimpan, atau menunggu ketersediaan untuk diperiksa. Setiap aliran transaksi memiliki langkah paling lambat sehingga selalu ada hambatan di suatu tempat, dan selalu ada jawaban nilai maksimum untuk pertanyaan berapa banyak pengguna bersamaan yang dapat ditangani oleh server web - dan mungkin ada beberapa batasan yang terlibat. Dalam hal ini, Anda ingin mengatur Queue Rate Anda cukup rendah untuk memastikan bahwa server Anda memiliki kapasitas waktu cpu untuk memproses cukup banyak orang secara bersamaan untuk langkah paling lambat dalam proses Anda sehingga orang tidak menumpuk di sana. Jika tidak, server web Anda bisa benar-benar terhenti.

tidak pasti bagaimana memperkirakan kapasitas server sumber daya server untuk setiap pengguna tunggal

Jadi apa yang harus saya lakukan?

Pengalaman kami adalah bahwa, memasuki penjualan pertama mereka, semua orang melebih-lebihkan kemampuan server mereka untuk mengatasi lalu lintas dengan volume lalu lintas yang tinggi.

Semua orang.

Menentukan durasi sesi rata-rata dan kinerja pengguna akhir secara akurat selama lalu lintas lambat atau puncak bukanlah untuk orang yang lemah hati. Hal terbaik yang harus dilakukan adalah menjalankan uji beban yang tepat, dengan pelanggan 'palsu' yang benar-benar melalui proses pemesanan saat pengujian beban persis seperti yang mereka lakukan dalam kehidupan nyata, membuat permintaan HTTP yang sama dalam urutan yang sama, dengan penantian yang sama di antara halaman-halaman saat pengujian beban seperti yang Anda lihat dalam kehidupan nyata, dan mengawasi beban prosesor, throughput IO, dan waktu respons saat Anda meningkatkan jumlah pengunjung virtual. Anda dapat menggunakan Apache JMeter untuk ini (kami juga menyukai K6 untuk beban yang lebih ringan atau mesin yang lebih lambat), tetapi alat apa pun yang Anda gunakan akan memakan waktu dan rumit untuk meniru perilaku setiap pengguna dengan cara yang tepat (terutama dengan kompleksitas caching). Bahkan kemudian, ambil angka maksimal Anda dan kurangi setengahnya.

Jika tidak ada hal itu, berhati-hatilah.

Anda dapat dengan mudah mengubah Tingkat Antrian untuk antrian Queue-Fair kapan saja menggunakan portal Queue-Fair. Mulailah dengan 10 pengunjung per menit, atau tingkat transaksi Anda pada hari yang lebih normal, lihat bagaimana hasilnya selama beberapa saat setelah tiket Anda mulai dijual, dan jika semuanya terlihat bagus, beban prosesor Anda rendah, database sql Anda baik-baik saja dan (di atas semua itu) halaman Anda responsif ketika Anda menekan CTRL-SHIFT-R, gandakan, tunggu sebentar, dan ulangi. Anda akan segera menemukan tingkat aktual yang Anda butuhkan selama 'load balancing' ini (lihat apa yang kami lakukan di sana?), dan ingat, dari sudut pandang pengalaman pelanggan, tidak masalah untuk menaikkan Tingkat Antrian karena hal ini menyebabkan perkiraan penantian yang dilihat oleh pelanggan Anda dalam antrian berkurang, dan semua orang senang melihat waktu respons yang memberikan perkiraan penantian yang lebih pendek.

Apa yang ingin Anda hindari adalah menetapkan Tingkat Antrian terlalu tinggi kemudian berada dalam posisi harus menurunkannya, karena ini a) berarti orang yang menggunakan situs mengalami pemuatan halaman yang lambat, dan b) menyebabkan perkiraan menunggu meningkat. Semua orang dalam antrian Anda akan menghela napas!

Gotcha #3: Meningkatkan tarif terlalu cepat setelah antrian terbuka

Ingat, Anda akan memiliki hambatan di suatu tempat dalam proses pemesanan Anda - setiap transaksi memiliki langkah paling lambat - dan Anda akan mendapatkan beberapa sesi menumpuk di sana. Apa yang tidak ingin Anda lakukan adalah mendapatkan satu menit ke dalam penjualan tiket Anda, melihat bahwa beban prosesor server Anda jauh di bawah angka maksimumnya, dan menaikkan tarif. Pengunjung Anda mungkin belum sampai pada tombol "Beli Sekarang". Anda ingin menunggu sampai database sql Anda melaporkan pesanan baru pada tingkat yang sama atau serupa dengan Tingkat Antrian Anda dan kemudian melakukan pengukuran dan tes responsivitas Anda. Ingatlah bahwa setiap kali Anda meningkatkan tarif, maka akan membutuhkan waktu yang sama bagi pengunjung ekstra untuk mencapai bottleneck Anda, jadi Anda tidak akan dapat menilai secara akurat bagaimana kinerja server Anda pada tarif baru sampai setelah waktu itu berlalu.

memperlambat keputusan untuk mengkonsumsi sumber daya server
server snap ketika kapasitas server terlampaui

Gotcha #4: Menjentikkan server Anda

Kita telah membahas bagaimana cara terbaik untuk meningkatkan Tingkat Antrian secara bertahap setelah antrian Anda dibuka. Anda mungkin menyadari bahwa server Anda memiliki batas yang tidak dapat dilampaui tanpa sistem mengalami crash dan bahkan mungkin menyadari apa batasnya - tetapi apa yang mungkin tidak Anda ketahui adalah bahwa ketika beban mendekati batas ini, biasanya hanya ada sedikit tanda - sering kali hanya ada beberapa kesalahan atau peringatan, atau beban prosesor di atas 80%.

Ketika layanan web gagal, layanan tersebut cenderung 'snap' atau gagal dengan sangat cepat. Ini biasanya karena begitu sistem Anda tidak dapat lagi memproses permintaan secepat permintaan yang masuk, antrian internal pemrosesan akan menumpuk. Sistem Anda kemudian harus melakukan pekerjaan memproses, mengelola, dan menyimpan antrian internalnya serta permintaan, dan itulah yang membuat server-server Anda mengalami kegagalan. Sangat cepat. Setelah itu terjadi, server Anda mungkin untuk sementara waktu dapat merespons dengan halaman kesalahan, tetapi ini tidak membantu Anda karena pengunjung yang melihatnya akan segera menekan Refresh, menambah beban.

Jadi, jangan memaksakan server Anda lebih keras dari yang Anda butuhkan. Mengejar 20% terakhir dari kapasitas waktu cpu biasanya tidak sebanding dengan risikonya. Jika ukuran antrian yang ditunjukkan di Portal Queue-Fair (angka dan garis kuning Menunggu di grafik) menurun atau bahkan hanya meningkat lebih lambat, menit demi menit, dan waktu tunggu yang ditunjukkan adalah 50 menit atau kurang, maka Anda memproses pesanan dengan cukup cepat dan antrian pada akhirnya akan kosong dan berhenti menampilkan Halaman Antrian secara otomatis, tanpa Anda harus melakukan apa pun, dan tanpa Anda harus memberi tahu atasan Anda bahwa Anda terlalu memaksakan dan merusaknya. Anda akan sampai di sana pada akhirnya selama kecepatan dari Bagian Depan Antrian lebih tinggi daripada jumlah Gabung setiap menitnya (keduanya ditampilkan dalam Portal Queue-Fair) - titik balik biasanya setidaknya beberapa menit dalam setiap acara. Jika Anda menjual produk dengan kuantitas terbatas, Anda mungkin akan terjual habis sebelum titik balik tercapai.

Kabar baiknya adalah jika Anda secara tidak sengaja mengatur Tingkat Antrian terlalu tinggi dan server Anda rusak, Queue-Fair dapat membantu Anda bangkit dan berjalan dengan cepat - cukup letakkan antrian pada Mode Tahan sampai server Anda siap untuk menangani pengunjung lagi. Dalam mode Tahan, orang-orang dalam antrian melihat halaman Tahan khusus yang dapat Anda rancang sebelum acara online Anda. Tidak ada yang diizinkan masuk dari depan antrian ketika dalam mode Hold, tetapi pengunjung internet baru masih dapat bergabung dengan antrian di belakang, untuk diantri secara adil setelah penyumbatan dibersihkan, yang akan terjadi dengan sangat cepat karena Queue-Fair melindungi situs Anda dari permintaan. Halaman Tahan adalah pengalaman pengguna yang lebih unggul daripada mengatur Tingkat Antrian yang sangat rendah, terutama jika Anda memperbaruinya untuk memberi tahu pengunjung jam berapa Anda mengharapkan Antrian dibuka kembali, yang mudah dilakukan dengan editor halaman Portal, bahkan ketika ratusan ribu orang sudah berada dalam antrian - dan dalam mode Tahan, Anda bahkan dapat membiarkan mereka masuk satu per satu dengan tombol Admit One yang unik dari Queue-Fair jika Anda perlu sementara sistem Anda pulih dari jepretannya.

Jadi, jika Anda menemukan server Anda perlu istirahat selama acara Anda, halaman Hold adalah yang Anda butuhkan untuk itu, dan akan membantu server Anda pulih lebih cepat untuk boot.

Kesimpulan

Dalam artikel ini kami telah menjelaskan mengapa antrean berbasis tarif selalu menjadi jalan ke depan, dan memberikan dua metode untuk menghitung tarif yang Anda butuhkan, tetapi kecuali Anda telah melakukan pengujian beban pengunjung virtual yang lengkap dan akurat pada seluruh aliran transaksi Anda, dan benar-benar sangat yakin tentang hal itu, saran kami selalu sama:

  1. Mulai dengan Tingkat Antrian yang ditetapkan ke 10, atau tingkat transaksi Anda pada hari yang lebih normal.
  2. Perhatikan beban prosesor Anda dan indikator performa lainnya.
  3. Tunggu sampai pesanan baru dicatat dalam database sql Anda pada tingkat yang sama atau serupa dengan Tingkat Antrian Anda.
  4. Tekan CTRL-SHIFT-R pada halaman Anda untuk memeriksa responsifitas.
  5. Tingkatkan Tingkat Antrian tidak lebih dari 20%.
  6. Kembali ke Langkah 2, dan tunggu lagi.
  7. Setelah ukuran antrian menurun atau terus meningkat kurang cepat setiap menitnya, dan waktu tunggu yang ditunjukkan kurang dari 50 menit, maka tidak perlu lebih cepat lagi.
  8. Duduk dan bersantailah! Queue-Fair siap membantu Anda.

Jika Anda menjual produk dalam jumlah terbatas, Anda juga tidak perlu memperhatikan Langkah 7.

Itu untuk antrian pertama Anda, ketika Anda tidak tahu Tingkat Antrian maksimum yang sebenarnya dapat didukung oleh sistem Anda. Untuk antrian-antrian berikutnya, sekali anda telah mengukur Tingkat Antrian yang sebenarnya dapat ditangani oleh sistem anda, anda mungkin dapat menggunakan angka yang sama lagi - tetapi hanya jika tidak ada yang berubah pada sistem anda. Dalam prakteknya, sistem anda mungkin sedang dalam pengembangan dan modifikasi yang konstan, dan anda mungkin tidak tahu bagaimana perubahan-perubahan terbaru telah mempengaruhi Tingkat Antrian maksimum anda - jadi mengapa tidak mulai dari setengah dari angka yang anda ukur sebelumnya dan mengulangi proses di atas?

Ingat, selalu lebih baik aman daripada menyesal.


Ratusan organisasi terkemuka mempercayai
solusi antrian
kami

Customer 1 Customer 2 Customer 3 Customer 4 Customer 5 Customer 6

Solusi sederhana untuk lonjakan lalu lintas internet Anda

Memulai