Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.138.141.202] |
|
Страницы: (6) « Первая ... 4 5 [6] все ( Перейти к последнему сообщению ) |
Сообщ.
#76
,
|
|
|
Очень может быть. Но существует случай, когда скромный велосипед лучше модного "мерседеса". Это когда мерседес постоянно валяется в кювете. --- Кроме того, можно заметить, что порт завершения для этой задачи не так уж и нужен. Поскольку он позволяет следить за разнородными объектами, а в данном случае требуется следить только за сокетами. Совершенно не понятно, как разорвать ассоциацию порта и сокета, а это существенный вопрос. (Возможно, уничтожением порта завершения и создания нового ? Не уверен.) Зато при использовании сокетов беркли "разрыв ассоциации" не проблема. В результате легко и просто организовать "конвейерную" обработку клиентов. Без любых проблем в многопоточной манипуляции сокетами. При этом сам "сервер" даже может (а, наверное, и должен) не знать, что он "сетевой". Он просто манипулирует объектами-клиентами. |
Сообщ.
#77
,
|
|
|
В искуственных тестах нагрузки она у меня и 50 тысяч в минуту держала на одном сервере. Давайте считать: 10 мс время обработки одного пакета - значит один поток обработает за секунду 100 пакетов или 6000 за минуту. У меня 16 потоков. В минуту будет 96000 даже если ошабаюсь на 50 процентов я то 40 тысяч в минуту держать должен так что до потолка ой как далеко. Если отключить запись в БД или очень сильно озадачиться оптимизацией этой записи - напрмиер ее вести асинхронно то время на обработку одного потока падает до 0-1мс |
Сообщ.
#78
,
|
|
|
Когда я тестировал грани возможностей IOCP, у меня 6-ядерный сервер держал 30000 запросов в секунду. И выдержал бы больше, если бы это был простой echo-сервер. |
Сообщ.
#79
,
|
|
|
Ну что ж, progman,Pacific - вы меня убедили и я даже за мелкомягкое изобретение IOCP имею немного гордости... молодцы, все таки что то стоящее сочинили.
Значит и надо его юзать по полной, а проблемы решать по мере поступления. Ну а теперь по расчетам. Цитата progman @ Давайте считать: 10 мс время обработки одного пакета - значит один поток обработает за секунду 100 пакетов или 6000 за минуту. Этот расчет слишком на мой взгляд слишком арифметически прямолинеен. В любой сложной системе крутятся сотни процессов и может быть тысячи потоков. Время переключения контекста потока с одного на другой в разных процессорных системах может колебаться от 20 до 300 циклов - смотрел только что в гуглях. Кроме того, надо учитывать и приоритетность и прочая. Так что процентов на 10-15 я бы ваши цифры уменьшил бы... Цитата Pacific @ Когда я тестировал грани возможностей IOCP, у меня 6-ядерный сервер держал 30000 запросов А сколько было рабочих потоков? Ну и кстати такой вопрос - а что такое "запрос"??? Это понятие ой как растяжимое. Скажем HTTP-запрос на сервер GET вообще может содержать не более чем 256 символов - а ответ на него может длиться секундами - пересылка сотен картинок и страниц текста. Так что обработка запроса должна рассматриваться только после ответа. Если просто принимать запросы - и не отвечать на них - тогда другое дело. Т.е. цифры зависят от характера транзакций. Цитата Pacific @ И выдержал бы больше, если бы это был простой echo-сервер. У эхо-сервера нет процесса обработки запроса. Если туда Хелло и обратно Хелло - может быть. А к примеру, в качестве запроса на эхо я шлю файлик так под мегабайт. И буду ждать ответа сервера. Тоже выдержит? Не все так просто... Но все равно, опыт ваш и прогмана впечатляет. Только вот прогман сдал IOCP и променял его на буст-обертку... Кстати, где-то в сети встречал сравнение по скорости исполнения одного и того же достаточно емкого запроса. Буст явно проигрывал...потому как библиотека, а не родное АПИ. |
Сообщ.
#80
,
|
|
|
Цитата Oleg2004 @ Ну и кстати такой вопрос - а что такое "запрос"??? Там был свой протокол на базе TCP+SSL. От клиента приходит не больше 1 Кб, от сервера к клиенту - от 1 до 64 Кб (в среднем было 3-4 Кб). Вот это все (установка TCP соединения, SSL хэндшейк, обработка запроса и закрытие соединения) обрабатывалось по 30000 в секунду. Все это конечно тестировалось в гигабитной локалке, в реальной работе таких нагрузок не было. |
Сообщ.
#81
,
|
|
|
Цитата Pacific @ Все это конечно тестировалось в гигабитной локалке, в реальной работе таких нагрузок не было. Это реально впечатляет. Вот что IOCP творить может |
Сообщ.
#82
,
|
|
|
Цитата Oleg2004 @ Этот расчет слишком на мой взгляд слишком арифметически прямолинеен. В любой сложной системе крутятся сотни процессов и может быть тысячи потоков. Время переключения контекста потока с одного на другой в разных процессорных системах может колебаться от 20 до 300 циклов - смотрел только что в гуглях. Кроме того, надо учитывать и приоритетность и прочая. Так что процентов на 10-15 я бы ваши цифры уменьшил бы... В данный момент как я уже писал у меня 16 потоков и примерно 7000 в минуту запросов обрабатывается. Счетчик показывает что среднее время на обработку одного запроса 10мс. Причем 99% этого времени занимает запись в БД. Загрузка CPU меньше одного процента. Почему я не имею право экстраполировать? )))) |
Сообщ.
#83
,
|
|
|
Цитата progman @ Почему я не имею право экстраполировать? )))) Имеете...у вас же все карты на руках... Я же выступаю с позиции удаленного скептика...а вы - локального прагматика. |