Система управления сайтом "Twilight CMS" имеет сложную многоуровневую схему кэширования данных, которая предназначена для повышения скорости работы и увеличения количества обрабатываемых запросов в единицу времени. Тем не менее, разработчик сайта всегда может написать такой код, который загрузит систему и сделает её работу медленной и неэффективной.
Типовые моменты, которые требуют внимания разработчика если он наблюдает медленную работу сайта при малой нагрузке.
Используется не последняя версия системы. Если требуется скачайте обновление и установите его. Как правило, более новые версии работают быстрее.
Проверьте, включено ли кэширование и сжатие на "боевом" сайте, файл preferences.xml, ключи html_cache и html_compress.
Проверьте значение ключа cache_timelimit_sec, не рекомендуется устанавливать его менее чем на неделю. Если кэш будет сбрасываться слишком часто его эффективность может быть сильно снижена.
Частая ошибка - включение макроса SetMetaTags в секцию item списков товаров или в вывод архива новостей, чтобы он вызывался каждый раз при выводе отдельной записи.
Проверьте правильно ли используется макрос CatalogFullTree. Он тянет в память и обрабатывает структуру с папками и товарами целиком, поэтому если в навигации вам нужны только папки стоит рассмотреть возможность применения пары CatalogTree/CatalogList вместо него.
Загляните в папку Cache, поищите файлы с расширением raw. Если такие файлы есть, проверьте макросы, которые есть внутри. Файлы raw - это все, что смогла закэшировать система если закэширован не весь результат работы. Оставшиеся в файле макросы обрабатываются при каждом обращении к соответствующей странице, поэтому чем их меньше - тем лучше. Сверьтесь со списком некэшируемых в принципе макросов и помните что кэшированием остальных макросов разработчик управляет при помощи ключа nocache.
Избегайте излишней вложенности макросов друг в друга. Проверьте везде ли вы применили алгоритмически верное решение.
Необходимо проверить нет ли излишнего циклического или массового вызова макросов? Для этого все макросы в подозрительных местах можно заменить на некую строку, чтобы в процессе отладки эти строки можно было увидеть и посчитать. Если у вас по коду будет 1500 вызовов $News[]$, пусть и для вывода крошечных кусочков HTML, система рада не будет.
Не злоупотребляйте макросом DataField. Если вам нужно последовательно вывести 15 полей для одной записи стоит не лениться и сделать отдельный дизайн для макроса News, который сделает 1 обращение к таблице и записи, а не 15. Система, конечно, будет пытаться кэшировать такие вызовы, но в определенных случаях это может не работать.
Частая ошибка - применение лишних макросов $Text[]$ для простановки условий отрисовки блоков вместо применения ключа condition прямо в макросе.
С версии 4.36 при обработке xml каталогов система формирует файлы с расширением hdx в папке Data. Проверьте их. Если вы видите несколько файлов вида [catalog]_[catalogid].hdx с одинаковым размером, то необходимо проверить существуют ли в файле [catalog].xml секции folder assign="catalog" с id="[catalogid]". Когда системе в макросах передают несуществующий catalogid она использует весь файл [catalog].xml целиком, что плохо отражается на производительности.
Если вы работаете с каталогами, число товаров в которых превышает 10000, а число категорий суммарно более 1000 и вы испытываете проблемы с производительностью имеет смысл попробовать разбить каталог товаров на несколько групп, которые разместить в отдельных секциях folder assign="catalog". Разносить секции по разным файлам смысла нет. Данное решение будет работать при условии, что вы отрисовываете каталоги обращаясь к ним из макросов по отдельности с указанием их id (через ключ catalogid).
Что не влияет на производительность и над чем не стоит задумываться:
количество записей в справочниках;
количество справочников;
размер кэша;
количество секций folder assign="catalog" в файле catalog.xml если вы обращаетесь к секциям по отдельности.
Если все рекомендации выполнены, а сайт продолжает притормаживать, имеет смысл потестировать площадку на предмет скорости работы. Помните, что виртуальный хостинг - это, как правило, 500-1000 сайтов, размещенных на одном сервере. В часы пиковой нагрузки всем сайтам системных ресурсов и канала может попросту не хватать.
Если в вашем распоряжении выделенный сервер и вы ожидаете большой посещаемости, стоит обратиться к опытному системному администратору чтобы он провел аудит настроек веб-сервера и используя средства системного администрирования поднял его производительность в целом.
При корректном использовании системы, нормально собранном сайте и достаточном канале выделенный сервер средней конфигурации (PIV-2.4Ghz, 2Gb RAM) легко справляется с реальным потоком в 100000-300000 уникальных посетителей в сутки. Данные приводятся для конфигурации без применения специальных средств типа lighthttpd или nginx, схемы с использованием squid и т.п.
