Проблема со скоростью. Ошибка в вебмастере, то появляется, то исчезает без изменений на сайте.

Аватар пользователя alexo alexo 28 сентября в 17:38

Для сайта одностраничника на Друпал 7 в Яндекс вебмастере выдается сообщение о проблеме со скоростью загрузки.
Так как на сайте ничего не меняется, а ошибка то появляется, то исчезает, возникает мысли, что все же дело в сервере (shared с выгодной ценой, в названии имеет fast... не хочу писать фирму, так ка к дело может быть все же не в нем, у них там SSD и т.д., т.е. они именно скоростью себя позиционируют) Может ли быть что проблема именно из-за недонастроенности их сервера для Друпал?
Т.е. я понимаю, что из-за неверных натсроек фронтэнда может тормозить, но здесь речь идет о том, что вообще ошибки выдаются.
Пытаться найти проблему или переезжать на другой сервер сразу?

В Гугл инсайтс ... developers.google.com/speed/pagespeed/insights
вообще выдается ошибка
время ответа огромное

На другом Друпал сайте на том же сервере аналогичная проблема.

На пустом сайте без Друпала (заглушка только)на том же сервере - 100% в Гугл инсайтс developers.google.com/speed/pagespeed/insights
На https://gtmetrix.com оба сайта нормально вроде отображаются около 70% время ответа от нескольких секунд

Это проблема взаимодействия сервера с Друпалом?

После запроса в службу поддержки сайт неожиданно стал нормально отображаться в Гугл инсайтс, правда они не говорят (можно даже сказать не признаются) о том, что меняли какие-то настройки.
Что делать?

0 Thanks

Комментарии

Аватар пользователя alexo alexo 28 сентября в 18:53

А какой лучше выбрать с соотношением невысокой цены за объем занимаемого места жесткого диска и приемлимой заточенностью под Друпал?

Аватар пользователя ivnish ivnish 28 сентября в 19:05
2

Лично я использую хостинг от Радон (нет ограничения по диску, но есть ограничение по трафику) и от таймвеб (нет ограничения по трафику, но есть ограничение по диску)

Оба хостинги заточены под друпал и имеют все необходимые инструменты

Аватар пользователя alexo alexo 15 октября в 14:13

Спасибо за рекомендацию timeweb. Не могу понять по файловой системе с public_html. У них файлы сайта не в корне по инструкции, а в public_html.
А если я захочу потом перенести на хостинг, где Друпал сразу в корне сайта нужно настраивать, то файлы будут нормально открываться?

Аватар пользователя ivnish ivnish 15 октября в 14:15

У всех нормальных хостеров сайты лежат не в корне домашнего каталога пользователя, а в каком-нибудь каталоге, например public_html

При переносе сайта на другой хостинг проблем не будет

Аватар пользователя alexo alexo 15 октября в 16:37

Спасибо. Вы имеете ввиду если Друпал лежит сразу в папке public_html?

А я имею ввиду, случай когда на одном аккаунте более одного сайта, тогда получится, что у дополнительного сайта "корень" Друпала будет лежать не просто в public_html ,

а в /new-site/public_html

Так как не только в корне домашнего каталога пользователя, но и внутри папки дополнительного сайта они тоже рекомендуют класть в папку public_html

У них так написано:
"/public_html - директория для файлов главного сайта;
• /new-site - директория для дополнительного сайта;
• /new-site/public_html - директория для файлов дополнительного сайта"

Есть же например Друпал хостинги, где
domains - папка для всех сайтов
/new-site - для дополнительного сайта;
и Друпал лежит прям в domains/new-site/

Аватар пользователя ivnish ivnish 15 октября в 16:41
1

Лично я считаю, что когда "на одном аккаунте много сайтов", то это очень плохая практика. Если один сайт будет вломан и заражен, то он сможет спокойно аразить все остальные сайты тупо через доступ к их файлам.

