There are several layers of redirects that we have setup. This should be the order in which they run:
1) .htaccess redirects. These include very high-level settings such as redirecting http to https and pointing certain URL formats to the WP application to be processed. This enables features such as SEO-friendly URLs, at the most basic level.
2) Our custom redirects code. We have a URL parser with specific pattern matching, mostly for processing URLs from the old site. If interested, this code is located in wp-content/plugins/biopac-custom/url-parsing.php. In general it matches certain script names and/or URL parameters, with some regex parsing thrown in when necessary.
3) WP Redirect plugin. Anything not already caught be another redirect will eventually get to this plugin. It checks exact matches first, then loops through all of the regexes to see if it matches one of those.
There could also be redirects thrown into other places in the code ad hoc as well.
The Redirection plugin has hundreds of regexes that need to be checked for matches. The plugin runs a query on every page hit to try to match on any exact match OR all of the regexes. It has the following Where clause when run from the /products/ URL:
WHERE (wp_redirection_items.regex=1 OR wp_redirection_items.url='/products/')
So basically it’s running a single query to try to match exactly AND pull in all of the regexes to check with code. This has the effect of pulling a recordset with over 3000 rows. The query itself runs very quickly, less than 0.01 seconds usually. The looping through and checking of each regex in PHP does take around a half second to process sometimes.
The CUSTOM redirects that we setup as part of the biopac-custom plugin, in the url-parsing.php file, do not appear to have a signicant impact on performance. Processing times are generally tiny fractions of a second. The code was written in a way to match on specific strings in the URL, so it should be pretty quick. Charity and Travis both worked on this file and know it fairly well.