DannyDainton / newman-reporter-htmlextra

A HTML reporter for Postman's Command Line Runner, Newman. Includes Non Aggregated Runs broken down by Iterations, Skipped Tests, Console Logs and the handlebars helpers module for better custom templates.
Apache License 2.0
357 stars 139 forks source link

[Performance] Generated report when multiple iterations are run #173

Closed wmedali closed 4 years ago

wmedali commented 4 years ago

When generating report with multiple iterations (+150) and each iteration contains multiple requests (+5) the report file become so large (like 30 Mb for the html). There is a performance issue. When opening the file (more than one minute to completely charge) and clicking in Total requests button takes approximately one minute to load. The timing may varry of course depending on number of iterations and transferred data size.

Steps To Reproduce

  1. Run the collection Postman Echo with parameter ''n 150"
  2. Open the report
  3. Click the Total Requests button

newman run https://www.getpostman.com/collections/161a23965791d263a3e6 -r cli,htmlextra -n 150 In real life the iterations are extracted from data source file (option -d)

Perf and rendering issue

you can notice the loading issue and clicking Total Requests doesn't open the page instantaneously (in order to avoid share sensitive data I am giving example of Postman Echo collection which is fast than real life collections ..)

Version and Platform Information:

Additional Context

DannyDainton commented 4 years ago

Thanks for raising this @wmedali. Appreciate, issues that I'm aware of so that's a good thing :)

I created a bug for the UI issue before and moved into a project board with the intention of fixing it, never got round to it though :(

https://github.com/DannyDainton/newman-reporter-htmlextra/issues/17

Could you break this out into 2 separate issues please, one for the Performance and one for the UI. You could have a huge collection that runs over 15 iterations, you would get the Perf issues but not the tabs so I would tackle those problems separately.

wmedali commented 4 years ago

Here you are @DannyDainton can't wait to see the fixes. Thanks for the great work and nice ticket templates btw. So Inspiring

DannyDainton commented 4 years ago

@wmedali I've made a quick change to the panels that render the 'big numbers', these should adjust in size if the assertions are more than 9999.

Still need to tackle that performance issue though :(

DannyDainton commented 4 years ago

Hey @wmedali,

In the latest version, I included a noSyntaxHighlighting flag which disables the Syntax Highlighting of request/response bodies, etc. I haven't documented it anywhere yet but I thought to let you know as it's been noted in the past to be something that impacts performance as it re-renders all the HTML as is a blocking action.

Syntax Highlighting is on by default so you would need to add the --reporter-htmlextra-noSyntaxHighlighting flag to the command if you're running it globally or add noSyntaxHighlighting: true to the Newman run object, if you're using the library.

Would be cool if you could try it out and see if that help with the performance. I'm going to still keep this ticket open as it's a bigger problem but it's worth giving it a go.

wmedali commented 4 years ago

@DannyDainton I did a quick test for the highlighting, even with the parameter --reporter-htmlextra-noSyntaxHightlighting I still get the highlighting/pretyfying of requests/bodies. Regarding the performance, I launched tests (282 iterations, 16 requests in each). I'll keep u updated once tests are run.

DannyDainton commented 4 years ago

My bad - Looks like a typo:

--reporter-htmlextra-noSyntaxHighlighting not --reporter-htmlextra-noSyntaxHightlighting

wmedali commented 4 years ago

Cool, it works with the good flag. I launched my tests for 100 iteration to see. If it works I'll do it for 300 to see the limits. I'll keep you updated

DannyDainton commented 4 years ago

Cool - It's not going to impact the size of the report created, the more you add to it the more it will grow in size.

This might make it slightly quicker to open but with this, you lose the fancy syntax colours but the all-important information is still there.

wmedali commented 4 years ago

hey @DannyDainton it's so good. nice work 👏 for me the performance is more important than the fancy syntax, at the end with the flag the consumer of the report can choose whatever wants. I can close the ticket if you want. it's good for me

DannyDainton commented 4 years ago

Awesome! I'm going to leave it open for now - I don't think this solves all the performance issues so I will continue to look at it over the next couple of weeks.

Appreciate you testing this out for me 🏆

DannyDainton commented 4 years ago

I'm going to close this one for now, the option is there to disable the syntax highlighting which has been proven to impact the performance of the larger reports and make them 'quicker' to open in the browser.

I will be trying to make different adjustments here and there to help with the overall performance but the size of the generated reports are nothing that I can really control, the more data that comes from Newman the bigger the report will be.

github-actions[bot] commented 2 years ago

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.