28 сентября 2019 в 17:38
Для сайта одностраничника на Друпал 7 в Яндекс вебмастере выдается сообщение о проблеме со скоростью загрузки.
Так как на сайте ничего не меняется, а ошибка то появляется, то исчезает, возникает мысли, что все же дело в сервере (shared с выгодной ценой, в названии имеет fast... не хочу писать фирму, так ка к дело может быть все же не в нем, у них там SSD и т.д., т.е. они именно скоростью себя позиционируют) Может ли быть что проблема именно из-за недонастроенности их сервера для Друпал?
Т.е. я понимаю, что из-за неверных натсроек фронтэнда может тормозить, но здесь речь идет о том, что вообще ошибки выдаются.
Пытаться найти проблему или переезжать на другой сервер сразу?
В Гугл инсайтс ... developers.google.com/speed/pagespeed/insights
вообще выдается ошибка
время ответа огромное
На другом Друпал сайте на том же сервере аналогичная проблема.
На пустом сайте без Друпала (заглушка только)на том же сервере - 100% в Гугл инсайтс developers.google.com/speed/pagespeed/insights
На https://gtmetrix.com оба сайта нормально вроде отображаются около 70% время ответа от нескольких секунд
Это проблема взаимодействия сервера с Друпалом?
После запроса в службу поддержки сайт неожиданно стал нормально отображаться в Гугл инсайтс, правда они не говорят (можно даже сказать не признаются) о том, что меняли какие-то настройки.
Что делать?
| Вложение | Размер |
|---|---|
 2019-09-28_16-22-58.png | 14.49 КБ |
