Одновременные запросы к сценарию PHP
При реализации поиска иглы стога сена объектно-ориентированным способом, у Вас по существу есть три альтернативы:
needle.find (стог сена)
haystack.find (игла)
searcher.find (игла, стог сена)
, Который Вы предпочитаете, и почему?
Исправляют меня, если я неправ, но во всех трех примерах Вы уже имеете ссылка на иглу, которую Вы ищете, так не это отчасти как поиск Ваших стекол, когда они находятся на Вашем носу?: Игра слов p
в стороне, я думаю, что она действительно зависит от того, что Вы рассматриваете обязанностью стога сена быть в данном домене. Мы просто заботимся об этом в смысле того, чтобы быть вещью, которая содержит иглы (набор, по существу)? Тогда haystack.find (needlePredicate) прекрасен. Иначе, farmBoy.find (предикат, стог сена) могло бы быть более соответствующим.
3 ответа
Сервер, в зависимости от его конфигурации, обычно может обслуживать сотни запросов одновременно - при использовании Apache, MaxClients Параметр конфигурации гласит:
Директива
MaxClientsустанавливает ограничение на количество одновременных запросы, которые будут обслуживаться.
Любые попытки подключения черезМаксимальное количество клиентовобычно составляет в очереди, до числа в зависимости от Директива ListenBacklog.
Когда-то был ребенком процесс освобождается в конце другой запрос, соединение будет затем будут обслуживаться.
Тот факт, что два клиента запрашивают одну и ту же страницу, не является проблемой.
Итак:
Будут ли запросы помещены в очередь?
Нет; кроме случаев, когда:
- где-то есть какая-то блокировка - что может произойти, например, если два запроса поступают от одного и того же клиента, и вы используете сеансы на основе файлов в PHP : пока выполняется сценарий, сеанс «заблокирован», что означает, что сервер / клиент должен будет дождаться завершения первого запроса (и разблокировки файла ), чтобы иметь возможность использовать файл для открытия сеанса для второго пользователя.
- запросы поступают от одного и того же клиента И одного и того же браузера; в этом случае большинство браузеров ставят запросы в очередь, даже если на стороне сервера нет ничего такого, что вызывает такое поведение.
- в настоящее время активны более
MaxClients- см. Цитату из руководства Apache непосредственно перед этим.
Будут ли они проигнорированы?
Нет: это будет означать, что только один пользователь может использовать сайт одновременно; это было бы не очень хорошо, не так ли?
Если бы это было так, я не мог бы опубликовать этот ответ, если бы вы одновременно нажимали F5, чтобы узнать, ответил ли кто-нибудь!
(Ну, SO отсутствует в PHP, но принципы те же самые)
Любая другая возможность?
Да ^^
редактировать после редактирования OP и комментария:
Будет ли каждый запрос имеет собственный скрипт instance?
Не существует такой вещи, как « экземпляр сценария »: проще говоря, то, что происходит, когда делается запрос к сценарию, это:
- веб-сервер разветвляет другой процесс для обработки запроса (часто из соображений производительности эти форки создаются заранее, но это ничего не меняет)
- процесс читает сценарий PHP с диска
- несколько процессов могут делать это одновременно : нет блокировки при чтении файла
- файл загружается в память; в отдельном блоке памяти для каждого процесса
- файл PHP в памяти « скомпилирован » для кодов операций - все еще в памяти
- эти коды операций выполняются - все еще из блока памяти, который принадлежит к процессу, отвечающему на ваш запрос
На самом деле, у вас может быть два пользователя, отправляющих запрос к одному и тому же сценарию PHP (или к различным сценариям PHP, которые все включают один и тот же файл PHP) ; это определенно не проблема, или ни один из веб-сайтов, над которыми я когда-либо работал, не работал бы!
Если 2 клиента звонят сервер одновременно, сервер, скорее всего, сможет ответить обоим клиентам почти одновременно. Здесь я определяю клиентов на уровне браузера.
Это означает, что на одном компьютере, если вы используете 2 браузера для одновременной загрузки одного и того же веб-сайта / страницы, оба должны быть загружены одновременно. .
однако, поскольку мы говорим о PHP, вам нужно делать особые заметки о сессиях. Если ваши страницы используют сеансы, сервер обслуживает только одну страницу за раз. Это потому, что файл сеанса будет заблокирован до выхода из сценария.
Посмотрите на этот пример. Два файла загружаются из одного сеанса, то есть одного и того же браузера, одного и того же пользователя.
scripta.php requested scripta.php served
------+---+---------------------------------+------------------------>
scripta.php started
scriptb.php requested scriptb.php started
---------------+-------------------------------+-----------------+--->
scriptb.php served.
Обратите внимание, что scriptb. php запускается только после обслуживания scripta.php. это потому, что при запуске scripta.php файл сеанса заблокирован для других сценариев, так что scripta.php может записывать в файл сеанса. Когда scripta.php завершается, файл сеанса разблокируется, и, следовательно, другие сценарии могут его использовать. Таким образом, scriptb.php будет ждать, пока файл сеанса не будет освобожден, затем он заблокирует файл сеанса и будет его использовать.
Этот процесс будет повторяться, чтобы предотвратить запись нескольких сценариев в один и тот же файл сеанса, вызывая задержки. Таким образом, рекомендуется вызывать session_write_close (), когда вы больше не используете сеанс, особенно на веб-сайте, где используется много окон iframe или AJAX.
Этот процесс будет повторяться, чтобы предотвратить запись нескольких сценариев в один и тот же файл сеанса, вызывая задержки. Таким образом, рекомендуется вызывать session_write_close (), когда вы больше не используете сеанс, особенно на веб-сайте, где используется много окон iframe или AJAX.
Этот процесс будет повторяться, чтобы предотвратить запись нескольких сценариев в один и тот же файл сеанса, вызывая задержки. Таким образом, рекомендуется вызывать session_write_close (), когда вы больше не используете сеанс, особенно на веб-сайте, где используется много окон iframe или AJAX.
Если вы не используете очень нестандартную настройку вашего веб-сервера (Apache, IIS, nginx и т. д.) ) будет иметь несколько процессов, которые запускают PHP отдельно для каждого запроса, поступающего на сервер. Одновременные заявки будут обслуживаться одновременно.