For a personalized view of our test case result we use process our output.xml files.
We now have some stability test cases that are running over 48 hours resulting in very large output.xml files, about 8.5GB.
When we try to process them with: result = ExecutionResult(output_file)
The code exits after about 900 seconds, with the only output “Killed”.
There are no exception throne, the python code just exits.
Are the any timeout that can be tweeted?
Any other ways to get around this?
Are these files on a local disk or some type of network drive?, though I’m not familiar with the code behind ExecutionResult, the 900 sec is leading me to think it might be a slow disk io issue?, if that’s is the case i’d try copying the file locally first (into a temp dir?)
here’s the API doc for ExecutionResult (if you didn’t have it), the only options that might help are the include_keywords and flattened_keywords that get passed though to ExecutionResultBuilder, maybe as a test you could try adding the option include_keywords=False just to see if that makes a difference?
After testing different ways of reprocessing using rebot, I found that it is not an timing it’s a size issue:
rebot --output small.xml --removekeywords ALL output.xml
Killed
rebot --flattenkeywords ITERATION --output small.xml output.xml
Resulted in successful processing and an 9MB small.xml file from an input of 8.5GB!
I also notice that we had output.xml files up to 2GB that has been successfully processed to that seems to be the limit.
I don’t have direct control of how the output.xml is created so, my way forward here is that I’ll check if my input output.xml file is larger the 2GB. In that case I’ll pre-process it with “rebot --flattenkeywords ITERATION --output small.xml output.xml”.
Now I can process it with result = ExecutionResult(output_file)
The main problem with processing huge output.xml files is typically the memory usage. If more memory is needed than the machine has real RAM, the operating system starts swapping and execution slows down. There’s also a limit for swapping and if that’s exceeded then the process is killed.
The reason --flatten-keywords help so much is that it affects XML parsing in very low level (see the code here). It basically throws away unnecessary XML nodes (which saves memory) and that avoids creating Robot’s keyword objects (which saves even more memory). Because flattening is so powerful, we added a dedicated robot:flatten keyword tag to support that during execution. It doesn’t at least yet support flattening loop iterations only similarly as --flatten-keywords iteration does (and yes, --flatten-keywords is badly named as it also affects control structures).
If you use --remove-keywords, the end result can be as good as with --flatten-keywords, but that option requires first parsing the whole output.xml and thus you may not ever see those end results.