Кэширование страниц

12
Р
На сайте с 10.10.2011
Offline
63
#11

Чем не устраивает Nginx? Программные среды логично использовать по назначению.

Разрешаю пользователям высокого мнения о себе и своих способностях минусовать мою репутацию )
nomarketing
На сайте с 23.09.2009
Offline
149
#12
Романо:
Чем не устраивает Nginx? Программные среды логично использовать по назначению.

Сайт хостится на обычном хосте - с еще несколькими. / на linux

Дело в том, что посещаемость сайта, пока что средняя, из за того что идет большая нагрузка на бд при не очень большом количестве трафика, трафика могло бы быть и больше, но падает бд, в итоге, щас оптимизирую сайт как могу, потом думаю перейти на vps

Р
На сайте с 10.10.2011
Offline
63
#13

Лучше сразу переходите на VPS, в России есть тарифы от $5. Я подобным занимался, кэшированием на PHP, а потом всем мой наработки были перечеркнуты простым обновлением серверного ПО.

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

nomarketing
На сайте с 23.09.2009
Offline
149
#14
Романо:
Лучше сразу переходите на VPS, в России есть тарифы от $5. Я подобным занимался, кэшированием на PHP, а потом всем мой наработки были перечеркнуты простым обновлением серверного ПО.

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

Вообщем решил проверить заголовки, вроде нет там nginx.

Так что придется пока что PHP, обходится, но вопрос не в этом !

Вопрос в том стоит ли кэшировать или не стоит - посты ?

И еще что нужно учитывать - на счет ботов ? - а то вдруг что то пойдет не так, боты сьедят то что не нужно и потом будет билебирда и сайт будет трясти в выдаче потому что менятся все будет ...

На счет ngnix - спасибо - учту при переходе на vps - почитаю что да как устанавливать и есть ли там такая возможность или уже есть встренный.. - посмотрел у конкурентов у половины стоит ngnix..

Просто я в этой области не силен, вот приходится изучать все аспекты и все учитывать.. так как если переходить на VPS то это целое дело :)

siv1987
На сайте с 02.04.2009
Offline
427
#15
nomarketing:
1- около 80% не динамического контента выводится юзерам (это и есть те самые посты)

Что вы подразумеваете под "не динамический контент" (я могу понять динамические страницы)?

nomarketing:
т.е лежат как устаревшие но тянут трафик. (то зачем их каждый раз дергать ?)

А что плохого в том, чтобы их дергать?

nomarketing:
так как все они тянутся с бд

nomarketing, в первую очередь вы должны понять одну вещь, нагрузка на бд создается не потому что это бд, или не потому что априори что-то дергается из бд. Вам сначала нужно выяснить в чем заключается нагрузка, и действительно и на сколько она выиграет если перенести посты на диске. Если это будет экономия на спичках, стоит ли оно вообще свеч? Анализируйте запросы, посмотрите план выполнения, можно ли их оптимизировать, действительно ли проблема в них. Каким образом вы собираетесь кешировать посты? У каждой темы есть свои посты, как будете делать сортировку постов с кешем на диске, и прочее операции которые выполняет бд? Имхо, вам сначала нужно аудит части, предоставить какие-то данные или результаты - чтобы вам могли стоит или не стоит. Пока же с таким подходом - не стоит, имхо.

PS

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

C
На сайте с 20.09.2007
Offline
115
#16
идет большая нагрузка на бд

nomarketing, изучите свой сайт и пометьте какое "кэширование" там необходимо.

Если вкратце - кэширование (оптимизация) может быть:

1. На стороне пользователя. Т.е. браузером кэшируются скрипты, стили, изображения.

2. На уровне сервера (и браузеру отдается правильный заголовок - LastModified) - страницы разделов (если они не часто меняются) и т.п. При этом - по-мимо заголовков вы из отдаете мгновенно (помня - что если даже кэш храните в файлах - то лучше разбить на папки).

3. Отдельные куски конкретной страницы - т.е те куски, которые не имеет смысл постоянно запрашивать, ибо они не так часто обновляются (хидер, футер).

4. Оптимизируйте БД. Как минимум - создайте индексы. Они бывают разные. Уникальные (как, например, id, полный ЧПУ и т.п.), так и просто выстроенные по порядку. В этом случае выборка будет очень быстрая. Если сайт реально огромный - то индексы также строите по 1-5 первых символов.

5. Дальше все зависит от частоты правок (исправлений) и количестве пользователей. Если все критично - убираете какой-нить update на раз в час. Не так заметно будет.

p.s. Ну и просто пройдитесь по БД - оптимизируйте ее.

-=[ Обогнать Дед Мороза! ]=- (http://richwap.ru/?rid=6856)
nomarketing
На сайте с 23.09.2009
Offline
149
#17
siv1987:
Что вы подразумеваете под "не динамический контент" (я могу понять динамические страницы)?


А что плохого в том, чтобы их дергать?


nomarketing, в первую очередь вы должны понять одну вещь, нагрузка на бд создается не потому что это бд, или не потому что априори что-то дергается из бд. Вам сначала нужно выяснить в чем заключается нагрузка, и действительно и на сколько она выиграет если перенести посты на диске. Если это будет экономия на спичках, стоит ли оно вообще свеч? Анализируйте запросы, посмотрите план выполнения, можно ли их оптимизировать, действительно ли проблема в них. Каким образом вы собираетесь кешировать посты? У каждой темы есть свои посты, как будете делать сортировку постов с кешем на диске, и прочее операции которые выполняет бд? Имхо, вам сначала нужно аудит части, предоставить какие-то данные или результаты - чтобы вам могли стоит или не стоит. Пока же с таким подходом - не стоит, имхо.

PS
Если под "посты" имеется ввиду кешировать сами страницы постов, чтобы это небыло, то конечно это будет существенный прирост в производительность по отношению к динамически сгенерируемой страницы.

1.К примеру мы имеем 90к постов

2.80к из них просто генерируются (не изменяются пользователями, ничего, просто генерируются с бд)

Я хотел просто эти 80% - закешировать, т.е выше приведенным кодом, просто сделать кеш на сервере в папке, и все, т.е они будут отдаватся с кеша.? (Или я не прав?) тем самым экономить на запросах к бд, т.е зачем тянут старые посты с бд, если они как бы статичны и не изменимы ? но них есть трафик.

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

---------- Добавлено 17.05.2014 в 10:25 ----------

censored!:
nomarketing, изучите свой сайт и пометьте какое "кэширование" там необходимо.
Если вкратце - кэширование (оптимизация) может быть:
1. На стороне пользователя. Т.е. браузером кэшируются скрипты, стили, изображения.
2. На уровне сервера (и браузеру отдается правильный заголовок - LastModified) - страницы разделов (если они не часто меняются) и т.п. При этом - по-мимо заголовков вы из отдаете мгновенно (помня - что если даже кэш храните в файлах - то лучше разбить на папки).
3. Отдельные куски конкретной страницы - т.е те куски, которые не имеет смысл постоянно запрашивать, ибо они не так часто обновляются (хидер, футер).
4. Оптимизируйте БД. Как минимум - создайте индексы. Они бывают разные. Уникальные (как, например, id, полный ЧПУ и т.п.), так и просто выстроенные по порядку. В этом случае выборка будет очень быстрая. Если сайт реально огромный - то индексы также строите по 1-5 первых символов.
5. Дальше все зависит от частоты правок (исправлений) и количестве пользователей. Если все критично - убираете какой-нить update на раз в час. Не так заметно будет.
p.s. Ну и просто пройдитесь по БД - оптимизируйте ее.

Ну исходят из того что я изучил, за два дня, я составил более мение план оптимизации..

1.GZIP

2.CACHE - (Хидер - Футер - и пока еще не знаю старые посты..)

3.СSS COMPRESSION

4.JS COMPRESSION

5.MYSQL QUERIES

Ну пока что все, еще буду изучать - на счет ngnix+php+apache

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

Просто что бы дальше идти, в том плане, переход на vps - потом на dedicated ну вообщем по нарастающей.. нужно хотя бы начать с малого это делать..

И еще вопрос -

1.Лучше делать кэширование на стороне клиента или на стороне сервера - какие приимущества у того или инного метода ? (а то что то я не могу найти)

nomarketing
На сайте с 23.09.2009
Offline
149
#18

Вообщем не много все странно, может я плохо искал..

Но, все статьи которые я находил, идут все как то поверхностно...

К примеру, по использованию мною приведенного примера, простого кэша..

Я не нашел ниодной статьи где бы был приведен код пхп кэша, его откладка, и вся функциональность,

К примеру что можно делать что не желательно делать, что не нужно делать...

Допустим мой выше приведенный кусок кода,

Мение простых примеров я не нашел, в том плане,

1.Использовать MD5

2.Использовать подпаки - и почему ?

3.Сверять даты - (ну допустим контент обновился сверяется дата модификации и заменятеся - если что то было изменено)

4.Отслеживаех и отдаем правильные хидеры

ПОЧЕМУ ЭТОГО НЕТ НИГДЕ ? )

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