Да, когда несколько сайтов на аккаунте, то часто один смотрит в public_html, а остальные уже в подкаталдогах находятся

В чем ваш вопрос не совсем понимаю, если честно. Поясните)

Аватар пользователя alexo alexo 15 октября в 17:29

Спасибо. Ясно. Буду стараться на разные аккаунты выделать разные сайты со временем.
Вопрос был о том, могут ли быть потом сложности с файлами и путями если структура каталогов поменяется с
расположения Друпала в

/new-site/public_html/

например на

domains/new-site/

Аватар пользователя ivnish ivnish 15 октября в 17:31
1

Если веб-сервер будет считать эти каталоги в качестве web-root, то вообще без разницы.

Проблемы могут возникнуть только если где-то в коде будут прописаны абсолютные пути

Аватар пользователя alexo alexo 15 октября в 21:29

Спасибо.
Мне просто не встречалось раньше, чтобы Друпал располагался для дополнительных сайтов внутри папки /new-site/public_html/

Вы имеете ввиду под web-root корень сайта с Друпалом (или корень аккаунта)?
Т.е. нужно уточнить в timeweb, является ли /new-site/public_html/ "вебрутом"?

Аватар пользователя ivnish ivnish 15 октября в 22:15

Мне просто не встречалось раньше, чтобы Друпал располагался для дополнительных сайтов внутри папки /new-site/public_html/

Это исключительно от хостинга зависит. У таймвеба с этим нет проблем

Аватар пользователя alexo alexo 16 октября в 0:53

Спасибо.
А какую версию php Вы там выбираете с учетом рекомендаций для Друпал 7 и необходимости работать с драш?
рекомендация 1

рекомендация 2

Аватар пользователя ivnish ivnish 16 октября в 9:27
1

У меня все сайты работают на PHP 7.2, но все они обновлены и актуальны. Если у вас будет ядро 2015 года, то, конечно, с 7.2 оно работать не будет.

drush нужно выбирать исходя из версии drupal. Для drupal 7 нужен drush 8, а для drupal 8 нужен drush 9

drush 10 ещё в бета версии и я не рекомендую его использовать

Аватар пользователя alexo alexo 28 сентября в 18:57

Как Вы думаете дело именно в самом сервере и его настройках, а не в расположении геогрфическом?
Просто у меня сейчас сервер выбран в Сингапуре, а у этого же провайдера есть серверы в других местах. Но раз пустой сайт нормально работает на том же сервере и в Гугл инсайтс на 100%, то наверное все же дело именно в несовместимости с Друпал, а не в географии?

Аватар пользователя Semantics Semantics 28 сентября в 19:34
1

Яндекс скорость фронта не замеряет поисковым ботом, просто не умеет.
Включайте кеш, возможно, ваш шаред кто-то иногда подгружает

Аватар пользователя Mnilionic Mnilionic 30 сентября в 15:45
2

Может у вас крон запускается с приходом яндекса каждые 3 часа по дефолту? ;)

Аватар пользователя alexo alexo 7 октября в 16:53

Спасибо. Как это исправить?
Сейчас у меня на странице admin/config/system/cron
"Последний запуск: 6 мин. 6 сек. назад."

В настройке
'Запускать cron каждые" - каждые 3 часа

Аватар пользователя alexo alexo 7 октября в 19:30

0 (ноль) человек в день. Ссылок на сайт нет нигде. В выдаче не выдается. Т.е. ни роботы, ни посетители его пока особо не посещают, перегруза от посещений быть не должно.
Этот сайт кириллический. И еще сейчас на нем такая же проблема
"Когда я вбиваю в поисковую строку целый абзац уникального текста с этой страницы с node2, страница с адресом site.ru/node2 все равно не выдается Яндексом, но выдается Гуглом"

Аватар пользователя alexo alexo 7 октября в 23:08

