[практика] 100 000 сокетов

man SEDA

It is also worth noting that a number of recent research papers have demonstrated that the SEDA prototype (in Java) performs poorly compared to threaded or event-based systems implemented in C. This would seem to contradict the findings in my work.

История успеха, чо.

Давайте так. Пишем на Java? Ожидайте пониженую производительность. А то офигеть, в задаче меряются такты, а мы написали одно на Java, другое на С и делаем research paper. Детский сад. А чо, естественно nginx на Java на напишешь с такой же производительность. Тем более возможно они вообще взяли в 10 соединений скормили данные и наслаждаются своей офигенностью. Потому бред.

Если говорить о гибкости, то SEDA - общая модель. Ее простым изменением параметров можно привратить в любую другую модель. И главное подстроить под задачу. Сейчас в своем проекте начну писать экспериментальный модуль, который на лету переконфигурирует SEDA. Ресерч эдакий, как часть магистерской

Кстати ещё - баян.

Видим, что apache держит порядка 10.000 конкурентных соединений, yaws - порядка 100.000. И тот и другой работают на одной машине.

Так это слова автора, который бросил эту тему ввиду бесперспективности.

*Бесперспективности*

Видим, что apache держит порядка 10.000 конкурентных соединений, yaws - порядка 100.000. И тот и другой работают на одной машине.

Бедный апач кто только не пинал уже. Не стыдно? Найди лучше как yaws уделывает nginx.

Если вы понимаете что такое SEDA, то вот в чем оверхеад при нормальной реализации понять тяжело. Возможно автор написав что-то на Java сразу думал что оно обгонит отточеные и простые как лопата серваки на С++. SEDA - это гибкость для админа системы, конфигурируемость потока данных искаропки.

Чорд, я представил лица архитекторов если я скажу что нужно заюзать сервак на Erlangе. Вижу как они прокусывают палец, рисуют пентаграму на земле и вызывают программиста на Erlang из демонического измерения.

Найди лучше как yaws уделывает nginx.

Зачем? Тот тест - пример обслуживания 100.000 параллельных соединений на одной машине (о чём, собственно, тред).

Видим, что apache держит порядка 10.000 конкурентных соединений

вообще-то там написано «мы запустили 4тыщи апачей для обслуживания 4тыщ соединений и у нас умерла система».

А вы представьте себе сферический сервер в вакууме: десятигигабитная выделенная линия; 128ГБ оперативки, 8 четырехъядерных процессоров; RAID-массив какой-нибудь сверхскоростной на пару-тройку петабайт...

Дешевле обычных серверов среднего уровня пачку взять, и по 10 тыщ коннектов раскидать. Не говоря уже о том, что от этого отказоустойчивость невероятно повышается.

«мы запустили 4тыщи апачей для обслуживания 4тыщ соединений и у нас умерла система».

Это какая фраза в оригинале?

>Nope. Не путай сокеты и порты.

1)Ну так, один сокет - один порт. В другом случае (нескольких сокетов на один порт) из сокетов будет читаться поочередно. Например,

socket
bind
listen
fork

Это ерунда.

2)В заголовке TCP нет никаких идентификаторов удаленного слушателя, кроме порта.

http://ru.wikipedia.org/wiki/TCP#.D0.97.D0.B0.D0.B3.D0.BE.D0.BB.D0.BE.D0.B2.D...

Один порт - одно приложение-получатель. В случае нескольких приложений, они все равно не могут работать параллельно.

>он бредит, об этом уже сказали в этом треде неоднократно. как минимум почитай вот это: http://pzz.livejournal.com/9564.html

С этими сокетами все равно нельзя работать параллельно.

Ну так, один сокет - один порт. В другом случае (нескольких сокетов на один порт) из сокетов будет читаться поочередно.

Выдыхай. Ты где этой фигни нахватался?

В заголовке TCP нет никаких идентификаторов удаленного слушателя, кроме порта.

ЛОЛИЩЕ! А в заголовке IP?

>Выдыхай. Ты где этой фигни нахватался?

По заголовку TCP понятно, я же тебе дал ссылку.

ЛОЛИЩЕ! А в заголовке IP?

А при чем тут заголовок IP??? Разговор идет о транспортном уровне.

IP доставляет пакет до хоста. TCP - до нужного приложения внутри хоста.

С этими сокетами все равно нельзя работать параллельно.

можно там всё. ты же не подумал что они мильён соединений до одного компа и одного порта устанавливают?

А при чем тут заголовок IP???

Сокетами рулит OS.

>можно там всё.

Если можно, давай пруф helloworld на тему.

ты же не подумал что они мильён соединений до одного компа и одного порта устанавливают?

До одного компа и 65535 портов. С большим числом параллельно работать нельзя.

>Сокетами рулит OS.

Ты куда-то не в ту степь пошел. К чему ты это сейчас сказал?

Сначала в сторону IP полез, теперь OS хочешь примешать.

Давай по-существу.

Следи за моим движением:

1) Сокет создается OS

2) Уникальность сокета определяется по (saddr, sport, daddr, dport)

3) Приложение в accept, получает сокет.

4) …

5) Так сколько сокетов можно принять?

2) Уникальность сокета определяется по (saddr, sport, daddr, dport)

Это так, наверное, на Марсе :) У нас на Земле он идентифицируется следующим:

struct sockaddr_in { 
  sa_family_t           sin_family;     /* Address family               */
  __be16                sin_port;       /* Port number                  */
  struct in_addr        sin_addr;       /* Internet address             */

