The Performance Implications Of Web Security

Over the past few years all of the browser vendors have substantially enhanced the surety of their product and with it the security of the internet.  This has led to a much wider adoption of the encrypted hypertext transport protocol HTTPS, and browser will now mark websites as ‘not secure’, especially when a form, for example a login or credit card details, is requested. 

Specifically, pages that included forms where login credentials or credit card details could be entered would be labelled as not secure. 

This approach makes perfect sense and has long been part of Google’s intentions, and eventually, we can expect to see all non HTTPS, (HTTP), pages flagged as insecure.

For now though, websites that haven’t yet upgraded to HTTPS from HTTP and the site contains an input form, such as a search box at the top of every page, will see warnings triggered for all the pages on its site. 

However, while this type of protection does not have a performance implication, there are many other security initiatives that you should be aware of and how they can impact on the delivery performance of web pages, and with it customer experience.

This article takes a look at some of the security measures and their potential performance impact as a precursor to later articles that cover each of the technologies in greater depth.

HTTPS protocol displayed in the browser
HTTPS protocol displayed in the browser

Performance Impact

Other things being equal, an HTTPS website will be almost inevitably be slower than its less secure counterpart, thanks to the extra round-trips required for the TLS (Transport Layer Security) handshake that makes HTTP secure.  While this may only amount to a maximum of a less than a hundred milliseconds, human interaction could perceive that the website is slower. What’s more, this effect will be more noticeable on high-latency mobile networks.

Fortunately, there are plenty of ways to make TLS fast. Here are a few:

OCSP Stapling

OCSP stands for Online Certificate Status Protocol. This is a way to ensure that a site’s TLS certificate is valid. The client does completes this task by querying the certificate with the certifying authority. However, this is far from ideal, as it means the client has to retrieve information from a third-party before it can even start getting content from the website.

OCSP stapling works around this delay by passing responsibility for certificate verification from the client, on each webpage request, to the server.  Instead of the client having to do the look-up when it accesses the site, the server will carry out the look-up from time to time to verify the status of the certificate with the authority and will then store, or ‘staple’ the certificate on the webserver.  This enables the client request to be verified by the web server and as such negates the extra TLS handshake protocol and the time it would normally take to execute.  

TLS Session Resumption

TLS session resumption works by storing information about a TLS connection that’s already been established. This allows a client to reconnect to a host with an abbreviated TLS handshake, cutting the time it takes to make the connection.  Consequently, should the client request a second resource from the web server it will no longer need to request certificate authorisation a second time.

HSTS

HSTS stands for HTTP Strict Transport Security and it is designed as an important security enhancement to help prevent man-in-the-middle attacks on the HTTP stream.   This function comes with a knock-on benefit for web performance.

Essentially, HSTS means telling the browser or user agent that it should only ever access your website over HTTPS. This saves a costly redirect to use the HTTPS protocol when a visitor to your website requests the HTTP version. 

To implement HSTS the ability for the server issues a response header to the browser or user agent’s first call enforces connection over HTTPS and disregards any other request, such as via a script, to load over HTTP.  Although this has the disadvantage of only working after the first visit someone makes to your site. 

HTTP/2

HTTP/2, now more commonly known simply as H2, offers a range of performance enhancements that complements the improvements in security.    A pre-requisite for H2 is HTTPS which enforces a high security regime for the fastest HTTP protocol. 

As H2 implements multiple requests and responses to be multiplexed over a single connection, the risk that one slow-loading asset will block other resources is reduced.  Response Headers are also compressed, reducing the size of both requests and responses. 

Other features, such as server push, are evolving, but should offer even more performance benefits.

A More Secure Future

As we are edging ever closer to an HTTPS-only web, delivering greater privacy and better security for all web users, browser vendors seem intent on accelerating the pace of change so an understanding of how security impacts on web performance can help you prepare to ensure customer experience is not impacted. 

Exposing the vagaries of ORM in load testing

Taking a look at database issues and why an ORM-accessed RDBMS may cause web performance issues

After a long journey in design, development and functional testing, rarely is a new website or application completed without a performance load test as one of its final milestones. Project, and sometimes regulatory, sign-off is dependent on certain criteria being met so there is often much riding on the successful outcome of the load test. Because of this there can be considerable trepidation in the team as they start the load testing process as load testing is designed to exercise both the software and hardware configurations to their limits.

Although the clear objective is to obtain the load test milestone, enabling sign-off for the project, real benefits can be achieved from a well-managed load testing programme that exercises different performance aspects, such as normal and peak operations together with stress, spikey and endurance scenarios. For new applications the load test can often be the first time more than a handful of end-to-end interactions occur concurrently and it is also the time when API’s and endpoints, potentially located in different environments, are tested for stability and scalability.

Its Not Just the Software

In our previous article A Cloudy Day in Performance Load Testing we covered some aspects of how cloud-based environments can influence an application’s scale-ability, but other paradigm’s, such as databases, can be just as influential.

Our chart above shows how influential poor-performing databases can be. These results, from a 4 hour endurance load test, show that after an hour of running at 500 concurrent users, degradation of successful test completions occurs. At this time server response slows, causing page load failures, identified by the black lines, for a significant number of tests.

During the test the client was able to determine that this was caused by a specific database query that was scanning a table for a result rather than using an index. Although the table scan gave the correct result, increasing load was developing on the database server that it could not serve in the time expected of it as the load test continued. The client was able to dynamically resolve the issue creating an index and enabling very fast index searches to occur and which alleviated the bottleneck for the remainder of the test.

ORM and RDBMS

Resolving database scan issues is not uncommon in load testing and when working directly with native databases, schema design, indexes and foreign key issues are easy to identify and resolve. However, things become more complicated when the database is abstracted through object relational mapping (ORM), technology.

ORM is a technology that sits between the database (RDBMS) and application code. As it cr eates a level of abstraction between the application code and the database it reduces the amount and complexity of code necessary to interact with a database. It is not a new technology and there are many commercial frameworks that support ORM and because of the abstraction and programming benefits, take up in application development is increasing.

However, ORM comes with a cost especially in its effect on databases and their performance. A quick search on the internet will unearth many good resources that cover ORM performance but sometimes performance enhancements in ORM are insufficient.

In a recent load test the client found that a particular ORM-accessed database resource was serialising and long queues were developing. This in turn was slowing response as the resource use was pervasive across the application. Having run out of ORM performance tuning options, a quick refactoring taking the resource out of ORM control and using a traditional direct SQL-based transactions resolved the issue. Database resources reduced from 70% to 7% utilisation at peak load and further load testing proved the environment could now run on 50% less configured database resources, saving further costs in their budget for cloud resources.

Closing Observation

Correctly structured, load testing is able to deliver a wealth of performance benefits to any web application project and as this article shows sometimes only when you really exercise the application do you find some real opportunities for performance enhancement and real cost saving.