Will RequestReduce impact server performance?

There are really two key operations to consider when it comes to RequestReduce's impact on server performance? There is the impact of the filter which runs over every text/html response and there is the impact of the reducer which scans css files for images it can sprite, generates new image files containing the image sprites and also creating a single new and minified css.

###Processing a CSS or Javascript Signature The second of these operations is by far the most expensive and potentially impactful. RequestReduce issues an HTTP request for every css and javascript file and every image that it intends to sprite. It has to load the image into memory and add it to a new image that it builds which will hold all of the sprites. There are several regular expression (compiled only once) operations involved and the final minification is not cheap either. On a server under minimal load, this could take a couple seconds for a simple and minimal css file. It might take a few minutes for if there are several CSS files, expecially if they include @imports and lots of background images. The good news is that this has to be done only once per CSS/javascript signature. Request Reduce considers the sum of each url in a group of scripts or stylesheets to be processed its signature. Many if not all pages on your site may share this same signature. Furthermore the results of the operation persist over application pool recycling events. RequestReduce will not reprocess a CSS signature until the signature changes (you rename, add or remove a css file) or you [explicitly ask RequestReduce to reprocess the signature].

Also, this operation will not block a request of one of your visitors. When RequestReduce sees that there is a new signature to be processed, it queues the signature and then passes the response through without filtering it. The actual processing operation is done on a single background thread devoted to this operation. RequestReduce will not use more than one thread and the thread does not come from the ASP.NET worker thread pool.

###The Response Filter I think the most important operation to consider is the filter which runs over every text/html response and has a direct impact on page performance. RequestReduce is very efficient here. It DOES NOT load the entire page into memory and then perform find/replace operations on the entire page. Rather, it inspects the response in a streaming fashion byte by byte. The only fragment of the page committed to memory is any portion that matches the tags tat RequestReduce scans for. My perf testing (albeit not under heavy load) revealed that only 1 to 2 milliseconds were spent inside of RequestReduce operations.

The whole point of RequestReduce is to improve page performance. If you suspect that RequestReduce is having a negative impact on your site performance, please stop using it and either contact me or add an issue to this project.