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.
Secara tradisional server e commerce disediakan untuk mendukung jumlah maksimum pengguna bersamaan, dan beban sering didefinisikan dengan cara ini. Ada masalah dengan menggunakan pendekatan ini untuk menjalankan antrian untuk situs web - masalah yang kami selesaikan dengan tarif.
Masalah muncul karena pengunjung hanya benar-benar menggunakan webserver saat browser mereka memuat setiap halaman web.
Misalnya, katakanlah sebuah situs e commerce menjual tiket. Dari awal perjalanan pengunjung hingga akhir perjalanan pengunjung (sesi pengguna) ada enam halaman sebagai pengunjung
Keseluruhan proses transaksi rata-rata memerlukan waktu lima menit.
Katakanlah, sekali lagi misalnya, 100 pengunjung datang untuk membeli tiket setiap menit, dan waktu rata-rata untuk menyelesaikan prosesnya adalah lima menit. Pada saat tertentu, ada 500 orang dalam proses transaksi pada saat yang sama, dan server harus disediakan untuk mendukung 500 pengguna bersamaan.
Orang mungkin berpikir bahwa seseorang bisa membuat Concurrent User Counter yang bertambah setiap kali pengunjung baru tiba di halaman beranda, dan berkurang setiap kali pengunjung menyelesaikan transaksi, dan ini akan memberi tahu Anda berapa banyak pengguna yang ditangani server tunggal pada satu waktu, tetapi ini tidak akan berhasil.
Ini tidak akan berhasil karena tidak setiap pengunjung menyelesaikan transaksi. Orang-orang berubah pikiran, atau terganggu, atau pergi dan kembali lagi nanti. Karena server web hanya berinteraksi dengan pengunjung ketika browser mereka memuat halaman, server web tidak memiliki cara untuk mengetahui kapan hal ini terjadi, atau kepada siapa.
Sebaliknya, untuk menentukan bahwa pengunjung tidak lagi menjadi bagian dari proses transaksi, server tunggal harus menunggu untuk melihat apakah tidak ada lagi permintaan halaman yang datang dari pengunjung tersebut dan kemudian timeout sesi pengunjung tersebut. Timeout harus selalu diatur jauh lebih lama dari waktu transaksi rata-rata (katakanlah 20 menit dalam contoh ini) karena beberapa pengunjung membutuhkan waktu lebih lama daripada yang lain untuk menyelesaikan transaksi mereka.
Seseorang bisa menambahkan fasilitas untuk juga mengurangi Penghitung Pengguna Konkuren notional setiap kali sesi pengunjung habis dengan cara ini, tetapi ini memberikan hasil yang sangat buruk.
Jika 10% dari 100 pengunjung yang datang setiap menit tidak melanjutkan untuk menyelesaikan transaksi mereka, pengunjung yang menyelesaikan akan aktif selama rata-rata lima menit dan pengunjung yang tidak menyelesaikan akan dianggap aktif setidaknya selama 20 menit selalu (sebenarnya batas waktu sesi ditambah durasi sesi rata-rata lebih mungkin terjadi ketika mempertimbangkan beberapa sesi).
Itu 90 * 5 + 10 * 20 = 650, dan server akan melaporkan 650 pengguna bersamaan, meskipun sebenarnya tidak terlalu sibuk!
Lebih jauh lagi, sebanyak 10 * 20 = 200 dari pengguna bersamaan tersebut tidak benar-benar menggunakan situs dan sedang dalam proses waktu habis, yaitu lebih dari 30% dari pengguna bersamaan yang dilaporkan, meskipun hanya 10% dari pengunjung yang gagal menyelesaikan transaksi.
Sekarang katakanlah seseorang ingin menambahkan antrian ke situs web ini, yang dikendalikan oleh Penghitung Pengguna Bersamaan kami. Setelah situs berada pada kapasitas, maka seorang individu yang berada di depan antrian hanya akan dilewatkan ke situs setelah counter berkurang. Ini disebut antrian satu-keluar-satu-masuk. Apa yang akan terjadi adalah bahwa 30% dari waktu, seseorang yang berada di depan antrian akan menunggu seseorang yang tidak akan menyelesaikan transaksinya untuk menyelesaikan tidak menyelesaikan transaksinya.
Ada juga pekerjaan integrasi teknis tambahan dan beban pada situs web untuk membuat dan menjalankan penghitung, dan berbagi informasi itu dengan sistem antrean. Jika mekanisme pembagian atau penghitungan turun atau rusak, antrian akan macet. Bahkan lebih buruk lagi, jika server tunggal menjadi sangat sibuk sehingga tidak dapat memperbarui server antrian untuk memberitahu server antrian untuk membiarkan orang berikutnya masuk, antrian akan macet juga.
Semua masalah ini dengan mudah dan sederhana diselesaikan dengan mengirimkan pengunjung dari depan antrean dengan kecepatan tetap yang konstan - dalam hal ini 100 pengunjung per menit.
Dengan begitu tidak perlu mengukur jumlah aktual pengguna bersamaan, dan tidak perlu integrasi yang rumit dengan situs web tiket, dan tidak ada risiko antrian macet.
Itulah mengapa kami menciptakan dan mematenkan Ruang Tunggu Virtual berbasis tarif untuk situs web yang sibuk pada tahun 2004.
Produk Luar Biasa & Mudah! Queue-Fair benar-benar indah. Sangat mudah untuk mengatur parameter secara real-time, dan sangat mudah untuk diintegrasikan juga. Dukungannya reaktif dan ramah. Saya sudah siap dengan Ruang Tunggu Virtual dalam 15 menit termasuk pengaturan! Jadi saya melindungi infrastruktur saya dari semua puncak trafik ini dengan Queue-Fair.
Perangkat lunak Anda berarti bahwa semua orang ditahan dalam antrean jauh dari server kami dan memungkinkan aliran pembeli yang lembut untuk melewati sistem. Itu sangat bagus! Toko online mana pun yang memiliki pelanggan yang terburu-buru akan merasa ini sangat berguna. Terima kasih sejuta dan teruslah bekerja dengan baik!
Brilian! Kami sangat senang dan puas dengan Queue-Fair, sungguh luar biasa memiliki tingkat dukungan seperti ini. Layanan ini bekerja dengan sempurna - kami menjual ribuan tiket dalam waktu singkat, dan Queue-Fair membantu kami mengelola lalu lintas selama puncaknya! Kami merekomendasikan Queue-Fair kepada mitra layanan kami juga. Saya sangat senang!
Orang-orang di Queue-Fair bekerja keras untuk membantu kami mengimplementasikan sistem antrian mereka dalam satu hari. Dengan lebih dari 25.000 orang dalam antrian, mereka membantu kami mengelola lalu lintas selama puncak tertinggi kami. Queue-Fair melakukan apa yang seharusnya dilakukan; mengantri orang dengan harga yang kompetitif. Kami senang dengan sistem Queue-Fair dan akan terus menggunakannya selama acara-acara mendatang.
Queue-Fair adalah apa yang kami butuhkan untuk mengelola lalu lintas dan layanan dukungannya sangat bagus! Sistem ini telah bekerja dengan sangat baik! Kami mencari beberapa perusahaan dan tanpa ragu kami telah menemukan yang terbaik! Terima kasih banyak, Queue-Fair!
Terima kasih yang sebesar-besarnya karena telah mengubah pertanyaan kami dengan begitu cepat. Mengirim email pada jam 9 malam hari Rabu, menerima halaman Antrian bermerek lengkap yang siap digunakan pada jam 11 pagi hari Kamis. Cukup brilian! Dasbor dan fitur-fiturnya sangat bagus - sangat intuitif, sangat bersih dan mudah digunakan. Kami mengantri lebih dari 22.000 orang untuk acara peluncuran produk kami dengan biaya yang sangat kompetitif. Terima kasih banyak untuk semuanya! Saya sangat senang memberikan Queue-Fair testimonial yang luar biasa dan akan merekomendasikan mereka kepada bisnis apa pun yang membutuhkan sistem antrean untuk acara atau promosi mereka.
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
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.
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!
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.
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.
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.
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.
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?
Untuk mengetahui jumlah maksimum Pengguna Konkuren Anda dari jumlah total maksimum Permintaan Konkuren Anda, Anda juga perlu mengetahui
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:
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).
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
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.
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.
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 secara akurat durasi sesi rata-rata dan performa pengguna akhir saat trafik lambat atau puncak bukanlah hal yang mudah. 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 waktu tunggu yang sama di antara halaman saat pengujian beban seperti yang Anda lihat di kehidupan nyata, dan mengawasi beban prosesor, throughput IO, dan waktu respons saat Anda meningkatkan jumlah pengunjung virtual. Anda bisa 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 sulit untuk meniru perilaku setiap pengguna dengan cara yang tepat (terutama dengan kerumitan caching). Meskipun begitu, ambil angka maksimal Anda dan bagi dua.
Jika tidak ada hal itu, berhati-hatilah.
Anda dapat dengan mudah mengubah Tingkat Antrian untuk antrian Queue-Fair mana pun kapan saja menggunakan portal Queue-Fair. Mulailah dengan 10 pengunjung per menit, atau tingkat transaksi Anda pada hari yang lebih normal, lihat bagaimana hasilnya untuk 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 segalanya) halaman Anda responsif ketika Anda menekan CTRL-SHIFT-R, naikkan tidak lebih dari 20 persen, tunggu sebentar, dan ulangi. Anda akan segera menemukan tingkat aktual yang Anda butuhkan selama 'penyeimbangan beban' ini (lihat apa yang kita lakukan di sana?), dan ingat, dari sudut pandang pengalaman pelanggan, tidak masalah untuk menaikkan Tingkat Antrian karena hal ini menyebabkan estimasi waktu tunggu yang dilihat oleh pelanggan Anda dalam antrean berkurang, dan semua orang senang melihat waktu respons yang memberikan estimasi waktu tunggu yang lebih singkat.
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!
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.
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.
Bahkan sebelum itu, jika pengunjung membutuhkan waktu lebih dari satu detik untuk melihat halaman Anda, mereka akan menekan Refresh. Ketika pengunjung menekan refresh, server web Anda tidak mengetahui bahwa pengunjung tidak lagi menunggu respons terhadap permintaan awal. Jika permintaan asli dan permintaan refresh diterima, server web Anda akan memproses keduanya. Ini berarti lebih banyak pekerjaan yang harus dilakukan oleh server web Anda, respons yang lebih lambat untuk semua pengunjung, dan lebih banyak orang yang melakukan refresh, yang mengakibatkan lingkaran setan yang membuat server web Anda berhenti bahkan sebelum mulai mengirimkan respons kesalahan.
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.
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:
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?
Jadi, itulah cara menggunakan Queue-Fair untuk membuat penjualan Anda menjadi lebih baik dan aman, dan ingat, selalu lebih baik berjaga-jaga daripada menyesal.
2024 The Fair Queue People Ltd. - Semua Hak Cipta Dilindungi Undang-Undang.
Bagian dari keluarga solusi antrean Orderly - OrderlyQ - OrderlyStats - WeQ4U
