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

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

24 июля 2007 в 17:22

Про "выгрузки-загрузки" - не понял, что это. А обращения к базе - идут, но не для каждой страницы - а по мере необходимости, не более того.
Касательно размеров: 641К - это только ядро, а еще переводы модулей - в хорошем сайте на мегабайт потянет Smile
Вытаскивать это по мере надобности из базы или грузить при каждом обращении к странице - вопрос философский. Если жить на выделенном сервере, то наверное файловый вариант получше будет...

24 июля 2007 в 16:37

raw на мылницах не поддерживается к счастью.
Увы Вам, есть такие мыльницы, где поддерживается Smile

24 июля 2007 в 16:35

On вт, 24/07/2007 - 15:52 sas@drupal.org says:
Ух ты ... наверно не маленький массив

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

24 июля 2007 в 13:26

On вт, 24/07/2007 - 13:14 sas@drupal.org says:
но что-то есть большие априорные сомнения, даже при отсутствие репрезентативности и хорошей корреляции, что запрос на каждый t() к базе есть быстрее чем из файлов

так нет же там запроса к базе на каждый t(). Один раз оно грузит все мелкие строки и потом ищет их в ассоциативном массиве. Лезет в базу только если не находит, и опять-таки, помещает найденное в массив, т.е. не более одного обращения к базе для строки.

24 июля 2007 в 11:33

Интересно, действительно ли наблюдается прирост производительности при такой конфигурации?
Дело в том, что Друпал при генерации страницы единоразово грузит строки длиной менее 75 символов в память (в статический массив). Таким образом, для большинства вызовов функции t() обращений к базе не происходит. В основном нагрузка на БД происходит при работе в админке, т.к. длинные строки используются именно там.

12 июля 2007 в 22:27

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

10 июля 2007 в 10:38

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

2 июля 2007 в 23:51

Мне кажется, нужно дать пользователю БД возможность создавать временные таблицы (где-то читал, что для Друпала это важно). судя по приведенным ошибкам, Друпалу не удалось создавть временную таблицу и, возможно, сделать какие-то важные первичные настройки (можно поискать в коде, зачем ему нужна таблица missing_nids)

29 июня 2007 в 12:27

amelnikov, пт, 29/06/2007 - 10:58
самый важный для поиcковиков H1 - это название сайта+слоган (есессно по умолчанию). Так и лег спать с горечью на душе. Что же делать с этим всем ?
А page.tpl.php на что? Полная свобода действий, в чем проблема-то?

28 июня 2007 в 18:45

Очень зависит от того, насколько правильно настроены апач и mysql, а также от количества материала на сайте. Засады со скоростью могут быть также и от некоторых модулей. Например, если сравнивать (при прочих равных) друпал.ру и тот же cardriver, наверняка у первого из расчета на одну страницу выполняется гораздо больше работы (в том числе запросов к БД), нежели у второго. Кроме того, не забывайте, что кэширование страниц работает только для незарегистрированных пользователей, т.е. на друпал.ру для Вас кэширование страниц не работает, что тоже сказывается на скорости.

28 июня 2007 в 11:52

пермишены на /files, включенная и нужной версии GD lib в PHP, правильно работающий .htaccess - вот что вспомнил навскидку.
А еще у меня из гарланда пропадал цвет, когда я только начинал разбираться с мультисайтингом.

28 июня 2007 в 11:01

On чт, 28/06/2007 - 08:01 Razgonka.ru says:
У меня прямо противоположное мнение.
Здесь мы обсуждаем техническую сторону вопроса, не так ли? Хотелось бы знать, что Вам не понравилось с точки зрения реализации?