Обе проблемы из-за крона? И проблемы со скоростью загрузки и то, что в Яндексе не выдается?
Дело в том, что вторая проблема (при вводе целого абзаца в поисковике с адресом URL, страницы все равно нет в выдаче Яндекса), эта проблем есть и на другом сайте, но там все страницы нормально индексируются и в выдаче нормально, а только с одной страницей такая проблема.

Аватар пользователя Mnilionic Mnilionic 7 октября в 18:43
1

На странице настройки крона отключите его (положение "никогда") и согласно инструкции на этой же странице настройки его запуск на стороне хостинга.
Интервал запуска на ваше усмотрение. Если контент добавляется/изменяется не часто, то я обычно ставлю раз в сутки часа на 3 ночи.

Аватар пользователя alexo alexo 7 октября в 19:37

Спасибо. Отключу хотя бы для теста, чтобы узнать, в этом ли дело, и попробую подключить на сервере.

Аватар пользователя marassa marassa 7 октября в 17:01

Если сайт действительно "одностраничник", на котором "ничего не меняется", то зачем на нём вообще крон запускать?

Аватар пользователя ivnish ivnish 7 октября в 17:15
1

Ну как минимум крон обновления проверяет и друпал уведомления шлет о них

Аватар пользователя marassa marassa 7 октября в 18:44
ivnish wrote:

Ну как минимум крон обновления проверяет и друпал уведомления шлет о них

У меня не проверяет почему-то - специально не настраивал, а из коробки вроде нет такого в восьмёрке?
Ну и в любом случае раз в три часа обновления не выходят ;)

Аватар пользователя ivnish ivnish 7 октября в 18:50
2

В восьмерке всё на своих местах

/admin/reports/updates/settings

Ну и в любом случае раз в три часа обновления не выходят ;)

А вообще крон же много чего делает. И обновы проверяет и контент индексирует для поиска и разные уведомления шлет по событиям. Я против отключения крона совсем, но всегда за, если можно настроить крон на сервере.

Аватар пользователя Semantics Semantics 8 октября в 8:02
1

Да не крон это, а банальное вытеснение сайта из опкеша более популярными соседями.
Вообще непонятно откуда эта байка взялась, что крон тормозит сайт, крон дёргаемый через http в этом случае даже бы ускорил.
Серверный в лучшем случае притормозит на момент блокировки таблиц во время ребилда кеша, это несколько мс.
А крон для бедных, что запускается при посещении, так его поисковики не умеют дёргать, уж яндекс точно.

Аватар пользователя ivnish ivnish 8 октября в 9:53

Это не байки. У меня есть сайты (муниципальные) у которых посещаемость 1 человек в 3 часа. И я когда сам заходил, не мог понять почему сайт долго открывается, а потом нормально. Да, это был веб крон. Переключил на серверный и проблема ушла

Аватар пользователя alexo alexo 8 октября в 9:55

Спасибо. Меня беспокоит в первую очередь такая картина в Гугл инсайтс

и критическая ошибка в Яндекс вебмастере

Я не пойму "а банальное вытеснение сайта из опкеша более популярными соседями" это тоже к этому относится? Соседи имеются ввиду соседи на сервере или в выдаче? Как это исправить?
Как это исправить?

Аватар пользователя Semantics Semantics 8 октября в 10:04

Лучше обратитесь к специалисту, пусть отделит мух от котлет.
Вы задаёте вопрос про скорость фронта и скорость бека. PageSpeed/Lighthouse, конечно, учитывает время генерации страницы, но только им 0 баллов не заработать

Аватар пользователя adano adano 8 октября в 9:04

Вообще непонятно откуда эта байка взялась, что крон тормозит сайт

Почему же "байка"?
В действительности, большие проекты при хорошей посещаемости, периодическом кроне с множеством задач, получают проблемы с отказами посещений в аналитике/метрике.
Статья даже где-то была в рунете, как распределяли реальный кейс на ultimate/elysia крон на пиковую посещаемость и получали положительные результаты, с графиками, исследованиями (не вспомню уже что/где/когда).

P.S. Естественно, там где лендинги/визитки, переживать за оптимизацию крона нет смысла. Де-факто, он там практически бесполезен и не заметен.

Аватар пользователя gun_dose gun_dose 8 октября в 9:49
1

У крона есть полезная функция - он удаляет ненужные файлы. Загрузили картинку в поле, потом удалили ноду, крон в течение четырёх часов картинку удалит. Если не запускать крон, картинки останутся в файловой системе. Плюс кэш форм очищается только по крону. Чтобы избежать проблем, возникших у автора, нужно отключить автоматический запуск крона и запускать его через системный крон. Кстати, на некоторых шаред-хостингах тоже есть такая возможность.

А сайт тормозит из-за того, что когда приходит время, при открытии любой страницы сайта сначала запускается крон, а потом уже отдаётся страница - из-за этого и задержка. Если крон запускать системным кроном, то при запросе страниц крон дёргаться не будет. В восьмёрке это сделали более продуманно - там при запросе страницы сначала отдаётся страница, а потом запускается крон, поэтому он на скорость отклика там не влияет никак.

Аватар пользователя ivnish ivnish 8 октября в 9:58

У меня как раз проблемы были именно на Д8. Так что с последним абзацем не соглашусь

Аватар пользователя adano adano 8 октября в 10:31
1

Все что сделано в 8ке - это перемещение крона в отдельный модуль.
Это никуда не делось:

Недостаток автоматизированного модуля cron заключается в том, что он запускается запросом, и незадачливый пользователь, отправляющий запрос, может столкнуться с довольно большой задержкой.

Источник - https://www.drupal.org/docs/8/administering-a-drupal-8-site/cron-automat...

Так что фраза:

В восьмёрке это сделали более продуманно

Является вымышленной.

Аватар пользователя alexo alexo 8 октября в 11:49

Спасибо. А может такое быть что настройка крона по автомату разная в разных инсталяциях или дистрибутивах?

У меня несколько сайтов. Под поисковики было оптимизировано только два последних. Остальные были по прямым заходам. Вот на другом, на котором тоже включен крон, тоже есть такая ошибка. И с поисковиками у него была проблема, просто мне казалось, что это из-за того что он СЕО не оптимизирован. Но возможно обе проблемы имели место.

На еще одном сайте на том же сервере тоже включен крон, но там в Гугл инсайтс 26%. Тоже не много, но не совсем ноль.

Вчера на сайте, о котором шла речь в топике, крон был отключен

В Яндекс Вебмастере запущена новая проверка, результат пока неизвестен. А в Гугл инcайтс пока все так же -
та же ошибка и ноль процентов.

Аватар пользователя gun_dose gun_dose 8 октября в 10:59

Является вымышленной.

Специально для любителей сказок:
Жил был модуль 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);

?>
Аватар пользователя ivnish ivnish 8 октября в 11:02

Это всё замечательно. Но я тебе говорю про реальные ситуации с моими реальными сайтами. При низкой посещаемости веб-крон тормозит открытие сайтов. При его отключении и настройке серверного крона всё приходит в норму. Можно хоть посреди ночи зайти и сайт откроется мгновенно

Аватар пользователя gun_dose gun_dose 8 октября в 11:19

Вот тут уже интересно, почему так. Даже в описании модуля написано

'Provides an automated way to run cron jobs, by executing them at the end of a server response.'

Аватар пользователя alexo alexo 8 октября в 11:52

Спасибо.

ivnish wrote:

При низкой посещаемости веб-крон тормозит открытие сайтов...

Именно при низкой?

Тогда понятно, почему на одном с включенным кроном хуже, на другом лучше. Это из-за этого?

Можно хоть посреди ночи зайти и сайт откроется мгновенно

А как вообще время суток влияет.

Аватар пользователя adano adano 8 октября в 11:35

