В этой теме хотелось бы осветить (скорее - обсудить) сколько запросов оптимально на одну страницу Битрикса, когда кеш оптимален, когда нет.
Под БД подразумеваем MySQL, под кешированием - запись в файл на диск. Для других БД / способов кеширования могут быть отличия.
Под запросами я конечно имею в виду не прямые запросы, а их обертки - GetList. Применяя по умному фильтр, фактически, вы меняете конечный запрос как хотите. Конечные запросы смотрятся через отладку.
Начну я со своим имхо, который вывел на основе личных наблюдений.
1. На данный момент кеширование (его методы) Битрикса фактически совершенно, и не стоит изобретать своих велосипедов в плане кеширования. Почему - потому что лучше вы сделаете вряд ли, а если есть какие-то моменты, которые вам жмут - так поделитесь с нами, может быть мы добьемся его включения в стандартный продукт.
Кеширование - ключевое "направление" развития продукта, и разработчики уделяют ему значительное внимание. В частности поэтому у вас есть риск на разросшемся проекте получить какой-то минус выбранного вами способа хранения данных, тогда как Битрикс закроет свои дыры и предоставит более мощный инструмент.
2. Оптимальное количество запросов. Нормой лично я считаю 30-50 на страницу, с включенной веб-аналитикой, баннерными местами, и прочими моментами, которые не кешируются (опросы, случайное фото, ...). В идеале их сводить к 10-20 на страницу.
Загонять в кеш 780 запросов, а 20 оставлять - тоже не дело. Больше 100 запросов без кеша - это уже дико, даже для Битрикса. Старайтесь в таком случае думать уже головой. Представьте, что случится с проектом, если посещаемая страница с несколькими сотнями запросов перестанет писать в кеш. Вообще, в идеале добиться максимальных показателей вовсе без кеша.
3. Бойтесь сложных фильтрованных запросов, и не бойтесь линейных. Помните, что линейный запрос (select * from table where id=123) очень быстро выполнится разогретым MySQL, тогда как жирный запрос, с кучей join'ов тупо заблокирует очередь (такие лучше уже кешировать). Грубо говоря, 50 мелких запросов менее вредны, чем один жирный.
4. Объединяйте линейные запросы. Например кучу "select * from table where id=123" проще объединить в "select * from table where id in (123, 34, 56)". Но опять - включайте голову - если их набирается под сотню, то наверное, что-то идет не так.
С другой стороны, иногда лучше разбить жирный запрос на пару менее требовательных.
5. Фильтры (например, сложный фильтр каталога товаров). Их лучше не кешировать, так как даже на очень посещаемом ресурсе к фильтру приебгают не так уж часто. Тогда как различные варианты фильтра раздуют ваш кеш и забьют винт.
В идеале - список и слабые фильтры (например, "все товары за последнюю неделю") - кешировать, а сложные фильтры (например, по автору) - уже нет.
6. Страницы авторизованных пользователей. Хороший пример - некоторые страницы соцсети. В таких разделах будут ходить только авторизованные пользователи, и там можно дать себе раздолье - до 50-80 некешируемых запросов на страницу. Но не пере_барщивать, так как пользователь уже давно привередливый. И если вы наблюдаете тормоза, ходя по соцсети (вопрос чисто комфорта, а не сколько запросов на счетчике), то стоит подумать об оптимизации (прежде всего сервера).
Под БД подразумеваем MySQL, под кешированием - запись в файл на диск. Для других БД / способов кеширования могут быть отличия.
Под запросами я конечно имею в виду не прямые запросы, а их обертки - GetList. Применяя по умному фильтр, фактически, вы меняете конечный запрос как хотите. Конечные запросы смотрятся через отладку.
Начну я со своим имхо, который вывел на основе личных наблюдений.
1. На данный момент кеширование (его методы) Битрикса фактически совершенно, и не стоит изобретать своих велосипедов в плане кеширования. Почему - потому что лучше вы сделаете вряд ли, а если есть какие-то моменты, которые вам жмут - так поделитесь с нами, может быть мы добьемся его включения в стандартный продукт.
Кеширование - ключевое "направление" развития продукта, и разработчики уделяют ему значительное внимание. В частности поэтому у вас есть риск на разросшемся проекте получить какой-то минус выбранного вами способа хранения данных, тогда как Битрикс закроет свои дыры и предоставит более мощный инструмент.
2. Оптимальное количество запросов. Нормой лично я считаю 30-50 на страницу, с включенной веб-аналитикой, баннерными местами, и прочими моментами, которые не кешируются (опросы, случайное фото, ...). В идеале их сводить к 10-20 на страницу.
Загонять в кеш 780 запросов, а 20 оставлять - тоже не дело. Больше 100 запросов без кеша - это уже дико, даже для Битрикса. Старайтесь в таком случае думать уже головой. Представьте, что случится с проектом, если посещаемая страница с несколькими сотнями запросов перестанет писать в кеш. Вообще, в идеале добиться максимальных показателей вовсе без кеша.
3. Бойтесь сложных фильтрованных запросов, и не бойтесь линейных. Помните, что линейный запрос (select * from table where id=123) очень быстро выполнится разогретым MySQL, тогда как жирный запрос, с кучей join'ов тупо заблокирует очередь (такие лучше уже кешировать). Грубо говоря, 50 мелких запросов менее вредны, чем один жирный.
4. Объединяйте линейные запросы. Например кучу "select * from table where id=123" проще объединить в "select * from table where id in (123, 34, 56)". Но опять - включайте голову - если их набирается под сотню, то наверное, что-то идет не так.
С другой стороны, иногда лучше разбить жирный запрос на пару менее требовательных.
5. Фильтры (например, сложный фильтр каталога товаров). Их лучше не кешировать, так как даже на очень посещаемом ресурсе к фильтру приебгают не так уж часто. Тогда как различные варианты фильтра раздуют ваш кеш и забьют винт.
В идеале - список и слабые фильтры (например, "все товары за последнюю неделю") - кешировать, а сложные фильтры (например, по автору) - уже нет.
6. Страницы авторизованных пользователей. Хороший пример - некоторые страницы соцсети. В таких разделах будут ходить только авторизованные пользователи, и там можно дать себе раздолье - до 50-80 некешируемых запросов на страницу. Но не пере_барщивать, так как пользователь уже давно привередливый. И если вы наблюдаете тормоза, ходя по соцсети (вопрос чисто комфорта, а не сколько запросов на счетчике), то стоит подумать об оптимизации (прежде всего сервера).
Изменено: Долганин Антон - 07.03.2011 20:55:24
. Кеш весит 15Mb и обрабатывается почти 5 минут.
и вносить не надо, и используется в кеше. Как-то взаимоисключающе звучит.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».
