Думаю, это довольно наивный вопрос. Мне часто нужно выяснить, что, если проблема с веб-приложением или это просто проблема с сетью - потеря пакетов или медленное соединение в любой точке между, скажем, вашим боссом на дрянном Wi-Fi-соединении в аэропорту и веб-сервером, или CDN и веб-сервер, или MySQL и веб-сервер, или модуль memcached ... Вы уловили идею. Кроме того, как узнать, DNS-сервер ли это?
Некоторые из вас упускают из виду суть. Это не вопрос измерения производительности веб-приложений. Это вопрос об измерении производительности сети как компонента производительности веб-приложений.
Настройте трассировку (возможно, переключаемую с помощью строки запроса), показывающую количество времени, потраченного на тяжелые участки кода, и общее время сервера. Если сервер создает страницу за 0,2 секунды, а загрузка занимает 10 секунд, вы знаете, что это либо сеть, либо браузер пользователя.
Вы также можете использовать вкладку Net в Firebug или представление временной шкалы в Fiddler, чтобы увидеть, как отдельные компоненты выходят из строя и сколько времени они занимают.
Наилучший подход - определить базовую производительность вашей веб-работы на сайтах с заведомо хорошей связью. После того, как вы это установили, вы можете начать довольно простой процесс установления причины задержки для вашего конкретного клиента <--> проблемы с веб-приложением от соответствующего клиента.
Мои рекомендации по определению базовой задержки были бы такими: pingdom.com - 10 долларов в месяц помогут вам (я использую их последние шесть месяцев - каждая проблема, о которой они сообщили, была реальной), анализ задержки из нескольких мест в Интернете, как а также мониторинг / уведомление о проблемах с веб-сайтом.
Особое значение для ваших требований имеет то, что они создают журнал аудита производительности ваших веб-сайтов из разных мест в Соединенных Штатах, а также за рубежом. Это может оказаться полезным, если у вас временная проблема, и вы хотите оглянуться назад.
Возможность предоставить вашему боссу (кто является вашей целевой аудиторией в вопросе) график средней задержки из двенадцати разных мест обеспечивает прочную основу для выявления проблем на стороне клиента (WiFi, DNS, проблемы с ноутбуком) в сравнении с проблемой с веб-сайтом. базовая производительность И подключение к Интернету.
Проблемы с DNS-сервером, конечно, могут быть немедленно устранены, если клиент поместит соответствующее имя хоста-> сопоставления IP в локальный / etc / hosts (или, в случае Windows, C: \ windows \ system32 \ drivers \ etc \ hosts) - если проблема исчезает, когда у вас настроен соответствующий файл / etc / hosts, это очень сильный индикатор того, что есть проблема в вашей цепочке преобразователя (локальный преобразователь, первый DNS-сервер в цепочке или канонический)
Чтобы узнать, является ли это DNS-сервером, вы можете попробовать обойти DNS-сервер. Вы можете сделать это, добавив соответствующие имена хостов в свой файл hosts. Если, когда у вас есть адреса в файле hosts, кажется, что веб-сервер отвечает намного быстрее, тогда исследуйте DNS дальше. Если производительность сайта по-прежнему оставляет желать лучшего, проблема, скорее всего, в другом месте.
Более продвинутый; Вы также можете запросить DNS напрямую с помощью nslookup или dig. Убедитесь, что вы запрашиваете авторитетные DNS-серверы домена вашего веб-сайта напрямую, чтобы увидеть их время ответа, а не время ответа локального DNS-сервера, который может иметь кэшированную копию записей.
Также не помешает выполнить фактическое нагрузочное тестирование из нескольких мест. Запустите локальный нагрузочный тест, а затем запустите его из разных мест за пределами вашего центра обработки данных. Локальные тесты должны дать вам хорошее представление о том, чего ожидать в локальной сети / местных условиях. Затем вы можете сравнить это с тем, что вы получаете извне, и увидеть, какие потери вы получаете на стороне сети. Очевидно, что время загрузки внешних тестов будет выше, но вы должны определить, что приемлемо в этой области.
В дополнение к другим рекомендациям мне нравится использовать Fiddler, чтобы точно видеть, сколько времени занимают отдельные запросы и сколько используется плохая пропускная способность. Он запускается от клиента, поэтому он показывает мне, сколько времени занимает каждый запрос от этого настойчивого запроса.
Также попробуйте YSlow, отличную надстройку для Firebug:
Мне кажется, вам нужно знать сетевые соединения для каждого процесса, объем трафика для каждого соединения сокета, время ответа для каждого сокета и способ визуализации данных.
appfirst.com работал на нас.