как Вы диагностируете производительность сети веб-приложения
Да Вы можете, это быть совершенно возможными. Не прекрасная идея иметь Exchange и AD на той же машине, это делает Вашу сеть немного менее безопасной - если Exchange будет поставлен под угрозу затем ее вероятное, то Ваша AD инфраструктура будет также.
Однако MS делает это с их продуктом SBS и многими многие, малый бизнес делает это.
Кроме того, если Вы использующий сервер 2008, необходимо использовать Exchange 2007 Sp1
Настройте трассировку (возможно, togglable querystring), показав количество времени, проведенное в тяжелых разделах кода, и полное время сервера. Если это, сервер создает страницу за.2 секунд и требуется 10 секунд для загрузки, Вы знаете, что это - или сеть или браузер пользователя.
Можно также использовать вкладку Net в Firebug или представление временной шкалы в Скрипаче, чтобы видеть, что снижаются отдельные компоненты и сколько времени они берут.
Чтобы видеть, является ли это сервер DNS, можно попытаться обойти сервер DNS. Можно сделать это путем добавления соответствующих имен хостов к файлу hosts. Если, когда у Вас есть адреса в файле hosts, веб-сервер, кажется, отвечает намного быстрее, затем исследует DNS далее. Если функционирование сайта все еще сосет, проблема наиболее вероятна в другом месте.
Более усовершенствованный; можно также запросить DNS непосредственно с nslookup или вырыть. Удостоверьтесь, что Вы запрашиваете авторитетные серверы DNS домена своего веб-сайта непосредственно для наблюдения их времени отклика, в противоположность времени отклика локального сервера DNS, который может иметь кэшируемую копию записей.
Лучший подход является к базовой линии Вашей веб-производительностью от сайтов с известной хорошей возможностью соединения. После того как Вы имеете, который установил, можно затем начать довольно простой процесс установления причины задержки для конкретного клиента <-> проблема веб-приложения от рассматриваемого клиента.
Моими рекомендациями для задержки определения исходного состояния был бы pingdom.com - $10/месяцев получают Вас, качают тело (я использовал их в течение прошлых шести месяцев - каждая проблема, о которой они сообщили, было реально), анализ задержки от нескольких местоположений в Интернете, а также контроле/уведомлении для веб-сайта вниз выходит.
Из особого значения для Ваших требований, то, что они устанавливают контрольный журнал Вашего функционирования веб-сайтов от нескольких местоположений в Соединенных Штатах, а также на международном уровне. Это может оказаться полезным, если у Вас есть переходная проблема, и Вы хотите оглянуться назад исторически.
Способность предоставить Вашему боссу (кто Ваша целевая аудитория в вопросе) график средней задержки от двенадцати различных мест обеспечивает прочную основу идентификации клиентских проблем (WiFi, DNS, проблемы с ноутбуком) по сравнению с проблемой с основной производительностью веб-сайта И соединением с Интернетом.
Проблемы сервера DNS, конечно, могут быть сразу исправлены при наличии клиентского места соответствующее имя хоста-> отображения IP в локальном/etc/hosts (или, в случае Windows, C:\windows\system32\drivers\etc\hosts) файл - Если проблема исчезает, когда у Вас есть соответствующий/etc/hosts настроенный файл, это - очень сильный индикатор, что существует проблема в Вашей цепочке сопоставителя (локальный сопоставитель, первый сервер DNS в цепочке, или каноническая)
Не может повредить выполнять тестирование действующей нагрузки от нескольких местоположений также. Выполните локальный нагрузочный тест и затем работайте один от различных местоположений за пределами Вашего дата-центра. Локальные тесты должны дать Вам хорошую базовую линию того, что ожидать при условиях LAN / локальных условиях. Затем можно сравнить это с тем, что Вы получаете внешне, и Вы видите, какая потеря Вы входите в сетевой конец. Очевидно, внешние тесты собираются иметь более высокое время загрузки, но необходимо определить то, что приемлемо в той области.
В дополнение к другим рекомендациям мне нравится использовать Скрипача для наблюдения точно, сколько времени отдельные запросы берут и сколько badwidth используется. Это работает от клиента, таким образом, это показывает мне, сколько времени каждый запрос берет от этого persepctive.
Кроме того, попробуйте YSlow, большое дополнение для Firebug: