Все ругают мастерхост, но я добился хорошей работы системы на тарифе «Эффективный».
Система отменно работает после 24:00 и до 08:00, с редкими перебоями и отказом в
доступе где-то в районе 3:00-4:00 - видимо это чей-то cron. Я позвонил в поддержку
лишь после того, как стал получать отказ в доступе к shell и FTP. MySQL работал,
но оно и понятно - другой сервер этим занят. В поддержке сказали, что сервер лежит,
они знают и чинят проблему. На мою просьбу дать письменное «оправдание» мне дали
совет написать «заявку», те кто не знает, это вполне мудрая и правильная система
документооборота у masterhost. К сожалению я почувствовал себя полным идиотом,
когда через 7 часов (в 12:00) мне ответили «всё работает, никаких сбоев небыло»,
а на вопрос, «почему в системе до сих пор нет error_log за этот самый "ничего небыло"
период» рекомендовали «обратиться к разработчику сайта». Но я сам себе так и не
смог дать ответ. Но песнь моя не про это.
Так вот, удивительно то, что в эти самые ночные часы debug меня радует, да и сама
выдача файлов сервером, по словам YSlow, отличная. А это 280Кб для первой страницы
со слайдшоу, из которых 210Кб лежат на стороннем бесплатном файлхостинге, более
быстром чем наша платная площкадка.
Естественно, я прочесал всю систему и отключил даже такие неиспользуемые плагины,
как Pagebreak, если они мной не используются и кеширование настроена без малого на
300 Минут и включено кеширование тех модулей, которые действительно нужно и можно
кешировать, да и нет у меня VirtueMart'a. SEF - стандартный, балого хватает, ну
если только JoomFish, но и у этого брата всё что надо кешируется. Анализ SQL
запросов никогда небыл дольше 0.0666 секунд, даже для столь тяжелого урода, как
Joomla XMAP (он кешируется также).
Т.е. дело точно не в запросах и не шаблонах, т.к. я даже условную загрузку модулей
сделала по If(). В общем - красавчик на 5-. Всё это дало мне в указанные ночные часы
такой вот debug:
Profile Information
Application afterLoad: 0.009 seconds, 0.25 MB
Application afterInitialise: 0.169 seconds, 2.82 MB
Application afterRoute: 0.192 seconds, 3.30 MB
Application afterDispatch: 0.526 seconds, 5.65 MB
Application afterRender: 0.664 seconds, 6.11 MB
т.е. такой тайм-шифт (промежутки времени по контрольным точкам)
0,009 / 0,16 / 0,023 / 0,334 / 0,138
Хорошо? Приемлемо? Те, кому еще не столь понятен debug CMS Joomla или уже забыл то,
что все знаю, но никто никому не рассказывает - о значении в формате «снизу вверх».
Вся информация получена из /index.php в корне сайта:
Application afterRender - «на твой html»
Application afterDispatch - «всё, что компоненты наработали, кладём в шаблон»
Application afterRoute - «так, всё ясно. компоненты, собирайте то, что нужно юзеру»
Application afterInitialise - «так, кто ты и на каком языке с тобой говорить?»
Application afterLoad - «погоди, ща подцеплю defines.php и framework.php»
Тук-тук-тук. Есть кто? - «доброе утро, сервер, слушаю. что? index.php?»
Вот, вроде всё ясно и честно: больше всего разрыв в скорости там, где компоненты
начинают свою работу, а сама выдача их результатов - уже не столь великий труд.
Однако же, друзья мои, что произошло через 30 секунд, когда всё это кешированное
хозяйство было пробуждено нажатием F5 - обновлением страницы в браузере:
Profile Information
Application afterLoad: 0.172 seconds
Application afterInitialise: 2.098 seconds
Application afterRoute: 2.425 seconds
Application afterDispatch: 3.133 seconds
Application afterRender: 4.533 seconds
и тайм-шифт:
0,172 / 1,926 / 0,327 / 0,708 / 1,4
Э, э, э!!! Чё за уличная магия? Чё за в «7 раз медленнее»? За какое? Мне еще этот
хлам в 280Кб по каналам слать впервой пользователю - аж под 5 секунд время убью +
ни за что 4 секунды накинули. Алё? Жму еще раз F5 - обновляю страницу:
Application afterLoad: 0.017 seconds, 0.25 MB
Application afterInitialise: 0.606 seconds, 2.82 MB
Application afterRoute: 0.784 seconds, 3.30 MB
Application afterDispatch: 3.041 seconds, 4.98 MB
Application afterRender: 5.307 seconds, 5.32 MB
и тайм-шифт:
0,017 / 0,589 / 0,178 / 2,257 / 2,266
Так повторяется в течении 10 минут. Часа. С перерывами и без. Иногда весь день.
Бывает что сериями в 9:00-10:00, в 14:00-16:00, в 17:00-19:00.
Так выглядит серия из n-опытов в течении часа:
Абсолютное время, сек. ∆, сек.Application afterLoad: 0,0090,1720,0170,1540,0060,0090,1720,0170,1540,006Application afterInitialise: 0,1692,0980,6062,3220,1340,1601,9260,5892,1680,128Application afterRoute: 0,1922,4250,7842,9980,1630,0230,3270,1780,6760,029Application afterDispatch: 0,5263,1333,0416,4140,2330,3340,7082,2573,4160,070Application afterRender: 0,6644,5335,3078,2040,4060,1381,4002,2661,7900,173ИТОГО: 0,6644,5335,3078,2040,406
Максимум что было – 20 сек. После чего сервер шлёт лесом Error 503, за перегруженный
в 10% процессор. И это при том, что весь контент лежит в готовеньких кешированых статичных файлах, которые отдаваться должны на 0,0раз-0,0два-0,0три.
И главное теперь не только найти, как устранить эти проблемы владельцу сайта, но и донести
до него мысль, что проблемы не в качестве моей работы (я бонусом провел всяческую оптимизацию),
а в непостоянстве качества услуг провайдера такого большого и уважаемого провайдера, на
площадках которого у клиента еще 5 проектов и все летают за считанные секунды. Как принудить
masterhost перенести сайт на более стабильную серверную площадку и грамотно мотивировать это
объективными фактами, что бы мне не говорили, что это я «испортил» Joomla в раковые для меня
10, 15 и 18 часов.
Внедряльщик Joomla в мастерхостовское чрево,
Дмитрий Чечик
webmaster@tc-audio.com
www.tc-audio.comДля особо интересующихся – прилагаю dump запросов SQL. Если будут крайне заинтересованные –
готов предоставить backup всего сайта для экспериментов. Это 9Мб в tar.gz на всю файловую часть
и дамп в 500Кб на SQL.
5 queries logged
1.
SELECT template
FROM jos_templates_menu
WHERE client_id = 0
AND (menuid = 0 OR menuid = 1139)
ORDER BY menuid DESC
LIMIT 0, 1
2.
SELECT a.*, u.name AS author, u.usertype, cc.title AS category, s.title AS section,
CASE WHEN CHAR_LENGTH(a.alias) THEN CONCAT_WS(":", a.id, a.alias) ELSE a.id
END AS slug, CASE WHEN CHAR_LENGTH(cc.alias) THEN CONCAT_WS(":", cc.id, cc.alias)
LSE cc.id END AS catslug, g.name AS groups, s.published AS sec_pub, cc.published AS
cat_pub, s.access AS sec_access, cc.access AS cat_access
FROM jos_content AS a
LEFT JOIN jos_categories AS cc
ON cc.id = a.catid
LEFT JOIN jos_sections AS s
ON s.id = cc.section
AND s.scope = "content"
LEFT JOIN jos_users AS u
ON u.id = a.created_by
LEFT JOIN jos_groups AS g
ON a.access = g.id
WHERE a.id = 11
AND ( ( a.created_by = 0 ) OR ( a.state = 1
AND ( a.publish_up = '0000-00-00 00:00:00' OR a.publish_up <= '2009-05-28 13:10:36' )
AND ( a.publish_down = '0000-00-00 00:00:00' OR a.publish_down >= '2009-05-28 13:10:36' ) ) OR ( a.state = -1 ) )
3.
SELECT jf_content.reference_field, jf_content.value, jf_content.reference_id, jf_content.original_value
FROM jos_jf_content AS jf_content
WHERE jf_content.language_id=1
AND jf_content.published=1
AND jf_content.reference_id IN(11)
AND jf_content.reference_table='content'
4.
UPDATE jos_content
SET hits = ( hits + 1 )
WHERE id='11'
5.
SELECT id, title, module, position, content, showtitle, control, params
FROM jos_modules AS m
LEFT JOIN jos_modules_menu AS mm
ON mm.moduleid = m.id
WHERE m.published = 1
AND m.access <= 0
AND m.client_id = 0
AND ( mm.menuid = 1139 OR mm.menuid = 0 )
ORDER BY position, ordering
19.01.2024, 19:44:50