Цитата(-ser- @ 9.6.2006, 11:16  ) |
| как официально на англ это зовется. |
broadcastings storms либо network (over)flood
| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > СУБД, общие вопросы > когда запросов больше, чем сервер может обслужить? |
| Автор: -ser- 9.6.2006, 09:13 |
| какой существует механизм, если клиентских запросов к базе больше, чем сервер может физически по скорости обработать? что я как программист могу здесь сделать? интересует сама идея. |
| Автор: Nuzur 9.6.2006, 10:11 |
| Сервер просто будет их игнорировать. Либо обвалиться тут уже все в его руках. Про шторм пакетов слышал когда-нибуть? Подождать пока сервер разгрузиться и повторить запросы. Мол пробуем получить ответ - нет(таймаут) - ждем интервал времени Икс - повторяем попытку. Либо запрос уже будет просрочем соответственно викидуем его из очереди. |
| Автор: -ser- 9.6.2006, 10:16 | ||
| это уже что-то. а почему либо игнорировать, либо обваливаться, это от чего зависит, от настроек, самой БД?
и что, каждый во что горазд, реализовывает этот механизм? |
| Автор: batigoal 9.6.2006, 10:23 | ||
broadcastings storms либо network (over)flood |
| Автор: Nuzur 9.6.2006, 12:45 |
-ser-, Ну вот и чудненько закажи себе broadcastings storms( про network (over)flood не слышал), и посмотри как поведет себя сервак, если он просто будет посылать клиентов на... то думай в таком направлении, если обвалиться лучше где-то начать чухаться пока с работы не поперли  Зависит очень от многово... какая СУБД, на какой платформе, на какой махине.... короче все что можна дописать мне лень  Я не знаю как кто но я не вижу проблем в реализации сего механизма... делаешЬ очередь, с приоритетами или без них и начинаеш нею жестоко по садо-мазо кормить сервер, стегать его плеткой... простите просто в прошлом посте про секс фантазии было  Просто тут все зависит от поставленой задачи. |
| Автор: -ser- 9.6.2006, 13:35 |
| Nuzur, да я тоже проблем в реализации не вижу, главное четко представлять как сервер работает, а я в этом, скажу честно, не очень. то есть, если я правильно понимаю, в подобных задачах создается очередь запросов. и механизм такой - посылаем из очереди один запрос на сервер, и ждем от него какой-то ответ. и только после того, как ответ с сервера получили, можно отсылать следующий запрос. в противном случае - результат нехороший, для чего и создали очередь. поправьте меня, если что-то не так или не все детали. просто вопрос сей был задан мне на интервью, ну и поскольку я теоретическую возможность такой ситуации смог представить, а что и как в этом случае делается, понятия не имел (я думал что сервер сам себе очередь выстраивает), то так им и сказал что я мля, в своей богатейшей практике, до таких ситуаций дело просто не допускал. что то в инете инфа по broadcastings storms все относительно архитектуры сетей. |
| Автор: batigoal 9.6.2006, 14:27 | ||||
Ну, в общем, да, это проблема топологии сети, а не надежности сервака.
Все, что сказано ниже, относится к системам в общем, а не к БД. Тут ведь проблема не в клиенте, а в сервере. Клиент может попасться как последовательный, так и многопоточный. А организация сервака может быть совершенно различной. Варианты, которые нам дает теория систем массового обслуживания (СМО): 1) увеличение количество одновременно обрабатываемых запросов. Т.е., например, на каждый запрос запускается поток, или его обрабатывает отдельная нода, в случае кластера. Ограничение - ресурсы компа, рано или поздно память кончится. 2) создание очереди ожидающих запросов. Ограничение - временнОе, клиент интернет-магазина не станет ждать двадцать минут, пока ему вернется страничка с описанием товара. Он просто уйдет на другой портал. Длина очереди обычно ограничивается, если приходит запрос, а длина очереди уже максимальна - ему отказывается в обслуживании. 3) Комбинированный вариант (самый частый). Например, максимум 10 одновременно обрабатываемых запросов, остальные стоят в общей очереди, из которой диспетчер перенаправляет их одному из обработчиков. |