9 февраля 2008 в 4:23
Итак я провел более тчательное тестирование. Сразу оговорюсь, что пишу тут далеко не о всех тестах что я проделал, а только о болле интересном, на мой взгляд. Итак...
Нодов 5000
Коментов 25000
Кэш выключен
64 мс на запрос — интерфейс английский
67 мс на запрос — интерфейс русский
Кэш включен
14.25 мс на запрос — локализация не влияет (естественно)
Агрессивный кэш
4.6 мс на запрос
Сразу видна разница с прошлым тестом, на агрессивном и нормальном кэше. В прошлом тесте нод был коротким и не имел комментариев. В этом нод имеет 10 комментариев и на нормальном кэшировании сразу проигрывает. Скорее всего это проигрыш на запросы к БД, но я поленился выяснять.
С включенным кэшем, разницы при просмотре содержимого раздела, не наблюдается. А вот с выключенным кэшем, просмотр раздела...
84.5 мс на запрос.
Следующий тест, по сути своей ничего не меняет, но призван удовлетворить претензии тех, кто считает тест на время выдачи одной страницы, не убедительным. В тесте, я загружаю весь сайт и засекаю время потраченное на загрузку всех 5000 нодов, 25000 комментов и 50 страниц разделов. Загрузка многопоточная. Загружаются одновременно все (разные) ссылки, найденные на странице.
Вот что получилось.
Без кэштрования - 28m16.055s
Нормальное кэширование — 5m41.067s
Агрессивное кэширование — 2m0.139s
Нормальное кэширование с включенным объединением CSS — 28m29.681s 
(трижды прогнал)
Что за глюк с включенным объединением CSS, я не знаю, но все указывает на то, что с ним, кэширование попросту не работает.
Далее по просьбам трудящихся, я проверил, насколько влияет на производительность Drupal, модуль VIEW.
Не имея ни малейшего представления, о том как правильнее выявить разницу в работе системы с этими модулями, я сделал просто. Протестировал скорость выдачи стандартного модуля трекер и главной страницы и сравнил это с соответствующими видами создаваемыми модулем view. Вот что вышло. Модуль view замедлил работу системы в среднем на 51% и время выдачи составило, в среднем 101 мс.
Модуль ССК тестировать не стал, так как считаю, что его влияние, очень сильно зависит от того, как он используется.
З.Ы.
Для сравнения, время выдачи обычной html страницы, у меня - 0.240 [ms]
Комментарии
Спасибо, очень интересно.
спасибо
Мне лично кажется, что для объективности не хватает описания многих условий в которых производились тесты. Настройки PHP, MySQL, кол-во памяти и свопа, загрузку памяти и прочее.
Может имеет смысл сделать типовой отчёт о быстродействии.
Кстати, вас "подшили" в книгу.
Скажите что конкретно Вас интересует и я напишу. Но еще раз..., я сделал этот тест, потому что мне было любопытно, как кэширование облегчает жизнь серверу. Естественно я не могу, да и не хочу тестировать производительность собственно различных конфигураций площадок. Но если кому что интересно, могу потестировать когда не лень
З.Ы.
Что есть, "Подшили в книгу"? (Я не сильно хорошо ориентируюсь на друпал.ру)
По мне так вообще смысла в этих тестах нет!
Настойки разнятся слишком сильно. Тут у некоторых imagecache не работает или другие модули. А кто-то настроит boost и Block Cache и сайт будет летать даже с CCK, views и прочими не лёгкими модулями.
Я не задумывался над тем, что это может Вам казаться бессмысленно . Мне было интересно и я сделал. Вопрос не в том как у кого что настроено. Я не о производительности сервера, я о том, насколько эффективен кэш друпал. Согласен что тесты не самые изысканные, но для того чтоб сделать определенные выводы, вполне достаточно.
Потому надо их описывать вместе со всем тем на чем вы тестировали.
Посмотрите колонку справа и увидите куда именно подшили. А книги есть в меню сверху.
Давайте я скажу по другому. На мой взгляд, тестирование должно быть индивидуальным. Вот Вы провели тесты и выяснили эффективность кэширования. Но это актуально только на вашей площадке. Плюс-минус настройка и/или плюс-минус модуль и результаты у других людей будут совсем другими. И даже подробный список ваших настроек других не спасёт - не будут же просить хостера пересобрать apache с таким-то настройками пользователи с хостингом за 5$ (а большинство проблем с производительностью на дешёвых российских хостингах).
Предлагаю подойти к проблеме с другой стороны - попытаться определить _как_ проводить тестирование. То есть разработать методику. На её основе написать модуль или скрипт который будет тестить сайт. Тогда каждый сможет запустить этот скрипт/модуль и получить индивидуальные результаты.
Спасибо за тесты.
Здесь не так важны сами цифры как соотнощение в процентах.
Честно скажу, что 50% для views меня убили.
Не, я конечно догадывался, что замедляет но 50% - это очень круто.
Чтож на крупных проектах придется отказываться от Views и CCK
что в принципе логично.
хорошая темка
Процентное соотношение тоже зависит от площадки. Например, где-то может быть быстрая БД и несколько лишних запросов не сильно изменят общее время, а где-то наоборот.