As you probably know, the percent of secure HTTPS web sites is growing every day. Moreover, even if you do not care about security, the latest news from Google suggests that you will have to move to HTTPS in any case, because otherwise you will see your site dropping down in search results.
Depending on the implementation of your site, switching it to secure connection may take from few minutes to few weeks. You may face functional problems, broken links and thigs like that. Imagine that after you have done everything required, you finally see your site working under the perfect green line of the browser address bar. The question is: what have happened with the site performance, and should you load test it again?
The answer is yes, because of three reasons. First, the data sent over SSL connection must be encrypted. This is done very fast, but still requires additional CPU resources in comparison with unencrypted HTTP, especially for sites with mainly static content. Second, SSL handshake takes additional time and resources. If, for some reason, the connection is reopened frequently, the impact will be higher. Third, some components of your application may start working differently after the switch. This refers not to the web server only. Even though in most cases this problem does not take place, you still need to load test the site in order to make reliable conclusions.
The next question is if you can apply the same tests with just the protocol type updated? The answer is: “yes, but this is not recommended”, which actually means “no”. The reason is that you will have to update too many places, because sometimes URLs are contained inside the POST data. Even if you do this work carefully, you cannot be sure that your application sends exactly the same sequences of requests as before. So, it is very much recommended to remake the tests.
If you never tested HTTPS sites before, you may face new problems while recording your tests. The problem is that when recording, WAPT works as a proxy between your browser and the target site. This is easy when the information is passed unencrypted. However the purpose of HTTPS is to make it impossible for anyone in the middle to read the encrypted information. How WAPT can do this? It actually has to decrypt and encrypt it again. The browser thinks that encryption performed by WAPT is done by the site. The site, in turn, thinks that it gets data encrypted by the browser. This is possible only in case your browser trusts WAPT as a highest authority. You can make it do so by adding WAPT recorder certificate to the system store called “Trusted Root Certification Authorities”:
By default, WAPT will try to install that certificate automatically. It will prompt you for that when you try recording an HTTPS web site for the first time. You need to have administrative rights on the system to complete this process.
You can also do this manually from the Setting dialog. Click the “View/Install Certificate…” button for that.
If certificate is installed properly, your browser should treat the connection as secure and you should be able to record the site without problems. The good news is that everything else is done for HTTPS sites exactly the same way as before.
