Любопытство про мульён или два...

Товарищи, очень интересно знать:
Предаставим, что есть у нас каталог к.-либо объектов на Drupal 7. Конечно, на этом гипотетическом сайте у нас будет вьюс и т.д. всё что обычно ставят. Элементов в каталоге у нас будет от МИЛЛОНА до ДВУХ МИЛЛИОНОВ. Посещаемость - 300 юзеров в сутки, которые будут смотреть эти объекты и чё то искать путём дёрганья фильтров на вьюсах.
Вопрос: для того что бы всё это боле-мене нормально работало, где это должно хоститься? Сколько для этого серваков надо?

Drupal стал медленнее работать

После месяца работы сайт на d7 стал работать очень медленно, сейяас devel пишет
Page execution time was 2739.59 ms. Memory used at: devel_boot()=1.09 MB, devel_shutdown()=10.81 MB, PHP peak=11.25 MB.

месяц назад:
Page execution time was 100.23 ms

Время запросов к БД возросло не значительно - Executed 283 queries in 15.81 ms, кол-во тоже

За это время изменилось:
кол-во модулей до 20 сторонних
кол-во нод > 40 000
кол-во полей для основного типа материала (объявление) > 20

В чем проблема такого значительно снижения производительности?

Тормозят сайты на Drupal. Win Server + IIS - помогите оптимизировать

Доброго времени суток!

Есть Web сервер на Windows Server 2008. VDS
Характеристики сервера - 1024 Mb ОЗУ, 2x2600 mHz проц.
На сервере развернуть IIS 7.5 на нем настроен PHP и развернут Drupal.
на Drupal-е используется мультисайтовость и развернуто ~40 веб сайтов с посещаемостью около 100 человек в сутки.

Сайты теперь тормозят. Смотрю нагрузку на VDS-е - почти под 100% загружен проц всегда. Хотя посещаемость довольно низкая. Если кто то заходит на сайт то загрузка страницы одной на секунд 5 загружает одно ядро проца на 100%.

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

Просто есть другой сайт на ASP.NET с посещаемостью около 6000 человек в сутки на таком же VDS. И там все работает быстро.

Производительность Drupal 7.0 vs 7.2

В продолжение своего предыдущего поста: http://www.drupal.ru/node/62641.
По аналогичной методике протестировал производительность новых версий drupal 6.22 и 7.2.

Drupal 7.2 показал +14% к скорости работы по сравнению с 7.0.

Конкретные цифры тут: http://edhel.krasu.ru/drupal-7-perfomance

1.5М зарег. юзеров - справится ли друпал?

Здравствуйте,
Я учавствую в разработке одного проекта, в котором заказчик хочет добавить 1.5М юзеров в базу и хотел бы с вами посоветоваться: стоит ли продолжать разработку на друпале?

Тестирование производительности Drupal 6 и Drupal 7

Провёл по возможности честное и приближенное к реальности тестирование d6 и d7:

1. в d6 сделал новостям такие же поля, как в d7 по умолчанию (title, body, tags, image), для чего пришлось поставить модули cck, filefield, imagefield, image api, imagecache
2. добавил новостям текстовое поле source
3. создал по 20 новостей с заполненными всеми полями
4. сделал меню из 6 пунктов + 3 развёрнутых подпункта
5. добавил меню в виде блока и сделал одинаковый набор блоков на обоих версиях (поиск, вход, меню, навигация)
6. загрузил русскую локализацию (в d7 пришлось фиксить ядро, иначе php не хватало времени для загрузки локализации)
7. отключил логи в апаче и mysql (иначе они портят тесты кэша)
8. выгрузил все программы какие смог
9. после каждого теста перегружал apache и mysql
10. тестировал на большем количество запросов (1000 запросов по очереди в один поток)

Результаты в мс (среднее значение):

страница	d6.20	d7.0
node	144	114
node/1	60	68
cache	11	15
нормированное время	1	1,07

