Максимально сумісні з'єднання Socket.IO


123

Це питання було задано раніше, але не останнім часом і не має чіткої відповіді.

Використовуючи Socket.io, чи існує максимальна кількість одночасних з'єднань, які можна підтримувати, перш ніж потрібно додати інший сервер?

Хтось знає про будь-які активні виробничі середовища, які широко використовують веб-розетки (зокрема, socket.io)? Мені дуже хотілося б дізнатися, яка установка найкраща для максимального з'єднання?

Оскільки веб-розетки побудовані поверх TCP, я розумію, що якщо порти не поділяться між з'єднаннями, ви будете обмежені лімітом порту 64K. Але я також бачив повідомлення про з'єднання 512K за допомогою Gretty . Тож я не знаю.


3
Trello використовує розетки в масових масштабах (конкретно, socket.io).
— Джеймс

Я прочитав, що Trello змушений був змінити код Socket.io через 10 000 обмежень підключення і зміг підтримувати "багато тисяч" з'єднань перед додаванням серверів. Досі величезна прогалина між цим та 512 Кб інших серверних систем.
— Андрій

1
Скільки років ця стаття? Нещодавно Trello досяг понад 1 мільйона активних користувачів щомісяця, тому я думаю, що зараз вони працюють понад 10 000 активних сокетів. Trello використовує Redis, щоб сісти на вершину socket.io для масштабованості
— Джеймс

2
Зараз у Trello більше 4 мільйонів користувачів, але, безумовно, вони працюють на великій кількості серверів, правда? Це повертає мене до мого початкового запитання: який фактичний пік підрахунку користувачів (або когось іншого) на один сервер? Було б також добре знати, який сервер / контейнер вони використовують. А вони все ще мають власну вилку, чи повертаються до походження / майстра? Єдиною моєю метою задати це питання було намагатися визначити, чи моя компанія (на той час) могла дозволити собі підтримувати додаток Socket.io для, ймовірно, 120 000 одночасних з'єднань.
— Андрій

1
Що стосується ліміту порту, я думаю , що пояснення , чому це не є проблемою , пояснюється тут . В основному, єдиний порт, який використовується у вашій системі, - це той, на якому ви слухаєте. Розетки створюються для кожного з'єднання, і вони використовують дескриптори файлів, але вони не використовують порти у вашій коробці.
— Пол Лінч

Відповіді:


77

Ця стаття може допомогти вам на цьому шляху: http://drewww.github.io/socket.io-benchmarking/

Я задався тим же запитанням, тому я закінчив написати невеликий тест (використовуючи XHR-опитування), щоб побачити, коли з'єднання почали виходити з ладу (або відставати). Я виявив (у моєму випадку), що розетки почали діяти приблизно при 1400-1800 одночасно з'єднаннях.

Це короткий зміст, який я зробив, подібний до тесту, який я використав: https://gist.github.com/jmyrland/5535279


7
Я усвідомлюю, що це старіша тема, але я знайшов її спочатку, коли шукав питання на свою відповідь, і в кінцевому підсумку виявив це корисним: rtcamp.com/tutorials/linux/increase-open-files-limit Ліміт відкритого файлу за процес за замовчуванням до м'якого обмеження 1024 та жорсткого обмеження 4096, і оскільки кожен відкритий порт TCP являє собою файл, важливо враховувати ці обмеження, визначаючи, скільки відкритих сокетів дозволить машина, перш ніж намагатися збільшити розмір бібліотеки.
— DeeperID

2
@JAM Ви коли-небудь дізналися, чому ваші веб-розетки діють близько 1400-1800 з'єднань? У мене однакова проблема, і ліміт моїх файлів встановлений на 100 000, тому я знаю, що це не проблема. Будь-яка допомога буде дуже вдячна. Дякую.
— Сет

@seth: минулий час я переглянув це, але я думаю, що це було висновком: опитування XHR забирало занадто багато ресурсів (стосовно інших методів транспорту). Під час використання веб-розеток кількість одночасних з'єднань була вищою.
— JAM

@JAM дякую за відповідь. Я бачу ті самі проблеми за допомогою модуля ws, а не socket.io, тому не повинно бути жодного опитування XHR з модулем ws. Саме там у мене виникають проблеми з усуненням проблем. Пошук триває.
— Сет

Це хороша чиста відповідь. Також правильно, як це залежить від конкретного випадку. Особисто я пропоную PPL написати свої власні орієнтири або симулятор підключення. Хоча тест для когось іншого може бути хорошим, він не відображає реального світового середовища ... Після того, як у вас є клієнтський тренажер, здатний обробляти будь-яку кількість клієнтів з різними помилками реального світу. Ви можете оцінити оцінку після великих змін, а також оновлюйте ваш тренажер по мірі руху. Операція інтерфейсу чату користувача буде відрізнятися для моніторингу браузера користувачів і так далі .. Python я знайшов дуже зручний сценарій для тренажера ...
— Angry 84

16

Я намагався використовувати socket.io на AWS, я можу не більше 600 підтримувати стабільність.

І я дізнався, що це тому, що socket.io спочатку використовував довге опитування, а пізніше оновлено до websocket.

після того, як я встановив конфігурацію лише для використання вебсокета, я можу зберегти близько 9000 з'єднань.

Встановіть цей конфігурацію на стороні клієнта:

const socket = require('socket.io-client')
const conn = socket(host, { upgrade: false, transports: ['websocket'] })

2
ти використовував EC2, який тип екземпляра? t2.micro, t2.nano?
— bvdb

2
Чи помітили ви різницю у чуйності, коли ви змушували веб-розетки?
— Лорен

Чи знаєте ви, якого розміру був ваш екземпляр? Крім того, будь-хто в майбутньому знає, що старі браузери не підтримують WebSockets, тому оновлення може бути важливим для деяких.
— Райан Содерберг

Як ми можемо перевірити, скільки з'єднань підтримує сервер? Як ти виміряв це 9000 підключень? Підкажіть будь ласка ..
— Цікавий розробник

15

Схоже, цей хлопець досяг одного мільйона одночасних з'єднань на одному сервері Node.js.

http://blog.caustik.com/2012/08/19/node-js-w1m-concurrent-connections/

Мені незрозуміло, скільки саме портів він використовував, хоча.


13
Не з socket.io, я думаю, навіть не з веб-розетками. Хлопець, здавалося, використовує довгі опитування, які, мабуть, є менш голодними.
— Тім 333

6

Для паралельного з'єднання + 300 к:

Встановіть ці змінні в /etc/sysctl.conf:

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

Також змініть ці змінні в /etc/security/limits.conf:

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

І, нарешті, також збільшуйте буфери TCP /etc/sysctl.conf:

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

для отримання додаткової інформації зверніться до https://www.linangran.com/?p=547


як перевірити, чи працюють наші зміни?
— Цікавий розробник
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.