Вход для клиентов и партнеров
в начало сайта
Партнерская программаОнлайн демоСкачатьКарта сайта
 

Регламент
Документация
Часто задаваемые вопросы (FAQ)
Решения типовых вопросов
Форум поддержки
Библиотека разработчика

Посмотрите демо-ролики и убедитесь в том, что "Twilight CMS" очень удобна в управлении, понятна и проста.

Бесплатно скачайте "Twilight.Basic", установите на своем компьютере и изучите систему более детально.

Если вам нужно установить "Twilight CMS" на существующий сайт или разработать новый - обращайтесь в отдел интеграции.

 

Ваше имя
Ваш Email
Вопрос
Twilight.basic
  • Узнайте больше
  • Сравните версии
  • Twilight.selection
  • Узнайте больше
  • Сравните версии
  • Twilight.evolution
  • Узнайте больше
  • Сравните версии
  •  
    Главная // Библиотека разработчика // Справочники // Книга рецептов (Cookbook) // Производительность системы //

    Оптимизация скорости работы сайта


    Система управления сайтом "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).
    • Не злоупотребляйте тамбнейлами. Если у вас большое число картинок на сайте, постарайтесь избежать многократной обработки изображений где это возможно. Мало того, что картинка значительно потеряет в качестве, так еще и в Cache будет большое число файлов, что усложнит операции поиска и удаления файлов там на уровне файловой системы операционки. Ну и само время генерации уменьшенных файлов также напрямую зависит от числа вызовов Thumbnail и размера исходного изображения. Может быть имеет смысл ресайзить картинки прямо на этапе загрузки через макрос Form (см. его ключи), или обработать папку с файлами один раз пакетно через ACDSee, например.
    • Не используйте макрос Captcha. Нет, мы не можем его запретить вам использовать, если вы маниак. С версии 4.40 в системе уже на каждой форме (сделанной с помощью Form) автоматически будет стоять защита, и, поверьте, она будет намного эффективнее капчи, а пользователям не нужно будет ничего вводить дополнительно вообще. Производительность же системы в целом будет падать, поскольку каждая капча, сгенерированная системой, падает в кэш и живет там некоторое время замусоривая его. Плюс, на генерацию капчи миллисекунды, но все таки нужны.

     Что не влияет на производительность и над чем не стоит задумываться:

    • количество записей в справочниках;
    • количество справочников;
    • размер кэша (в байтах);
    • количество секций folder assign="catalog" в файле catalog.xml если вы обращаетесь к секциям по отдельности.

    Если все рекомендации выполнены, а сайт продолжает притормаживать, имеет смысл потестировать площадку на предмет скорости работы. Помните, что виртуальный хостинг - это, как правило, 500-1000 сайтов, размещенных на одном сервере. В часы пиковой нагрузки всем сайтам системных ресурсов и канала может попросту не хватать.

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

    При корректном использовании системы, нормально собранном сайте и достаточном канале выделенный сервер средней конфигурации (PIV-2.4Ghz, 2Gb RAM) легко справляется с реальным потоком в 100000-300000 уникальных посетителей в сутки. Данные приводятся для конфигурации без применения специальных средств типа lighthttpd или nginx, схемы с использованием squid и т.п. Хотя, конечно, производительность будет зависеть в том числе и от начинки сайта.

    « к списку

    версия для печати

     
    © 2003-17 Страта Технологии (создание сайтов, разработка cms), Twilight CMS in english.
    Наш адрес: Москва, пр. Маршала Жукова д.51
    Тел.: (495) 222-6436, E-mail: , карта сайта, условия использования информации о CMS
    Звоните через Skype:  

    Реклама: