Методы кэширования объектов PHP в файл?

Re: Есть ли другой метод сохранения в файл, который я забыл?

Это имеет ограниченную полезность, но если у вас есть особенно мощный запрос к базе данных, вы можете записать сериализованный объект обратно в индексированную таблицу базы данных. У вас все равно будут накладные расходы на запрос базы данных, но это будет простой выбор, в отличие от сложного запроса.

Re: Является ли сохранение файла безопасным? и дешевая учетная запись общего хостинга)

Печальный факт заключается в том, что дешевый общий хостинг небезопасен. Насколько вы доверяете 100 500 или 1000 другим людям, которые имеют доступ к вашему серверу? По историческим и (по иронии судьбы) соображениям безопасности в средах общего хостинга PHP/Apache работает как непривилегированный пользователь (с PHP, работающим как модуль Apache). Рациональная безопасность здесь заключается в том, что если мир, с которым сталкивается процесс apache, будет скомпрометирован, у эксплуататоров будет доступ только к непривилегированной учетной записи, которая не может испортить важные системные файлы.

Плохая часть в том, что это означает, что всякий раз, когда вы пишете для файла, использующего PHP, владельцем этого файла является тот же непривилегированный пользователь Apache. Это справедливо для каждого пользователя в системе, что означает, что у любого есть доступ на чтение и запись к файлам. Теоретические хакеры в описанном выше сценарии также имели бы доступ к файлам.

В PHP также существует постоянная плохая практика предоставления разрешений каталога 777 для каталогов и файлов, чтобы позволить непривилегированному пользователю apache записывать файлы, а затем оставлять каталог или файл в этом государство. Это дает любому в системе доступ на чтение/запись.

Наконец, вы можете подумать, что неизвестность спасает вас. "Они никак не могут узнать, где находятся мои секретные файлы кэша", но вы ошибаетесь. Общий хостинг настраивает пользователей в одной группе, и большинство масок файлов по умолчанию предоставляют пользователям вашей группы разрешение на чтение создаваемых вами файлов. Как-нибудь подключитесь по SSH к своей учетной записи общего хостинга, перейдите в каталог, и обычно вы можете начать просматривать файлы других пользователей на система. Это можно использовать для поиска файлов, доступных для записи.

Решения не из приятных. Некоторые хосты будут предлагать оболочку CGI, которая позволяет запускать PHP как CGI. Преимущество здесь в том, что PHP будет работать от имени владельца скрипта, а это значит, что он будет работать от вашего имени, а не от имени непривилегированного пользователя. Проблема предотвращена! Новая Проблема! Традиционная CGI медленная, как патока в феврале.

Есть FastCGI, но FastCGI привередлив и требует постоянной настройки. Не многие общие хостинги предлагают это. Если вы найдете тот, кто это делает, скорее всего, у них будет включен APC и, возможно, даже сможет предоставить механизм для memcached.

У меня была похожая проблема, и поэтому я написал решение - кэш памяти, написанный на PHP. Для этого требуется только сборка PHP для поддержки сокетов. Кроме того, это чисто php-решение, и оно должно отлично работать на общем хостинге.

Http://code.google.com/p/php-object-cache/

Что я всегда делаю, если мне нужно уметь писать, так это убедиться, что я не пишу нигде, где у меня есть PHP-код. Обычно моя структура каталогов выглядит примерно так (она варьируется в зависимости от проекта, но это общая идея):

project/
  app/
  html/
    index.php
    data/
  cache/

app не доступен для записи веб-сервером (как и index.php, предпочтительно). cache доступен для записи и используется для кэширования таких объектов, как проанализированные шаблоны и объекты. data возможно, доступно для записи, в зависимости от необходимости. То есть, если пользователи загружают данные, это переходит в данные.

Веб-сервер получает указание на project/html, и любой удобный метод используется для настройки index.php в качестве сценария для запуска для каждой страницы в проекте. Вы можете использовать mod_rewrite в Apache, или согласование контента (мое предпочтение, но часто это невозможно), или любой другой метод, который вам нравится.

Весь ваш реальный код находится в app, который не доступен напрямую веб-серверу, но должен быть добавлен в путь PHP.

Это довольно хорошо работало для меня в течение нескольких проекты. Я даже смог заставить, например, Викимедиа работать с измененной версией этой структуры.

О... и я бы использовал сериализацию()/несериализацию() для кэширования, хотя генерация PHP-кода имеет определенную привлекательность. Все известные мне механизмы создания шаблонов генерируют PHP-код для выполнения, что делает пост-анализ очень быстрым.

Если у вас есть доступ к кэшу запросов к базе данных (т.Е. MySQL) вы могли бы пойти с сериализацией ваших объектов и сохранением их в БД. База данных позаботится о хранении результатов запроса в памяти, так что это должно быть довольно быстро.

Вы не объясняете - почему - вы пытаетесь кэшировать объекты. Вы пытаетесь ускорить медленный запрос к базе данных, обойти дорогостоящее создание экземпляра объекта, избежать повторного создания сложной страницы, поддерживать состояние приложения или вы просто навязчиво храните объекты на случай долгой зимы?

Лучшее решение, учитывая чудовищные ограничения большинства недорогих общих хостингов, будет зависеть от того, чего вы пытаетесь достичь. Иду на дно бочки общий хостинг означает, что вы должны согласиться с тем, что вы не будете работать с лучшими инструментами. Цифры трудно поддаются количественной оценке, но существует компромисс между стоимостью хостинга, производительностью сайта и временем разработки (т. Е. Быстро, дешево или просто).

Теоретически возможно хранить объекты в сеансах. Это может помочь вам решить проблему с отключением записи файлов. Кроме того, вы можете сохранить сеанс в таблице, поддерживаемой памятью mysql, для ускорения запроса.

В некоторых местах размещения может быть скомпилирован APC.. Это позволит вам хранить объекты в памяти.