Spence Harbar has a great 3-part blog here on how to configure request management. It however does not go into the deep level of what is occurring in the code. This blog will take you a bit deeper into how Request Management works.
What is Request Management? It is a Reverse Proxy implemented in SharePoint 2013. It is defined by the SPRoutingReverseProxy class. As Spence points out, Request Management is implemented in the Http Module of SharePoint (Microsoft.SharePoint.ApplicationRuntime.SPRequestModule). Internally it works like this:
- An HTTP request is received by a SharePoint Web
Application
- As part of the ASP.NET pipeline, the SPRequestModule
is passed the HTTP request for processing
- The module will check if Request Management
settings are present for the respective web application
- If settings are present, the module will then
check to see if Routing or Throttling has been enabled and if the request management
service is started. The module will also
check to see if the request routing has already been cached as part of any previous requests for the client by
an internal reverse proxy called the SPRoutingReverseProxy
- Request Management will then check to see if the
client has been assigned an affinity to a particular machine via the SPRoutingAffinity
logic
- If the request does have affinity, Request
Management will check that the target server is available, if it doesn’t, then
the next Routing Target will be selected
- Once a target has been selected, the HTTP
context will have a “SPRequestManagementRouted” item added to it for future
routing
- Lastly, the request will then be routed to the
target, the response will be proxied back to the client as long as it responds
before the Request Execution Timeout in the Request Management Settings
- The request is sent using basic HttpRequest classes and it is basically copying the request from the SharePoint server to the target server, so as long as the target server is a part of the SharePoint farm, technically any applications running on the SharePoint server can be routed too (not just SharePoint ones).
I'm actually very excited about having this reverse proxy in SharePoint. There have been a number of things I have been wanting to do on the ACS network but just couldn't do with both SharePoint and my other apps running. This gives me the ability to route the http requests to other applications on my internal network, not just SharePoint ones!
Even though Request Management is implemented as a reverse
proxy, it is lacking some common features of a full reverse proxy such as:
- URL Rewriting
- Static and Dynamic Content Caching
- Response manipulation (adding or removing JavaScript,
etc)
The process of determining the final target host is as follows:
- The request is passed to the SP Routing Rule
Evaluator
- The routing rules are evaluated and a pool of
targets will be returned. The first routing
rule to have targets wins.
- Each target is pinged to determine if they are
available, only targets that are available are considered
- For each available target, the throttling rules
are applied, if a target fails it is removed from the routing list
- The remaining targets, if more than one, are
evaluated based on their weighting, the machine with the lowest weighting is
returned
- Lastly, and not performant-ly by the way, if there is an affinity machine, it is
selected and returned (this should have been done first before analyzing the weighting, this is a design flaw in the code)
The last point about this new feature is the APIs are all set as internal. This is LAME. It keeps people like me and the real MVPs(the ones that could build these tools whether Microsoft MVP or not) from building GUI tools for it. Maybe they will open it up in the future?
To learn even more about how Request management works, buy our book when it comes out!
Enjoy!
Chris