up vote 0 down vote favorite
share [g+] share [fb]

I have a linux box running an ecommerce store. Everything is fine until the user goes to checkout. Once the user clicks checkout the system moves the user to the https service. Images and page load times are taking longer then expected. There doesn't seem to be any abnormal processes or processes taking up an irregular amount of memory. I've restarted the two apache processes (HTTP & HTTPS) running the website.

How would I go about profiling this issue?

link|improve this question
75% accept rate
feedback

3 Answers

up vote 1 down vote

I'm assuming you can at least reproduce the issue. Have you profiled the page loads to see if it's one particular part of the page that's causing the problem, or whether all calls are bad? It could be that it has nothing to do with SSL at all and actually is to do with the checkout process (e.g. database slowness/locking).

If it's all SSL queries, next step is to test SSL without any of the complicated stuff going on. Time a simple wget or curl of a small file over SSL. Try it, if you can, both locally and remotely; if it's fast from the webserver machine then you possibly have an issue on the network.

link|improve this answer
OK I tried it both local on the webserver and remotely on my box. Remotely it was taking at least 5 seconds to load the checkout.php page but locally the page loaded in less then a second. I also experienced a delay in connecting to the box over SSH, again it took about 5 seconds to connect, normally it's pretty immediate. Does this necessarily determine a network issue, or could it be something related to openssl? – Brian Wigginton Sep 18 '09 at 16:38
If you're connecting via SSL with the local test, I'm inclined to think networking somewhere, because the encryption load would be constant. If you're doing localhost/whatever.html then the only difference is going over the network vs. the loopback. – Morven Sep 18 '09 at 18:23
feedback
up vote 1 down vote

How much difference in performance are you seeing? Remember that browsers and proxies should not cache any content HTTPS including graphics, stylesheets and script files. This alone can make a site feel significantly less responsive depending on your design and how close you are already to those magic points where us humans start to notice response time differences.

Also, what sort of environment are you running under? A fully dedicated box, or a VM of some sort? What of the many web server, scripting options and database solutions are you using - this could make a big difference to how you will go about watching processes to look for issues. Does your checkout process use the same language and such as the main site? (I have seen sites where the main catalogue is done in PHP and the checkout process in something else, presumably as one or both parts have been bought in and integrated).

link|improve this answer
It feels like the site is just choking on handling the request. The sites been running fine for years, and then suddenly the other day the checkout process just chokes for about 5-10 seconds sometimes worse. The entire site is written in PHP on a dedicated LAMP box. The only difference is that there are two http processes running, one with SSL and one without. – Brian Wigginton Sep 18 '09 at 16:26
Is the machine swapping due to being low on memory? It could be that the SSL handling process are getting swapped out as they aren't used often, and swapped back in first time they are needed after a while. – David Spillett Sep 18 '09 at 16:43
feedback
up vote 0 down vote accepted

Turns out the DNS servers the box was using weren't working for whatever reason. Once we pointed the box to a new set of nameservers the delay disappeared.

link|improve this answer
feedback

Your Answer

 
or
required, but never shown
discard

Not the answer you're looking for? Browse other questions tagged or ask your own question.