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

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

На сегодняшний день одна из лучших возможностей ASPNET, IMO.

С тех пор я врезался в Windows для Linux, и поэтому PHP, Python и Ruby для webdev. Я использую PHP больше всего, потому что я создаю несколько проектов с открытым исходным кодом, все используют PHP.

Излишне говорить, что я исследовал, что PHP может предложить с точки зрения кэширования данных-объектов. До сих пор я играл с:

Сериализация файла (довольно медленный/дорогостоящий процесс)
Запись данных в файл как JSON/XML/plaintext/etc (еще медленнее для операций чтения)
Запись данных в файл как чистый PHP (самый быстрый, но довольно запутанный метод записи)

Теперь я должен подчеркнуть, что я ищу решение, которое не полагается на стороннее приложение (например, memcached), поскольку приложения установлены во всех сценариях, большинство из которых не имеют прав на установку ( например: дешевая учетная запись общедоступного хостинга).

Итак, вернемся к тому, что я делаю сейчас, продолжает защищать файл? Rule 1 на сервере производственного сервера всегда было отключено запись файлов, но я действительно ничего не вижу PHP может кэшировать, если он не может писать. Есть ли советы и/или трюки для повышения безопасности?

Есть ли другой метод persist-to-file, который я забываю?

Есть ли лучшие методы кеширования в "ограниченных" средах?

Ответ 1

Сериализация вполне безопасна и широко используется. Однако есть альтернатива, и это необходимо для кэширования в память. Проверьте memcached и APC, они оба свободный и высокопроизводительный. Эта статья о различных методах кеширования в PHP также может представлять интерес.

Ответ 2

Re: Есть ли еще один метод persist-to-file, который я забыл?

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

Re: Сохраняется ли файл в безопасности? и дешевый общий хостинг-аккаунт)

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

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

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

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

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

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

Ответ 3

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

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

Ответ 4

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

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

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

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

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

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

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

Ответ 5

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

Ответ 6

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

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

Ответ 7

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

Ответ 8

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