- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Как удалить плохие SEO-ссылки и очистить ссылочную массу сайта
Применяем отклонение ссылок
Сервис Rookee
Если место на сервере позволяет - можно тупо сделать файловый кэш за 2 минуты
да скиньте пжста.
С другой стороны я попробовал сохранить страницу в html, которая формируется на основе БД. То есть сделал статическую ("сохранить как" в браузере).
Результат в google speed test даже хуже почему-то ) вероятно, потому что в папку все сохранилось отдельную, но тем не менее..
можно, лично я не вижу в этом острой необходимости, проблема уровня NOTICE)
ясно ) а как поправить?
Если место на сервере позволяет - можно тупо сделать файловый кэш за 2 минуты
Сделать кеш как таковой хоть на файлах хоть в памяти это не проблема. Самый главный вопрос при кешировании это определение инвалидация данных. Это хорошо когда контент практически статический, но когда есть динамика, то простое кеширование уже может потерять свою эффективность.
Как понимаю у ТС есть и достаточно динамические данные. Тут может потребоваться и кеширование не всей страницы, а страницы по частям. реализовать можно по разному, возможно более менее "простое" решение - подгрузка динамичных блоков на ajax - у которых будет свой кеш (отдельный от всей страницы). Который сбрасывать, на пример, не только по таймауту, но и при поступлении новых данных - тут уже зависит больше от деталей проекта.
Но кроме кеширования, конечно и с БД надо явно поработать. И тут может быть стоит задуматься и о денормализации, или периодической агрегации данных в отдельные таблицы (например по расписанию) - все сильно зависит от деталей проекта. Возможно, полезным будет использование представлений
Так же хорошим бы шагом было бы (но тут зависит от возможностей хостинга) было бы использование для статистических данных более подходящей СУБД. в частности ClickHouse
Ну и да, лучше озадачиться и перейти на php 8.* Не обязательно, как тут выше писали это про ООП, можно и в процедурном стиле. Это даст и увеличенное быстродействие и добавит безопасности.
И тут может быть стоит задуматься и о денормализации,
Ты точно это имел ввиду? Не наоборот?
Ты точно это имел ввиду? Не наоборот?
Нет. Именно "де". :)
При повышении быстродействия (на отдачу) это вполне себе вариант. Возможно, конечно, на этом проекте это не нужно - все же 5 гигов по современным меркам это не много.
Нет. Именно "де". :)
Да, перечитал еще раз, понял, что ты имеешь ввиду. Но этой агрегацией ты упрощаешь запросы, то есть ходишь за данными в одну таблицу, но начинаешь гонять по сети лишние данные и хранить дубли данных. Так себе вариант
Да, перечитал еще раз, понял, что ты имеешь ввиду. Но этой агрегацией ты упрощаешь запросы, то есть ходишь за данными в одну таблицу, но начинаешь гонять по сети лишние данные и хранить дубли данных. Так себе вариант
В смысле лишние данные?
Ясно дело к с любому решением надо обдуманно подходить. Расставляем приоритеты для каждого выполнения скриптов (в т.ч. хит посетителя). В проблеме вынесенной ТС ом на обсуждение проблема именно с отдачей. Данные будут все те же самые хоть от нормализованной БД хоть нет.
Т.е. разница будет только в момент записи, но, вряд ли запись идет на хите посетителя и сразу тысячами записей. Даже на страницах (если таковые будут) где позволительно работать с "нормализованным" - опять же там не будет лишних данных. Конечно если не писать в выборках * вместо перечня необходимых полей... Но использование звездочек в селектах в общем случае это зло, за которое бьют по рукам. ИМХО.