Почему я так подхожу к этому делу ?

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

На данный момент задача модифицировать скрипт,


<?php
// мониторим скорость выполнения
$start = microtime(true);
// задаем время жизни кэша в секундах
$cacheTime = 60;
// Название скрипта
$fileName = strrchr($_SERVER***91;"SCRIPT_NAME"***93;, "/");
// удаляем все слеши
$fileName = trim($fileName, '/\\');
// путь для хранения кеша
$cacheFile = "cache/$fileName.cache";
// если кэш существует
if (file_exists($cacheFile)) {
// проверяем актуальность кеша
if ((time() - $cacheTime) < filemtime($cacheFile)) {
// показываем данные из кеша
echo file_get_contents($cacheFile);
// мониторим скорость работы
echo 'Время выполнения скрипта: '.(microtime(true) - $start).' сек.';
exit; // Завершаем скрипт
}
}
// открываем буфер
ob_start();
?>

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Test cache</title>
<meta http-equiv="content-type"content="text/html; charset=utf-8" />
</head>
<body>
<?php
// для теста
$arrayTest = array();
for ($i=0; $i < 10000; $i++){
$arrayTest***91;$i***93; = $i;
}
foreach($arrayTest as $i){
echo $i;
}
?>
</body>
</html>

<?php
// Открываем файл для записи
$file = fopen($cacheFile, 'w');
// сохраняем все что есть в буфере вфайл кеша
fwrite($file, ob_get_contents());
// закрываем файл
fclose($file);
// выводим страницу
ob_end_flush();
// мониторим скорость работы
echo 'Время выполнения скрипта: '.(microtime(true) - $start).' сек.';
?>

1.Сделать MD5

2.cache/Сделать подпаки

3.Сверять даты .. (сверят дату, и заменят, обновлять кэш) - сдесь не знаю как пока это сделать

4.Отдавать правильные заголовки (сдесь пока тоже не знаю как сделать) - но думаю заголовки можно смотреть в http header плагине, ну или софте анализер..

Т.е мне нужно четко все отладить проверить и уже потом запускать..

Ну кто поможет чем сможет :)

zhitov
На сайте с 30.01.2005
Offline
220
#19
nomarketing:
ПОЧЕМУ ЭТОГО НЕТ НИГДЕ ?

Потому что это решает разработчик, в зависимости от задач.

nomarketing:
1.Сделать MD5

2.cache/Сделать подпаки

3.Сверять даты .. (сверят дату, и заменят, обновлять кэш) - сдесь не знаю как пока это сделать

4.Отдавать правильные заголовки (сдесь пока тоже не знаю как сделать) - но думаю заголовки можно смотреть в http header плагине, ну или софте анализер..

1. Самый простой способ.

2. Не нужно, т.к. п.1 все решает.

3. С чем сверять? Проще сбрасывать кэш конкретной страницы, если она изменилась.

4. Не помешает.

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

В вашем случае: пользователь обновил объявление -> записываем в БД и сбрасываем кэш этой, конкретной страницы.

Строительные калькуляторы (http://www.zhitov.ru/)
nomarketing
На сайте с 23.09.2009
Offline
149
#20
zhitov:
Потому что это решает разработчик, в зависимости от задач.


1. Самый простой способ.
2. Не нужно, т.к. п.1 все решает.
3. С чем сверять? Проще сбрасывать кэш конкретной страницы, если она изменилась.
4. Не помешает.

Я не задаю время жизни кэша в секундах. Сбрасываю кэш по мере необходимости. Для всего сайта, отдельной страницы или их группы.
В вашем случае: пользователь обновил объявление -> записываем в БД и сбрасываем кэш этой, конкретной страницы.
3. С чем сверять? Проще сбрасывать кэш конкретной страницы, если она изменилась.

И то верно, можно сделать так, пользователь модифицирует страницу, и тем же скриптом, будет убивать кэш, т.е он нажимает кнопку сохранить, выполняется удаление кэша, и обновляется бд.. как я понял.

На счет 4 пункта

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

Просто не хочу что бы гуглбот ел старые печеньки вместо новых.. или еще хуже ел и те и другие.. в итоге возникнет много проблем в плане сео.. потом..

Щас пока хочу понять что нунжо для правильной работы хидеров что отдавать и за чем следить

Смотрю сдесь разработчиков тьма, 😂 (п.с - разработчиков дорвеев 😂)

12

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