форум общения русскоязычных пользователей CMS Текстпаттерн
Вы не зашли.
интересная статейка
http://particletree.com/features/how-to … ttern-site
Неактивен
Оптимизацией сайта с целью увеличения скорости надо заниматься по окончании периода отладки сайта, когда все настройки сделаны, структура, навигация и оформление определены и у разработчика появляется легкая эйфория, что сайт удался.
Но вот знать, что надо и можно оптимизировать и представлять - какие пути оптимизации существуют, надо, пожалуй, с самого начала.
Давайте подытожим методы увеличения скорости сайтов, предлагаемые автором вышеприведенной статьи:
1. Turn off logging - Отключить ведение логов средствами ТП.
Процедура проста и безболезненна. В админ.панели меню - preferences - селектор Logging установить в положение None.
Что при этом происходит?
Перестает записываться в базу каждый чих… пардон, каждый шаг посетителя по сайту. Учитывая, что некоторые посетители (например, роботы поисковых машин) не имеют тормозов относительно числа проиндексированных страниц, и имеют дурную привычку периодически повторять свои обходы, выключение этого режима может привести к серьезному снижению нагрузки на базу. Метод особенно полезен, если у Вас на сайте большое количество страниц и(или) посетителей.
2. Turn off/on Send Last-Modified Header - выключить указания времени последней модификации при запросе данной страницы.
Порядок выключения аналогичен предыдущему пункту, за одним исключением. В админ.панели "заведует" этим режимом не селектор, а radio button, где надо установить одно из двух значений, либо "yes", либо "no". Не думаю, что это вызовет какие-то трудности.
Насчет целесообразности выключения этого режима вопрос сложнее.
Существует мнение, что дата модификации документа, выдаваемая апачем, имеет серьезное значение для роботов поисковых машин. Находясь далеко от разработчиков алгоритмов поиска, мне трудно судить о правомерности этого мнения, но простота модификации этого заголовка вселяет подозрение, что если эта дата и имеет еще значение, то скоре всего, в ближайшем будущем, с ростом технологий поисковых оптимизаторов, перестанет быть актуальной.
Решение о включении-выключении этого режима принимать Вам, но надо учитывать, что при выключении его вы экономите один "нырок" скрипта в Базу MySQL за датой последней модификации статьи.
3. Don’t use the built in css editor - не использовать встроенный редактор css.
Автор как-то сгоряча озаглавил этот метод, рискуя быть непонятым читателями.
Давайте остановимся чуть подробнее.
TXP, следуя в ногу современным веяниям, хранит все, что только можно, в базе MySQL (на мой взгляд, слегка перебарщивают с этими веяниями, но подобной тенденции придерживаются и другие cms), в том числе и css-стили.
В шаблоне по умолчанию, присутствует тэг txp:css для "выдергивания" из базы css-директив для каждой страницы.
Так вот, этот метод оптимизации и предлагает, по сути, не использовать тэг txp:css, указывая в шаблоне страницы обычную прямую ссылку на самый обычный css-файл, который закачивается на сайт с помощью любого ftp-клиента.
Рациональное зерно в этом есть определенно. Мы можем, как минимум, сэкономить 2 запроса к базе на каждую страницу. Один - для определения, какой css-стиль использовать для текущей секции, а второй - чтение самого текста стиля.
Немного арифметики. Например, у вас на сайте 1000 посетителей в день, предположим, что каждый из них просматривает 5 страниц.
Отказавшись от использования тэга txp:css мы экономим 10 000 обращений к базе в сутки. Много это или мало - решать Вам.
Если Вы надумали отказаться от использования этого тэга, то лучше всего это делать, конечно, по окончанию отладки.
Что там говорить, с встроенными стилями отлаживаться удобнее.
4. Turn on gzip compression for php, css and js files - включить gzip сжатие для php, css и js файлов
Способ, требующий модификации .htaccess и настроек php.
Вопрос по использованию этого метода обсуждался здесь, на форуме
Кроме этих 4х перечисленных способов, еще способ повышения быстродействия TXP указан здесь:
при небольшом количестве и редко меняющихся наименованиях секций имеет смысл в окончательном варианте сайта отказаться от использования тэга txp:section_list, впечатывая навигацию по секциям непосредственно в шаблон страницы.
Неактивен
Evgeny написал:
2. Turn off/on Send Last-Modified Header - выключить указания времени последней модификации при запросе данной страницы.
Порядок выключения аналогичен предыдущему пункту, за одним исключением. В админ.панели "заведует" этим режимом не селектор, а radio button, где надо установить одно из двух значений, либо "yes", либо "no". Не думаю, что это вызовет какие-то трудности.
Насчет целесообразности выключения этого режима вопрос сложнее.
Яндекс ругается если сайт не выдает Last-Modified. Да и вообще, насколько я понимаю, пользователям проксей и любителям кэша, которые экономят трафик, это тоже важно.
Я бы не отключал, короче. Поисковики - это наш хлеб, с ними нужно дружить. :-)
Evgeny написал:
TXP, следуя в ногу современным веяниям, хранит все, что только можно, в базе MySQL (на мой взгляд, слегка перебарщивают с этими веяниями, но подобной тенденции придерживаются и другие cms), в том числе и css-стили.
Рискую уйти в оффтопик, но все-таки интересно в чем преимущество хранить шаблоны и css в базе?
Примечание Администратора:
Вынес в отдельную ветку тред про современные тенденции
Неактивен
Как Вы заметили, вышеперчисленные рекомендации в основном направлены на уменьшение количества обращений к базе MySQL.
Продолжим тему оптимизации.
Есть еще 2 тэга в ТП, о которых надо упомянуть.
Это тэги txp:sitename и txp:site_slogan. Результат действия этих тэгов Вам заранее известен - вывод на страницу названия и девиза-слогана Вашего сайта.
Правильнее будет этот результат впечатывать непосредственно в шаблон Вашей страницы.
И еще одна рекомендация, которая уже мелькала здесь, на форуме:
повсеместное использование тэга txp:output_form. (К сожалению, на revision 710, на которой я сейчас работаю, кэширование форм барахлит, если кто на более поздних revision проверит работоспособность кэширования форм, и расскажет об этом - буду признателен )
Неактивен
Отказ от использования txp:site_slogan, txp:sitename, txp:output_form, txp:css не верый пусть к оптимизации. Так мы до статического html дооптимизируемся. Кеширование форм звучит куда разумней. Тем более, что отказ от них напоминает экономию на спичках, всё равно, что ради пары байт значения атрибутов в html писать не в кавычках.
Да и нужна ли она эта оптимизация? Жалкие проценты, они не важны для той посещаемости на которую расчитан txp.
Неактивен
Nicck написал:
Отказ от использования txp:site_slogan, txp:sitename, txp:output_form, txp:css не верый пусть к оптимизации. Так мы до статического html дооптимизируемся. Кеширование форм звучит куда разумней. Тем более, что отказ от них напоминает экономию на спичках, всё равно, что ради пары байт значения атрибутов в html писать не в кавычках.
Да и нужна ли она эта оптимизация? Жалкие проценты, они не важны для той посещаемости на которую расчитан txp.
Почему? Имхо такие теги нужны для быстрой установки универсальных шаблонов (тем), воткнул и все работает. А когда шаблоны сам делаешь, то какая разница где текст менять в одной формочке или другой, а производительность увеличиться.
Неактивен
Nicck написал:
Отказ от использования txp:site_slogan, txp:sitename, txp:output_form, txp:css не верый пусть к оптимизации.
От txp:output_form отказываться не надо. Наоборот, здесь был призыв использовать ее как можно чаще.
Nicck написал:
Да и нужна ли она эта оптимизация?
Вопрос правильный. Но пусть его решает каждый сам, исходя из своих условий и своего знания, что можно соптимизировать.
Nicck написал:
не важны для той посещаемости на которую расчитан txp.
А на какую посещаемость рассчитан txp? :-)) Можно ссылочку на источник информации? :-)
Отредактированно Evgeny (25-08-2005 14:09:38)
Неактивен
У txp, на мой взгляд, своя ниша. Средние и малые сайты. А это вполне умеренная посещаемость, т.е. такое количество запростов в ед.времени при котором задержка, вызванная обращением к базе данных, не заметна.
Используя отличные от задуманных разработчиком способы организации информации мы усложняем себе переход на новые версии продукта т.к. наши способы не будут учтены. Так же мы лишаем себя определённой функциональности и гибкости. Т.е. отказавшись от txp:site_slogan мы будем вынуждены менять его во всех шаблонах, если что.
Оптимизация -- задача разработчика а не пользователя.
И по поводу txp:output_form: как его использование позволит нам "увеличить скорость сайта на Textpattern"? Это разве не ещё одно обращение к базе?
Ссылочку не дам, если она есть я имею привычку её проставлять т.к. надеюсь что читающие при ответе мне тоже так поступят. Порой даже иду и гуглю за вас.
Отредактированно Nicck (25-08-2005 16:48:41)
Неактивен
Nicck написал:
У txp, на мой взгляд, своя ниша. Средние и малые сайты. А это вполне умеренная посещаемость...
По поводу первой части - мнение единодушно, об этом уже было писано, а вот по поводу второй я не совсем согласен, т.к. не связываю размер сайта (количество страниц на сайте) с его посещаемостью.
Посещаемость больше зависит от интересности-актуальности-модности темы (материала) сайта и от рекламных акций.
Технических ограничений по количеству посетителей у сайта на ТП пока не наблюдается.
Nicck написал:
Оптимизация -- задача разработчика а не пользователя.
Мы говорим про разработчика сайта или про разработчика CMS?
Про пользователя сайта или пользователя CMS?
Nicck написал:
И по поводу txp:output_form: как его использование позволит нам "увеличить скорость сайта на Textpattern"? Это разве не ещё одно обращение к базе?
Речь как раз и шла о том счастливом моменте, когда кэширование форм заработает в полную силу. Сейчас - да, txp:output_form требует обращения к базе. Когда будет кэширование - обращения к базе не будет.
Неактивен
Evgeny написал:
Nicck написал:
Оптимизация -- задача разработчика а не пользователя.
Мы говорим про разработчика сайта или про разработчика CMS?
Про пользователя сайта или пользователя CMS?
Nicck написал:
Про разработчика CMS и пользователя CMS.
Оптимизация CMS, безусловно, задача разработчика CMS. Но он может сделать оптимизацию для общего случая.
Для конкретного использования CMS оптимизацию может (да, не обязательно должен, именно - может) сделать только разработчик сайта, т.е. пользователь CMS, знающий особенности этого конкретного использования.
Evgeny написал:
Nicck написал:
И по поводу txp:output_form: как его использование позволит нам "увеличить скорость сайта на Textpattern"? Это разве не ещё одно обращение к базе?
Речь как раз и шла о том счастливом моменте, когда кэширование форм заработает в полную силу. Сейчас - да, txp:output_form требует обращения к базе. Когда будет кэширование - обращения к базе не будет.
Возвращаюсь к этому давнему разговору. Надо признать, что до кэширования txp:output_form дело пока так и не дошло. Сделано только кэширование (насколько я сумел разобраться в коде) многократного использование функций на одной странице. Т.е. если одна и та же функция на странице вызывается несколько раз, то база будет "дергаться" 1 раз.
Во всех остальных случаях, каждое обращение к функции - это обращение к базе. Иногда это надо учитывать в работе.
Отредактированно Evgeny (01-12-2005 11:47:28)
Неактивен
Evgeny написал:
Возвращаюсь к этому давнему разговору. Надо признать, что до кэширования txp:output_form дело пока так и не дошло. Сделано только кэширование (насколько я сумел разобраться в коде) многократного использование функций на одной странице. Т.е. если одна и та же функция на странице вызывается несколько раз, то база будет "дергаться" 1 раз.
Во всех остальных случаях, каждое обращение к функции - это обращение к базе. Иногда это надо учитывать в работе.
Евгений, эта информация все еще актуальна? А то меня тут убеждают, что для небольшого сайта 18 обращений к базе со страницы многовато, вот я и задумался... 8-/
А вообще, чего это я такие вопросы задаю? Вероятно актуально, раз количество запросов не меняется. Или, если бы не кэшировались, то было бы еще больше? И если они кэшируются, то в какой момент, при создании?
Неактивен
в используемой сейчас TxP 4.03 никаких продвижек с кэшированием не произошло.
Бегло просматривая svn -на предмет что готовится в следующей версии, так и там не заметил движений в эту сторону. Единственно что мелькнуло - было связано с кэшированием плагинов.
Но что там сдвинулось - будем разбираться когда релиз будет.
про "нормальное" и ненормальное количество обращений к базе обсуждалось здесь, здесь, здесь и т.д.
вообще - вопрос это возникает периодически-постоянно
В одном из перечисленных топиков мелькала цифра - повторю ее.
минимум для ТП - 4 запроса к базе на страницу.
Меньше не бывает.
И еще...
Begemot написал:
меня тут убеждают, что для небольшого сайта 18 обращений к базе со страницы многовато
Решать тебе, но я бы отнесся с сомнением в компетенции таких советчиков.
Дело в том, что для небольшого сайта, как раз, количество обращений к базе может быть любым, не создающим дискомфорт у посетителей по времени загрузки страницы.
Многовато такое количество может быть для БОЛЬШОГО сайта. Большого с точки зрения посещаемости, когда количество обращений может стать ограничителем роста этой самой посещаемости, когда начинают не выдерживать сервера одновременно выполняемых МайСКЛ запросов.
Подтверждение этому можешь увидеть сам, ползая по Интернету, если обратишь внимание на то, что чем посещаемее ресурс, тем он менее наворочен.
если сравнение Больших-Маленьких сайтов относится к количеству страниц на сайте, то это, как сам понимаешь - вообще не влияет на количество запросов на одну страницу.
Отредактированно Evgeny (30-08-2006 09:04:53)
Неактивен
Евгений, спасибо. Согласен с тобой, примерно такие же доводы я и высказал своим критикам по-поводу количества запросов.
Но все равно жаль, что кэширования пока нет... будем надеятся, что в будущем появится эта функция.
Неактивен
Еще один способ выноса css и, соответственно, уменьшения количества запросов к БД предложил Nicck.
И еще мысль возникла.
Возможно вынести все плагины из БД, поэкспериментировав с переменной plugin_cache_dir
Не тестировал это решение, но на первый взгляд все должно работать. Устанавливаем директорию кэширования плагинов. Переносим в эту директорию тексты всех плагинов (берем их путем копирования текста плагина в режиме редактирования), не забывая добавть <?php в начале текста и ?> в конце.
Запускаем ТхП. Все должно работать.
P.S. Возможно - понадобится деактивация присутствующих плагинов в базе. Но, как говорил - не тестировал этот режим.
Неактивен
Сегодня искал кое что про htaccess и наткнулся на статейку (там в комментариях).
tashik написал:
Многократное увеличение скорости работы сайта при помощи кэширования!
Статья на тему: Speed Up Sites with htaccess Caching
# НА МЕСЯЦ
Header set Cache-Control "max-age=2592000"
# НА НЕДЕЛЮ
Header set Cache-Control "max-age=604800"
# НА ДЕНЬ
Header set Cache-Control "max-age=43200"
Кто делал что-то подобное?
Неактивен
Есть ещё занятная вещь - jpcache. Правда кеширует она слишком агрессивно. но если изменения на сайт вносятся редко - то будет очень полезна.
Неактивен
А зачем она нужна, если есть встроенное?
Неактивен
ЭЭ.. Где? Не заметил там встроенного кешера..
Неактивен
1
Отредактированно RussianAustria (25-11-2014 15:00:57)
Неактивен
Выше по треду -- встроенное в хостера, конечно.
Неактивен
1
Отредактированно RussianAustria (25-11-2014 15:01:07)
Неактивен
Апну-ка я тему про оптимизацию ;-)
Долго-долго выводятся на сайтах те странички, на которых много-много мелких превьюшек.
Решил распараллелить запросы между четырьмя хостами: i0, i1, i2, i3.
Сейчас выводятся превьюшки так:
<img src="http://www.wildlifephoto.ru/images/1t.jpg" /> <img src="http://www.wildlifephoto.ru/images/2t.jpg" /> <img src="http://www.wildlifephoto.ru/images/3t.jpg" /> <img src="http://www.wildlifephoto.ru/images/4t.jpg" /> и т. д.
А надо, чтобы вот так:
<img src="http://i0.wildlifephoto.ru/images/1t.jpg" /> <img src="http://i1.wildlifephoto.ru/images/2t.jpg" /> <img src="http://i2.wildlifephoto.ru/images/3t.jpg" /> <img src="http://i3.wildlifephoto.ru/images/4t.jpg" /> <img src="http://i0.wildlifephoto.ru/images/5t.jpg" /> <img src="http://i1.wildlifephoto.ru/images/6t.jpg" /> <img src="http://i2.wildlifephoto.ru/images/7t.jpg" /> <img src="http://i3.wildlifephoto.ru/images/8t.jpg" /> и т.д.
Как, без лишней крови, изменить форму вывода, чтобы добиться желаемого результата?
Сейчас там лишь одна строчка с фигуристым урлом от smd_gallery.
<img src="{thumburl}" />
Отредактированно Anger (25-05-2011 10:28:25)
Неактивен
Если честно, то не думаю, что стоит заморачиваться на более, чем один отдельный домен для картинок. Хотя, конечно, зависит от количества ресурсов на странице с этого домена.
Есть т.н. "встроенное решение". Можно в config.php раскоментироватьстрочку с ihu и вписать туда адрес, по которому лежат картинки
http://phpxref.com/xref/textpattern/tex … ource.html
Например, на http://bookilla.com/ я все картинки гружу с адреса images.bookilla.com. На хостинге настроил symlink так, что картинки на самом деле находятся где и прежде. Но т.к. запрос идет на поддомен, эти картинки грузятся в параллельном потоке. Что, собственно, и ускоряет загрузку сайта.
Неактивен
the_ghost написал:
Если честно, то не думаю, что стоит заморачиваться на более, чем один отдельный домен для картинок. Хотя, конечно, зависит от количества ресурсов на странице с этого домена.
Товарищи-оптимизаторы из Yahoo как-то доказали, что имеет смысл делать отдельные домены для мелких картинок, особенно если их много. И не более 4-х доменов — иначе толку будет мало.
Проверил результат раскидывания по 4-м поддоменам 58 мелких картинок, правда на статичном, а не txp сайте. Выигрыш, действительно, потрясающий — время загрузки сократилось в 1.9 раз с использованием кэша и в 2.2 раза без него.
Попробую сократить количество поддоменов и почувствовать разницу.
the_ghost написал:
Есть т.н. "встроенное решение".
Боюсь, что встроенное решение загрузит поддомен точно также как и основной… и только с 4.3.0 — так не хочется обновляться ;-)
Неактивен