Another possibility perhaps. Do you really need an external monitor?
Never use an external monitor when a built-in one will work as well. Forking a shell and running even the simplest shell script takes a significant amount of system resources, so external monitors should be avoided whenever possible. If possible, have the server administrator script execution of the required transaction on the server itself (or locate/author an alternative script on the server) that reliably reflects its availability. Then, instead of an external monitor, you can define a built-in monitor that requests that dynamic script from the server, and let the server run the script locally and report results. For example, the simple request/response HTTP transaction in the sample script below would be much better implemented using the built in basic HTTP monitor.
We can use the built in monitors until F5 add SNI capability without the performance hit. see links below
There is another alternative.
http://blogs.technet.com/b/applicationproxyblog/archive/2014/06/19/how-to-support-non-sni-capable-clients-with-web-application-proxy-and-ad-fs-2012-r2.aspx
A very useful tool for manipulating http.sys
http://www.codeproject.com/Articles/437733/Demystify-http-sys-with-HttpSysManager
Hope this provides another perspective.