Фитнес-фреймворк очень медленный, когда глубина папки больше 4 - почему?

В настоящее время мы внедряем пригодность в качестве инструмента тестирования, позволяющего пользователям проводить приемочные испытания. Пока все хорошо. мы используем версию Java «20091121». У нас проблемы с папками глубже 4.

Мы настроили следующую структуру папок:

Настраивать

Тестирование

content.txt + properties.xml (внутри просто "!contents")

Вариант использования2204

content.txt + properties.xml (внутри просто "!contents")

SingleRequest02

content.txt + properties.xml (внутри просто "!contents")

Положительный тест

content.txt + properties.xml (внутри просто "!contents")

одинвзрослыйсребенком

здесь content.txt + properties.xml для фактического теста, содержащего 18 таблиц фикстур

Когда мы запускаем фитнес и переходим в самую глубокую папку («OneAdultWithChild»), до отображения страницы проходит около 10 секунд. Теперь, когда я перемещаю содержимое вверх на один уровень иерархии (в «PositiveTest»), для отображения страницы требуется 3 секунды. Когда я помещаю тестовый контент на второй уровень («UseCase2204»), он отображается почти мгновенно.

Такое же поведение происходит во время выполнения теста. После нажатия кнопки "тест" выполняются тесты:

  • второй уровень: 12 секунд
  • четвертый уровень: 14 секунд
  • пятый уровень: 40 секунд! (плюс, требуется много времени, пока не появится кнопка «захват результата»)

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


java testing performance fitnesse fit-framework
person Marcel    schedule 22.12.2009    source источник

Ответы (4)


arrow_upward
0
arrow_downward

Это может быть не конкретное решение, но есть исправление для одной проблемы с рендерингом виджета, которая в настоящее время рассматривается: http://www.pivotaltracker.com/story/show/2200962

Существует также история о переделке синтаксического анализатора, чтобы сделать его более эффективным и способным, но это требует значительных усилий. Не уверен, когда начнется работа над этим.

person Dan Woodward    schedule 15.01.2010
comment
кстати новый парсер исправил... просто для записей - person Marcel; 18.02.2014

arrow_upward
1
arrow_downward

Вы пытались связаться по этому поводу с сопровождающим(и) FitNesse? Это должно быть вашим первым курсом действий. Вот их ссылка «Получить помощь»: http://www.fitnesse.info/help.

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

Обновление: Просто задумайтесь, находится ли ваша тестовая иерархия на монтировании NFS? Не могли бы вы попробовать запустить его на «настоящем» диске?

person Carl Smotricz    schedule 22.12.2009
comment
Спасибо за быстрый ответ. да, профилирование стоило бы попробовать. мы уже просмотрели исходный код на наличие другой проблемы, и в некоторых местах код не самый читаемый ;-). это действительно странное поведение. Следующее, что я попробую, это использовать новый экземпляр Fitnesse и воссоздать структуру папок с нуля, без каких-либо настроек и т. д. Кстати, мы используем Slim в качестве тестовой системы, возможно, это еще одно замедление. любая дополнительная помощь действительно приветствуется, так как я думаю, что у других людей должны были быть такие же проблемы. - person Marcel; 22.12.2009

arrow_upward
1
arrow_downward

Итак, мы сделали некоторое профилирование. основное время из 40 секунд на загрузку страницы (именно загрузить, а не запустить) тратится на следующие методы:

  • Fitnesse.wikitext.widgets.WidgetRoot.render
  • Fitnesse.wikitext.widgets.WidgetRoot.getVariable
  • Fitnesse.wiki.PageData.initializeVariableRoot
  • Fitnesse.wikitext.widgets.VariableWidget.doRender

это похоже на логику замены varibale + рендеринг виджета используется все время :(

особенно "private void doRender()" в Fitnesse.wikitext.widgets.VariableWidget вызывает у меня головную боль. есть комментарий, жалующийся на сложность и на то, что все это должно быть реорганизовано.

глянь сюда

http://github.com/lvonk/fitnesse/commit/a7242991039970d720db682afa2336285afa2336285700d421#diff-10" rel="nofollow noreferrer"> 10

для меня это выглядит как тупик в данный момент. мы бы использовали пригодность для действительно большого проекта, одного из крупнейших ИТ-проектов, которые в настоящее время реализуются в Германии/Европе. но я не могу продать это, если такие базовые вещи не работают достаточно быстро :-/

я все еще надеюсь, что кто-то знает исправление, иначе мне придется копаться в коде на Рождество и попытаться сделать его немного быстрее.

я только что заметил, что на git hub есть более новая версия (2009-11-25), которая избавилась от комментария, а также были изменены некоторые строки кода. я дам это попробовать.....

помощь высоко ценится

ура марсель

person Marcel    schedule 22.12.2009

arrow_upward
0
arrow_downward

Дэн,

спасибо за Ваш ответ. это то, что я разместил в группе Yahoo Fitnesse:

hi,

Я только что загрузил выпуск «20100103» с веб-сайта и попробовал его с той же настройкой. серьезное улучшение! я очень рад этому. теперь я могу продолжить первоначальную настройку и, надеюсь, убедить всех в этом.

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

я надеюсь, что остальная часть системы ведет себя так же :)

большое спасибо за быструю помощь. я вернусь с дополнительными отзывами (или проблемами ;-)) после того, как первоначальная настройка будет выполнена, и люди начнут работать с ней (разработчики и тестировщики).

ура марсель

person Marcel    schedule 19.01.2010