%20%D0%B7%D0%B0%D0%BC%D0%B5%D0%B4%D0%BB%D1%8F%D0%B5%D1%82%20%D0%B7%D0%B0%D0%B3%D1%80%D1%83%D0%B7%D0%BA%D1%83%20%D1%81%D1%82%D1%80%D0%B0%D0%BD%D0%B8%D1%86%D1%8B.png)
У нас есть небольшая сеть (возможно, 15 пользователей в часы пик, около 30 устройств), управляющая интернет-подключением и телефонными линиями.
Основное использование сети — для пользователей, чтобы получить доступ к веб-интерфейсу внешней размещенной базы данных, с помощью которого они управляют бизнесом (клиенты, продажи, счета и т. д. и т. п.). Этот веб-интерфейс базы данных — это приложение php/mysql, разработанное за последние полтора года. Как основной (если не единственный) программист, я имею доступ ко всему, что касается этого приложения и нашей сети, от нашего хостингового решения до исходного кода и выбора технологий.
Несколько месяцев назад мы заметили очень сильное замедление примерно на 5% кликов, сделанных с использованием интерфейса базы данных. Я имею в виду, что большинство кликов доставляют контент в течение одной-двух секунд, а затем, иногда, один из кликов загружается до одной минуты.
Что меня ослепляет, так это
- похоже, что это не связано с содержимым страницы. Загрузка одной и той же страницы снова и снова будет работать в 95% случаев, при этом один щелчок иногда будет занимать от 1000% до 2000% больше времени для загрузки. загрузка разных страниц снова и снова будет иметь те же результаты.
- веб-интерфейс сталкиваетсяотсутствие замедления при доступе извне офиса. то есть он замедляется только при использовании внутри нашей локальной сети.
- другие веб-страницы, похоже, не замедляются, но остановка отстающей страницы и ее перезагрузка будут работать нормально,что заставляет меня думать, что это происходит в течение нескольких секунд, блокируя все клики, сделанные в течение этого порогового значения, но не те, которые сделаны через две секунды
- сайт использует jquery и jquery-ui, а также некоторые другие библиотеки (jquery cookie master, xdate). Медленность возникает, если они загружаются с наших серверов или напрямую из jquery и ajax.googleapis
Столкнувшись со всем этим, я проконсультировался со специалистами по сетям, и в конце концов мы заменили наше сетевое оборудование. Теперь мы используем межсетевой экран Cisco ASA-5505 и управляемый коммутатор Cisco Catalyst.
- Ранее мы замечали, что пинги на google.com иногда прерывались или загружались со временем до 13000 мс, тогда как обычно пинг составляет 20-30 мс.
- мы также заметили, проконсультировавшись с нашим интернет-провайдером, что у нас есть до800гбзагрузок в месяц! мы обрабатываем фотографии и тяжелые файлы, но 800 ГБ — это далеко не нормальное использование. Какое-то время мы думали, что высокий сетевой трафик загрузки может помешать загрузке ресурсов страницы. Мы могли видеть по истории нашего интернет-провайдера, что замедление и массовые загрузки, похоже, происходят примерно в одно и то же время. Я не могу сказать без сомнений, что произошло раньше, похоже, что и то, и другое происходит в одну и ту же неделю.
- очевидно, у нас было множество ошибок потери пакетов
- Я не могу точно сказать, на какие протоколы влияет замедление, а на какие нет. Я не сталкивался напрямую с обрывом загрузки и не получал жалоб от пользователей на то, что их загрузка не удалась, но загрузка файлов на ftp через netbeans будет затронута. Однако пользователи используют
transmit
для передачи файлов нашим клиентам и обратно, и у меня не было жалоб на то, что файлы не загружаются правильно или клиенты получают поврежденные файлы.
к сожалению, то, что у меня не было жалоб, не значит, что этого не было, так как общение с пользователями в такие моменты несколько напряженное. Я бы сказал, что медленная сеть виной [каламбур].
Когда эксперты, которых мы наняли, пришли, чтобы установить новые части в сети, они провели некоторую настройку и мониторинг, и теперь наш пинг вернулся в норму, а ошибки потери пакетов случаются гораздо реже, до такой степени, что мы думаем, что это просто обычная потеря пакетов через интернет. Также, насколько мы можем видеть (прошло всего несколько дней), гигантские загрузки прекратились.
Однако 5% кликов по-прежнему требуют много времени для загрузки.
Я попробовал отладить с помощью вкладки net в firebug, чтобы увидеть, какая часть сайта загружается медленно. Сам сервер отвечает в течение 200-800 мс, в зависимости от сложности страницы, что кажется нормальным. Большинство изображений загружаются нормально, библиотеки тоже, но когда случается замедление, одно или несколько изображений или библиотек будут ждать загрузки вечно.это не всегда одна и та же библиотека или изображение
Я думаю, что каким-то образом при загрузке изображений и библиотек для отображения страницы сетевая нагрузка не позволит ресурсам правильно достичь места назначения.
как определить, что мешает загрузке определенного ресурса, будь то изображение или библиотека JS?
Мне не хватает технических навыков, чтобы использовать wireshark или другие продвинутые (с моей скромной точки зрения) сетевые инструменты, но я изучу их, если понадобится. При этом, мониторинг на данном этапе кажется неактуальным, я не хочу видеть, как он работает медленно, я знаю, что он работает медленно. Я хочу знатьчто мешает ресурсам достигать своих целевых компьютеров в нашей локальной сети.
решение1
Таким образом, без фактического подключения к вашим сетям и проведения с вами подробной диагностики, ответ здесь, скорее всего, будет скорее «указанием вам направления» и проверкой того, сработает ли это.
Тем не менее, когда я имею дело с подобными вещами, я применяю своего рода подход бритвы Оккама.
Вы заявили:
«веб-интерфейс не испытывает замедления при доступе из-за пределов офиса. То есть он замедляется только при использовании в нашей локальной сети».
Если это действительно так, то это как раз тот фрагмент, на который стоит обратить внимание.
Проблема ДОЛЖНА быть где-то внутри этой "локальной сети". Она НЕ на внешнем сервере/приложении, иначе те же проблемы могут быть воспроизведены из другого места.
Ну и где? Вы уже поменяли несколько единиц сетевого оборудования, но, судя по всему, безрезультатно.
Вот что я бы вам посоветовал сделать. Это может показаться простым, но действуйте от самой дальней внешней точки вашей сети в обратном направлении:
- Возьмите ноутбук, который НИКОГДА не был в локальной сети, не является частью домена и т. д., и подключите его напрямую к интернет-провайдеру локальной сети. Прямое подключение — это ключ. Подключите ноутбук напрямую к сети интернет-провайдера без брандмауэра или чего-то подобного в смеси и посмотрите, какие ответы/производительность вы получите, и сравните их с вашей заведомо хорошей внешней настройкой, которая работает отлично.
- Если на шаге 1 вы не видите проблем, переместите ноутбук на один уровень назад, подключив его напрямую к брандмауэру ASA, а затем повторите попытку через брандмауэр.
- Если на этапе №2 проблем нет, вернитесь на другой уровень, на этот раз за управляемый коммутатор.
- Если в пункте 3 проблем нет, то проблема не в сети.
И так далее и тому подобное (пробуя клиента, у которого есть "проблемы" внешне и т. д.), пока вы, по крайней мере, не сможете объективно сказать, что/где происходит, даже если вы не знаете, почему или что конкретно вызывает ее на определенном "слое". Затем вы начинаете более глубокое погружение в этот конкретный "слой", если хотите.
решение2
Вам, вероятно, понадобится использовать nmap (или Wireshark, например) для проверки локальной сети. Это может помочь вам обнаружить компьютер с Windows, зараженный вирусом и отправляющий тысячи спам-запросов ARP, или пользователя, использующего клиент BitTorrent или что-то еще, что может перегрузить вашу локальную сеть или ваш интернет-загрузчик.
Другой вариант заключается в том, что большинство провайдеров далеки от совершенства... возможно, иногда у провайдера возникают проблемы с потерей пакетов или стабильностью загрузки. Установка инструмента мониторинга, например smokeping, и мониторинг цели в Интернете может помочь вам увидеть это (потеря пакетов, медленная загрузка, медленный пинг), а также позволит вам увидеть, когда это происходит (каждый раз, когда Джон Доу находится в офисе и подключает свой компьютер к сети?).