I have an application that reads a large binary file (1GB on average) and compresses into a bzip2 archive. I started out at first compressing these files synchronously, as I didn't want to impede performance on a client machine. Sometimes however, these files come in bursts and I'd like to handle these files as quickly as possible. So I rewrote the method to use a
future asynchronous call. They are stored in a vector until complete and then are destroyed.
During my stress test, I noticed that I would inevitably have an issue with CPU usage if, let's say, 5 files came in at once on a 4 core machine. The client machine would basically be unusable until all operations were complete.
So, this brings me to design question. I am inexperienced with futures and trying to determine best practice to mitigate high CPU usage. This is the design I have in mind but before I go through the trouble of hammering out the semicolons, is there a more native feature to futures that I am unaware of?
- Determine how many CPU's are available to the host machine
- Divide number of CPU's by half to prevent more than 50% CPU usage by the application
- Use a loop on a separate thread to manage the future objects stored in a
- The loop detects when a object is no longer in scope, and starts the next
Would this be the best way to go?