Как профилировать мое рабочее веб-приложение?

У меня есть блог, который я сделал. В последнее время заметил некоторые проблемы с производительностью. У меня время ожидания индексной страницы составляет около 400 мс. Я считаю, что это довольно много. Когда я впервые развернул его (с меньшим количеством функций, но все же), я помню, что время загрузки индекса составляло примерно 80 мс.

Теперь я бы профилировал это, но проблема в том, что это происходит только в моей производственной среде. В моей тестовой среде индексная страница занимает всего 10 мс.

Как мне приступить к профилированию рабочего приложения? Я использую Apache + mono + mod_mono в Arch Linux с MongoDB. У меня аналогичная тестовая среда, за исключением того, что я использую xsp.

Я не уверен, где искать: мой код, конфигурацию Apache или MongoDB? Как я могу профилировать свой рабочий сервер, чтобы понять, почему он намного медленнее, чем моя среда разработки?


person Earlz    schedule 11.07.2012    source источник


Ответы (2)


Трудно быть конкретным без подробностей, но вот пример общего руководства:

Сначала я бы порекомендовал использовать что-то вроде Firebug для Firefox - есть аналоги в других браузерах, но это мой старый путь инструмент для такого рода вещей. Включите его и получите представление Net Panel для водопадной диаграммы, которое покажет вам список каждого объекта, который загружается на странице (возможно, вам придется обновить) - он также будет иметь синий цвет, показывающий событие рендеринга (когда страница становится видимый).

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

Если плагины вам не нравятся или вы подозреваете, что это может быть что-то локальное для вашей машины, вызывающее проблему, взгляните на: http://www.webpagetest.org/

Это даст вам возможность удаленного тестирования из разных мест, разных браузеров, скорости и т. Д. И даст вам аналогичные подробные результаты.

Если это статический файл, обратите внимание на проблемы с сетью, Apache как причину. Если он генерируется динамически, посмотрите Apache, ASP, mongodb и т. Д.

Что говорят журналы доступа Apache о времени отклика для страницы индекса? Предполагая, что Apache 2 или новее, убедитесь, что у вас есть %D%T, если хотите), чтобы вы могли видеть время, затраченное на обслуживание страницы (с точки зрения Apache) с требуемым уровнем детализации. Подробнее об этом см. В директиве LogFormat .

Я не могу помочь со стороны ASP / Mono, это не мое дело, но добавление операторов отладки в различных точках для отслеживания генерации индексной страницы (при условии, что она генерируется динамически) было бы довольно стандартным подходом.

Для базы данных MongoDB по умолчанию регистрирует только «медленные» запросы, которые занимают> 100 мс - если вы пытаетесь отследить проблему с временем отклика менее 100 мс через журналы, вам нужно будет отрегулировать это, иначе вы, вероятно, получите очень мало. Это можно сделать следующим образом:

> db.setProfilingLevel(0,20) // leave profiling off, slow threshold=20ms

Вы также можете настроить его как параметр запуска (--slowms) для процесса mongod. Более подробную информацию о профилировании, которое также может помочь, но связано с накладными расходами, можно найти здесь:

http://www.mongodb.org/display/DOCS/Database+Profiler

person Adam Comerford    schedule 11.07.2012
comment
Я использую Firebug. Вот откуда я взял число 400 мс :) Проблема в том, что он ждет моей индексной страницы 400 мс. И хороший момент о mongodb - person Earlz; 11.07.2012
comment
Обычно стоит потрудиться и на webpagetest - посмотрите, влияет ли расположение / расстояние от производства. Если нет, и проблема заключается в самой странице индекса, то вы, вероятно, можете сузить ее - я добавлю несколько примечаний - person Adam Comerford; 11.07.2012

Я предлагаю вам взглянуть на Mini Profiler Сэма Сафронса. Если вы используете его на своем сайте, он позволяет вам включить профилирование в производственной среде.

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

person Grhm    schedule 11.07.2012