Integrating to legacy temperature monitoring device

Below is sample code of a proxy ASP.Net page that queries a TempageR 4E realtime temperature monitor and exposes the temperature to PRTG in order to report and escalate out of range values.

public partial class FetchTemp : System.Web.UI.Page
    {
        protected void Page_Load(object sender, EventArgs e)
        {
            System.Net.Sockets.TcpClient client = new System.Net.Sockets.TcpClient(System.Configuration.ConfigurationManager.AppSettings["ip"], 80);
            NetworkStream ns = client.GetStream();
            byte[] request = System.Text.Encoding.ASCII.GetBytes("GET /getData.htm HTTP/1.1\r\n\r\n");

            ns.Write(request, 0, request.Length);

            byte[] resp = new byte[2048];
            int bytes = -1;

            StringBuilder sb = new StringBuilder(); 

            while (bytes != 0)
            {
                bytes = ns.Read(resp, 0, resp.Length);
                sb.Append(System.Text.Encoding.ASCII.GetString(resp, 0, bytes));
            }

            dynamic obj = JsonConvert.DeserializeObject(sb.ToString());
            Response.Write("[" + obj.sensor[0].tempc + "]");
        }
    }

It calls the getData.htm page, which exposes the device info, sensors and their values as a JSON object. This gets parsed, and the value of the first sensor is written to the Response in blockquotes. The PRTG HTTP Content sensor is configured with the URL of the page (FetchTemp.aspx).

The code uses a TcpClient instance to retrieve the data. The getData.htm page does not return HTTP response headers, which causes HttpWebRequest as well as the built-in PRTG HTTP XML/REST sensor to fail with "The underlying connection was closed unexpectedly", using TcpClient solves this issue.

HTTP concurrent connections

Our application exposes a webservice interface to clients, and connects to other providers for performing transactions. Whilst doing loadtesting, I noticed that the client connecting to an upstream provider using HttpWebRequest was not opening more than 2 concurrent connections at any time, causing latency to go through the roof and tps not scaling once the number of simultaneous requests to the webservices goes over 5. Googling a bit yielded this link: http://social.msdn.microsoft.com/Forums/en-US/1f863f20-09f9-49a5-8eee-17a89b591007/asynchronous-httpwebrequest-maximum-connections-best-approach-threads-or-delegates?forum=netfxnetcom.

Googling a little bit more I found details about the connectionManagement config section. After adding a section to the application's config file it now scales as expected, with more simultaneous connections increasing the tps as expected.