#php #connection-pooling #pooling #object-pooling
#php #объединение в пул соединений #объединение #объединение объектов
Вопрос:
Возможно ли объединить данные или функциональность в PHP?
Любительский PHP-код, который я пишу, просыпается для обработки ответа, загружает функции, открывает подключения к базе данных, создает объекты, инициализирует их, а затем умирает через 0,01 секунды после обработки ответа, оставляя следующий запрос для перезагрузки, анализа и повторного запуска в основном того же самого.
Это бессмысленно, и я считаю, что отсутствие пула функциональности / данных / объектов снижает ценность большей части моей работы. Например, я могу писать классы и обнаруживать, что все они повторно инициализируются с каждым запросом — какой смысл мне пытаться разработать осмысленную структуру объекта?
И так: как я могу написать PHP для объединения данных и функциональности?
Ответ №1:
В PHP нет пула решений 1 или постоянного состояния, у него нет состояния приложения, подобного Java, оно более или менее соответствует протоколу без состояния, которым является HTTP. Что вы можете сделать, это:
- Создавайте постоянные подключения к базам данных (т. Е. Они будут использоваться повторно, если вы вызываете их с теми же параметрами, они не будут существовать волшебным образом, но вы можете избежать накладных расходов при фактическом подключении).
- Храните объекты в сеансах, чтобы сохранить вычисляемое состояние (они будут сериализованы и несериализованы при следующем запросе).
- Маршрутизировать работу, требующую значительной, но одноразовой инициализации демоном, работающим независимо от веб-сервера (на ум приходят сервер gearman и рабочие).
- Но, в конце концов, если вашему приложению требуется глобальное состояние, возможно, PHP просто не является правильным решением.
Комментарии:
1. «Но, в конце концов, если вашему приложению требуется глобальное состояние, возможно, PHP просто не является правильным решением» да … то, на что я надеялся, было не так… Но очень информативно, спасибо.
Ответ №2:
PHP вряд ли когда-либо является узким местом. Наши серверы обрабатывают сотни запросов в секунду в пиковые моменты. И это тоже не крошечные запросы. Это кажется нелогичным, но PHP на самом деле очень быстрый. И вы можете использовать APC cache для кэширования предварительно скомпилированных файлов PHP, чтобы сделать это еще быстрее. Затем вы можете использовать MemCache для хранения данных, поэтому любые результаты запроса и подобные им данные можно легко кэшировать, не полагаясь на неоптимальный кэш запросов MySQL.
Комментарии:
1. Итак, я мог бы использовать APC cache для хранения набора функций, которые я обычно загружаю с помощью include… Это немного успокаивает.
2. Вам не нужно активно управлять кэшем APC из PHP. APC может хранить файлы автоматически, поэтому, когда вы включаете их, вы получаете предварительно скомпилированную версию из кэша, вместо обычной текстовой версии с диска.
Ответ №3:
Я разделяю те же опасения, что и вы; но, странно, PHP работает ослепительно быстро. Помимо запросов к базе данных, которые должны кэшироваться сервером, остается только проблема с подключением. Который можно легко объединить.
Моим системам даже приходится анализировать XML-файл размером в несколько кб для получения ответов. Все еще бутылочное горлышко всегда является сервером базы данных.
Однако у этого временного состояния PHP есть хорошая сторона. Проблемный запрос, сбой системы не окажет никакого негативного влияния на следующее соединение. Мне кажется более стабильным.