Скорость работы CMS при нагрузках и кэширование

[LORDotU]

Собственно, вопрос: какую максимальную нагрузку способна вынести Frog
с учетом того, что она пропускает куски кода через eval и не кэширует
их? Способен ли положительно повлиять на скорость работы APC-кэш?

[Александр Маслаков]

Про APC-кэш почитаю. Действительно интересное расширение. Только вопрос: насколько часто на серверах установлена поддержка APC? Если это расширение распространено на более 50% серверов, естественно имеет смысла добавить поддержку этого расширения в будущем.

Больше всего нагрузки генерирует выборка страниц из базы. При каждом FrontPage::find() делается запрос к БД. Я немного оптимизировал этот процесс, добавив статическую переменную, в которую складываются объекты. При каждом новом FrontPage::find() перед запросом к БД проверяется наличие объекта страницы по хэшу, что избавляет от дублирующихся запросов.

Допустим есть несколько проектов www2.just.dn.ua и www.leif.com.ua. Сайты довольно объемные. Проекты сейчас не у меня, но попробую попросить чтобы сделали замер производительности. Но все равно это не будет "чистым" результатом, потому что при комбинации различных плагинов будет совершенно разная производительность.

18 мая 2011 г. 12:29 пользователь LORDotU <levs...@gmail.com> написал:

Собственно, вопрос: какую максимальную нагрузку способна вынести Frog
с учетом того, что она пропускает куски кода через eval и не кэширует
их? Способен ли положительно повлиять на скорость работы APC-кэш?

--
Данное сообщение отправлено Вам, так как Вы являетесь подписчиком
группы "Frog CMS RU" в Группах Google.
Для того, чтобы отправить сообщение в эту группу, пошлите его по адресу
frog-...@googlegroups.com
Чтобы отменить подписку на эту группу, отправьте сообщение по адресу:
frog-cms-ru...@googlegroups.com
Чтобы выполнить другие действия, посетите страницу группы
http://groups.google.ru/group/frog-cms-ru?hl=ru

--
С уважением, Маслаков Александр.
Разработка сайтов: дизайн, программирование, подготовка информации, сопровождение

Портфолио: http://up.dn.ua/
Тел.: +38 099 669–15–06
Эл. почта: jmas.u...@gmail.com
Skype: maslakov.alexandre

[Левшин Олег Сергеевич]

Хорошо, Саш, спасибо Вам.

18 мая 2011 г. 13:49 пользователь Александр Маслаков <jmas.u...@gmail.com> написал:

[jMas]

Думаю насчет кэширования некоторых данных в памяти сервера. Посмотрел APC cache, но не уверен в актуальности на серверах. Проверил на довольно известном украинском сервере hosted.ua - поддержка отсутствует.

Можете проверить поддержку APC на ваших серверах? Создайте файл, к примеру, apc.php с одной строчкой:

<?php var_dump(function_exists('apc_add'));

[sartas]

На моем хостинге стоит eAccelrator. Привязываться к определенному
кешеру не стоит, прикрутить класс, например от коханы, будет и APC, и
eAccelrator, и memcache.

на сайте в 500 страниц (у страниц 3-9 частей) админка уже тормозит,
раскрытое дерево может даже до конца не загрузиться.

> При каждом FrontPage::find() делается запрос к БД.

зачем в адмике на странице pages делать запросы к page_parts, нужны
ведь только заголовки страниц, а не все содержимое!

[Александр Маслаков]

А они и не делаются. При работе с деревом на странице, находящейся по роуту page/index, идет работа только с заголовками - дерево не строится.

Дерево строится только, если использовать модель FrontPage::find(), тогда необходимо построить дерево для нахождения всех элементов адреса, например если у нас /articles/my_article1/, тогда происходит поиск страницы, имеющей slug "articles", затем "my_article", которая в еще и должна иметь страницу-родителя c ID пред идущей страницы. Никаких других страниц не подтягивается - только те которые присутствуют в URI. Да и здесь обращение к page_parts не происходит.

Чтение page_part происходит только по методу $page->content('page_part_name').

Дело в том, что раньше вообще ничего не кэшировалось, а сейчас "кэшируются" отдельные страницы, извлеченные из ранних FrontPage::find(), но эффективность такого "кэширования" тоже под вопросом, потому что специальных тестов не проводилось.

Сейчас есть желание после того, как будет доработан основной функционал, сесть за оптимизацию и тесты.

Пришлите пожалуйста, класс, занимающийся кэшированием в Кохане.

10 июля 2011 г. 19:25 пользователь sartas <ardu...@gmail.com> написал:

