1. Главная
  2. divined

divined: Комментарии

Главные вкладки

8 сентября 2011 в 16:00

Добавление.

Друпал последнее время это неповоротливый слон. Да что говорить, вы посмотрите как открывается drupal.ru, создание ноды до 10 сек, открытие 5-8 сек.

Это показывает нам эталон работы самого друпала.
Если вы хотите чтобы у вас было быстрее чем друпал.ру и не надейтесь ))

8 сентября 2011 в 15:51

я так понимаю выводите в блок?

посмотрите поиском тут про аргументы views в блоке, там надо поставить обработчик, который бы вытягивал их из пути.

наводка:
$argument->handler = arg(0);

8 сентября 2011 в 15:47

Со стороны системного администрирование могу сказать что односторене правильный вопрос.

При редактировании, сохранении, удалении ноды действительно может подтормаживать сервер.
Конечно если при редактировании то имеем виду долгое открытие страницы редактирования ноды, или долгие пост запроси по типу (зависимых списков и т.д., т.е. ahah, ajax и прочее).

Вариантов на самом деле несколько:

8 сентября 2011 в 1:49

Пасиб что натолкнули на мысль, проблему нашел.
Напарник за каким то макаром включил кэширование блоков, и это при ориентации сайта только на анонимов Lol

Форма выводилась в блоке, и соответственно в этом была проблема Smile

7 сентября 2011 в 23:09

так, аха...

ahah.js не грузится у анонимов.
локализовать проблему удалось.

теперь попробовать найти решение Smile

Забыл сказать что раньше работало =). Так что думаю код не имеет смысла приводить, да и до боли он простой.
Каскадные списки для формы поиска + генерация пути для ссылки на основе выбранных значений, чтобы Views могла обработать их как аргументы и показать ускоренный кэшированный вывод.

6 сентября 2011 в 13:02

Насколько я знаю он создает отдельный интерфейс загрузки изображений, при этом сам создает ноду/несколько нод.

А как виджет CCK поля его использовать нельзя, соответственно для организации галереи внутри ноды он не подходит.

6 сентября 2011 в 11:11

"Crea" wrote:

Это у вас браузер тормозит, а не Друпал. Проверяйте скрипты и плагины.

Да, все браузеры на моем компе и все браузеры в офисе тормозят )))

PS. Я думаю что каждый веб-разработчик пользуется по крайней мере 4-мя браузерами ))

6 сентября 2011 в 11:09

Нашел я виновника Sad Но не доволен что нашел Sad
Оказывается это делает SWFUpload, а отказ от него это равнозначно отказу от drupal.

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

1 сентября 2011 в 16:50

Это не решает проблему!

Теперь JSON ответ вместо того чтобы вставляться на страницу выводится в блок alert();
Без какого либо указания ошибки. Причем делает это через раз. Т.е. При переходе на след страницу вьюхи может показать результат выведя JSON ответ на страница, а может вывести через Алерт его исходники.

Как узнать все-таки причину ошибки.

29 августа 2011 в 13:30

Ничего так выяснить и не получилось.
Единственно как что-то работает это оставить variable разными, но синхронизировать их время от времени. Иначе куча ошибок и нерабочая структура.

Странно что представители drupal'a молчат. Вроде одна из самых востребованных современных фишек, дык нет, глухо Sad

25 августа 2011 в 10:40

Оказывается, дело все-таки в ресурсах сервера (

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

Он вызывает процесс php5-cgi который жрет 60% CPU, соответственно любой запрос apache или mysql съедает оставшиеся ресурсы сервера.

24 августа 2011 в 18:02

Отключено логирование.

А вы случаем не знаете как можно протестировать скорость работы Mysql сервера?
Есть у него нечто типа проверочного запроса?
Типа вычисления числа ПИ до 2000 тыс знаков Lol //так проверяется сам сервер

24 августа 2011 в 16:43

2974.63 - время выполнения запроса (через phpmyadmin 0.002c)

1

locale

SELECT s.source, t.translation, t.language FROM locales_source s LEFT JOIN locales_target t ON s.lid = t.lid AND t.language = 'ru' WHERE s.textgroup = 'default' AND s.version = '6.22' AND LENGTH(s.source) < 75

24 августа 2011 в 16:24

И все-таки как пользоваться модулем devel для анализа узких мест в производительности сайта.

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

17 августа 2011 в 10:08

А я не согласен с королем анахронизма. Smile

Мой совет (кто послушает, кто нет - его дело).
Если разбираешься хоть немного в программирование ставь dev ветки смело, там очень много исправленных ошибок, пусть за это ты заплатишь 2-мя 3-мя часами допиливания, зато сэкономишь 2-е 3-е суток несовместимости с другими современными модулями. Оно того стоит.

16 августа 2011 в 11:44

Таки да:

в этой строчке происходит синхронизация перевода картинок, и именно этот кусок жрет память. Для меня это не критично, поэтому закоментил этот кусок: