Какой самый простой способ добавить кеш страницам (php)

N8
На сайте с 26.11.2008
Offline
141
#71
Если место на сервере позволяет - можно тупо сделать файловый кэш за 2 минуты
На одном проекте так сделал и забыл
Если нужно - скину код в личку
A
На сайте с 12.10.2011
Offline
220
#72
naf83 #:
Если место на сервере позволяет - можно тупо сделать файловый кэш за 2 минуты
На одном проекте так сделал и забыл
Если нужно - скину код в личку

да скиньте пжста.


С другой стороны я попробовал сохранить страницу в html, которая формируется на основе БД. То есть сделал статическую ("сохранить как" в браузере).

Результат в google speed test даже хуже почему-то ) вероятно, потому что в папку все сохранилось отдельную, но тем не менее..

A
На сайте с 12.10.2011
Offline
220
#73
master32 #:

можно, лично я не вижу в этом острой необходимости, проблема уровня NOTICE)

ясно ) а как поправить?

I1
На сайте с 31.07.2023
Offline
41
#74
Да индексов там нет 100% или они кривые. 

Автор, скинь фото c explain по тормозящим запросам. 
Александр Воробьев
На сайте с 03.02.2020
Offline
56
#75
naf83 #:
Если место на сервере позволяет - можно тупо сделать файловый кэш за 2 минуты

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

Как понимаю у ТС есть и достаточно динамические данные. Тут может потребоваться и кеширование не всей страницы, а страницы по частям. реализовать можно по разному, возможно более менее "простое" решение - подгрузка динамичных блоков на ajax - у которых будет свой кеш (отдельный от всей страницы). Который сбрасывать, на пример, не только по таймауту, но и при поступлении новых данных - тут уже зависит больше от деталей проекта.

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

Так же хорошим бы шагом было бы (но тут зависит от возможностей хостинга) было бы использование для статистических данных более подходящей СУБД. в частности ClickHouse

Ну и да,  лучше озадачиться и перейти на php 8.*  Не обязательно, как тут выше писали это про ООП, можно и в процедурном стиле. Это даст и увеличенное быстродействие и добавит безопасности.

Что такое ClickHouse | ClickHouse Docs
Что такое ClickHouse | ClickHouse Docs
  • clickhouse.com
ClickHouse — столбцовая система управления базами данных (СУБД) для онлайн-обработки аналитических запросов (OLAP). В обычной, «строковой» СУБД, данные хранятся в таком порядке: Строка WatchID JavaEnable Title GoodEvent EventTime То есть, значения, относящиеся к одной строке, физически хранятся рядом. Примеры строковых СУБД: MySQL, PostgreSQL...
S3
На сайте с 29.03.2012
Offline
368
#76
Александр Воробьев #:
И тут может быть стоит задуматься и о денормализации,

Ты точно это имел ввиду? Не наоборот?

SA
На сайте с 12.04.2024
Offline
52
#77
Для начала нужно очистить таблицы с логами если они есть, потом снова посмотреть
Александр Воробьев
На сайте с 03.02.2020
Offline
56
#78
Sly32 #:

Ты точно это имел ввиду? Не наоборот?

Нет. Именно "де". :)

При повышении быстродействия (на отдачу) это вполне себе вариант. Возможно, конечно, на этом проекте это не нужно  - все же 5 гигов по современным меркам это не много. 

S3
На сайте с 29.03.2012
Offline
368
#79
Александр Воробьев #:
Нет. Именно "де". :)

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

Александр Воробьев
На сайте с 03.02.2020
Offline
56
#80
Sly32 #:

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

В смысле лишние данные? 

Ясно дело к с любому решением надо обдуманно подходить. Расставляем приоритеты для каждого выполнения скриптов (в т.ч. хит посетителя). В проблеме вынесенной ТС ом на обсуждение проблема именно с отдачей. Данные будут все те же самые хоть от нормализованной БД хоть нет.  

Т.е. разница будет только в момент записи, но, вряд  ли запись идет на хите посетителя и сразу тысячами записей.  Даже на страницах (если таковые будут) где позволительно работать с "нормализованным" - опять же там не будет лишних данных. Конечно если не писать в выборках * вместо перечня необходимых полей... Но использование звездочек в селектах в общем случае это зло, за которое бьют по рукам. ИМХО.

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий