Быстрый вопрос. Я протестировал свой домен, используя следующий сайт http://cloudmonitor.ca.com/en/ping.php
Он показал высокие потери пакетов во всех странах. Потеря пакетов 70-100% Означает ли это, что мой сайт загружается медленно или не загружается вообще для пользователей в этих странах?
Короткий ответ: Да.
Длинный ответ: Это зависит.
Нуль это единственная допустимая величина потери пакетов.
Потеря пакетов> 0 указывает на проблему, которую необходимо исследовать.
Небольшая потеря пакетов (<5%, иногда) может замедлить работу веб-сайтов (с задержки ретрансляции или потерянные запросы DNS), но средний пользователь, вероятно, этого не заметит.
Умеренная потеря пакетов (до 10%, происходит нерегулярно) часто будет заметна. Сайт будет «медленным».
Высокая потеря пакетов (> 10%, полурегулярно / постоянно) приведет ваших пользователей в ярость. Веб-сайт будет загружаться долго или может не загрузиться совсем. Вероятно, это будет настолько мучительно медленно, что люди перестанут посещать.
Вы не испытываете "высокую" потерю пакетов - вы испытываете ЭКСТРЕМАЛЬНЫЙ потеря пакетов (70 +% того, что вы отправляете, никогда не попадет туда, куда идет - если бы UPS работал таким образом, вы бы никогда больше с ними ничего не отправили).
Я ожидал НИЧЕГО работать с такой серьезной потерей пакетов, как вы утверждаете - вы фактически не подключены к Интернету.
Мой вам совет - исправить ситуацию с потерей пакетов (т.е. «Найдите нового провайдера»).
То, что вы описываете, совершенно неприемлемо.
То, что ваш веб-сервер плохо отвечает на запросы ping, никак не влияет на его производительность как веб сервер. Если вы специально не разработали его так, чтобы он хорошо реагировал на пинги, нет причин ожидать, что он будет так хорошо работать, или беспокоиться о том, что это не так.
Обновить: Похоже, что нет никакой координации между кем бы то ни было, управляющим вашим сервером, и кем бы то ни было, измеряющим его производительность. Я был бы очень обеспокоен тем, что конфигурация брандмауэра не очень хорошо продумана и может блокировать такие вещи, как определение MTU пути.
Есть несколько вещей, которые вы можете сделать, чтобы узнать, является ли он вашим провайдером веб-хостинга или находится ли он в паре шагов от конечной точки вашего сервера. Я рекомендую войти на ваш сервер, на котором размещен ваш сайт (при условии, что вы действительно можете войти в него) и запустить mtr для различных доменов (это также предполагает, что вы используете какой-то вариант Linux, хотя я думаю, что для Windows есть MTR).
пример команды будет выглядеть так: mtr somedomainhere.com
Я бы порекомендовал различные сайты, такие как google, amazon, facebook или какой-либо другой хорошо известный сервер, который, скорее всего, будет отвечать на эхо-запросы ICMP.
если вы хотите работать только в течение определенного периода времени, вы можете использовать флаг -c для установки количества пакетов.
пример: mtr -c 500 somedomainhere.com
если вы хотите запустить его и посмотреть позже, вы можете использовать переключатель --report и сохранить его в текстовый файл.
пример: mtr -c 500 somedomainhere.com --report >> mtrReport.txt
Если у вас нет прав администратора, вы можете спросить провайдера веб-хостинга, могут ли они запустить его для вас и предоставить вам данные отчета. Это хорошее место для начала при попытке устранить неполадки с подключением.
использование этого инструмента поможет точно определить ГДЕ пакеты сбрасываются и кто виноват в потере пакетов. Если вы определили, что пакеты отбрасываются на вашем сервере, вы можете приступить к следующим шагам.
Если запуск mtr с вашего сервера на внешние серверы не приводит к потере пакетов, пакеты, скорее всего, фильтруются на вашем брандмауэре. Я бы порекомендовал запустить еще один mtr с вашего локального компьютера на сервер, чтобы узнать, есть ли и где потеря пакетов ... если это происходит на последнем прыжке или не происходит вообще, вы знаете, что проблема заключается в вашем веб-сервере, и вы можете переместить переходим к следующим шагам ... если вы получаете потерю пакетов где-то еще, вы можете быть уверены, что проблема связана с сетью.
Следующие шаги:
посмотрите журналы
посмотрите конфигурацию брандмауэра
посмотрите файлы конфигурации для вашего веб-сервера