This commit is contained in:
@@ -3,62 +3,13 @@
|
||||
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
|
||||
|
||||
|
||||
todo: REPORT BACKEND - more timeouts for report rendering, hard kill after 30 seconds tops but adjustable interval maybe?
|
||||
each process takes time in part, need to see which is taking which time the most and killable
|
||||
i.e. run a huge report and see which exact step takes which time for each
|
||||
we have the pre-render timing out maybe need more for each step where it's vulnerable to crashing / timing out
|
||||
|
||||
Devops droplet is overwhelmed by 10k records of widgets using the customfields example report
|
||||
symptom is super high cpu usage (100%) pegged and probably virtual memory usage as well
|
||||
timeout is kind of a hard core way to work around this issue, maybe instead it should be looking at excessive cpu and memory usage?
|
||||
The metrics don't catch it because it happens too quickly for the metrics lifecycle
|
||||
|
||||
I want it to be able to handle it gracefully without crashing
|
||||
Looks like jsreports has this issue too and they hard kill the process I think if necessary, but they actually re-use the same instance for reporting I think.
|
||||
If it's not an issue then no need to resolve at the moment
|
||||
|
||||
|
||||
todo: REPORT BACKEND - report delete throws server exception about db context re-use or something to that effect
|
||||
No exact steps top repro, but happens for Joyce with win64 release build if go in and edit same template a few times from widget list then attempt to delete it
|
||||
try to repro on debug build figure it out, could be a big issue if it's not specifically a report issue but wider biz object issue
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
//before getting into timeouts and shit make sure it's running as well as can be in docker
|
||||
todo: look at guidance for running puppeteer (js) on alpine docker here: https://github.com/puppeteer/puppeteer/blob/main/docs/troubleshooting.md#running-on-alpine
|
||||
how jsreport is launching headless chrome, i.e. which settings and flags etc
|
||||
https://github.com/puppeteer/puppeteer/blob/main/docs/api.md#puppeteerlaunchoptions
|
||||
https://jsreport.net/learn/chrome-pdf
|
||||
https://github.com/jsreport/jsreport-chrome-pdf/blob/master/lib/conversion.js
|
||||
(after looking at it, it's still a bit unclear, maybe not relevant as they seem to do a lot differently for that)
|
||||
|
||||
|
||||
todo: look over this: https://github.com/puppeteer/puppeteer/issues/1834
|
||||
|
||||
todo: reporting load test
|
||||
test locally with 20k widgets, make it crash then determine what limits to set on it and properly return error when it's exceeded
|
||||
right now it just says something about puppeteer and "crash"
|
||||
|
||||
todo: trial license should print evaulation watermark over the report pages
|
||||
todo: bizrule for report scale value at server
|
||||
and maybe other shit as well
|
||||
|
||||
|
||||
|
||||
|
||||
todo: Need a setting that warns people about printing too much data, i.e. "That's a lot of data, are you sure you want to render that, it will be slow" or something to that effect
|
||||
|
||||
|
||||
todo: look at metrics snapshot lifecycle, perhaps it should be shorter as it's missing 100% cpu pegging during big rendering on devops
|
||||
|
||||
|
||||
|
||||
todo: Take a serious look at .net5 migration, it will almost certainly be better to do it now than down the road after a release
|
||||
it also has many performance enhancements and nifty features like code analysis and warnings which might save me a lot of hassle
|
||||
Tasks:
|
||||
1) Look at all libs I use and see if they have .net5 compatibility
|
||||
2) Do it!
|
||||
|
||||
todo: take a look at front end cypress testing etc again, it's going to be the best way to assure quality going forward and indespensible for smoke / load testing
|
||||
|
||||
|
||||
todo: triage this stuff:
|
||||
@@ -117,7 +68,7 @@ todo: wiki drag and drop image should automatically attach the image and do the
|
||||
todo: notification subscription form tags control looks like ordinary tags control might confuse people that they are tagging that subscription
|
||||
Maybe change the text to "Automatic filter tags" or "Only if tagged with"
|
||||
|
||||
todo: "lighthouse" score? PWA test tool for certification?
|
||||
|
||||
|
||||
todo: export from grid to xls, csv etc.
|
||||
I'm thinking perhaps also a secondary ability to make report templates that are actually intended for export to xls or whatever as an additional feature
|
||||
@@ -151,8 +102,22 @@ aspnetcore 5.x update
|
||||
Plan: figure out if can ditch it as a dependency and if not then figure out how to work with it now as it's all different
|
||||
|
||||
|
||||
=-=-=-=-
|
||||
REPORTING STUFF THAT IS FUTURE OR ON HOLD
|
||||
MOVE THIS TO A v.next case or into reporting SPEC doc for future reference if not a coding issue now
|
||||
|
||||
|
||||
todo: bizrule for report scale value at server
|
||||
and maybe other shit as well
|
||||
|
||||
todo: Need a setting that warns people about printing too much data, i.e. "That's a lot of data, are you sure you want to render that, it will be slow" or something to that effect
|
||||
|
||||
|
||||
todo: REPORT BACKEND - report delete throws server exception about db context re-use or something to that effect
|
||||
No exact steps top repro, but happens for Joyce with win64 release build if go in and edit same template a few times from widget list then attempt to delete it
|
||||
try to repro on debug build figure it out, could be a big issue if it's not specifically a report issue but wider biz object issue
|
||||
COULD NOT REPRO HERE
|
||||
|
||||
todo: (On hold pending testing) pdf options UI and passthrough
|
||||
OUTSTANDING
|
||||
Docs
|
||||
@@ -182,7 +147,42 @@ todo: I have console logging capture code now in backend, but it's doing nothing
|
||||
and return property with pdf name would be in an object with additional properties for diagnosis etc
|
||||
But only if it proves helpful or necessary
|
||||
mainly this would allow a console log or error or trace to flow back to the user from the script being run at the server
|
||||
|
||||
//before getting into timeouts and shit make sure it's running as well as can be in docker
|
||||
todo: look at guidance for running puppeteer (js) on alpine docker here: https://github.com/puppeteer/puppeteer/blob/main/docs/troubleshooting.md#running-on-alpine
|
||||
how jsreport is launching headless chrome, i.e. which settings and flags etc
|
||||
https://github.com/puppeteer/puppeteer/blob/main/docs/api.md#puppeteerlaunchoptions
|
||||
https://jsreport.net/learn/chrome-pdf
|
||||
https://github.com/jsreport/jsreport-chrome-pdf/blob/master/lib/conversion.js
|
||||
(after looking at it, it's still a bit unclear, maybe not relevant as they seem to do a lot differently for that)
|
||||
|
||||
|
||||
todo: look over this: https://github.com/puppeteer/puppeteer/issues/1834
|
||||
|
||||
todo: REPORT BACKEND - more timeouts for report rendering, hard kill after 30 seconds tops but adjustable interval maybe?
|
||||
each process takes time in part, need to see which is taking which time the most and killable
|
||||
i.e. run a huge report and see which exact step takes which time for each
|
||||
we have the pre-render timing out maybe need more for each step where it's vulnerable to crashing / timing out
|
||||
|
||||
Devops droplet is overwhelmed by 10k records of widgets using the customfields example report
|
||||
symptom is super high cpu usage (100%) pegged and probably virtual memory usage as well
|
||||
timeout is kind of a hard core way to work around this issue, maybe instead it should be looking at excessive cpu and memory usage?
|
||||
The metrics don't catch it because it happens too quickly for the metrics lifecycle
|
||||
|
||||
I want it to be able to handle it gracefully without crashing
|
||||
Looks like jsreports has this issue too and they hard kill the process I think if necessary, but they actually re-use the same instance for reporting I think.
|
||||
If it's not an issue then no need to resolve at the moment
|
||||
|
||||
UPDATE: No way to timeout the pdf generation built into puppeteer sharp so far, maybe some workarounds
|
||||
I think the nuclear option would be to start timer once we know the process id of the chormium instance and that time automatically kills that process ID if still found around XX seconds later
|
||||
(or in the form of a clean up job maybe like the temp file deleter job)
|
||||
|
||||
todo: reporting load test
|
||||
test locally with 20k widgets, make it crash then determine what limits to set on it and properly return error when it's exceeded
|
||||
right now it just says something about puppeteer and "crash"
|
||||
NOT ABLE TO REPRO HERE
|
||||
=-=-=-=-=-
|
||||
|
||||
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
|
||||
@@@@@@@@@@@@@ ROADMAP STAGE 5 - FINALIZE ALL NON BIZ OBJECT SPECIFIC FUNCTIONALITY
|
||||
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
|
||||
@@ -199,7 +199,7 @@ todo: FRONT END ROADMAP RELEASES (Sept 23 2020 was put on hold as it appears vue
|
||||
Vuetify 3.x is lagging way behind vue 3.x and doesn't appear to be even close so
|
||||
Put front end newification on hold until it all shakes out, looks like post release`
|
||||
|
||||
|
||||
todo: "lighthouse" score? PWA test tool for certification?
|
||||
todo: it would be *extremely* useful if we could run automated tests against the release ui with devops server
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user