IT:AD:Documentation:SAD:RAW:Example:1:Appendices:Web Development Constraints

Responsiveness is dependent on latency, which is in turn dependent on the network the client is using to access the service.

In the case of NZ inhabitants using an organisation service hosted in Australia, the following information is relevant:

“Ping times [24ms] to Australia [on Verizon] are on a par with domestic times. Reannz (Research and Education Advanced Network New Zealand Ltd) reports domestic latency between the two furthest points of presence on its network, North Shore and Invermay is 22ms. While traffic from New Zealand’s South Island has to travel to Auckland before making the trans-Tasman hop, for New Zealand companies in Auckland, Eastern Australia has domestic-like latency.”¹⁾

Assuming that an uncached page requires an average of 9 additional requests for associated css, images, scripts, and that the leading browser can parallelize 6²⁾ connections at a time, the additional latency to Australia – on Verizon – could be as low as 48ms.

If the above analysis is more or less correct, 2×15.87ms is faster than 2x48ms for a complete View request. But not by much.
If the page was optimized to keep the number of requests required below 6, the additional latency would be 24ms-15.87ms (8.13ms).

The actual page itself takes time too. With throughput from NZ to NZ being 26.21 Mbps, and Australia to NZ being 13.11 Mbps, a complete view takes 76ms (or 152ms) to be transferred from server to client.

In light of the above data, the latency from the network distance to Australia is negligible, and the most performance improvements will come from paying attention to how the application is actually put together, implementing basic design recommendations.

A current standard web server (eg: IIS on Windows Server 2012, 4 Core CPU) can handle 80,000 Requests per Second (RPS) for a static text page³⁾.
When developing using .NET Core, the RPS increases to 1.1 million RPS:

⁴⁾

A static text html page orchestrating requests for approximately 9 additional uncached requests for related static css, images and js files means only 1/10th the number of complete pages can be sent per second (ie 100,000 *pages).

The above implies that a .NET Core based app on a single web server is capable of servicing uncached requests for a static html page by the whole working population of New Zealand in just over 40 seconds.

At this point in time, it is hard to define the true cost of dynamic page websites. If you use server based UI development methods (ASP.NET, ASP.MVC, etc.) practically every page has the same cost as the above first single page. In other words, 10 requests per page. But if you are developing using SPA development practices, subsequent responses do not include images, css, etc. And so therefore the number of responses required for further operations drops closer to 1 response per operation.

Either way, if the application server does not do cross device calls, and is not performing non-trivial time consuming calculations, the cost of the dynamic assembly of the response stream can be assumed to be absorbed in the above.

But a dynamic web page is only as fast as its slowest component – which can be the NIC, Database Service, or SAN.

Generally speaking, a 100Mbs NIC is only able to handle about 3000 batch requests per second, and a 1Gbs Card could get up to 6000 requests (1Gbs card should, but is not 10 times as fast).

Sql Server with a 3000 Batch Requests/Sec is typically high.

And then there is the SAN, which cannot be summarized.

Discounting the SAN for now, the above indicates that for a dynamic pages, due to the database bottleneck, the following responses can be achieved: • 1000 dynamic pages, with 3 db hits per page, and judicious caching
• 3000 dynamic pages with 1 db hit per page, and judicious caching