Aslında bir dışarı, bir içeri yaklaşımının herhangi bir avantajını bulamadık. Özetle, bu yaklaşımla ilgili sorun, kullanıcılar e-ticaret web sitelerinin ziyaretçileri olduğunda, web sunucusunun herhangi bir zamanda kaç eşzamanlı kullanıcıya sahip olduğunu bilmemesidir. Bu bir engeldir. İşte nedeni.
Bu makalenin ilerleyen bölümlerinde, sitenizi korumak için oran tabanlı bir sanal odayı nasıl kullanacağınızı da anlatacağız.
Geleneksel olarak e-ticaret sunucuları maksimum sayıda eşzamanlı kullanıcıyı destekleyecek şekilde hazırlanır ve yük genellikle bu şekilde tanımlanır. Bu yaklaşımı bir web sitesi için bir kuyruk çalıştırmak için kullanmanın bir sorunu var - bu sorunu oranlarla çözüyoruz.
Sorun, ziyaretçilerin web sunucusunu yalnızca tarayıcıları her bir web sayfasını yüklerken kullanıyor olmalarından kaynaklanmaktadır.
Örneğin, bir e-ticaret sitesinin bilet sattığını varsayalım. Ziyaretçi yolculuğunun başlangıcından sonuna kadar (kullanıcı oturumu) ziyaretçi olarak altı sayfa vardır
Tüm işlem süreci ortalama beş dakika sürmektedir.
Diyelim ki, yine örnek olarak, her dakika 100 ziyaretçi bilet satın almak için geliyor ve işlemi tamamlamak için ortalama süre beş dakika. Herhangi bir anda, işlem sürecinde aynı anda 500 kişi vardır ve sunucu 500 eşzamanlı kullanıcıyı destekleyecek şekilde sağlanmalıdır.
Ana sayfaya her yeni ziyaretçi geldiğinde artırılan ve bir ziyaretçi işlemi her tamamladığında azaltılan bir Eşzamanlı Kullanıcı Sayacı oluşturulabileceği ve bunun size tek bir sunucunun herhangi bir zamanda kaç kullanıcıyla ilgilendiğini söyleyeceği düşünülebilir, ancak bu işe yaramayacaktır.
Her ziyaretçi işlemi tamamlamadığı için işe yaramayacaktır. İnsanlar fikirlerini değiştirir, dikkatleri dağılır ya da gider ve daha sonra geri gelirler. Web sunucusu ziyaretçilerle yalnızca tarayıcıları sayfaları yüklerken etkileşime girdiğinden, web sunucusunun bunun ne zaman gerçekleştiğini veya kime gerçekleştiğini bilmesinin bir yolu yoktur.
Bunun yerine, bir ziyaretçinin artık işlem sürecinin bir parçası olmadığını belirlemek için, tek sunucunun o ziyaretçiden başka sayfa isteği gelip gelmediğini görmek için beklemesi ve ardından ziyaretçinin oturumunu zaman aşımına uğratması gerekir. Bazı ziyaretçilerin işlemlerini tamamlaması diğerlerinden çok daha uzun sürdüğü için zaman aşımları her zaman ortalama işlem süresinden (bu örnekte 20 dakika) çok daha uzun olacak şekilde ayarlanmalıdır.
Bir ziyaretçi oturumu bu şekilde her zaman aşımına uğradığında, kişinin kavramsal Eşzamanlı Kullanıcı Sayacını azaltma olanağı da eklenebilir, ancak bu çok kötü sonuçlar verir.
Her dakika gelen 100 ziyaretçinin %10'u işlemlerini tamamlamazsa, tamamlayanlar ortalama beş dakika aktif olacak ve tamamlamayanlar her zaman en az 20 dakika aktif olarak kabul edilecektir (aslında oturum zaman aşımı artı ortalama oturum süresi, birden fazla oturum düşünüldüğünde daha olasıdır).
Bu 90 * 5 + 10 * 20 = 650 eder ve sunucu aslında daha az meşgul olmasına rağmen 650 eşzamanlı kullanıcı bildirecektir!
Dahası, bu eşzamanlı kullanıcıların 10 * 20 = 200 kadarı siteyi gerçekten kullanmıyor ve zaman aşımına uğrama sürecinde; bu da, işlemi tamamlayamayan ziyaretçilerin yalnızca %10'u olmasına rağmen, bildirilen eşzamanlı kullanıcıların %30 'undan fazlasına tekabül ediyor.
Şimdi diyelim ki bu web sitesine Eşzamanlı Kullanıcı Sayacımız tarafından kontrol edilen bir kuyruk eklemek istiyoruz. Site kapasitesine ulaştığında, kuyruğun önündeki bir kişi ancak sayaç azaldığında siteye geçebilecektir. Buna bir dışarı-bir içeri kuyruğu denir. Kuyruğun önündeki bir kişi, zamanın %30'unda işlemini tamamlamayacak olan birinin işlemini tamamlamamasını bekleyecektir.
Ayrıca, sayaç oluşturma, çalıştırma ve bu bilgileri kuyruk sistemiyle paylaşma gibi ek teknik entegrasyon çalışmaları ve web sitesi üzerindeki yük de söz konusudur. Paylaşım veya sayım mekanizması çökerse veya bozulursa, kuyruk takılıp kalır. Daha da kötüsü, tek sunucu çok meşgul olursa, kuyruk sunucusuna bir sonraki kişiyi içeri almasını söylemek için kuyruk sunucusunu güncelleyemezse, kuyruk da sıkışır.
Tüm bu sorunlar, ziyaretçileri kuyruğun önünden sabit, sabit bir oranda - bu durumda dakikada 100 ziyaretçi - göndermek yerine kolayca ve basitçe çözülür.
Bu şekilde eş zamanlı kullanıcıların gerçek sayısını ölçmeye gerek kalmaz, biletleme web sitesiyle karmaşık bir entegrasyona gerek kalmaz ve kuyruğun sıkışması riski ortadan kalkar.
Bu nedenle 2004 yılında yoğun web siteleri için fiyat bazlı Sanal Bekleme Odasını icat ettik ve patentini aldık.
‘Web sitemiz ve hizmetlerimiz, tekliflerimizin yoğun talebini karşılayamadı. Queue-Fair bizi kurtardı! Anlaşılması ve uygulanması kolay, süreç boyunca harika destek. Artık kampanyalarımızı güvenilir bir şekilde yürütebilir ve web sitemizin bununla başa çıkacağından emin olabiliriz.’
‘Queue-Fair'daki çalışanlar, kuyruk sistemlerini bir gün içinde uygulamamıza yardımcı olmak için yukarıda ve öteye gittiler. Kuyrukta 25.000'den fazla kişi varken, en yoğun anlarımızda trafiği yönetmemize yardımcı oldular. Queue-Fair yapması gerekeni yapıyor; insanları rekabetçi bir fiyatla sıraya sokuyor. Queue-Fair sisteminden memnunuz ve gelecekteki etkinliklerimizde de kullanmaya devam edeceğiz.’
‘Harika bir araç dükkanımızı kurtardı. Müşteri hizmetleri çok iyi. Queue-Fair, yoğun bilet satışlarında sunucu doygunluğunu bizim için çözdü. Kurulum kolaydı ve aracın verimliliğini beğendim.’
‘Harika ürün, kusursuz çalışıyor. Kolay kurulum ve entegrasyon, Mükemmel raporlama, Harika iletişim ve destek, Paranın karşılığı ve 5 yıldızlı deneyim. Bilet satışımızın sorunsuz geçtiğini söylemekten heyecan duyuyoruz! Queue-Fair'nun sanal bekleme odası çözümünün yardımıyla, tek bir aksaklık veya müşteri şikayeti olmadan ilk günden biletlerimiz tükendi. Queue-Fair harika ve Queue-Fair ekibinin tüm desteği için çok minnettarız - her şey mükemmeldi. Biz mutlu bir Queue-Fair müşterisiyiz!’
‘Queue-Fair bir Hayat Kurtarıcıdır! Onlarla çalışmaya başlamak hızlı ve basitti. Çok hızlı ve basit - 2 adım 1 gün! Büyük ön satış etkinlikleri sitemizi çökertiyordu, şimdi insanlar sanal bir sıraya giriyor - çok verimli. Queue-Fair'yu şüphesizbaşkalarına tavsiye ederim !’
‘Online mağazamızın açılış gününün stresini azalttık! Bu yıl siparişlere açıldığımız gün yepyeni bir web sitesi açtık. Lansman günü web sitemize büyük bir müşteri akını oldu ve Queue-Fair'nun yerinde olması bu deneyim boyunca kendimizi rahat hissetmemize yardımcı oldu. Müşterilerden kuyrukla ilgili sıfır e-posta aldık (bunu her şeyin yolunda gittiğinin bir işareti olarak görüyoruz). Kuyruğu web sitemize entegre etmek kolaydı. Queue-Fair ekibiyle olan deneyimimiz sorunsuz ve profesyoneldi ve hepsinden önemlisi müşterilerimiz harika bir deneyim yaşadı! Queue-Fair'ya sahip olmanın sağladığı gönül rahatlığını takdir ediyoruz.’
‘Yetkin ve şaşırtıcı profesyoneller tarafından desteklenen verimli sıralama için harika bir çözüm. Queue-Fair çok kullanıcı dostu ve entegrasyonu basit. Ekipleri bize her adımda yardımcı oldu. Queue-Fair sayesinde kullanıcılarımıza iyi görünümlü ve işleyen bir otomatik kuyruk sağlayabildik. Güzel bir yönetim panosu var. Queue-Fair'yu bulduğumuz ve iş ihtiyaçlarımız için onlara güvenebileceğimiz için mutluyuz. Bu hizmeti çok seviyoruz!’
‘Bu ürünü tavsiye ederim! Brezilya'da bir e-ticaretimiz var ve altyapımız talebi sağlamak için yeterli değil. Queue-Fair sorunlarımı çözdü! Bu ürünü kullandığım için mutluyum.’
‘İnanılmaz destek, her şey en başından beri çalışıyor. Queue-Fair, web sitemizdeki yüksek talebi azaltmamıza yardımcı oluyor ve çökmesini engelliyor. Kurulum ve çalıştırma adımları beklenenden çok daha kolaydı ve destek olağanüstü. Dokümantasyon çok açık ve net. Kuyruk çalışırken hiçbir sorun tespit edilmedi. Genel olarak, bizim için mükemmel bir çözüm. Her şey mükemmeldi.’
‘Olağanüstü müşteri hizmetleri ile desteklenen mükemmel ürün . Queue-Fair, web sitemiz üzerinden bilet talebindeki ani artışları yönetmek için mükemmel bir çözüm oldu. Queue-Fair web trafiğindeki ani artışları idare ediyor, sunucuların aşırı yüklenmesini önlemeye yardımcı oluyor ve müşterilerimizin adil bir şekilde sıraya alındıklarını kolayca görmelerini sağlıyor. Müşterilerimiz kuyruktaki ilerlemeyi gerçek zamanlı olarak izleyebiliyor. Queue-Fair'nun ürün ve hizmeti beklentilerimizi aştı.’
‘Sağlam, hayat kurtarıcı ve uygulaması kolay! Kullanmaya ne kadar hızlı başlayabileceğinizi ve çok kullanıcı dostu bir arayüzü seviyoruz. Belirli anlarda yüksek trafik yönetimi sorunumuzu çözen Queue-Fair'yu kullanmanın hiçbir dezavantajı yoktur, böylece hiçbir satışı kaçırmayız ve müşteri deneyimini olabildiğince iyi tutarız! Yüksek trafikle ilgili sorunlarımı çözmesini beklediğim her şey Queue-Fair'yu uygulamaya koyar koymaz çözüldü.’
‘Her şey mükemmel çalıştı! Ziyaretçi kaybetmemek için her trafik artışında bunu kullanacağım. Queue-Fair piyasadaki en ucuz çözüm. Kurulumu tam anlamıyla birkaç dakika. Harika destek ve gerçekten iyi tepkisellik. Sayfaları düzenlemek kolay. Kritik olayınızı halletmek için alabileceğiniz paranızın karşılığını en iyi şekilde veriyor, TV şovundan 10.000'den fazla ziyaretçi trafiğini kusursuz bir şekilde halledebildim.’
Bir web sunucusunun kaç eş zamanlı kullanıcıyı işlediğini ve işlem akışınızdaki ilk sayfadan sipariş onay sayfasına kadar ortalama işlem süresini veya ziyaret süresini biliyorsanız, bunu Little Yasasını kullanarak kullanıcı sayısını süreye bölerek bir Kuyruk Oranına dönüştürebilirsiniz:
Kuyruk oranı = Eşzamanlı kullanıcılar / İşlem süresi
Queue-Fair web sitenize sizin belirlediğiniz hızda ziyaretçi gönderir - her dakika istediğiniz ziyaretçi sayısının her dakika aldığınız ziyaretçi sayısı olmasını sağlamak için sektördeki en doğru Sıra Yapay Zekasına sahibiz, sırası geldiğinde orada bulunmayanların yanı sıra geç gelenleri de otomatik olarak hesaba katıyoruz.
Bu, Eşzamanlı Kullanıcı sayısına nasıl dönüşür? Elbette, sitenize ulaşan her ziyaretçinin işlemini tamamlaması tam olarak ortalama işlem süresini almayacaktır, ancak Büyük Sayılar Yasası nedeniyle Queue-Fair ile çok sabit sayıda Eşzamanlı Kullanıcı elde edeceksiniz.
Örneğin, dakikada 100 ziyaretçiden oluşan bir Kuyruk Hızınız olduğunu varsayalım. Sitenize her dakika düzenli bir akışla 100 ziyaretçi göndereceğiz - yaptığımız iş bu ve bu konuda şaşırtıcı derecede iyiyiz. Ayrıca insanların web sitenizi ortalama (ortalama) beş dakika kullandığını ve bunların %70'inin kuyruktan geçtikleri andan son sayfa talebini yaptıkları ana kadar (bir işlemi tamamlasınlar ya da tamamlamasınlar) 4 ila 6 dakika sürdüğünü varsayalım. Bu da ortalamanın her iki tarafında bir dakikalık Standart Sapma anlamına gelir. İstatistiksel olarak konuşmak gerekirse bu, beş buçuk dakika süren her ziyaretçi için dört buçuk dakika süren başka bir ziyaretçi olacağı anlamına gelir ve bu nedenle birden fazla oturumda bireysel ziyaret sürelerindeki bu varyasyonlar, herhangi bir şekilde çok sayıda ziyaretçi saydığınızda birbirini iptal etme eğilimindedir. Büyük Sayılar Yasası, bu iptalin ilgili kişi sayısı arttıkça daha da kesinleşeceğini söyler.
Tam olarak ne kadar kesin? Bunu küçük bir istatistikle çözebiliriz. Burada söz konusu olan Büyük Sayı olan 5 * 100 = 500'lük bir örneklem büyüklüğü vardır. Saydığınız kişi sayısı bu kadar. Bu, Ortalamadaki Standart Hata için istatistiksel formüle göre işlem süresi için Ortalamadaki Standart Hatanın 1 (standart sapma, 1 dakika) ile örneklem büyüklüğünün kareköküne (yani 500'ün kareköküne) bölünmesi anlamına gelir; bu da işlem süresi için 0,044 dakika veya sadece 2,7 saniye, yani yüzde birden daha az bir Ortalamada Standart Hata verir.
Bu, 100'lük bir Kuyruk Oranı ve her bir ziyaretçi için aşağı yukarı 5 dakikalık bir işlem süresiyle, sitenizde zamanın yaklaşık %70'inde 495 ila 505 arasında eşzamanlı kullanıcı beklemeniz gerektiği anlamına gelir, bu nedenle matematik, orana dayalı bir kuyruk kullanmanın web sunucularınızda istenen şekilde çok istikrarlı bir yük sağlayacağını söyler.
Ama matematik doğru mu? Burada bazı incelikler var - örneğin, neşeyle karesini aldığımız örneklem büyüklüğü, Eşzamanlı Kullanıcılar her sayıldığında (yani zamanın herhangi bir anında) her zaman tam olarak 500 değildir ve ayrıca normal (Gauss) bir dağılım, gerçek hayatta meydana gelmeyen negatif işlem süreleri verebilir. Bu nedenle, bu tür hesaplamaları kontrol etmek üzere ölçümler yapmak için ziyaretçi bazında, saniye bazında bir simülatör kullanıyoruz ve bu bize yukarıdaki rakamlarla, zamanın %70'inde 493 ila 507 ziyaretçi beklemeniz gerektiğini söylüyor, yani matematik oldukça iyi durumda! Verilerin ölçülmesi de bize sitenizin zamanın en az %95 'inde 500 ± 15 Eşzamanlı Kullanıcıya sahip olacağını söylüyor.
Bu muhtemelen web sunucunuzun sitenizi kullanan kişi sayısını ölçebildiği doğruluktan daha sabittir! Daha da iyisi, burada gerçekten güzel olan şey, ziyaretçileriniz için ortalama işlem süresinin veya standart sapmanın ne olduğu hakkında hiçbir fikriniz olmasa bile, bu matematiksel büyüklükler siz bilseniz de bilmeseniz de mevcuttur ve yine de istikrarlı bir yük elde edersiniz.
Sonuç olarak Queue-Fair, istediğiniz dakika başına ziyaretçi sayısını neredeyse mükemmel bir doğrulukla sunarak sitenizde çok sabit sayıda eşzamanlı kullanıcı ve üzerinde tam kontrole sahip olduğunuz istikrarlı bir web sunucusu yükü sağlar.
Yaşasın!
Ve şimdi bir uyarı. Sitenizdeki eşzamanlı kullanıcı sayısının istikrarının - ve dolayısıyla sunucu yükünüzün istikrarının - Sanal Bekleme Odası sağlayıcınızın her dakika istediğiniz ziyaretçi sayısını size ne kadar doğru gönderdiğine kritik bir şekilde bağlı olduğunu ve bu nedenle bir Sanal Bekleme Odası platformu seçtiğinizde bunun önemli bir faktör olduğunu belirtmek gerekir. Dünyadaki en doğru Sanal Bekleme Odasını sağladığımız için, hiç kimse sunucularınızın taşmasını Queue-Fair'dan daha iyi durduramaz.
Bir sunucunun kaç Eşzamanlı Kullanıcıyı veya İşlem Süresini kaldırabileceğini bilmiyorsanız ne olur? Darboğazınız olması muhtemel olan sayfaya bakabilirsiniz - genellikle bir "Şimdi Satın Al" düğmesine tıklamanın sonucu olan sayfaya. Bu sayfaya gelen aylık tekil ziyaretçileri bulmak için Google Analytics'i kullanın ya da aylık siparişlerinizi sayın. Bunu 30 * 24 * 60 = 43.200'e bölün, bu da bir aydaki dakika sayısıdır (yaklaşık olarak). Bu, tüm ay boyunca dakika başına düşen ortalama ziyaretçi sayınızdır. Bunu üç ile çarpın. Bu, mesai saatleri içinde dakika başına düşen ortalama ziyaretçi sayınızdır (yaklaşık olarak). Bunu ikiye katlayın. Bu muhtemelen Kuyruk Oranı için kullanılacak güvenli bir rakamdır.
Örneğin, ayda 100.000 sipariş işlediğinizi varsayalım - bu, "Şimdi Satın Al" düğmesine 100.000 tıklama anlamına gelir. Bu da dakikada 100.000 / 43.200 = 2,31 sipariş eder. Bu siparişlerin çoğunun gün içinde olmasını ve sunucularınızın geceleri daha sessiz olmasını beklersiniz, bu nedenle bunu 3 ile çarpın ve sunucunuzun iş saatlerinde ne kadar meşgul olduğuna dair kabaca bir tahmin olarak dakikada 7 sipariş elde edin. Ortaya çıkan rakam 50'den azsa: talepte iniş ve çıkışlar olacaktır, bu nedenle sunucunuz yoğun saatlerde fark edilir derecede yavaş değilse, bunu 2 ile çarparak dakikada 14 aktif kullanıcı elde edin. Rakam 50'den fazlaysa: dakikadan dakikaya iniş ve çıkışlar karşılaştırıldığında daha küçük olacaktır ve bunu iki katına çıkarmak güvenli değildir. Elde ettiğiniz rakam muhtemelen Kuyruk Oranı için başlangıçta güvenli bir rakamdır ve saniyede kaç isteği güvenle yönetebileceğinize karşılık gelir; sistemlerinizin bu oranda son kullanıcı performansı için hala duyarlı olduğunu fark ederseniz her zaman artırabilirsiniz.
Siparişleriniz zaman damgalı ise, geçen ay tek bir dakika içinde aldığınız maksimum siparişlere de bakabilirsiniz - ancak sunucularınızın yavaşlaması nedeniyle bu dakika içinde kaç sipariş düşürmüş olabileceğinizi bilemeyeceğiniz için dikkatli kullanın, bu nedenle bunu% 20 azaltın.
Bu makalenin geri kalanında Kuyruk Oranını hesaplamanın diğer bazı yolları tartışılmaktadır.
Yaygın kullanımda en az iki "Eşzamanlı Kullanıcı" tanımı olduğunu belirtmekte fayda var.
' Herhangi bir zamanda bir işlem akışına katılan kişi sayısı ' tanımını kullanıyoruz. Kuyruk Oranını ayarlamak için bilmeniz gereken anahtar sayı budur. Bu, şu anda sitenizi kaç kullanıcının görüntülediğini gösterir. Eşzamanlı Oturumların sayısı genellikle eşzamanlı bağlantıların veya eşzamanlı kullanıcıların sayısından biraz daha fazladır, çünkü oturumların bazıları zaman aşımına uğrayarak ortalama oturum süresini artırmaktadır.
Bunu, web sunucunuz tarafından herhangi bir zamanda işlenen HTTP isteklerinin sayısı olan Eşzamanlı İstek sayısı ile karşılaştırın. Çok kafa karıştırıcı bir şekilde, pek çok teknoloji insanı kaç Eşzamanlı Kullanıcı derken kaç Eşzamanlı İsteği kasteder.
Bir de Eşzamanlı Bağlantılar (ya da ağ arayüz kartınızdaki aynı sunucu portuna yapılan eşzamanlı TCP bağlantıları) vardır, bu da sunucu port unuzda ya da arka uç hizmetinizde herhangi bir anda açık olan TCP/IP Soketlerinin sayısıdır. Sayfa istekleri yapılırken, tarayıcılar varsayılan olarak sayfa tarafından başka isteklerin yapılması veya kullanıcının farklı bir sayfaya gitmesi durumunda bağlantıyı açık bırakacaktır. Bu, yeni TCP/IP bağlantıları açmak için saniye başına yapılan istek sayısını azaltarak sunucu sürecini daha verimli hale getirir. Bu eşzamanlı bağlantılar için zaman aşımları tarayıcıya göre 60 saniye ile hiç kapanmama arasında değişir. Sunucunuz da belirli bir süre faaliyet göstermediğinde bağlantıları otomatik olarak kapatabilir. Linux web sunucularında, bu komutla aynı sunucu portuna yapılan Eşzamanlı Bağlantıların sayısını alabilirsiniz: netstat -aenp | grep ":80 \|:443 " | wc -l
Eğer merak ediyorsanız deneyebilirsiniz. Yine, bazı insanlar bunu "Eşzamanlı Kullanıcılar" olarak da adlandırıyor, oysa gerçekte eşzamanlı bağlantılar anlamına geliyor.
Aslında, barındırma sağlayıcınızdan web sunucunuzun işlediği maksimum Eşzamanlı Kullanıcı sayısını (ne kadar yoğun trafik) söylemesini isterseniz, size muhtemelen Eşzamanlı Oturumlar, Eşzamanlı İstekler veya Eşzamanlı Bağlantılar için bir rakam vereceklerdir, çünkü ortalama işlem sürenizi, işlem akışınızdaki sayfa sayısını veya web sunucunuzun kaç eşzamanlı kullanıcıyı işlediğini size söylemelerine izin verecek diğer bilgilerin hiçbirini bilmiyorlar. Tüm bu sayılar farklı değerlere sahiptir.
Barındırma sağlayıcınızdan veya teknik ekibinizden maksimum trafik seviyeleri hakkında bilgi istiyorsanız, Eşzamanlı Kullanıcılar mı, Eşzamanlı Oturumlar mı, Eşzamanlı İstekler mi yoksa Eşzamanlı Bağlantılar mı demek istediklerini netleştirmeniz çok önemlidir.
İşte nedeni. Her sayfa tek bir HTTP isteğidir, ancak web uygulamanızdan gelen ve tarayıcının sayfayı görüntülemek için kullandığı tüm resimler, komut dosyaları ve diğer dosyalar da HTTP isteğidir.
Teknik ekibinizin size sunucunun 500 Eşzamanlı Kullanıcıyı desteklediğini söylediğini, ancak aslında 500 Eşzamanlı İsteği kastettiklerini düşünelim. 5 dakikalık işlem sürenizle yukarıdaki formülü kullanır ve sitenizin dakikada 100 ziyaretçiyi destekleyebileceğini varsayarsınız.
Olabilir mi? Hayır.
İnsanlar işlem akışından geçerken, aslında yalnızca her sayfa yüklenirken sunucularınızdan istekte bulunurlar. Bu, sunucunuzun saniye başına ne kadar trafik veya aktif kullanıcı kaldırabileceğini etkiler. Beş dakikalık işlem süresi, ortalama bir kullanıcı için yalnızca birkaç saniyedir. Bu nedenle 500 Eşzamanlı İsteğin çok daha fazla Eşzamanlı Kullanıcıyı idare edebileceğiniz anlamına geldiğini düşünebilirsiniz, ancak yanılıyor olabilirsiniz. Şimdi web sitenizin kapasitesini ne kadar trafik veya toplam aktif kullanıcı sayısı açısından anlamanın ne kadar karmaşık bir iş olduğunu görebiliyor musunuz?
Maksimum Eşzamanlı Kullanıcı sayınızı maksimum toplam Eşzamanlı İstek sayınızdan hesaplamak için şunları da bilmeniz gerekir
Muhtemelen 1) ve 2)'yi zaten biliyorsunuzdur - bizim örneğimizde 6 sayfa ve 5 dakika. Bir işlem yaparken gördüğünüz sayfaları kolayca sayabilirsiniz. Ortalama işlem süresini bilmiyorsanız, Google Analytics size söyleyebilir veya web sunucusu günlüklerinizi kontrol edebilirsiniz.
3) ve 4) için Firefox tarayıcısı yardımcı olabilir. Sitenizdeki bir sayfaya sağ tıklayın, Öğeyi İncele'yi ve Ağ sekmesini seçin. Ardından sayfayı tamamen yenilemek için CTRL-SHIFT-R tuşlarına basın. Listede sayfanın her öğesi için ağ yükleme sürelerini göreceksiniz. Aktarılan sütununda aktarım boyutlarını görebildiğinizden emin olmak istersiniz, aksi takdirde dosyalar bir önbellekten sunulabilir ve bu da hesaplamalarınızı bozabilir. Bazı komut dosyalarının ve diğer kaynakların siteniz dışındaki sunuculardan geldiğini görebilirsiniz, bu nedenle soldaki filtre kutusuna sitenizin alan adını yazabilirsiniz. Süre sütununu görmek için herhangi bir sütun başlığına sağ tıklayın ve açılır menüden Zamanlamalar -> Süre öğesini seçin. Ekranınız aşağıdaki gibi görünmelidir:
Bu sayfa için queue-fair.com'dan gelen İsteklerin Süresini ve sayısını gösteren Firefox Ağ sekmesi
Sayfalarınızın görüntülenmesinde kullanılan dosyalar bir dizi farklı siteden gelebilir, bu nedenle sol üstteki filtreyi yalnızca sitenizdekileri göstermek için de kullanmak istersiniz - ancak yalnızca diğer sitelerdeki dosyaların yavaş sayfa yüklemelerinin nedeni veya darboğazınızın bir parçası olmadığından eminseniz .
Firefox ekranın sol alt kısmında sizin için istekleri sayar ve sadece bu sayfaiçin 36 HTTP isteği gösterir.
Bunu işlem akışınızdaki her sayfa için yapmanız gerekir - toplamı sayın ve her sayfa için ortalama HTTP isteği sayısını bulmak için sayfa sayısına bölün, listemizde 3 numara). Artık her HTML sayfası için alt istek sayısının web sunucunuzun ne kadar trafiği kaldırabileceği konusunda neden bu kadar önemli bir faktör olduğunu görebilirsiniz.
4) için Süre sütununa bakmanız ve tüm sayfalarınız için tüm HTTP isteklerinin ortalamasını bulmanız gerekir. Emin değilseniz, yarım saniye varsayabilirsiniz - zaten bu konuda çok fazla belirsizlik vardır (aşağıya bakın).
Bazı örnek sayılar verelim. Örnek sunucu işlem akışında altı dinamik sayfa olduğunu, yani 1) ve ortalama işlem süresinin beş dakika olduğunu, yani 2) söylemiştik. 3) için sayfa başına 36 HTTP isteği ve 4) için her bir HTTP isteği için sunucu işlem süresinin yarım saniye olduğunu varsayalım.
Bu rakamlarla, 500 Eşzamanlı İsteği karşılayabilen bir sunucu saniyede 500 / (0,5 saniye) = 1000 HTTP isteğini karşılayabilir, bu da tamamen maksimuma ulaştığında dakikada 60.000 HTTP isteği anlamına gelir.
Beş dakikalık işlem süresi boyunca, 5 * 60.000 = 300.000 HTTP isteğini karşılayabilir. Çok fazla gibi görünüyor, değil mi?
Ancak, her ziyaretçi için, her biri ortalama 36 HTTP isteğine sahip altı sayfa vardır, bu da 6 * 36 = 216 istek anlamına gelir
Dolayısıyla, 300.000 HTTP isteği kapasitesi teorik olarak 300.000 / 216 = 1.389 Eşzamanlı Kullanıcıyı idare edebilir
Hey, bu harika! Sadece 100 kuyruk oranına sahip olabileceğimizi düşünüyorduk, ancak 1.389 / 5 dakika = dakikada 278 ziyaretçi, yani daha yüksek bir kuyruk oranına sahip olabiliriz!
Muhtemelen hayır. Birincisi, ziyaretçileriniz yukarıdaki hesaplamanın varsaydığı gibi tam olarak yarım saniyelik aralıklarla düzgün bir şekilde istek göndermeyecektir. Daha da önemlisi, girdi verilerinizi site meşgul değilken ölçüyor olacaksınız. Çöp girer, çöp çıkar.
Site meşgul olduğunda, sunucunun istekleri işlemesi daha uzun sürer - işler yoğun olduğunda sayfalar için daha uzun süre beklediğinizi diğer sitelerde fark etmişsinizdir. Bu, sunucunuzun tek bir HTTP isteğini işlemek için harcadığı ortalama süreyi artırır (4), bu da maksimum verimi düşürür. Yani dakikada 278 ziyaretçi sayısını alın ve yarıya indirin. Sonra tekrar yarıya indirin. Maksimum yükte muhtemelen gerçekçi olarak dakikada yaklaşık 70 yeni ziyaretçiye bakıyorsunuzdur.
Diğer karıştırıcı faktörler arasında, ziyaretçilerinizin tarayıcılarının her bir sayfa için her bir isteği yapması gerekmeyebileceği anlamına gelen önbellekleme yer alır - bu, sunucunun daha az kaynağa ihtiyaç duyduğu anlamına gelir ve sunucunuzun işleyebileceği dakika başına yeni ziyaretçi sayısını artırabilir. Yükü birkaç sunucuya dağıtan yük dengeleyiciler ve dinamik sayfalar yerine statik içerik sunmak da her sunucu daha az kaynak gerektirdiğinden sunucu sürecinizi hızlandırabilir.
Ayrıca, bazılarının üretilmesi ve sunulması için diğerlerinden daha az kaynak gerektiğinden, tüm sayfaların tamamlanmasının aynı zaman almadığını göreceksiniz. Veritabanı aramaları, arama sorguları ve güncellemeler en uzun süreyi alır, bu nedenle sürecinizin bir yerinde insanların yığıldığı, kredi kartı bilgilerinin işlenmesini ve siparişlerin saklanmasını beklediği veya müsaitlik durumunun kontrol edilmesini beklediği bir darboğazınız olacaktır. Her işlem akışının en yavaş adımı vardır, bu nedenle her zaman bir yerlerde bir darboğaz vardır ve bir web sunucusunun kaç eşzamanlı kullanıcıyı idare edebileceği sorusunun her zaman bir maksimum değer yanıtı vardır - ve birden fazla sınır söz konusu olabilir. Bu durumda, Kuyruk Hızınızı, sunucunuzun işleminizdeki en yavaş adım için yeterli sayıda insanı eşzamanlı olarak işleyebilecek işlemci zamanı kapasitesine sahip olmasını sağlayacak kadar düşük ayarlamak istersiniz, böylece insanlar orada yığılmaz. Aksi takdirde web sunucunuz tam anlamıyla durma noktasına gelebilir.
Deneyimlerimiz, ilk satışlarına girerken herkesin sunucularının yüksek trafik hacimleriyle başa çıkma yeteneğini abarttığı yönündedir.
Herkesi.
Yavaş veya yoğun trafik sırasında ortalama oturum süresini ve son kullanıcı performansını doğru bir şekilde belirlemek kolay değildir. Yapılacak en iyi şey, gerçek hayatta olduğu gibi yük testi yaparken 'sahte' müşterilerin sipariş sürecinden geçtiği, aynı sırayla aynı HTTP isteklerini yaptığı, yük testi sırasında sayfalar arasında gerçek hayatta gördüğünüz gibi aynı bekleme sürelerinin olduğu uygun bir yük testi yapmak ve sanal ziyaretçi sayısını artırdıkça işlemci yükünüzü, IO veriminizi ve yanıt sürelerinizi takip etmektir. Bunun için Apache JMeter 'ı kullanabilirsiniz (daha hafif yükler veya daha yavaş makineler için K6 'yı da seviyoruz), ancak hangi aracı kullanırsanız kullanın, her bir kullanıcının davranışını tam olarak doğru şekilde taklit etmek zaman alıcı ve zordur (özellikle önbelleğe alma karmaşıklığı ile). O zaman bile, maksimum sayınızı alın ve yarıya indirin.
Bunun olmadığı durumlarda, ihtiyatlı davranın.
Queue-Fair portalını kullanarak herhangi bir Queue-Fair kuyruğu için Kuyruk Oranını istediğiniz zaman kolayca değiştirebilirsiniz. Dakikada 10 ziyaretçiyle veya daha normal bir gündeki işlem oranınızla başlayın, biletleriniz satışa çıktıktan sonra bir süre nasıl gittiğine bakın ve her şey iyi görünüyorsa, işlemci yükünüz düşükse, sql veritabanınız iyiyse ve (hepsinden önemlisi) CTRL-SHIFT-R'ye bastığınızda sayfalarınız yanıt veriyorsa, yüzde 20'den fazla artırmayın, biraz bekleyin ve tekrarlayın. Bu 'yük dengeleme' sırasında ihtiyacınız olan gerçek oranı kısa sürede bulacaksınız (ne yaptığımızı gördünüz mü?) ve unutmayın, müşteri deneyimi açısından Kuyruk Oranını yükseltmek iyidir çünkü bu, kuyruktaki müşterilerinizin gördüğü tahmini beklemelerin azalmasına neden olur ve herkes daha kısa bir tahmini bekleme sağlayan bir yanıt süresi görmekten mutlu olur.
Yapmaktan kaçınmak istediğiniz şey, Kuyruk Oranını çok yüksek ayarlamak ve daha sonra düşürmek zorunda kalmaktır, çünkü bu a) siteyi kullanan kişilerin yavaş sayfa yüklemeleriyle karşılaşması anlamına gelir ve b) tahmini bekleme sürelerinin artmasına neden olur. Kuyruğunuzdaki tüm insanlar iç çekecektir!
Unutmayın, sipariş sürecinizin bir yerinde bir darboğaz olacaktır - her işlemin en yavaş bir adımı vardır - ve orada yığılan birden fazla oturum alacaksınız. Yapmak istemeyeceğiniz şey, bilet satışınıza bir dakika kala sunucu işlemci yükünüzün maksimum sayının çok altında olduğunu görmek ve oranı yükseltmektir. Ziyaretçileriniz muhtemelen "Şimdi Satın Al" düğmesine kadar gelmemiştir. Sql veritabanınız yeni siparişleri Kuyruk Oranınızla aynı veya benzer oranda rapor edene kadar beklemek ve ölçümlerinizi ve yanıt verebilirlik testlerinizi o zaman yapmak istersiniz. Oranı her artırdığınızda, ekstra ziyaretçilerin darboğazınıza ulaşmasının da aynı süreyi alacağını unutmayın; bu nedenle, bu süre geçene kadar sunucunuzun yeni oranda nasıl performans gösterdiğini doğru bir şekilde değerlendiremezsiniz .
Kuyruğunuz açıldıktan sonra Kuyruk Oranını kademeli olarak artırmanın en iyisi olduğunu zaten tartışmıştık. Muhtemelen sunucularınızın sistem çökmeden aşılamayacak bir sınırı olduğunun farkındasınızdır ve hatta bu sınırın ne olduğunu biliyor olabilirsiniz - ancak bilmediğiniz şey, yük bu sınıra yaklaşırken genellikle çok az işaret olduğudur - genellikle sadece birkaç hata veya uyarı veya %80'in üzerinde bir işlemci yükü.
Web hizmetleri başarısız olduğunda, çok hızlı bir şekilde 'kopma' veya ele geçirme eğilimindedirler. Bunun normal nedeni, sisteminiz artık istekleri geldikleri kadar hızlı işleyemediğinde, dahili işlem kuyruklarının oluşmasıdır. Sisteminiz daha sonra isteklerin yanı sıra kendi iç kuyruklarını işleme, yönetme ve depolama işini de yapmak zorunda kalır ve bu da sunucuları uçurumun kenarına getirir. Hem de çok çabuk. Bu gerçekleştiğinde, sunucularınız bir süreliğine bir hata sayfası ile yanıt verebilir, ancak bu size yardımcı olmaz, çünkü bunu gören ziyaretçiler hemen Yenile'ye basarak yükü artıracaktır.
Bundan önce bile, ziyaretçilerin sayfalarınızı görmesi yaklaşık bir saniyeden fazla sürüyorsa, Yenile düğmesine basarlar. Bir ziyaretçi yenileme tuşuna bastığında, web sunucunuz ziyaretçinin artık orijinal isteğin yanıtını beklemediğini bilmez. Hem orijinal hem de yenileme isteği alınırsa, web sunucunuz her ikisini de işleyecektir. Bu da web sunucunuz için daha fazla iş, tüm ziyaretçileriniz için daha da yavaş yanıtlar ve daha fazla kişinin yenilemeye basması anlamına gelir, bu da web sunucunuzu daha hata yanıtları göndermeye başlamadan durduran bir kısır döngüye neden olur.
Bu yüzden sunucularınızı gerekenden daha fazla zorlamayın. İşlemci zaman kapasitesinin son %20'sine ulaşmak genellikle riske girmeye değmez. Queue-Fair Portalında gösterilen kuyruk boyutu (grafiklerdeki sarı Bekleme rakamı ve çizgisi) her geçen dakika azalıyor veya daha yavaş artıyorsa ve gösterilen bekleme süresi 50 dakika veya daha azsa, siparişleri yeterince hızlı işliyorsunuz demektir ve kuyruk sonunda boşalacak ve sizin hiçbir şey yapmanıza gerek kalmadan ve patronunuza onu çok zorladığınızı ve bozduğunuzu söylemenize gerek kalmadan otomatik olarak Kuyruk Sayfalarını göstermeyi durduracaktır. Kuyruğun Önündeki hız, her dakikadaki Katılım sayısından daha yüksek olduğu sürece (her ikisi de Queue-Fair Portalında gösterilir) eninde sonunda oraya ulaşacaksınız - dönüm noktası genellikle her etkinliğin en az birkaç dakikasıdır. Sınırlı miktarda bir ürün satıyorsanız, dönüm noktasına ulaşılmadan önce muhtemelen satışınız tükenecektir.
İyi haber şu ki, Kuyruk Oranını yanlışlıkla çok yüksek ayarlarsanız ve sunucularınız kilitlenirse, Queue-Fair hızlı bir şekilde çalışmaya devam etmenize yardımcı olabilir - sunucularınız ziyaretçileri tekrar idare etmeye hazır olana kadar kuyruğu Beklemeye alın. Bekletme modunda, kuyruktaki kişiler çevrimiçi etkinliğinizden önce tasarlayabileceğiniz özel bir Bekletme sayfası görürler. Bekleme modundayken kuyruğun önünden kimsenin geçmesine izin verilmez, ancak yeni internet ziyaretçileri yine de arka taraftaki kuyruğa katılabilir, tıkanıklık giderildikten sonra adil bir şekilde sıraya alınabilirler, bu da çok hızlı bir şekilde gerçekleşecektir çünkü Queue-Fair sitenizi talepten korur. Bekletme Sayfası, Kuyruk Oranını gerçekten düşük ayarlamaktan daha üstün bir kullanıcı deneyimidir, özellikle de ziyaretçilere Kuyruğun ne zaman yeniden açılmasını beklediğinizi söyleyecek şekilde güncellerseniz, ki bunu Portal sayfa editörü ile yapmak kolaydır, yüz binlerce kişi zaten kuyrukta olsa bile - ve Bekletme modunda, sisteminiz aniden toparlanırken gerekirse Queue-Fair'nun benzersiz Birini Kabul Et düğmesiyle her seferinde bir tane geçmelerine bile izin verebilirsiniz.
Dolayısıyla, etkinliğiniz sırasında sunucularınızın ara vermesi gerektiğini fark ederseniz, Bekletme sayfası tam da bunun için ihtiyacınız olan şeydir ve sunucularınızın daha hızlı bir şekilde toparlanmasına yardımcı olacaktır.
Bu makalede oran bazlı kuyruğun neden her zaman ileriye dönük bir yol olduğunu açıkladık ve ihtiyacınız olan oranı hesaplamak için iki yöntem verdik, ancak tüm işlem akışınız üzerinde tam ve doğru sanal ziyaretçi yük testi yapmadığınız ve bundan gerçekten süper ekstra mega emin olmadığınız sürece, tavsiyemiz her zaman aynıdır:
Sınırlı miktarda ürün satıyorsanız, 7. Adıma da dikkat etmenize gerek yoktur.
Bu, sisteminizin destekleyebileceği gerçek maksimum Kuyruk Hızını bilmediğiniz ilk kuyruğunuz içindir. Sonraki kuyruklar için, sisteminizin gerçekten kaldırabileceği Kuyruk Hızını ölçtükten sonra, aynı rakamı tekrar kullanabilirsiniz - ancak yalnızca sisteminizde hiçbir şey değişmediyse. Pratikte sisteminiz muhtemelen sürekli geliştirilmekte ve değiştirilmektedir ve son değişikliklerin maksimum Kuyruk Hızınızı nasıl etkilediğini bilmiyor olabilirsiniz - öyleyse neden daha önce ölçtüğünüz rakamın yarısından başlayıp yukarıdaki işlemi tekrarlamıyorsunuz?
İşte Queue-Fair'yu satışınızı güzel ve güvenli hale getirmek için nasıl kullanacağınız ve unutmayın, güvende olmak her zaman üzgün olmaktan daha iyidir.
2004'te icat edilen ve patenti alınan Queue-Fair, yoğun web siteleri ve uygulamalar için çevrimiçi sıra yönetimi sağlayan orijinal Sanal Bekleme Odasıdır.
2024 The Fair Queue People Ltd. - Tüm hakları saklıdır.
Orderly kuyruk çözümleri ailesinin bir parçası - OrderlyQ - OrderlyStats - WeQ4U
