На одном своем проекте обнаружил следующую проблему. Время генерации страниц было от 1.3 до 2.4 (причем никаких тяжелых компонентов нет.) Что бы убедиться, что это не мои кривые руки не компоненты, - создал пустой шаблон.
Обнаружил, что даже на пустом шаблоне, 90% нагрузки идет на Эпилог-Ядро
Нагуглил на форумах битрикса подобные вопросы. В частности, эта тема мне помогла. В итоге, удалил я модуль bitrixcloud, и мои страницы теперь отдаются веселей - 0.085 сек.
Щукин Олег написал: Кстати, для каждой области шаблона (WA, PA, ...) формируется отдельный кеш - посмотрите генерацию salt в ManagedCache::getCompCachePath(). Т.е. если меню есть в header'e и в footer'e, то, в случае с файловым кешем, в cache/bitrix/menu/ будут встречаться дублирующиеся файлы в двух подкаталогах (06f и 345).
Мальцев Денис, ну, видимо, чтоб если компонент зависит от $BX_STATE, но программист забыл добавить его в ключ кеша, то кеши не перехлестнутся. Думаю, что этот изврат для совместимости с какими-то компонентами. Я другого объяснения не вижу.
P.S.: Если кому интересно, наглядный список состояний $BX_STATE (где они могут встречаться) можно найти в файле debug_info.php
Задача банальная, но встречается довольно часто. Есть сайты(клиенты), которые очень дотошно относятся к обновлению числа показов (SHOW_COUNTER), а как известно, при кешировании компонета количество показов далеко от реальных данных.
Задачу решили следующим образом: 1. Для списка компонентов - дергаем скрипт - который возвращает массив SHOW_COUNTER. После получения данного массива - при помощи jQuery проставляем для каждого элемента соотв. значение. 2. В детальном просмотре - аналогично дергаем скрипт, только уже получаем одно значение SHOW_COUNTER для текущего элемента. И так же добавляем его при помощи jQuery 3. Еще в детальном просмотре дергаем скрип - который увеличивает значение SHOW_COUNTER
Таким образом, получаем кешированные компоненты - с актуальными для нас данными.
Компонент как-раз стандартный. news.detail Сайт новостной - с большим трафиком. Так вот, к примеру при онлайне в 900 - количество просмотров было на уровне 30.. Сейчас же - количество просмотров соотв. данным гугл аналитики (+- пару едениц)
Понятно, что талантливый человек, должен быть талантлив во всем. Но в данном контексте, я считаю что ты либо хороший верстальщик, либо хороший программист (одни навыки прокачиваются в ущерб других) Бывают конечно исключения....
Как по мне, то в компании должен быть: - отдельно человек, который занимается качественной версткой, - отдельно человек, который занимается качественным кодом.
Просто у меня в голове были более сложные проекты =) Где стандартный функционал и модули с маркетплейса решают в лучшем случае половину задач.
Ну тут да конечно, программисты должны быть - они и решают эти задачи. Да и тут не дать одному человеку делать иначе сроки растянутся... Но такие проекты редкость (по крайней у меня). Да и опять же вариант наличия универсала "интегратора" - который 1 следит за всем проектом раздает задачи и сам все интегрирует (части верстки, модули и т.п.).
Были бы сложные проекты на потоке, была бы, конечно, другая идеология... А так я еще не пощупал за 5 лет, чтото по настоящему крутое.
Считаю что программисты должны разбираться в JS и верстке, но для того чтобы легко интегрировать, если что внести какие-то небольшие правки и т. п. Умение сделать все с нуля им не обязательно. Как правильно сказано - человек-оркестр во всем одинаково хорошо и глубоко не может разделяться. Если это не маленькая компания, то разделение нужно обязательно. Верстальщик должен знать все нюансы верстки, все нюансы поддержки браузеров (а тут меняется все каждый раз), тонкости и т. п. А программист должен не отставать от своего "паравоза" и быть на передовом острее технологий. Вопрос остается открытым, кто должен владеть JS в хорошей степени. Это уже как сложится. Порой сложные скрипты пишется такие, что серверный код отдыхает. С другой стороны html верстальщик, который не знает js - это странный верстальщик, который просто отстал от жизни.
Ранее считал, что лучше написать свой компонент, нежели править стандартный. В коде только то что тебе нужно....
Но, сейчас кардинально поменял свое мнение. Один проект заставил вести разработку в очень сжатые сроки. Пошел по пути модификации стандартных компонентов, и о чудо! Скорость разработки возросла в разы, причем качество не страдает (а скорее наоборот...).
Видимо, пока сам к этому не придешь, никакие советы и рекомендации не воспринимаются.
Все мы через это проходим, я изначально стараюсь делать все на стандартных, а вот где начинаются тормоза, там обрубаю все лишнее, иначе бывало, всплывали косяки, когда сайт разрастается до нескольки штук с коллективным пользованием, с проверкой прав и т.д. и т.п. Еще и потому что, после того как отдашь сайт клиенту еще несколько раз там половину переделаешь, то так, то сяк, пока все понравится, обкатается, замучаешься на своих компонентах добавлять параметры, обрабатывать их и т.п. Выросла посещалка, начало что-то тормозить, вот, пожалуйста, делаем то-то и все будет ок, иначе изначально клиент может быть не готов пожертвовать ради скорости в каталоге кнопочками для редактирования, изменением настроек, сортировок и прочей красотой, нужно что бы он уже был готов к этому, потом он сам напишет, с вопросом, как и что нужно сделать, чтобы это работало быстрее, я будет на все готов
Хм, ну, это предположение как можно сделать, в моей практике пока небыло два iblock.element.add.form на одной странице
Если в компоненте идет проверка
if (!$APPLICATION->CaptchaCheckCode($_REQUEST["captcha_word"], $_REQUEST["captcha_sid"]))
то можно было бы перед первой формой обнулить эти переменные (например, записать их в другую глобальную переменную), а потом после выполнения первой формы - вернуть значения назад, чтобы они применялись для второй формы.
Надоели тормоза на одном из проектов. Килограммовые запросы, которые выполняются в результате использования api - просто ужас. Переписали пару компонентов через ХРАНИМКИ в SQL - сайт сразу задышал. Время генерации компонентов в среднем сократилось с 0.1(0.5...) до 0.005...
Да - не универсально Да - не соответствует стандартам Битрикс НО работает БЫСТРО.
Расширенный опрос-голосование с картинками и прочими примочками.
На днях завершил задачу, в которой нужно было дополнить стандартный опрос дополнительными фишками.
А именно, привязка варианта ответа к элементу инфоблока, с последующим отображением в формах голосования и результатах.
Пошел по пути использования пользовательских свойств, переписал интерфейс в админке (Теперь и вопрос и варианты ответов и привязки - все редактируется в одной форме, только разнес по закладкам).
А в компонентах, при помощи result_modifier.php - собственно и дополняем наш опрос новыми фишками. Таким способом сможете, к примеру, повесить видео на каждый вариант ответа, или устанавливать разъяснения к ответам, дополнять их ссылками и т.д. Причем все это не только к вариантам ответов, но и вариантам вопросов.
Описал лишь алгоритм решения моей задачи. Надеюсь мой пост будет кому-то полезен.
Надоели тормоза на одном из проектов. Килограммовые запросы, которые выполняются в результате использования api - просто ужас. Переписали пару компонентов через ХРАНИМКИ в SQL - сайт сразу задышал. Время генерации компонентов в среднем сократилось с 0.1(0.5...) до 0.005...
Да - не универсально Да - не соответствует стандартам Битрикс НО работает БЫСТРО.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».