1 февраля 2011 в 13:35
Есть хостер bluehost.com на нем висит несколько сайтов, drupal в одной папке для всех сайтов, каждый сайт использует модули, которые другой сайт может не использовать.
Нужно ли удалять ли неиспользуемые модули(отключенные), повысит ли это быстродействие?
Содержимое сайта публикуется на условиях CreativeCommons Attribution-ShareAlike 3.0 или более поздней версии. Программные коды в тексте статей — на условиях GNU GPL v2 или более поздней версии.
Документация по совместной работе с репозиторием drupal.ru – https://docs.drupal.ru/code
Drupal – торговая марка Дриса Бёйтарта
Поддерживать инфраструктуру Drupal.ru нам помогает компания ДАЛЕЕ
Комментарии
О как, это новое слово в друпал-разработке.
К примеру один сайт использует модуль forum, другой сайт не использует forum, а все сайты не используют модуль groups )))
Оказывается меня bluehost.com затролил на использование CPU, хотя я везде поставил boost. Может когда я бекапил базу у меня забрали часть "CPU", типа много ем.
bluehost.com затролил — новый сленг красноглазых MS-ненавистников?
Ответ на ваш вопрос: нет.
Если я был MS-ненавистник, или красноглазом, я бы взял VDS.
Off-top: По поводу "MS-ненавистников" - причём тут MS, у поклонников-MS мания преследования? Им уже мерещится, что везде их ущемляют, даже в хостингах)))
Удаление неиспользуемых модулей из директории с модулями даст какой-то выйгрыш в произоводительности. Этот выйгрыш будет получен при вызовах функции drupal_system_listing(). Но сама эта функция запускается очень редко(точно вызывается на странице списка модулей). Так что выйгрыш будет настолько мизерным, что никаким образом на общую производительность не повлияет.
Ищите то что может сущесвенно улучшить производительность.
Например, замена двойных кавычек
"на одинарные'даёт прирост производительности до 7 разпережал проц в запросах
# Query_time: 1.159581 Lock_time: 0.000431 Rows_sent: 231 Rows_examined: 688
use mammshop_gradsafety;
/* jedai : menu_tree_page_data */
SELECT m.load_functions, m.to_arg_functions, m.access_callback, m.access_arguments, m.page_callback, m.page_arguments, m.title, m.title_callback, m.title_arguments, m.type, m.description, ml$
FROM _1_menu_links ml LEFT JOIN _1_menu_router m ON m.path = ml.router_path
WHERE ml.menu_name = 'navigation' AND ml.plid IN (3004, 3012, 6125, 0, 5138)
ORDER BY p1 ASC, p2 ASC, p3 ASC, p4 ASC, p5 ASC, p6 ASC, p7 ASC, p8 ASC, p9 ASC
# Tue Feb 1 07:01:15 2011
# Query_time: 1.529264 Lock_time: 0.050776 Rows_sent: 0 Rows_examined: 0
use mammshop_gradsafety;
/* jedai : cache_get */ SELECT data, created, headers, expire, serialized FROM _1_cache_menu WHERE cid = 'links:navigation:tree-data:32f7bb98c4a274a60f89fa6ed7f36e32'
# Tue Feb 1 07:01:31 2011
# Query_time: 1.711916 Lock_time: 0.649006 Rows_sent: 1 Rows_examined: 1
use mammshop_gradsafety;
/* jedai : cache_get */ SELECT data, created, headers, expire, serialized FROM _1_cache_menu WHERE cid = 'links:navigation:tree-data:66d7fb97154c9082bf1923b05c2527e9'
# Tue Feb 1 07:01:46 2011
# Query_time: 2.503227 Lock_time: 0.000166 Rows_sent: 2942 Rows_examined: 15701
use mammshop_gradsafety;
/* jedai : locale */ SELECT s.source, t.translation, t.language FROM _1_locales_source s LEFT JOIN _1_locales_target t ON s.lid = t.lid AND t.language = 'ru' WHERE s.textgroup = 'default' AND $
# Tue Feb 1 07:01:56 2011
# Query_time: 1.046353 Lock_time: 0.000225 Rows_sent: 1 Rows_examined: 1
use mammshop_artkavkaz;
SELECT s.lid, t.translation, s.version FROM locales_source s LEFT JOIN locales_target t ON s.lid = t.lid AND t.language = 'ru' WHERE s.source = 'Backup and Migrate makes the task of backing up$
# Tue Feb 1 07:02:01 2011
# Query_time: 2.879868 Lock_time: 0.313189 Rows_sent: 1 Rows_examined: 1214
use mammshop_gradsafety;
/* jedai : node_update_index */ SELECT MAX(comment_count) FROM _1_node_comment_statistics
# Tue Feb 1 07:09:48 2011
# Query_time: 1.926137 Lock_time: 0.000169 Rows_sent: 50 Rows_examined: 2856
use mammshop_artkavkaz;
SELECT w.wid, w.uid, w.severity, w.type, w.timestamp, w.message, w.variables, w.link, u.name FROM watchdog w INNER JOIN users u ON w.uid = u.uid ORDER BY w.wid DESC LIMIT 0, 50
# Tue Feb 1 07:09:52 2011
# Query_time: 1.828562 Lock_time: 0.000121 Rows_sent: 2945 Rows_examined: 15704
use mammshop_gradsafety;
/* jedai : locale */ SELECT s.source, t.translation, t.language FROM _1_locales_source s LEFT JOIN _1_locales_target t ON s.lid = t.lid AND t.language = 'ru' WHERE s.textgroup = 'default' AND $
# Tue Feb 1 07:09:55 2011
# Query_time: 1.322370 Lock_time: 0.000085 Rows_sent: 0 Rows_examined: 0
use mammshop_gradsafety;
/* jedai : lock_release_all */ DELETE FROM _1_semaphore WHERE value = '801172614d48142e8c2cf0.99360124'
# Tue Feb 1 07:09:55 2011
# Query_time: 1.323022 Lock_time: 0.000166 Rows_sent: 1 Rows_examined: 2
use mammshop_artkavkaz;
SELECT s.lid, t.translation, s.version FROM locales_source s LEFT JOIN locales_target t ON s.lid = t.lid AND t.language = 'ru' WHERE s.source = 'Views are customized lists of content on your s$
# Tue Feb 1 07:10:17 2011
# Query_time: 1.976740 Lock_time: 0.000114 Rows_sent: 1697 Rows_examined: 11112
use mammshop_artkavkaz;
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.20' AND LENG$
# Tue Feb 1 07:10:24 2011
# Query_time: 1.796807 Lock_time: 0.000043 Rows_sent: 1 Rows_examined: 1
use mammshop_artkavkaz;
SELECT data, created, headers, expire, serialized FROM cache_menu WHERE cid = 'links:admin_menu:tree-data:c8f36f281d51707b7b5dfa0e8895df23'
# Tue Feb 1 07:10:29 2011
# Query_time: 1.278180 Lock_time: 0.003516 Rows_sent: 1700 Rows_examined: 11115
use mammshop_artkavkaz;
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.20' AND LENG$
Интересно 820 секунд проца это сколько в процентах от общей загрузки сервера?
Мой сайт основной жрет проца 230 секунд в сутки это с бустом. Че-то у меня смутные сомнения что 820 секунд это может быть с бустом да еще и на посещалке, сколько там у тебя, ведь совсем небольшая насколько я понимаю.
Либо тебя на сервак перекинули совсем какой-то дохлый, либо че-то там в скриптах переклинило... ну такое ощущение возникает.
А типы таблиц ты менял там на INNODB напрмер? это не могло вызвать ошибки с залочиванием таблиц или строк на запись?
Ну из запросов которые ты привел видно что каждый выполняется по секунде-две, а т.к. друпал запросов делает много, проц задумывается. Ты эти запросы в ПХПмайадмине пробовал выполнять? тоже медленно выполняет?
у хостинг-центра в неделю лимит 600 секунд.
Я видел сайты которые в сутки едят 10000 секунд.
В процентах это по разному, зависит от проца
причем когда boost не ставил, всё было нормально. Как поставил boost через время админка начала тупить и тупит щас. Если заходит аноним c бюстом, у него все летает. Загрузки на проц/бд почти нет
может в .htaccess косяк с перенаправлениями страниц???
очень похоже на ошибку в правилах, да и по времени совпадает, когда буст поставил и когда хостер стал жаловаться.
Так зато в админке прибрано и не надо лазить через горы ненужного хлама, которые качается 30 секунд ровно с учётом угуления на предмет искомого сабжа.
ПэхаПэ? Шо риальна?
Таблицы БД я не менял.
Ну я ставил .htaccess друпаловский по умолчанию который идет, ошибок по поводу htaccess нет ни в одном из случаев, причем всё также тупит. Служба поддержки в чате сказала что все нормуль с сервером, и что скорее всего вы не доделали на сайте что-то)
Может разделить некоторые таблицы например таблицы кеша, в отдельную БД?
10 секунд на 161 запрос это нормально?
Увольте
При двойных кавычках [делаю умный вид] пых сканирует текст на наличие переменных и если они там есть выводит их содержимое. А при одинарных если в тексте встретится $teaser_text например то так и выведет на экран, будто это текст. Отсюда естессно разница в скорости.
Что значит фраза «ставил htaccess друпаловский по умолчанию»??? При установке буста, он генерит некий набор правил, который нужно поставить в htaccess в строго определенное место. Они вообще там есть эти правила в этом файле у тебя? В нужном месте стоят?
Если на все ответы - да, то попробуй снеси буст нафиг и посмотри пару деньков понаблюдай за процом (у тебя-же есть в админке доступ к отчетам по процу?). Под термином "снеси буст" я подразумеваю в том числе убрать и его правила в файле htaccess.
Почему-то подозрения у меня именно на htaccess не знаю. Я вот когда игрался с этим файлом (нужно было перенаправить хитро одну друпаловскую страницу на папку с HTML), дык я много раз писал такие правила, которые зацикливали не знаю, то-ли браузер, то-ли сервер на 5-10 секунд что-ли... и браузер ругался потом и говорил "у вас бесконечное перенаправление". И в тот момент я напрягался потому что понимал, что если зацикливается сервер, то мне хостер за такие вещи может пригрозить пальчиком. То есть нужно аккуратнее с этим файлом.
Ну а если у тя на каждый запрос в админке сервак задумывается на 10 секунд, естественно никакому хостеру это не понравится. Поэтому снеси буст и посмотри.
И еще - у тебя мультисайт? Может для мультисайта бусту нужны специальные настройки?
Может это и не удивительно, но после вчерашнего общения со службой поддержки на моём кривом английском, может зацепило их сердца, и вот сегодня такая противоположная картина:
«Почему-то подозрения у меня именно на htaccess не знаю. Я вот когда игрался с этим файлом (нужно было перенаправить хитро одну друпаловскую страницу на папку с HTML), дык я много раз писал такие правила, которые зацикливали не знаю, то-ли браузер, то-ли сервер на 5-10 секунд что-ли... и браузер ругался потом и говорил "у вас бесконечное перенаправление". И в тот момент я напрягался потому что понимал, что если зацикливается сервер, то мне хостер за такие вещи может пригрозить пальчиком. То есть нужно аккуратнее с этим файлом. »
Зацикливало Браузер. Хотя, иногда можно и сервер подгрузить, но это вряд ли.
Что касается данной проблемы - просто перегруженный сервер в тапочки.
Ещё как
Причём на долго