Maksimum eşzamanlı Socket.IO bağlantısı

124

Bu soru daha önce sorulmuştu ancak yakın zamanda sorulmuştu ve net bir cevabı yok.

Socket.io kullandığınızda, başka bir sunucu eklemeniz gerekmeden önce birinin sürdürülebileceği maksimum eşzamanlı bağlantı sayısı var mı?

Büyük ölçekte web soketleri (özellikle socket.io) kullanan herhangi bir aktif üretim ortamını bilen var mı? Maksimum bağlantı için ne tür bir kurulumun en iyisi olduğunu gerçekten bilmek isterim?

Web soketleri TCP üzerine kurulduğundan, anladığım kadarıyla bağlantı noktaları bağlantılar arasında paylaşılmadıkça, 64K bağlantı noktası sınırına bağlı kalacaksınız. Ancak Gretty kullanan 512K bağlantı raporlarını da gördüm . Yani bilmiyorum.

websocket  socket.io 
— Andrew
kaynak
3
Trello , büyük ölçekte soketler kullanır (özellikle socket.io).
— James
Trello'nun 10.000 bağlantı sınırı nedeniyle Socket.io kodunu değiştirmek zorunda kaldığını ve sunucu eklemeden önce 'binlerce' bağlantıyı sürdürebildiğini okudum. Yine de diğer sunucu sistemleri ile 512K arasında büyük bir uçurum var.
— Andrew
1
Bu makale kaç yaşında? Trello kısa süre önce ayda 1 milyondan fazla aktif kullanıcıya ulaştı, bu yüzden şu anda 10.000'den fazla aktif soket çalıştırdıklarını tahmin ediyorum. Trello , ölçeklenebilirlik için socket.io'nun üstüne oturmak için Redis'i kullanıyor
— James
2
Trello'nun şu anda görünüşte 4 milyondan fazla kullanıcısı var, ancak kesinlikle bunu çok sayıda sunucuda çalıştırıyorlar, değil mi? Bu beni asıl soruma geri getiriyor: sunucu başına gerçek en yüksek eşzamanlı kullanıcı sayısı (veya başkasının) nedir? Ne tür bir sunucu / konteyner kullandıklarını bilmek de iyi olacaktır. Ve hala kendi çatallarını mı kullanıyorlar yoksa başlangıç ​​/ ustaya geri mi döndüler? Bu soruyu sormaktaki tek amacım, şirketimin (o sırada) muhtemelen 120.000 eşzamanlı bağlantı için bir Socket.io uygulamasını sürdürebilir olup olmadığını ölçmeye çalışmaktı.
— Andrew
1
Liman limiti ile ilgili olarak, bunun neden sorun olmadığına dair açıklamanın burada açıklandığını düşünüyorum . Temel olarak, sisteminizde kullanılan tek bağlantı noktası dinlediğiniz bağlantı noktasıdır. Her bağlantı için soketler oluşturulur ve bunlar dosya tanımlayıcıları kullanır, ancak kutunuzdaki bağlantı noktalarını kullanmazlar.
— Paul Lynch

Yanıtlar:

78

Bu makale yol boyunca size yardımcı olabilir: http://drewww.github.io/socket.io-benchmarking/

Aynı soruyu merak ettim, bu yüzden bağlantıların ne zaman başarısız olmaya başladığını (veya geride kaldığını) görmek için küçük bir test (XHR yoklama kullanarak) yazdım. (Benim durumumda) soketlerin yaklaşık 1400-1800 eşzamanlı bağlantılarda çalışmaya başladığını buldum.

Bu, kullandığım teste benzer şekilde yaptığım kısa bir özet: https://gist.github.com/jmyrland/5535279

— REÇEL
kaynak
7
Bunun daha eski bir konu olduğunun farkındayım, ancak ilk önce cevabıma bir soru ararken buldum ve sonunda bunun yararlı olduğunu keşfettim: rtcamp.com/tutorials/linux/increase-open-files-limit İşlem başına açık dosya sınırı varsayılan olarak 1024 yumuşak sınıra ve 4096 sabit sınıra sahiptir ve her açık TCP bağlantı noktası bir dosyayı temsil ettiğinden, kitaplığı en üst düzeye çıkarmaya çalışmadan önce bir makinenin kaç açık sokete izin vereceğini belirlerken bu sınırların dikkate alınması önemlidir.
— DeeperID
2
@JAM Web soketlerinizin neden yaklaşık 1400-1800 bağlantıda çalıştığını keşfettiniz mi? Ben de aynı sorunu yaşıyorum ve dosya limitlerim 100.000 olarak ayarlandı, bu nedenle sorunun bu olmadığını biliyorum. Herhangi bir yardım çok takdir edilecektir. Teşekkür ederim.
— Seth
@seth: Bunu en son gözden geçirdiğimden bu yana biraz zaman geçti, ama bence sonuç buydu: XHR anketleri çok fazla kaynak kullandı (diğer taşıma yöntemleriyle ilişkili olarak). Web yuvalarını kullanırken eşzamanlı bağlantı sayısı daha yüksekti.
— JAM
@JAM cevap için teşekkür ederim. Soket.io'yu değil, ws modülünü kullanırken aynı sorunları görüyorum, bu nedenle ws modülüyle herhangi bir XHR yoklaması olmamalı. Sorun giderme sorunları yaşadığım yer burası. Arama devam ediyor.
— Seth
Bu iyi ve temiz bir cevaptır .. Durum bazında olduğu gibi de doğrudur .. Şahsen ben ppl'nin kendi ölçütlerini veya bağlantı simülatörünü yazmasını öneririm. Başkası için bir test iyi olabilirken, gerçek dünya ortamını temsil etmez ... Çeşitli gerçek dünya hatalarıyla herhangi bir sayıda müşteriyi idare edebilecek bir istemci simülatörüne sahip olduğunuzda .. Büyük değişikliklerden sonra ve ayrıca simülatörünüzü ilerledikçe güncelleyin. Bir kullanıcı sohbet arayüzünü kullanmak, kullanıcıların tarayıcısını izlemek için farklı olurdu. Python, bir simülatör komut dosyası oluşturmayı çok kullanışlı buldum ...
— Angry 84
16

Soket.io'yu AWS'de kullanmaya çalıştım, en fazla 600 bağlantıyı sabit tutabiliyorum.

Ve anladım, çünkü socket.io önce uzun yoklama kullandı ve daha sonra websocket'e yükseltildi.

Yapılandırmayı yalnızca websocket kullanacak şekilde ayarladıktan sonra, yaklaşık 9000 bağlantı tutabilirim.

Bu yapılandırmayı istemci tarafında ayarlayın:

const socket = require('socket.io-client')
const conn = socket(host, { upgrade: false, transports: ['websocket'] })
— Salem Chen
kaynak
2
EC2 kullandınız mı, ne tür bir örnek? t2.micro, t2.nano?
— bvdb
2
Web yuvalarını zorladığınızda yanıt verme hızında bir fark fark ettiniz mi?
— Lauren
Örneğinizin hangi boyutta olduğunu biliyor musunuz? Ayrıca, gelecekte bazı eski tarayıcıların WebSockets'i desteklemediğini bilmesi için, bu nedenle yükseltme, bazıları için önemli olabilir.
— Ryan Soderberg
Sunucunun ne kadar bağlantıyı desteklediğini nasıl test edebiliriz? 9000 bağlantıyı nasıl ölçtünüz? Lütfen önerin ..
— Meraklı Geliştirici
6

+ 300k eşzamanlı bağlantı için:

Bu değişkenleri şurada ayarlayın /etc/sysctl.conf:

fs.file-max = 10000000 
fs.nr_open = 10000000

Ayrıca, bu değişkenleri şurada değiştirin /etc/security/limits.conf:

* soft nofile 10000000
* hard nofile 10000000
root soft nofile 10000000
root hard nofile 10000000

Ve son olarak, TCP arabelleklerini de artırın /etc/sysctl.conf:

net.ipv4.tcp_mem = 786432 1697152 1945728
net.ipv4.tcp_rmem = 4096 4096 16777216
net.ipv4.tcp_wmem = 4096 4096 16777216

daha fazla bilgi için lütfen https://www.linangran.com/?p=547 bakın

— MajidJafari
kaynak
değişikliklerimizin işe yarayıp yaramadığını nasıl kontrol edebilirim?
— Meraklı Geliştirici
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.