Все же рекомендую детальней изучить:
https://github.com/symfony/http-kernel

а потом сопоставить с твоей же фразой:

сначала отдаётся страница, а потом запускается крон, поэтому он на скорость отклика там не влияет никак.

Аватар пользователя gun_dose gun_dose 8 октября в 12:05

Там так и написано, как я сказал))

As you can see, by calling $kernel->terminate after sending the response, you will trigger the kernel.terminate event where you can perform certain actions that you may have delayed in order to return the response as quickly as possible to the client (e.g. sending emails).

Другое дело, что

Internally, the HttpKernel makes use of the fastcgi_finish_request PHP function. This means that at the moment, only the PHP FPM server API is able to send a response to the client while the server's PHP process still performs some tasks. With all other server APIs, listeners to kernel.terminate are still executed, but the response is not sent to the client until they are all completed.

Вот этого я не знал. Но это означает, что то, что я говорил, работает лишь при определённой конфигурации сервера, но никак не является вымыслом.

Аватар пользователя adano adano 8 октября в 12:50

Если бы показал какую-то явную асинхронность, то тогда можно было бы принять за реальность... А так, даже оф. документация говорит обратное твоей фразе...

Аватар пользователя adano adano 8 октября в 13:16

Вот когда будет, что-то подобное в коде:

<?php
fastcgi_finish_request
()
?>

Тогда и можешь утверждать подобное.

Аватар пользователя adano adano 8 октября в 13:39

Не сойдет, повторюсь еще раз:
Все же рекомендую углубиться в более детальное изучение архитектуры...

Аватар пользователя gun_dose gun_dose 8 октября в 13:41

Почему не сойдёт? Именно этот метод send вызывается в index.php перед terminate. Что не так?

Аватар пользователя adano adano 8 октября в 15:19

Потому что юзер получит ответ вместе с кроном, как раз в самом terminate.

Аватар пользователя gun_dose gun_dose 8 октября в 16:08
1

Ну в коде же стоит вызов fastcgi_finish_request. С каких пор мануал стал важнее кода?)) Все доказательства, которые вы просили, я привёл, чего вам ещё надо то?

Могу даже объяснить по-быстрому - в пхпшторме в index.php нажимаем ctrl и в предпоследней строчке тыкаем на слово send)))

Аватар пользователя adano adano 8 октября в 16:43

Я тебе все разъяснил. Просто ты любыми, даже смешными способами пытаешься этого не видеть.
У тебя стандартная реакция: "стрелки" в сторону и три скобочки в сообщении )))

которые вы просили

Опять выдумываешь. Я тебя ни о чем не просил.

Аватар пользователя gun_dose gun_dose 8 октября в 16:58

Что ты мне разъяснил?

Вот когда будет, что-то подобное в коде:
fastcgi_finish_request()
Тогда и можешь утверждать подобное.

Вот ссылка на фрагмент кода, где это используется.
Для ленивых процитирую:

<?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(0true);
        }
        return 
$this;
    }

?>

И этот метод дёргается напрямую из index.php. Пока что смешно тут только то, как отчаянно ты пытаешься отрицать свою ошибку.

Аватар пользователя gun_dose gun_dose 8 октября в 17:17
1

На одну строчку выше идёт вызов send, в котором идёт fastcgi_finish_request. То есть он вызывается раньше, чем terminate, соответственно при наличии fastcgi ответ юзеру уходит раньше, чем вызывается terminate. Неужели это непонятно?

Аватар пользователя Andruxa Andruxa 8 октября в 11:33

А что со сроком жизни кеша?
Может, периодическая задержка связана с тем, что кеш просрочен, и в этот момент ребилдится заново?

Аватар пользователя Andruxa Andruxa 8 октября в 12:00
1

Раз кеш был отключен, то дело не в его ребилде. Но включить все равно не помешает.
Если это одностраничник со статикой - то можно и побольше срок жизни кеша сделать.