время отклика ping

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

Это было бы - порт 80 для http, 443 для https в случае необходимости, порт 20/21 для FTP.

И получите кого-то, кого можно позвать конфигурацию.В самом деле. И учитесь от него - develoeprs, должен знать основы сетевого администратора.

И в следующий раз - спрашивают относительно servervault.

1
задан 18 August 2011 в 08:00
6 ответов

Выполните переход от веб-сервера к серверу базы данных и посмотрите, где сообщается о замедлении. Затем подтвердите, выполнив переход от сервера базы данных к веб-интерфейсу. Используйте IP-адреса узлов, а не DNS-имена. Как указал Уомбл, это может быть замедление rDNS.

FYI, pathping, как и tracert, может предоставлять ложную информацию о пути просто на основе того, как пакеты могут быть маршрутизированы в одну сторону вперед и в другую сторону в обратном направлении в зависимости от перегрузки сети. Кроме того, не гарантируется, что прямой путь будет одинаковым с каждым увеличенным интервалом. Однако на данный момент это лишние темы. Двигаемся дальше ...

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

2
ответ дан 3 December 2019 в 19:21

Вы можете использовать traceroute, чтобы увидеть, есть ли на пути точка, которая все замедляет.

1
ответ дан 3 December 2019 в 19:21

Traceroute ( mtr еще лучше) путь между двумя машинами, ища определенные переходы, которые увеличивают задержку. После того, как вы определили местоположение, вы можете найти причину (проверьте статистику портов по обе стороны от рассматриваемой ссылки, чтобы увидеть, есть ли очереди или какие-либо другие проблемы); вы не отбрасываете пакеты (ну, не слишком большое их количество - 21 пинг не совсем статистически значимый), так что вы , вероятно, нигде не переполняете буферы.

Однако вы все еще только 1,8 мс задержки для "более медленного" соединения, что действительно превосходно для любого типа канала WAN. Если вы не делаете что-то невероятно чувствительное к задержке (например, высокоскоростная торговля), я с трудом могу представить, как это может быть «очень медленным»

0
ответ дан 3 December 2019 в 19:21

Передано 10 пакетов, принято 10, потеря пакетов 0%, время 8998 мс

8998 мс - это огромная задержка в сети. Вы можете использовать mtr, чтобы узнать, не работает ли он в какой-то момент? Как далеко находится дата-центр? Он подключается к Китаю из США? Какова средняя загрузка сервера?

0
ответ дан 3 December 2019 в 19:21

Стандартное отклонение ( mdev ) пакетов в "медленном" режиме велико по сравнению со средним значением. Я бы сказал, что сеть перегружена (либо на уровне хоста, либо на коммутаторе / маршрутизаторе)

Вы можете попробовать использовать iperf в режиме UDP, тогда вы получите дрожание.

0
ответ дан 3 December 2019 в 19:21

В своем вопросе вы указываете, что сайт стал медленным, а затем спрашиваете о времени отклика. Возможно ли, что сайт работает медленно по другим причинам?

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

] Возможно, стоит проверить, сколько данных вы извлекаете из базы данных в каждом запросе. Нет ничего необычного в том, что 10 МБ возвращаются в запросе к базе данных только для того, чтобы язык сценариев анализировал / искажал / отбрасывал данные, пока не осталось всего несколько КБ для отправки пользователю. Многие люди используют SELECT *, даже когда им нужно только одно поле. Также стоит проверить, какой объем трафика вы можете видеть на порту вашей базы данных в целом. Если у вас есть только 10-мегабайтная ссылка на другой центр обработки данных и вы откатываете даже 1-мегабайтный запрос, доставка займет почти секунду.

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

0
ответ дан 3 December 2019 в 19:21

Теги

Похожие вопросы