если послать на сервер одновременно множество запросов что произойдет
Отправка множества запросов одновременно.
Вроде все просто и понятно. Но если игрок будет ddosить сервер запросами, то может получиться так *отсортировано по времени*
1Запрос 1Этап) проверяем кол-во ресурса
2Запрос 1Этап) проверяем кол-во ресурса
1Запрос 2Этап) проверяем кол-во зданий у игрока
2Запрос 2Этап) проверяем кол-во зданий у игрока
1Запрос 3Этап) проверяем Уменьшаем ресурс+ строим здание
2Запрос 3Этап) проверяем Уменьшаем ресурс+ строим здание // а вот тут ресурса может быть уже недостаточно, или лимит построек превышен.
т.о. 2 запрос фактически построился без проверок. И если у игрока было недостаточно ресурса, то теперь у него его будет отр. кол-во.
Как правильно с этим бороться?
Варианты пришедшие в голову:
1) ограничить прием одинаковых запросов от игрока, до раза в секунду // в целом в концепт игры укладывается, но выглядит не очень.
2) Отнимать ресурс сразу после проверки. // Но тогда, придется его возвращать, если второе условие не соблюдено, и так же не ясно как быть с кол-вом построек, нельзя же его просто увеличить.
Ни дня без счастливого человека, открывшего для себя транзакции.
Chipmunk
Спасибо за термин, вот ссылочка ещё.
Сервер не должен слушаться клиента, и делать что ему скажут, он должен неохотно выполнять, либо дерзко игнорировать. В данном случае, дом не «достроен», клиент сидит и ждёт, когда нада будет, сообщите ему о успехе или неудачи, а покуда это не сообщено, игнорируй его по отношению к строительству..
Можно просто хладнокровно спамить в ответ отказами: «You do not have enough mana», «I can’t do that yet», «Spell is not ready!» 🙂
Wexsel, а зачем вообще эти запросы и при чём тут читерство?
Все проверки должен делать сервак. Но это совсем не обязательно делать по запросу клиента. Делай так:
— пришёл запрос от клиента построить здание такое-то там-то
— сервер делает все проверки разом
— если всё прошло успешно, то шлём ответ что успешно и шлём ответ что построено
— если не успешно, то шлём ответ что фэйл
slava_mib
Но в твоём объяснении идёт речь только о самом клиентском «честном» приложении. Это конечно нужно, и должно быть, но что если мы симулируем запросы, вот тут и встаёт вопрос, о сохранности на сервере, чтобы не позволить подобному произойти..
MoKa, читай внимательно:u]
1. метод kvakvs
2. плюс сервер должен считать всё сам и лишь тогда, когда он сам хочет
3. запросы клиента можно не удовлетворять, если это мешает серверу (см п. 1)
Chipmunk
> Ни дня без счастливого человека, открывшего для себя транзакции.
Транзакции тут не годны ибо часть параметров лежит в памяти сервера, а часть в базе.
kvakvs
> Если пошёл спам сообщениями более Х за Y секунд, такого игрока отключать,
> писать в базу данных ему бонусный балл подозрения на читерство.
Именно так я и предполагал(«1) ограничить прием одинаковых запросов от игрока, до раза в секунду»), просто вдруг есть более разумный вариант.
slava_mib
> Все проверки должен делать сервак.
Вообще, что бы избавиться от лагов, лучше дублировать большую часть логики. Вопрос не в том где делать, вопрос был в том, что если клиент шлет «Хочу построить здание #521» сотнями в секунду, то сервер был уязвим, могла сложиться ситуация, когда для n-запросов удались проверки на ресурсы etc, хотя ресурсов только на одно здание.
В общем пока сделал так:
Когда от игрока приходит запрос, в памяти ставиться флаг, уникальный для вида запроса и игрока.
Как только сервер закончил обработку запроса, флаг сбрасывается.
Так же флаг сбрасывается через 3 секунды после установки автоматически.
Логика запроса выполняется только если флага нет.
kvakvs
> писать в базу данных ему бонусный балл подозрения на читерство.
Спасибо, ценная идея). позже приделаю.
Wexsel
> Транзакции тут не годны ибо часть параметров лежит в памяти сервера, а часть в
> базе.
С точки зрения архитектуры современных ММО, держать данные в БД, не хорошая тенденция. Т.к. это ведёт к тормозам, и зависимости от БД.
Данные должны быть в ОЗУ, загружены, и там должны быть всегда. И лишь говорить БД, «запиши то, и вон то».
> Не согласен. Это вызывает видимость «лагов» у потенциального покупателя.
Какие лаги? Это как заюзать скилл, там будет крутиться маленький таймер (визуально стрелка часов с частичным заполнением иконки или кнопки).
> Вопрос не в том где делать, вопрос был в том, что если клиент шлет «Хочу
> построить здание #521″ сотнями в секунду, то сервер был уязвим, могла сложиться
> ситуация, когда для n-запросов удались проверки на ресурсы etc, хотя ресурсов
> только на одно здание.
Wexsel, ответ был дан: http://www.gamedev.ru/code/forum/?id=152150#m3
ИМХОсы, на практике нада это отработать, а пока видится данный путь очень актуальным и современным (с умом) подходом к таким задачам.
Собственно это уже оффтоп.
MoKa
> Там есть концепция Ventilator > Workers > Sink. На её основе, можно без проблем
> раздавать кучу информации, не заботясь о её обработке. Это могут быть отдельные
> компьютеры по обработке.
Чем-то мне это эрланг напомнило.
У джавы есть jmx для таких целей как мониторинг/профилирование всего и вся.. Делается простенький сервис типа SecurityService.shedule(player, exception). с привязкой к политикам внутри. У нас много чего мониторится вплоть до общей нагрузки конкретного игрока. а потом кластерным анализом по группам. этот у нас читер, а вот этот бот. 😉
Что будет если на сервер придет одновременно два запроса?
Доброго дня!) Вопрос теоретический, но все же. Смотрите например есть форма куда забиваются данные, по нажатию кнопки эти данные отправляются на сервер, на сервере на основе этих данных формируется отчет в word (например отчет формируется в течении 5 минут) и возвращается обратно пользователю.
Что будет если в то время пока формируется отчет, с другого компа отправят еще запрос (или 2 запроса)?
Что в этом случае будет делать сервер, он эти запросы в очередь поставит?
Добавлено через 3 минуты
Т.е. я к чему: если например с интервалом в 1 секунду (чисто гипотетически) придет 10 запросов из формы, то если принять что на один отчет сервер тратит 5 минут, последний пользователь который отправил запрос получит ответ через 10*5=50 минут?
Два запроса на сервер одновременно
Друзья помогите советом, рекомендацией. Есть site1. На нем пользователь проходит процесс.
Что будет, если к базе данных, расположенной на сервере, одновременно обратятся 2 компьютера
Что будет, если к базе данных, расположенной на сервере одновременно обратятся 2 компьютера и.
Т.е. если я не ошибаюсь, то Апач создаст полностью новый поток. Запустит в нем Джангу, проделает всю бизнес-логику.
Тут прилетает новый запрос, новый поток, новая джанга. Возможно, есть настройки у Апача, чтобы он работал событийно.
Nginx форкать ничего не будет, новую Джангу создавать не будет. Он существующей Джанге даст во вьюху новый запрос. А когда Джанга отработает, поймает ее ответ. И вернет юзеру.
Но я вот в этом всем очень плаваю. И если кто из гуру ответит на поставленный вопрос, было бы просто здорово.
Так что присоединяюсь к вопросу.
Если на сервер идет много запросов
Нужно отправлять много curl запросов на удаленный сервер
Юзал обычные curl_exec, curl_close, если в качестве хоста указан localhost все быстро работало.
Если поисковых запросов слишком много?
Хотелось бы послушать уважаемых оптимизаторов. Допустим, есть портал широкой, тематики.
Какие проблемы возможны, если к одному сервлету будет много запросов одновременно?
Какие проблемы возможны, если к одному сервлету бедет очень много запросов одновременно? Как я.
Стоит ли использовать MemCashed вместо MySQL если на сервер в день поступают свыше 10тысяч запросов?
Объясните пожалуйста про MemCashed она и вправду снижает нагрузку на сервер. Работает в 3раза.
Можно вот про кэширование и про очереди чуть подробнее? И то и то по умолчанию делает mysql или это настраивается? Разные ли используется очереди?
Добавлено через 55 минут
А всякого рода коллизии неужто не случаются?
Кеширование работает примерно так: после выполнения select-запроса, его результаты (полностью или в виде сокращенного «дайджеста») некоторое время хранятся в специальном буфере. По мере выполнения других select-запросов их результаты точно так же складываются в этот буфер, вытесняя из него наиболее старые результаты. Если очередной запрос окажется таким же, как один из сохраненных, его результаты просто извлекаются из кеша. Это упрощенная схема, реально еще контролируются изменения таблиц и результат запроса может быть удален из кеша раньше срока, если он стал неактуальным.
Что касается коллизий, то модифицирующие запросы всегда блокируют всю таблицу или изменяемую запись на время выполнения, поэтому коллизий быть не может.
Одновременные запросы к php скрипту
Если движок PHP уже находится в середине выполнения скрипта на сервере, что произойдет с другими одновременными запросами браузера к тому же скрипту?
4 ответов
на MaxClients директива устанавливает ограничение на количество одновременных запросы, которые будут обслуживаться.
любой попытки подключения через MaxClients ограничение обычно будет в очереди, до номера, основанного на ListenBacklog директива.
после того, как ребенок процесс освобождается в конце другой запрос, соединение будет тогда обслуживайтесь.
Тот факт, что два клиента запрашивают одну и ту же страницу-не проблема.
будут ли запросы поставлены в очередь?
нет, за исключением, если :
редактировать после редактирования OP и комментария:
каждый запрос будет иметь свой собственный сценарий экземпляра?
нет такой вещи, как»экземпляр скрипта» : проще говоря, то, что происходит, когда делается запрос на скрипт:
Если 2 клиента одновременно вызывают сервер, сервер, скорее всего, сможет ответить обоим клиентам почти одновременно. Клиенты здесь я определяю их до уровня браузера.
означает, что на одном компьютере, если вы используете 2 браузера для загрузки одного и того же веб-сайта/страницы одновременно, оба должны быть загружены одновременно.
однако, поскольку мы говорим о PHP, вам нужно сделать специальные заметки о сеансах. Если ваши страницы используют сеансы, сервер обслуживает только одну страницу за раз. Это связано с тем, что файл сеанса будет заблокирован до выхода скрипта.
посмотрите на этот пример. Файлы 2 загружаются из того же сеанса, что и тот же браузер, тот же пользователь.
обратите внимание, что scriptb.php запускается только после скрипты.PHP-это утро. это потому, что когда скрипта.php запущен, файл сеанса заблокирован для других скриптов, так что скрипта.php может записывать в файл сеанса. Когда скрипта.php завершается, файл сеанса разблокирован и таким образом другие скрипты могут использовать его. Таким образом scriptb.php будет ждать, пока файл сеанса не будет освобожден, затем он заблокирует файл сеанса и использует его.
этот процесс будет повторяться, чтобы предотвратить запись нескольких сценариев в один и тот же файл сеанса, вызывая задержки. При этом рекомендуется звонить session_write_close () когда вы больше не используете сеанс, особенно на веб-сайте, использующем много iframes или AJAX.
Если вы не используете очень нестандартную настройку вашего веб-сервера (Apache, IIS, nginx и т. д.) будет иметь несколько процессов, которые запускают PHP отдельно для каждого запроса, который входит в сервер. Одновременные запросы будут обслуживаться одновременно.
просто столкнулся с этим сам. В основном вам нужно позвонить session_write_close() для предотвращения блокировки одного пользователя. Убедитесь, что после вызова session_write_close() вы не пытаетесь изменить какие-либо переменные сеанса. Как только вы назовете это, рассматривайте сеансы только для чтения с этого момента.
Как обрабатывает множество одновременных запросов серверная часть сайта на php?
Допустим одновременно в одну секунду сразу 1000 пользователей открывают страницу сайта,куда подгружается много данных из бд. Каков в таком случае порядок и принцип обработки множества одновременных запросов?Неужели все запросы обрабатываются поочереди? как сервер выбирает какому пользователю первым отправить ответ, если пользователи обратились к нему одновременно? Прошу дать развёрнутый ответ, а не вбросы в комментариях.
1 ответ 1
Начнём с простого: 1000 пользователей одновременно обращаются к встроенному веб-серверу php. Встроенный сервер очень простой и не умеет распарллелить обработку запросов, поэтому запросы будут выстраиваться в очередь и выполняться по одному. Если обработка занимает существенное время, часть клиентов не дождётся ответа.
Чуть сложнее: в качестве веб-сервера используем nginx. Nginx умеет запускать несколько обработчиков параллельно (это принесёт наибольший профит, если процессор машины, на коорой крутится веб-сервер многоядерный), но и nginx создаст очередь, просто будет разгребать её быстрее, запуская по несколько обработчиков параллельно. Если обработка занимает существенное время, часть клиентов не дождётся ответа.
Ещё немного сложнее: если один сервер не справляется с обработкой всех запросов, то остаётся использовать несколько серверов. Для этого используются балансировщики нагрузки. Вот как это работает. 1000 пользователей открывают страницу и обращаются к балансировщику, балансировщик тоже создаёт очередь (никакого чуда не произошло), но вся работа балансировщика заключается в том, что он отправляет пользователей на веб-серверы (на отдельных машинах), стоящие за ним, по кругу (первый, второй, третий. снова первый, второй). Работа балансировщика очень простая и он делает её очень быстро, и очень быстро разгребает очередь. Он работает гораздо быстрее, чем отвечают веб-серверы, поэтому в случае если пользователей стало больше, обычно достаточно добавить ещё веб-серверов, на которые он будет разбрасывать запросы. Важно понимать, что и в этом случае, если обработка занимает существенное время, часть клиентов не дождётся ответа. Всегда есть какой-то порог, после которого сайт ляжет, просто он должен быть выше, чем пиковая нагрузка на сайт.
Приблизительно так это работает на уровне веб-серверов. Однако сами веб-серверы обычно код не выполняют, а передают обработку на серверы приложений и ждут ответа от них. Например nginx очень быстр, но он не выполняет php, а передаёт обработку в php-fpm. А php не занимается работой с данными, а обращается за ними к базе данных. Все эти слои параллелятся по похожему принципу.
В конкретной ситуации всё может отличаться. Например браузеры, веб-серверы, приложения на php, базы данных поддерживают кэширование и другие оптимизации, которые позволяют ответить на часть запросов срезав путь.