Как оценить производительность моих веб-приложений?
Есть ли способ узнать узкие места в веб-приложении?
EDIT: я не спрашиваю о каких-либо настройках переднего конца, таких как изображения, css и т. Д. Я хочу знать, как профилировать конец приложения, чтобы я знал, какие методы / запросы нужно изменить для повышения производительности.
Что касается узких мест на сервере приложений, вы можете использовать инструмент профилирования, чтобы узнать, сколько времени потрачено на каждую часть вашего кода, сколько памяти используется и т. Д. Для PHP webgrind кажется популярным, основанным на графическом интерфейсе способом профилирование. Что-то вроде dotTrace будет делать то же самое для приложения ASP.NET. Обратите внимание, что когда дело доходит до баз данных, такие инструменты профилирования будут показывать только те запросы баз данных, которые медленны, а не почему они медленны. Для этого вам нужно будет изучить профилирование базы данных …
Еще одним аспектом узких мест в веб-приложениях является то, сколько времени на самом деле занимает браузер, чтобы сбрасывать все (импорт и импорт CSS и JavaScript, изображения и т. Д.) И отображать страницу. Есть несколько компаний, таких как Keynote, у которых есть боты, которые попадут на ваш сайт со всего мира, проанализируют производительность и дадут вам рекомендации об изменениях, которые вы можете сделать, чтобы получить выход вашего приложения в браузер и отобразиться как можно быстрее ( например, «используйте сжатие gzip и поместите свой JavaScript в конце страницы вместо головы» и т. д.). Разумеется, вы также можете сделать это самостоятельно. Например, такие плагины Firefox, как Jiffy и YSlow, будут выполнять эту работу.
Для любого веб-приложения вы можете попробовать использовать расширение Firebug вместе с расширением Yahoo YSlow (Firebug). Очень полезно в производительности страницы. http://developer.yahoo.com/yslow/
Трассировка – отличный старт
Fiddler – хороший инструмент для регистрации и мониторинга трафика. Он работает на клиенте, и вы можете видеть, какие запросы и ответы идут между клиентом и веб-сервером. Вы можете легко анализировать медленные страницы и определять причины (для многих запросов, большой страницы, …)
В частности, для ASP.Net существует механизм трассировки, который может создавать подробный журнал для веб-приложений. Журнал показывает информацию о времени, и вы можете найти длинные функции. (Статья MSDN: Обзор трассировки ASP.NET
попробуйте использовать некоторые тестовые механизмы, такие как PHPUnit, чтобы подчеркнуть ваше приложение и использовать оболочку, чтобы узнать, какой процесс требует больше времени для решения.
в Unix / Linux вы можете использовать команду «top»
в Windows используйте диспетчер задач (расширенный)
Если вы используете Perl, то Devel :: NYTProf супер потрясающий .
У меня есть учебник, который я сделал несколько раз в OSCON и в конференции MySQL « Real World Web: Performance & Scalability » (слайды, доступные в формате PDF ), вам может показаться интересным.
Связанные темы:
Не могли бы вы более подробно рассказать о платформе (XP, Vista, Server 2000, 2003, 2008) и методе запуска приложения (IIS, Windows Service). Как упоминалось выше, трассировка является хорошим началом, но есть и другие инструменты, зависящие от среды, на которой настроено веб-приложение.
Включите функцию трассировки, trace = true, если это веб-приложение, и введите инструкции трассировки в начале и конце ваших методов, которые срабатывают. Это даст вам очень подробное считывание тиков в системе и, следовательно, сколько времени каждая часть будет выполнять.
Если у вас есть библиотека, которая вызывается, вы также можете сделать трассировку в ней, используя httpcontext.Current.Trace.Write, чтобы вывести то, что вам нужно посмотреть. В качестве альтернативы, если ваше приложение действительно утомительно, вы можете написать свою собственную функцию для хранения операторов трассировки в общей переменной и записать ее в БД или другой механизм после запуска скрипта.
Если вам нужен общий способ поиска узких мест, попробуйте использовать инструмент мониторинга HTTP. Это позволяет вам видеть, какие типы запросов занимают больше времени, или если они возвращают сообщения об ошибках. Затем вы можете использовать инструмент профилирования для конкретной платформы в нуль в определенных областях вашего приложения на основе данных из инструмента.
Мне нравится использовать HTTP-прокси-инструмент, такой как Charles, для этого типа анализа.
Первый шаг – быстрый и грязный. Попробуйте это на iPhone, ноутбуке с 3G-соединением, ПК со спутниковым интернет-соединением и мобильным КПК для Windows. Если это сработает, все готово. Если нет, триангуляция.