It's quite a while since I wrote the last blog post about jsreport and you maybe wondering what is new and what we are currently working on. It's 2 months since we closed feature scope and started to concentrate mainly on better code base, stability and performance. We have made a huge step already in all of these areas. Today I will go deeper into performance improvements we have added into jsreport and show you some results.
jsreport is safe by design and rendering any report should not hurt the system. This was reached by moving report rendering into separate process where we control it's consumptions and kill it if needed. Unfortunately this turned out to be quite slow approach and not very well behaving when thousands of requests to render report come at once. The biggest problem there is allocating child process for every request takes some time and also you cannot allocate hundreds of them at once.
You can see current jsreport infrastructure schema on the following picture.
By default jsreport allocates a worker for every cpu to maximize parallelization. This can be changed in config file and I recommend you to check out config file documentation for other options.
Ok, give us some numbers and results...
You can see these results are pretty good. This means that doing reports based on html -> pdf conversion is not only the most flexible way but also performing very well. 641 pdf pages per second should be enough for the most crazy reporting solution you have.