PHP - это хорошая практика для кэширования MYSQL-запросов в текстовом файле?

Question

Я создаю интернет-магазин и пытаюсь повысить производительность за счет минимизации запросов MYSQL.

Является ли хорошей практикой кэширование запросов mysql через txt-файл, а затем извлекать его вместо запроса?Это то, что я делаю "

1. PHP-класс принимает SQL-запрос в виде строки
2. делает md5 из этого
3. , если это первый разон запускается
4. , затем выполняет запрос к базе данных
5. получает результаты в массиве
6. , сериализует массив и сохраняет его как md5_Of_Query.txt
7. returnлибо unserialize (file_get_contents (md5_of_Query.txt)), либо $ results реального запроса, в зависимости от того, существует ли кеш и является ли он действительным.
8. Класс также проверяет filemtime () файла txt и, если егобольше, чем, скажем, один час, затем повторите запрос и обновите кеш.

Является ли это более эффективным, чем выполнение запросов sql каждый раз? Какие-то проблемы с безопасностью я пропускаю?

Answer 1

Если вы сделаете эталонный тест, затраты на создание уникального хэша и выполнение ввода-вывода на диск будут больше, чем просто выборка с сервера MySQL.

ИМХО, не беспокойтесь о степени. Хорошие мысли, но MySQL уже имеет внутреннюю настройку кэширования и производительности.

Сосредоточьтесь на создании своего приложения, поскольку «преждевременная оптимизация - корень всего зла».

Answer 2

Если вы только запускаете приложение, memcache - гораздо более быстрый способ, чем использование текстовых файлов.

http://memcached.org/

Текстовые файлы сделают свою работу, и шаги, которые вы обрисовали в общих чертах, имеют смысл, но memcache будет быстрее и справится с тяжелой работой за вас.

Answer 3

Если вы хотите добиться кэширования, ориентируясь на будущую масштабируемость, я бы порекомендовал настроить службы RESTful, которые выполняют запросы к базе данных, а затем использовать функции кэширования HTTP вашего веб-сервера для кэширования результатов.Шаги будут выглядеть следующим образом:

1. На исходной странице необходимо выполнить запрос
2. Она генерирует HTTP-запрос GET к URL-адресу службы, передавая параметры в качестве параметров запроса в URL-адресе * 1006.*
3. Сценарий php, расположенный по адресу URL, принимает параметры запроса, проверяет их и добавляет их в запрос MySql
4. Сценарий выполняет запрос к базе данных
5. Сценарийсериализует результат и устанавливает его как вывод
6. Веб-сервер кэширует ответ на запрос и возвращает его для будущих запросов с тем же URL-адресом
7. Исходная страница использует сериализованные результаты службы длясгенерировать HTML

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

Answer 4

Ваш метод выглядит как перемещение проблемы из одного угла в другой.

Введение кеша не улучшает производительность Mysql. Лучше посмотрите, какие запросы на самом деле медленные, а затем оптимизируйте их.

http://dev.mysql.com/doc/refman/5.1/en/slow-query-log.html

Answer 5

Это бессмысленно, вы должны кэшировать результаты .

Время сборки запроса должно быть довольно незначительным.(Если это не так, вы не используете SQL, как предполагается , генерируя вместо этого потоков глупых select s, где умный join решил бы)

Загрузка запроса с диска, очевидно, склонна к замедлению.
(Хотя операционная система может кэшировать дисковый ввод-вывод и затруднять его обнаружение)

Что действительно должноВ любом случае, потратьте время на получение результатов из БД, а затем добавьте их обратно в веб-страницу через шаблон.На вашем месте я бы кешировал на диск стилизованные результаты данного запроса, а когда меня спросили, если кеш не очень старый, я бы напрямую readfile() их.

Answer 6

Два взгляда на 2, сравнение и профилирование . Единственный способ, с помощью которого вы можете сравнивать сколько-нибудь значимое, - это совместное использование 2-х метрик этих линий, использование используемого в настоящее время mysql config, php.ini, httpd.conf, .htaccess, перезаписывающих мод и многих других вещей, которые можно сравнить и профилировать действующие технологии, выполняющие задачу.

Answer 7

Я просто хотел взвесить мои два цента, что, как сказали serialworm и thephpdeveloper, разделяет тот факт, что память / оперативная память намного быстрее, чем любая операция, связанная с дисковым вводом-выводом, с которой вы столкнулись. Бросьте столько памяти, сколько сможете в mysql, и вам не придется иметь дело с управлением кешем, если вам действительно не нужно перейти на кластер, а для этого нужны другие соображения. Memcache дает вам больший контроль над управлением кэшем, и, следовательно, вам нужно больше кодировать.

Я бы начал с создания приложения, затем стресс-тестирования, оптимизации запросов и / или добавления управления кешем по мере необходимости.

Answer 8

Вы настроили MySQL кеш запросов ?