Вот небольшая предыстория периодически возникающей, но очень реальной проблемы. Я поддерживаю веб-приложение, работающее в частном облаке Esxi. У нас есть сервер базы данных и 4 сервера веб-приложений. У всех четырех серверов веб-приложений очень странная проблема. Все серверы работают (Ubuntu 10.04.3, 2.6.32-28-сервер, веб-сервер Apache, ftp proftp). Когда я передаю много изображений через ftp или http (внутренний или внешний), в большинстве случаев это очень медленный. Например, загрузка каталога, содержащего около 400 изображений (<2 мегабайт), имеет очень медленную скорость передачи, иногда даже полностью неподвижную. Точно так же по http, если я загружаю одну из своих страниц в свой браузер в первый раз, в зависимости от количества изображений может возникнуть такая же проблема. Когда я снова загружаю ту же страницу, это нормально из-за кеширования браузера, однако, как только я очищаю кеш, он возвращается к очень медленным скоростям. Я говорю «может», потому что это происходит не всегда, иногда файлы передаются с нормальной скоростью, то есть практически мгновенно. Все эти машины виртуальные, и я попытался просто построить их снова, но безуспешно. Кто-то предположил, что это могло быть имя хоста или проблема с именованием, но на самом деле не дал подсказки, где быть, чтобы опровергнуть эту теорию. Я не серверный парень и не претендую на него. Наши серверы обслуживаются третьей стороной с управляемым хостингом, однако управляемый хостинг, похоже, не знает, что делать с этой проблемой. Любая помощь будет принята с благодарностью
Ваша цель здесь - найти узкое место. Другими словами, конкретное место в конвейере, которое вызывает замедление.
Первый шаг к этому - сбор данных. Наиболее распространенными узкими местами являются сетевой ввод-вывод, дисковый ввод-вывод, ограничения ЦП и памяти. Вы можете использовать полноценную систему мониторинга, которая собирает данные, такие как Cacti, или что-то локальное, например sar который является частью пакета systat.
Получив эти данные, вы сможете сопоставить их со временем отклика из веб-журналов и посмотреть, коррелируют ли какие-либо из этих данных. Возможно, это не так, и вам придется копать глубже - но это как жизненно важные показатели, которые вы всегда проверяете в первую очередь.
Менее навороченный, вы можете просто посмотреть что-нибудь вроде vmstat вывод, и вам может повезти и вы поймете проблему, но периодически возникающие проблемы бывает трудно решить.
При решении проблемы часто имеет смысл использовать своего рода двоичный поиск по конвейеру, чтобы попытаться исключить переменные.
Так, например, если вы тестируете из браузера на рабочей станции, запустите тесты с самого сервера, чтобы отключить вашу рабочую станцию и сеть. Если у вас больше нет этой проблемы, это либо ваш рабочий стол, либо сеть между вами и сервером. Если проблема не исчезла, она должна находиться где-то на сервере.
Кроме того, если это динамическая веб-страница, могут возникнуть проблемы с самим приложением, поэтому вы также можете подойти к этому с помощью профилирования производственного кода.
Наконец, одна из трудностей с виртуализированными средами заключается в том, что другие виртуальные серверы могут влиять на ваши, но вы, вероятно, не захотите делать это заключение, пока, по крайней мере, не проведете мониторинг своих жизненно важных функций.
Медлительность, постоянная или прерывистая, может быть связана только с конфликтом ввода-вывода. Если на том же хосте, что и ваш, много активных виртуальных машин, вы будете конкурировать с ними за пропускную способность ввода-вывода. Также может быть, что хост перегружен с точки зрения использования памяти, поэтому страницы памяти, выделенные вашей виртуальной машине (виртуальным машинам), активно меняются местами, что имеет примерно такой же эффект, но хуже.
Однако при передаче большого количества небольших файлов изображений через HTTP проблема может быть не в сервере. Если вы находитесь на некотором расстоянии от машины, это может быть просто проблемой с задержкой. Если между вами и сервером 100 мс (вы можете проверить это с помощью базового ping команда), а браузер использует 2 одновременных соединения, тогда вы увидите среднее значение около 50 мс на изображение, добавленное ко времени загрузки страницы только из-за задержки в сети.
Точно так же для отправки большого количества файлов через FTP, хотя протокол FTP очень болтлив (для передачи файла требуется как минимум два цикла приема команд и открытие нового соединения для передачи данных), поэтому он более чувствителен к проблемам производительности, связанным с задержкой, чем HTTP. . Вы можете улучшить производительность передачи файлов, используя более современный протокол, такой как SFTP или SCP (оба предоставляются OpenSSH и другими серверами SSH) (не FTPS: это просто FTP через потоки SSL, поэтому есть все узкие места обычного FTP, а также SSL).