| ошибка | 73.27 КБ |
| ошибка | 63.74 КБ |
| Гугл инсайтс, было | 2.87 КБ |
| Гугл инсайтс, преображение сразу после запроса на хостинг в службу поддержки | 5.37 КБ |
Комментарии
Видимо, менять хостинг на другой
А какой лучше выбрать с соотношением невысокой цены за объем занимаемого места жесткого диска и приемлимой заточенностью под Друпал?
Лично я использую хостинг от Радон (нет ограничения по диску, но есть ограничение по трафику) и от таймвеб (нет ограничения по трафику, но есть ограничение по диску)
Оба хостинги заточены под друпал и имеют все необходимые инструменты
Спасибо за рекомендацию timeweb. Не могу понять по файловой системе с public_html. У них файлы сайта не в корне по инструкции, а в public_html.
А если я захочу потом перенести на хостинг, где Друпал сразу в корне сайта нужно настраивать, то файлы будут нормально открываться?
У всех нормальных хостеров сайты лежат не в корне домашнего каталога пользователя, а в каком-нибудь каталоге, например public_html
При переносе сайта на другой хостинг проблем не будет
Спасибо. Вы имеете ввиду если Друпал лежит сразу в папке public_html?
А я имею ввиду, случай когда на одном аккаунте более одного сайта, тогда получится, что у дополнительного сайта "корень" Друпала будет лежать не просто в public_html ,
а в /new-site/public_html
Так как не только в корне домашнего каталога пользователя, но и внутри папки дополнительного сайта они тоже рекомендуют класть в папку public_html
У них так написано:
"/public_html - директория для файлов главного сайта;
• /new-site - директория для дополнительного сайта;
• /new-site/public_html - директория для файлов дополнительного сайта"
Есть же например Друпал хостинги, где
domains - папка для всех сайтов
/new-site - для дополнительного сайта;
и Друпал лежит прям в domains/new-site/
Лично я считаю, что когда "на одном аккаунте много сайтов", то это очень плохая практика. Если один сайт будет вломан и заражен, то он сможет спокойно аразить все остальные сайты тупо через доступ к их файлам.
Да, когда несколько сайтов на аккаунте, то часто один смотрит в public_html, а остальные уже в подкаталдогах находятся
В чем ваш вопрос не совсем понимаю, если честно. Поясните)
Спасибо. Ясно. Буду стараться на разные аккаунты выделать разные сайты со временем.
Вопрос был о том, могут ли быть потом сложности с файлами и путями если структура каталогов поменяется с
расположения Друпала в
/new-site/public_html/
например на
domains/new-site/
Если веб-сервер будет считать эти каталоги в качестве web-root, то вообще без разницы.
Проблемы могут возникнуть только если где-то в коде будут прописаны абсолютные пути
Спасибо.
Мне просто не встречалось раньше, чтобы Друпал располагался для дополнительных сайтов внутри папки /new-site/public_html/
Вы имеете ввиду под web-root корень сайта с Друпалом (или корень аккаунта)?
Т.е. нужно уточнить в timeweb, является ли /new-site/public_html/ "вебрутом"?
Это исключительно от хостинга зависит. У таймвеба с этим нет проблем
Спасибо.
А какую версию php Вы там выбираете с учетом рекомендаций для Друпал 7 и необходимости работать с драш?
рекомендация 1
рекомендация 2
У меня все сайты работают на PHP 7.2, но все они обновлены и актуальны. Если у вас будет ядро 2015 года, то, конечно, с 7.2 оно работать не будет.
drush нужно выбирать исходя из версии drupal. Для drupal 7 нужен drush 8, а для drupal 8 нужен drush 9
drush 10 ещё в бета версии и я не рекомендую его использовать
Как Вы думаете дело именно в самом сервере и его настройках, а не в расположении геогрфическом?
Просто у меня сейчас сервер выбран в Сингапуре, а у этого же провайдера есть серверы в других местах. Но раз пустой сайт нормально работает на том же сервере и в Гугл инсайтс на 100%, то наверное все же дело именно в несовместимости с Друпал, а не в географии?
Яндекс скорость фронта не замеряет поисковым ботом, просто не умеет.
Включайте кеш, возможно, ваш шаред кто-то иногда подгружает
Может у вас крон запускается с приходом яндекса каждые 3 часа по дефолту?
Спасибо. Как это исправить?
Сейчас у меня на странице admin/config/system/cron
"Последний запуск: 6 мин. 6 сек. назад."
В настройке
'Запускать cron каждые" - каждые 3 часа
А какая посещаемость у сайта? Сколько человек/ботов в час?
0 (ноль) человек в день. Ссылок на сайт нет нигде. В выдаче не выдается. Т.е. ни роботы, ни посетители его пока особо не посещают, перегруза от посещений быть не должно.
Этот сайт кириллический. И еще сейчас на нем такая же проблема
"Когда я вбиваю в поисковую строку целый абзац уникального текста с этой страницы с node2, страница с адресом site.ru/node2 все равно не выдается Яндексом, но выдается Гуглом"
А, дак это 146% крон, как и предположил @Mnilionic
Обе проблемы из-за крона? И проблемы со скоростью загрузки и то, что в Яндексе не выдается?
Дело в том, что вторая проблема (при вводе целого абзаца в поисковике с адресом URL, страницы все равно нет в выдаче Яндекса), эта проблем есть и на другом сайте, но там все страницы нормально индексируются и в выдаче нормально, а только с одной страницей такая проблема.
На странице настройки крона отключите его (положение "никогда") и согласно инструкции на этой же странице настройки его запуск на стороне хостинга.
Интервал запуска на ваше усмотрение. Если контент добавляется/изменяется не часто, то я обычно ставлю раз в сутки часа на 3 ночи.
Спасибо. Отключу хотя бы для теста, чтобы узнать, в этом ли дело, и попробую подключить на сервере.
Если сайт действительно "одностраничник", на котором "ничего не меняется", то зачем на нём вообще крон запускать?
Ну как минимум крон обновления проверяет и друпал уведомления шлет о них
У меня не проверяет почему-то - специально не настраивал, а из коробки вроде нет такого в восьмёрке?
Ну и в любом случае раз в три часа обновления не выходят
В восьмерке всё на своих местах
/admin/reports/updates/settings
А вообще крон же много чего делает. И обновы проверяет и контент индексирует для поиска и разные уведомления шлет по событиям. Я против отключения крона совсем, но всегда за, если можно настроить крон на сервере.
Да не крон это, а банальное вытеснение сайта из опкеша более популярными соседями.
Вообще непонятно откуда эта байка взялась, что крон тормозит сайт, крон дёргаемый через http в этом случае даже бы ускорил.
Серверный в лучшем случае притормозит на момент блокировки таблиц во время ребилда кеша, это несколько мс.
А крон для бедных, что запускается при посещении, так его поисковики не умеют дёргать, уж яндекс точно.
Это не байки. У меня есть сайты (муниципальные) у которых посещаемость 1 человек в 3 часа. И я когда сам заходил, не мог понять почему сайт долго открывается, а потом нормально. Да, это был веб крон. Переключил на серверный и проблема ушла
Спасибо. Меня беспокоит в первую очередь такая картина в Гугл инсайтс
и критическая ошибка в Яндекс вебмастере
Я не пойму "а банальное вытеснение сайта из опкеша более популярными соседями" это тоже к этому относится? Соседи имеются ввиду соседи на сервере или в выдаче? Как это исправить?
Как это исправить?
Лучше обратитесь к специалисту, пусть отделит мух от котлет.
Вы задаёте вопрос про скорость фронта и скорость бека. PageSpeed/Lighthouse, конечно, учитывает время генерации страницы, но только им 0 баллов не заработать
Почему же "байка"?
В действительности, большие проекты при хорошей посещаемости, периодическом кроне с множеством задач, получают проблемы с отказами посещений в аналитике/метрике.
Статья даже где-то была в рунете, как распределяли реальный кейс на ultimate/elysia крон на пиковую посещаемость и получали положительные результаты, с графиками, исследованиями (не вспомню уже что/где/когда).
P.S. Естественно, там где лендинги/визитки, переживать за оптимизацию крона нет смысла. Де-факто, он там практически бесполезен и не заметен.
Действительно большие проекты не задаются вопросами, что в топике.
У крона есть полезная функция - он удаляет ненужные файлы. Загрузили картинку в поле, потом удалили ноду, крон в течение четырёх часов картинку удалит. Если не запускать крон, картинки останутся в файловой системе. Плюс кэш форм очищается только по крону. Чтобы избежать проблем, возникших у автора, нужно отключить автоматический запуск крона и запускать его через системный крон. Кстати, на некоторых шаред-хостингах тоже есть такая возможность.
А сайт тормозит из-за того, что когда приходит время, при открытии любой страницы сайта сначала запускается крон, а потом уже отдаётся страница - из-за этого и задержка. Если крон запускать системным кроном, то при запросе страниц крон дёргаться не будет. В восьмёрке это сделали более продуманно - там при запросе страницы сначала отдаётся страница, а потом запускается крон, поэтому он на скорость отклика там не влияет никак.
У меня как раз проблемы были именно на Д8. Так что с последним абзацем не соглашусь
Все что сделано в 8ке - это перемещение крона в отдельный модуль.
Это никуда не делось:
Источник - https://www.drupal.org/docs/8/administering-a-drupal-8-site/cron-automat...
Так что фраза:
Является вымышленной.
Спасибо. А может такое быть что настройка крона по автомату разная в разных инсталяциях или дистрибутивах?
У меня несколько сайтов. Под поисковики было оптимизировано только два последних. Остальные были по прямым заходам. Вот на другом, на котором тоже включен крон, тоже есть такая ошибка. И с поисковиками у него была проблема, просто мне казалось, что это из-за того что он СЕО не оптимизирован. Но возможно обе проблемы имели место.
На еще одном сайте на том же сервере тоже включен крон, но там в Гугл инсайтс 26%. Тоже не много, но не совсем ноль.
Вчера на сайте, о котором шла речь в топике, крон был отключен
В Яндекс Вебмастере запущена новая проверка, результат пока неизвестен. А в Гугл инcайтс пока все так же -
та же ошибка и ноль процентов.
Специально для любителей сказок:
Жил был модуль automated_cron и был он подписан на одно событие.
И вызывалось это событие в HttpKernel symfony в методе terminate
Который, в свою очередь, вызывался в index.php
но лишь после отправки ответа:
<?php/**
* @file
* The PHP page that serves all page requests on a Drupal installation.
*
* All Drupal code is released under the GNU General Public License.
* See COPYRIGHT.txt and LICENSE.txt files in the "core" directory.
*/ use Drupal\Core\DrupalKernel;
use Symfony\Component\HttpFoundation\Request; $autoloader = require_once 'autoload.php'; $kernel = new DrupalKernel('prod', $autoloader); $request = Request::createFromGlobals();
$response = $kernel->handle($request);
$response->send(); $kernel->terminate($request, $response); ?>
Это всё замечательно. Но я тебе говорю про реальные ситуации с моими реальными сайтами. При низкой посещаемости веб-крон тормозит открытие сайтов. При его отключении и настройке серверного крона всё приходит в норму. Можно хоть посреди ночи зайти и сайт откроется мгновенно
Вот тут уже интересно, почему так. Даже в описании модуля написано
Спасибо.
Именно при низкой?
Тогда понятно, почему на одном с включенным кроном хуже, на другом лучше. Это из-за этого?
А как вообще время суток влияет.
Все же рекомендую детальней изучить:
https://github.com/symfony/http-kernel
а потом сопоставить с твоей же фразой:
Там так и написано, как я сказал))
Другое дело, что
Вот этого я не знал. Но это означает, что то, что я говорил, работает лишь при определённой конфигурации сервера, но никак не является вымыслом.
Если бы показал какую-то явную асинхронность, то тогда можно было бы принять за реальность... А так, даже оф. документация говорит обратное твоей фразе...
Ну где ж обратное? Написано, что работает с PHP FPM
Вот когда будет, что-то подобное в коде:
<?phpfastcgi_finish_request()
?>
Тогда и можешь утверждать подобное.
Так сойдёт?
Не сойдет, повторюсь еще раз:
Все же рекомендую углубиться в более детальное изучение архитектуры...
Почему не сойдёт? Именно этот метод send вызывается в index.php перед terminate. Что не так?
Потому что юзер получит ответ вместе с кроном, как раз в самом terminate.
Почему? Там же вызывается fastcgi_finish_request
Надоело уже одно и то же талдычить...
Короче, следуйте документации - https://www.drupal.org/docs/8/administering-a-drupal-8-site/cron-automat...
И не выдумывайте всякую херню.
Ну в коде же стоит вызов fastcgi_finish_request. С каких пор мануал стал важнее кода?)) Все доказательства, которые вы просили, я привёл, чего вам ещё надо то?
Могу даже объяснить по-быстрому - в пхпшторме в index.php нажимаем ctrl и в предпоследней строчке тыкаем на слово send)))
Я тебе все разъяснил. Просто ты любыми, даже смешными способами пытаешься этого не видеть.
У тебя стандартная реакция: "стрелки" в сторону и три скобочки в сообщении )))
Опять выдумываешь. Я тебя ни о чем не просил.
Что ты мне разъяснил?
Вот ссылка на фрагмент кода, где это используется.
Для ленивых процитирую:
<?php// index.php line 20
$response->send();
?>
<?php// symfony/http-foundation/Response.php line 366
/**
* Sends HTTP headers and content.
*
* @return $this
*/
public function send()
{
$this->sendHeaders();
$this->sendContent();
if (\function_exists('fastcgi_finish_request')) {
fastcgi_finish_request();
} elseif (!\in_array(\PHP_SAPI, ['cli', 'phpdbg'], true)) {
static::closeOutputBuffers(0, true);
}
return $this;
} ?>
И этот метод дёргается напрямую из index.php. Пока что смешно тут только то, как отчаянно ты пытаешься отрицать свою ошибку.
Прям как котенка в саки тыкать надо:
<?php$kernel->terminate($request, $response);
?>
На одну строчку выше идёт вызов send, в котором идёт fastcgi_finish_request. То есть он вызывается раньше, чем terminate, соответственно при наличии fastcgi ответ юзеру уходит раньше, чем вызывается terminate. Неужели это непонятно?
А что со сроком жизни кеша?
Может, периодическая задержка связана с тем, что кеш просрочен, и в этот момент ребилдится заново?
Кэш был выключен. Не помню, почему. Сейчас включен
Раз кеш был отключен, то дело не в его ребилде. Но включить все равно не помешает.
Если это одностраничник со статикой - то можно и побольше срок жизни кеша сделать.