  /* Pad to size of `struct sockaddr'. */
  unsigned char         __pad[__SOCK_SIZE__ - sizeof(short int) -
                        sizeof(unsigned short int) - sizeof(struct in_addr)];
};

У тебя ошибка в рассуждениях.

по ссылке всё есть. Я устал доказывать что я не идиот. Вы можете сколько угодно теоретизировать доказывать почему это нельзя и работать не будет. Мне всё равно, у меня всё работает.

Кстати, я правильно понял, по-твоему, приложение знает только о транспортном уровне?

У нас на Земле он идентифицируется следующим:

абсолютно левый и нерелевантный кусок кода. Ищи место где входящий пакет ассоциируется с соединением, там найдёшь ответ.

> У нас на Земле он идентифицируется следующим:

это только половина идентификатора.

До одного компа и 65535 портов. С большим числом параллельно работать нельзя.

Что будет если сделать так:

ifconfig eth0:1 127.0.0.1 up
ifconfig eth0:2 127.0.0.2 up
..
ifconfig eth0:n 127.0.0.n up

?

Тогда будет доступно n интерфейсов и можно будет работать с максимум n * (2 ^ 16 - 1) клиентскими сокетами, правильно?

Хорошо, уникальность соединения. Сколько соединений можно принять (а об этом и идет речь), при условии разных удаленных сокетов?

> Выходит, высоконагруженные серверы могут быть только распределенными. Плохо.

А вы представьте себе сферический сервер в вакууме: десятигигабитная выделенная линия; 128ГБ оперативки, 8 четырехъядерных процессоров; RAID-массив какой-нибудь сверхскоростной на пару-тройку петабайт...

И потеря 100% траффика в случае если это чудо техники упадет.

Ну так я же не про «крутой» сервер говорил, а про обычную домашнюю файлопомойку.

> Ну так я же не про «крутой» сервер говорил, а про обычную домашнюю файлопомойку.

Для домашней файлопомойки такая конфигурация - это слишком круто :)

И потеря 100% траффика

а рядом стоит запасной, делов-то :)

> а рядом стоит запасной, делов-то :)

Учитывая описанные характеристики запасной влетит в копеечку.

Ну ладно, более приземленно: штуки 3 гигабитных сетевухи, два четырехъядерных процессора, 32ГБ оперативки и 100ТБ RAID. Все вместе выйдет где-то в 150т.р. А у некоторых компьютеры и подороже бывают...

Ты как всегда в своем репертуаре. Таких «крутых» серверов нет даже у порталов с миллиардами кликов в день. Дешевле и надежней купить много машин с обыкновенным железом.

Учитывая описанные характеристики запасной влетит в копеечку.

Запасной встрянет в такие же деньги как и основной. За надёжность надо платить. Никто же не жалуется что raid «неэкономно» расходует место.

Но согласен, лучше собирать кластер из дешёвых и среднедешёвых тачек чем пихать одну большую и ждать когда она навернётся.

Заменить 3 гигабитные сетевухи на две гигабитные, встроенные в мамку, 100Тb RAID на ~4Tb RAID и уже будет похоже на то, что реально используется.

Мечтать не вредно =)

Ну и процессор один, одноядерный.

Нет, по процам и памяти все верно.

Таких «крутых» серверов нет даже у порталов с миллиардами кликов в день.

Ошибаешься. Только их обычно не для веба а для СУБД, кривых приложений итп что плохо масштабируется. Если бы не было спроса то не было бы и предложения.

Оперативка - понятное дело, нужна. А вот зачем столько процессоров, если только мы не используем файлопомойку еще и как вычислительный сервер?

Я к тому, что там дохленького атома за глаза хватит две несчастные гигабитные сетевушки обеспечивать-то.

Не хватит.

Ну да, на 10000 обыкновенных машин одна такая может и стоять.

Во, нашёл :) 8 процов по 8 ядер держит(с поддержкой будущих 10ядерных). До 256 гиг оперативки. http://www.supermicro.com/products/motherboard/Xeon7000/7500/X8OBN-F.cfm

Но ты прав, такое говно нормальный человек не купит.

еще вброшу, что для приема входящих соединений система может иметь несколько ip-адресов, так что на каждый из них можно принимать по 65535 соединений

а вообще лучще покопаться в исходниках ядра и так выяснить максимально возможное кол-во сокетов, все ведь от конкретной реализации зависит. Или спросить в LKML :)

>по ссылке всё есть. Я устал доказывать что я не идиот. Вы можете сколько угодно теоретизировать доказывать почему это нельзя и работать не будет. Мне всё равно, у меня всё работает.

где входящий пакет ассоциируется с соединением

Ладно, согласен

еще вброшу, что для приема входящих соединений система может иметь несколько ip-адресов, так что на каждый из них можно принимать по 65535 соединений

Вбросил, так вбросил. Аж лопасти затрещали. Назови три причины почему один ip не может принять больше 65535 соединений?

да я и не отрицаю, возможно и может :) но надо смотреть реализацию в ядре

еще такой момент, есть же возможность указать INADDR_ANY при вызове bind и соотв. принимать соединения на любой адрес одним сокетом, тут получается, что локальный адрес выпадает из признаков уникальности сокета :)

> есть же возможность указать INADDR_ANY при вызове bind и соотв. принимать соединения на любой адрес одним сокетом, тут получается, что локальный адрес выпадает из признаков уникальности сокета

Из признаков уникальности bound сокета.