*кэш от конкретной страницы почти не зависит, поэтому для него приведена просто одна цифра*

Тестировалось на winxp, php 5.2.9, eaccelerator (xampp).

Накануне более "тупо" тестировал drupal 5,6,7, там цифры для drupal 7 получилась менее утешительные, результаты тут: http://edhel.krasu.ru/drupal-5-6-7-perfomance.

мини тест pressflow

Залил контент, добавил нужных модулей и чуток потестировал pressflow-6.20.97

настройка Performance
Caching mode : Disabled
Page compression : Enabled
Block cache : Disabled
Optimize CSS files : Disabled
Optimize JavaScript files : Disabled

модуль трэйсера - Tracker 2

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

главная страница

529.05 ms. 397 queries 124.87 milliseconds. devel_it()=2.82 MB, devel_shutdown()=29.31 MB.
477.19 ms. 403 queries 79.42 milliseconds. devel_it()=2.81 MB, devel_shutdown()=28.98 MB.
514.61 ms. 392 queries 97.94 milliseconds. Memory usage:Memory used at: devel_it()=2.82 MB, devel_shutdown()=27.79 MB.
409.51 ms. 392 queries 69.31 milliseconds. devel_it()=2.82 MB, devel_shutdown()=27.8 MB.
392.5 ms. 392 queries 69.25 milliseconds. devel_it()=2.82 MB, devel_shutdown()=27.8 MB.
391.05 ms. 392 queries 68.32 milliseconds. devel_it()=2.82 MB, devel_shutdown()=27.8 MB.
---pressflow---
503.62 ms. 396 queries 125.31 milliseconds. devel_it()=2.98 MB, devel_shutdown()=28.97 MB.
398.83 ms. 391 queries 75.63 milliseconds. Memory used at: devel_it()=2.98 MB, devel_shutdown()=27.46 MB.
411.62 ms. 391 queries 71.07 milliseconds.
393.17 ms. 391 queries 70.42 milliseconds.
444.57 ms. 405 queries 81.94 milliseconds.

1 000 000 посетителей в месяц. Рекорд HR-Portal.ru

По данным статистики LiveInternet в марте 2011 года, HR-Portal.ru посетило более миллиона пользователей.
График прилагаю

[решено]Производительность. Страница отображается быстро, но браузер продолжает висеть в ожидании

В чем может быть проблема?
Пробовал отключать Javascript - проблема осталась?
Что еще может быть - или можно сразу обращаться к хостеру?

Есть ли какой то инструмент или модуль посмотреть на чем задержка?

Спасибо

Решено: лег сайт, с которого подключался скрипт

Почему мы всегда используем Pressflow для Drupal6-проектов

Pressflow - дистрибутив Drupal, который обеспечивает улучшенную производительность и масштабируемость. Он разработам ребятами из компании Four Kitchens.

Данный дистрибутив разработан для использования на сайтах с большой нагрузкой. Как известно, на серъезных сайтах используются только стабильные версии Drupal, обновление этих сайтов есть особый процесс. Pressflow - продукт, который развивается на осовании стабильных версий Drupal, и очень часто как раз новые версии Drupal уже содержат в себе наработки из Pressflow. Как пишут разработчики, при выходе каждой новой версии Drupal, они стараются побыстрее выпустить соотвествующую версию Pressflow, при выпуске которой учитывается совместимость модулей, - что вошло в ядро Drupal, что остается из прежнего Pressflow-релиза, плюс включаются свежие наработки.

Что особенно радует, это постоянное развитие проекта.

Читать полностью...

Очистка Drupal (из серии "Радио - начинающим")

Уважаемые камрады, ВНИМАНИЕ! Из комментов и голосования стало понятным, что ожидания большинства читающих были иные. Поэтому считаю должным предупредить, что эта статья - тупая инструкция и тем, у кого друпал не глючит, читать ее не стоит - с тем же кайфом можно прочесть на досуге инструкцию по установке запорной арматуры унитаза или сборки шкафа-купе. Не теряйте времени! Тем, у кого друпал стал работать криво - рекомендую и гарантирую положительный результат.