--
Данное сообщение отправлено Вам, так как Вы являетесь подписчиком
группы "Frog CMS RU" в Группах Google.
Для того, чтобы отправить сообщение в эту группу, пошлите его по адресу
frog-...@googlegroups.com
Чтобы отменить подписку на эту группу, отправьте сообщение по адресу:
frog-cms-ru...@googlegroups.com
Чтобы выполнить другие действия, посетите страницу группы
http://groups.google.ru/group/frog-cms-ru?hl=ru

[sartas]

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

[jMas]

Задумался о кэшировании в проекте. Довольно большой сайт-каталог получился, с продуктами в виде страниц.

Первое что пришло в голову: сериализовать полученные объекты-деревья.

Написал небольшой плагин, который делает следующее:

1. Вешается на событие page_requested (происходит до поиска страниц по базе), проверяет наличие уже закэшированного дерева страниц в файле (md5(CURRENT_URI), например), если такой есть, разсериализовываем все дерево и делаем $page->display(); die; Если такого нет, ничего не делаем.

2. Вешается второе событие на frontpage_found, то есть уже после того, как страница найдена. Сереализуем найденное дерево-объект страницы и ложем в все тот же файл md5(CURRENT_URI)

Провел небольшой тест на вскидку для страницы 5-го уровня. Результаты:

Без кэшрования:

0.2174 - 

0.3494 - 

0.2738 - 

0.2741 - 

0.2115 - 

0.2407 - 

0.2261 - 

0.2383 - 

0.2087 - 

0.2867 - 

С кэшированием:

0.1943 - 

0.2138 - 

0.2109 - 

0.2211 - 

0.1958 - 

0.1911 - 

0.2147 - 

0.1882 - 

0.2153 - 

0.1744 - 

То есть если вывести среднее из времени без кэширования  (10 результатов):

(0.2174+0.3494+0.2738+0.2741+0.2115+0.2407+0.2261+0.2383+0.2087+0.2867)/10 = 0.25267

С кэшированием (10 результатов):

(0.1943+0.2138+0.2109+0.2211+0.1958+0.1911+0.2147+0.1882+0.2153+0.1744)/10 = 0.20196

Нехитрое уравнение:

100 - ((0.20196*100) / 0.25267) = 20.0696560731

Получается, что кэширование экономит 20% на конкретно взятом варианте. Но нужно учитывать, что это кэшируется только 1 дерево, но при построении страницы и генерации разных меню используется $this->find(...), который тоже неплохо бы закэшировать.

Тестировал локально, нужно проверить еще на сервере.

Дальше попробую таким образом кэшировать деревья, которые получаются в результате $this->find(...); и проверю: насколько неудобно редактировать страницы с включенным кэшированием. Плюс нужно ввести механизм чистки кэша, когда страница была отредактирована.

Вообщем еще куча работы. :)

Если все будет ок, отпишусь еще.

[jMas]

Вообщем закэшировал все запросы с $this->find(...); но результат разочаровал. Никакого прироста по производительности нет, если не считать несчастных 2-5%.

Странно вообщем это как то.

Пока плагин кэширования в паблик не вылаживаю - еще сыроват, будет включен в версию 0.1. Погоняю на Linux-хостинге (в разных вариациях тэстов): может там будет хоть какой ни будь заметный результат...

Хотя есть несомненно плюс в написании плагина: пришлось сковырнуть фреймверк и наконец переписать немножко Observer::notify(). Теперь можно передавать аргументы по ссылке, что даст больше возможностей. Но и писать теперь придется, не:

Observer::notify('event', $argument1, $argument2...$argumentN);

а:

Observer::notify('event', array($argument1, $argument2...$argumentN));

и можно по ссылке:

$argument1 = null;

Observer::notify('event', array(&$argument1, &$argument2...&$argumentN));

// $argument1 = ...;

Надеюсь, каких ни будь серьезных проблем такой вид записи не создаст.

[jMas]

Закончил плагин кэша.

Сделал поддержку двух видов кэширования:

1. Динамического (о котором писал раньше)

2. Статического (кэшируется и отдается статический HTML)

Теперь немножко цифр с включенным статическим кэшированием.

Среднее 10-ти результатов:

((0.0755+0.0421+0.0452+0.0408+0.0482+0.0419+0.0431+0.0530+0.0513+0.0414)/10) = 0.04825

100 - ((0.04825*100) / 0.25267) = 80.9039458582%

На выходе имеем увеличение производительности на 80%. Ну это и понятно: отдается статический HTML.

Где и как можно будет применять кэш: динамический, в принципе, можно использовать на любых сайтах. В статическом кэше необходимо будет указывать страницы, которые должны быть закэшированы. В кэш можно добавить как отдельные разделы, так и сайт целиком.