Comments 33
Хотелось бы грязных технических подробностей.
шикарное приложение :) Для полного счастья пусть добавят опцию нереально крутой шифрации типа как у RIM.
А потом этот сервер внезапно с треском падает, и миллион юзеров вылетает в оффлайн. Блеск.
А если он обслуживает 100 000 сессий и с треском падает, то что?
Я так полагаю, что имелось ввиду, что каждый из серверов может обслуживать по миллиону. А падение сервера приходится предусматривать вне зависимости от количества пользователей на нем.
Я так полагаю, что имелось ввиду, что каждый из серверов может обслуживать по миллиону. А падение сервера приходится предусматривать вне зависимости от количества пользователей на нем.
Да, именно так и есть:
Over the past few months we have been making a lot of improvements to our servers to increase the performance, uptime and scalability. Today we have tuned some knobs, shifted some traffic around and achieved 1 million established tcp sessions on a single machine
Over the past few months we have been making a lot of improvements to our servers to increase the performance, uptime and scalability. Today we have tuned some knobs, shifted some traffic around and achieved 1 million established tcp sessions on a single machine
Скажите, что в моем комментарии указывало на то, что я подразумеваю наличие у WhatsApp одного единственного сервера?
Ребята показали реальную продакшен-ситуацию, когда на один сервер у них зацеплен миллион клиентов. Не «может запиться», а «зацеплен». Улавливаете разницу между 10*10^6 и 100*10^5? В какой из этих конфигураций стоимость простоя ниже?
Ребята показали реальную продакшен-ситуацию, когда на один сервер у них зацеплен миллион клиентов. Не «может запиться», а «зацеплен». Улавливаете разницу между 10*10^6 и 100*10^5? В какой из этих конфигураций стоимость простоя ниже?
Ситуация «сервер внезапно с треском падает, и миллион юзеров вылетает в оффлайн» возможна только с случае одного сервера, если их несколько, то почему юзеры должны вылететь в офлайн?
Если это мои деньги, то очень даже улавливаю: разница равна сумме 90 * (на стоимость одного сервера).
Улавливаете разницу между 10*10^6 и 100*10^5?
Если это мои деньги, то очень даже улавливаю: разница равна сумме 90 * (на стоимость одного сервера).
1. Потому что если это не кластер, юзерам придется переподключаться. А если это полноценный дублирующий кластер, то оно какой-то слегка бессмысленный. Или я чего-то не знаю о недостатках горизонтального масшабирования.
2. Вот только а) стоимость железа несравнима; б) простой пяти серверов из сотни пройдет для пользователей (и вашего кошелька) незаметно, а пяти из десятка — EPIC FAIL.
2. Вот только а) стоимость железа несравнима; б) простой пяти серверов из сотни пройдет для пользователей (и вашего кошелька) незаметно, а пяти из десятка — EPIC FAIL.
А почему должен быть кластер? Юзер подключен, как я понимаю, к балансеру, а дальше куда он пойдет — зависит уже от реализации распределения нагрузки в данной конторе. В ebay, например, юзер, просматривая последовательно пять страниц, подключается к пяти разным серверам. Ну т.е. теоретически это может быть и один, но 3 года назад (сейчас не знаю) у них было 16 000 серверов, так что вероятность попасть на тот же очень мала. Никаких кластеров в ebay нет.
Не очень понятно сравнение: 5 из сотни это 5%, 5% из десятка это полсервера. Т.е. если надежность серверов однаковая и — для простоты — сервер выходит из строя раз в 10 дней, то в день я буду иметь нерабочими либо 10 серверов из сотни либо один из десятка.
Не очень понятно сравнение: 5 из сотни это 5%, 5% из десятка это полсервера. Т.е. если надежность серверов однаковая и — для простоты — сервер выходит из строя раз в 10 дней, то в день я буду иметь нерабочими либо 10 серверов из сотни либо один из десятка.
UFO just landed and posted this here
Если сможете так сделать (надежно), то попробуйте поискать работу в Cisco — просите не меньше 200k$ в месяц.
Special SYN packets include a Migrate option
Теория — это всегда здорово, но для практической реализации ребятам надо было предложить это решение лет на 20 раньше.
А пройти дальше первой ссылки никак?
citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.88.7110&rep=rep1&type=pdf
dl.acm.org/citation.cfm?id=1534911
итд, полно всего, втч и реализации под линукс.
citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.88.7110&rep=rep1&type=pdf
This paper describes the design, implementation, and performance evaluation of ST-TCP (Server fault-Tolerant TCP), which is an extension of TCP to tolerate TCP server failures. This is done by using an active backup server that keeps track of the state of the TCP connection and takes over the TCP connection whenever the primary fails. This migration of the TCP connection to the backup is completely transparent to the client. Because no changes are required on the client machine, any TCP client can access a ST-TCP server. The performance overhead of ST-TCP over standard TCP is minimal, and during normal operation its behavior is the same as that of a regular TCP. In addition, ST-TCP provides a fast and seamless failover whenever the primary server fails.
dl.acm.org/citation.cfm?id=1534911
This article describes an architecture that allows a replicated service to survive crashes without breaking its TCP connections. Our approach does not require modifications to the TCP protocol, to the operating system on the server, or to any of the software running on the clients. Furthermore, it runs on commodity hardware. We compare two implementations of this architecture (one based on primary/backup replication and another based on message logging) focusing on scalability, failover time, and application transparency. We evaluate three types of services: a file server, a Web server, and a multimedia streaming server. Our experiments suggest that the approach incurs low overhead on throughput, scales well as the number of clients increases, and allows recovery of the service in near-optimal time.
итд, полно всего, втч и реализации под линукс.
Ты предлагаете писать свою специализированную версию реализации TCP-стека?
Вы сейчас точно не про UDP?
Свой сервер и свой клиент? Тогда такое вполне можно предусмотреть и корректно обработать: клиент просто должен при обрыве tcp соединения тихо переподключиться к другому.
Из миллиона клиентов заметят только те, кто в данный момент общаются, и то только в виде лага размером с TCP_TIMEOUT, и это будет очень похоже на то, что собеседник задумался. Это же IM, а не реалтайм.
Не вижу проблемы.
Из миллиона клиентов заметят только те, кто в данный момент общаются, и то только в виде лага размером с TCP_TIMEOUT, и это будет очень похоже на то, что собеседник задумался. Это же IM, а не реалтайм.
Не вижу проблемы.
Ну да, еще это все поверх 3G работает, как правило. А ваш второй сервер выдержит еще миллион пользователей? Я четко вижу, что у ребят сервак держал сегодня 1М коннектов. Значит ли это, что все их сервера обслуживают примерно столько же подключений (±10..15%)? Мне кажется — да, значит.
Нет не значит. Может быть сегодня как раз был такой момент, когда один сервер вылетел и клиенты ушли на другой. Или плановая перебалансировка с целью протестировать сервер в пике в продакшине после нескольких искусственных тестов. Или перебалансировали чтобы потом попиарится.
Я не понимаю, как на таких скудных входных данных можно так негодовать ;) Ничего же не известно.
Я не понимаю, как на таких скудных входных данных можно так негодовать ;) Ничего же не известно.
Предлагаете на каждого сервер ставить? =)
/etc/sysctl.conf
и
sysctl -a
этого сервера в студию!
и
sysctl -a
этого сервера в студию!
Ну, потестим. Вроде как в течении 24 часов обещают релиз версии для WP7.
То то он падает постоянно…
Sign up to leave a comment.
Сервер WhatsApp обслуживает более миллиона TCP-соединений