Анонс:

В настоящей статье рассказано о том, как:

* быстро, надежно, без малейшего риска и умственных усилий,
* очистить Drupal от скопившегося «мусора», сократить объем базы данных,
* восстановить исчезнувшие административные настройки модулей,
* обеспечить корректность установки новых модулей,
* повысить общую производительность движка и, в итоге,
* сделать так, чтобы Drupal снова заработал, как новенький - :)

Ссылка - http://tdocs.su/15168

Зависимость производительности от типа материалов

Привет, друпаловцы! Вопрос такой: сильно ли влияет ли количество типов материалов (более 1000) на общую производительность сайта?

А теперь обо всем по порядку. У меня есть блоговый проект, которые реализован путем создания типа материалов (1 блог - 1 тип материалов), для каждого из которых отдельно задаются свои синонимы, настойки и т.п.. Я был бы и рад реализовать данную задачу другим путем, однако модулей, которые бы реализовывали перечисленные ниже требования я не встретил.

Требования:
1. Категории.
2. Свой auto_increment (если на сайте всего 1000 постов в разных категориях, то новый пост должен иметь id не 1001, а допустим 15 (если в блоге, в который добавляется пост, перед этим было 14 записей).

Может стоит поколдовать с таксономией, что думаете? По крайней мере я не знаю, как с помощью неё можно реализовать второе требование.

Оптимизация сайта (более 80 модулей, более 2500 просмотров в сутки)

Статистика по модулю Devel:

Average memory per page: 24.8 MB
Average ms per page: 8,358.12

Путь # accesses Max Memory (MB) Avg Memory (MB) ms (Max) ms (Avg) Query ms (Max) Query ms (Avg) Query Count (Max) Query Count (Avg)
1 574 25.25 21.92 4,583.0 1,117.0 1,245.0 246.0 373 294
node 119 41.00 20.55 39,437.0 2,893.0 1,092.0 125.0 406 176

Размер главной страницы 24.9 KB (с дополнительными обращениями к серверу 284.2 KB)- время загрузки на сторону клиента 4.16s (с дополнительными обращениями к серверу 7.86s, onload: 6.65s), 31 запрос к серверу

Прошу гуру оптимизации прокомментировать эту статистику.
Еще хотелось бы узнать, что за мистическая страница 1? На сайте ее нет.

Что влияет на производительность?

Привет!
друпал очень медленно работает. На сервер несколько сайтов. Остальные работают быстро, а один, самый тяжелый, в десятки раз медленей. 1.2 запроса в секунду.
кроме количества модулей, на сайте в сотни раз больше пользователей и в тысячи раз - материалов. (при равной посещаемости)
терзают следующие вопросы
1) На сколько количестов пользователей и материалов влияет на отдачу? Или искать проблему в модулях?
2) неподключенные модули в папке modules как-то влияют на производительность? понимаю что недолжны, но всетаки
3) и самое главное что сделать, чтобы сайт работал быстрее?

[Производительность] Куча SQL-запросов от drupal_lookup_path

Добрый день.

В общем у меня вопрос общего характера. Озаботился я что довольно несложный сайт загружается довольно долго (от одной до двух секунд). Прошёлся профайлером (xdebug) и немного опечалился. Обычная страница делает 311 sql-запросов. Это очень много. Очень.

Выяснилось что большинство запросов (171 штука) происходит от функции drupal_lookup_path. Посмотрел её. Ещё больше опечалился. Ребята на каждый запрос к этой функции делают sql-запрос, вместо того чтобы при первом обращении скачать всю таблицу альясов и потом работать уже с ней в памяти. Или хотябы прикрутить несколько стратегий, например если кол-во памяти ограничено, а кол-во альясов велико. Прийдётся переписывать.

Вопрос простой - это нормально что в ядре друпала такой говнокод?