Как локализовать проблемы производительности?

Как быстро локализовать проблемы производительности?
Автор: Compuware
Перевод: RedRoxx Technologies

Гарантия производительности и масштабируемости сложных распределенных приложений — непростая задача, встающая перед участниками процесса разработки. Сложность этой задачи усугубляется еще и тем, что тe, кто находят проблемы производительности, в редких случаях могут разобраться, чем они обусловлены, и наоборот, те, кто способны исследовать подобные проблемы, редко является теми, кто их ищет.

В данной статье рассматривается решение Compuware для совместной работы разработчиков и тестировщиков при локализации проблем производительности, которое позволяет резко снизить среднее время устранения дефектов для данного типа тестирования.

Да, и про эту маркетинговую агитку, можно тоже пояснить, зачем она? На форуме есть люди, которые будут отстаивать эту статью? Кроме того, какова дата публикации первоисточника, можно ссылку на него?

Думаю, если вы аргументированно поясните в чём "агитность" статьи, наши коллеги из Compuware ответят.

Думаю, если вы аргументированно поясните в чём "агитность" статьи, наши коллеги из Compuware ответят.

Не хочется метать бисер попусту, ну да ладно.
В начале статьи заявляется, что она про сложные распределённые приложения. Выводом, очевидно, является: [с использованием нашего тула] "тестировщики теперь могут предоставлять разработчикам всю необходимую информацию для анализа, диагностики и исправления проблем производительности, не имея специальной технической подготовки или знания исходного кода." (видимо, речь по-прежнему идёт о сложных распределённых приложениях)
Однако, этот смелый вывод ниоткуда не следует. Саппортающие его вторая и третья картинки демонстрируют профилирование GUI-клиента той или иной степени толщины (что, кстати, прямо противоречит тексту статьи, где утверждается обратное :) ), а вовсе не многопоточного сервера приложений, для которого имеет смысл многопользовательское нагрузочное тестирование. Кроме того, на третьей картинке не продемонстрировано анонсировнного "утекающего" соединения.
Что касается действительно относящейся к нагрузочному тестированию первой иллюстрации, то очень понравился логический переход "Таким образом, мы обнаружили узкое место производительности нашей тестовой среды в виде процессорной мощности сервера." => "Итак, QA-команда, успешно справляясь со своей ролью искателей дефектов, ...".
P.S. Да, чуть было не забыл. На знатока и ценителя артефактов нагрузочного тестирования такая надпись должна действовать как красная тряпка на быка, ИМХО, конечно: "Тесты показывают, что процесс сбора данных требует от 2,5 до 3 процентов CPU. "

Сообщение отредактировал a66at: 23 апреля 2007 - 19:20

Маркетинговая агитка? Ну, смотря что подразумевать под маркетингом. Вообще, цель публикации проста - показать , какие инструменты существуют в мире, всем, кто имеет отношение к сфере разработки ПО. Как еще они смогут узнать о том, что выпускают передовые компании? Такие статьи рождаются не из воздуха. За ними стоят длительные исследования потребностей конечных пользователей, разработка и шлифовка инструментов на основе обратной связи от пользователей. Ведь коммерческие компании выпускают только такие продукты, на которые есть спрос, т.е. которые удовлетворяют какие-то потребности потенциальных потребителей.
В данном случае, речь идет о потребности ускорить устранение проблем производительности при разработке ПО. Учтены основные сложности, с которыми сталкиваются участники процесса, а именно: "черный ящик" системы для тестировщика и недостаток диагностической информации для разработчика при выявлении дефектов.
Ваша аргументация касается в основном функциональных возможностей инструментов, поэтому комментировать ее здесь считаю неуместным. Если Вы хотите узнать об инструментах Compuware больше, дайте знать. Я вышлю дополнительную информацию.
О первоисточнике: статья вышла в апреле 2005 года. Адрес статьи на сайте Compuware: http://www.compuware...701000000004eqf (требуется бесплатная регистрация)

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

Ну почему же? Профессиональный форум как раз и предназначен для подобного рода комментариев. Тем более, что статья и в самом деле довольно слабая - a66at верно подметил несоответствие текста и иллюстраций.

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

Статья ведь посвящена описанию функциональных возможностей продукта. И, на мой взгляд, намеренно создаёт ошибочное о них впечатление у неискушённого читателя. Ещё раз говорю: если бы профилирование промышленного сервера приложений с показанным на картинке уровнем детализации без фильтрации под существенной нагрузкой с помощью этого инструмента было бы возможно, то это действительно было бы уникальным достижением. Но статья ограничивается декларациями, без доказательств, кроме того, применены явные подтасовки.
В конце статьи следует вывод, на мой взгляд, бездоказательный и совершенно противный интересам всех участников соответствующего процесса, кроме поставщиков данного инструмента, разумеется (и то, в случае, если они не собираются нести ответственность за результаты его использования).

О первоисточнике: статья вышла в апреле 2005 года. Адрес статьи на сайте Compuware: http://www.compuware...701000000004eqf (требуется бесплатная регистрация)

"Sorry, the white paper you are trying to access cannot be found.", если есть кто-то более удачливый, вышлите мне пожалуйста на ichalov<где>gmail.com.

Ну да, действительно маркетинговая агитка.
Использовать эту статью в практических целях практически невозможно, т.к. в ней идет смешение технических вопросов и рекламных материалов. Если бы автор вместо этой статьи написал две, одну "Как быстро локализовать проблемы производительности?", без упоминания иструмента, а вторую "Как это можно делать с помощью продукта ..." - было бы лучше.

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

PS. Вполне возможно, что продукт неплохой, но насколько портит впечатление о нем эта статья!

Справедливости ради, добавлю, что в оригинале, который попал в мой почтовый ящик, всё именно так и есть (почти). В оригинальной статье третьего изображения нет (видимо оно добавилось в процессе перевода, чтобы хоть как-то проиллюстрировать абзац про утечку). Весь оригинальный текст именно теми же самыми ляпами и усеян, перевод достаточно точный. Единственное исключение на которое я обратил внимание заключается в том, что в оригинале хитро написано, что профилирование применяется "in conjunction" с нагрузочным тестированием, что в переводе превратилось в "выполнять сложный анализ производительностьи прямо во время нагрузочного тестирования и видеть, какие части кода работают медленно".
В общем, мораль такова. Надо очень критически относиться к творениям западных маркетологов, горшки они обжигают ничуть не хуже наших продавцов.