ca000001.pl Take a long time to "process"

[Mark Crisell]

Hi,

Having now brought on-board a reputable site monitoring company we have been shown that a high volume of our visitors are experiencing slow processing surrounding the "process time" of ca000001.pl when they "confirm" the shopping cart page (after adding a product to the cart).

Sometimes it's a couple of seconds, other times it's 10 seconds and more.

Anyone ever experienced this?

I'm assuming it's down to the available CPU on the shared server we host upon (Verio VPS), but I'd like some better knowledge before I approach them.

Thx in advance.

[I-CC]

Could be a number of things, all based on reducing impact of lots of perl scripts running at the same time, session limits, right down to the cpu and available ram on the server, where perl checkout scripts use a lot of ram, so multiple concurrent perl scripts running the checkout can cause this also.

Explain you are using Actinic with the perl scripts and see if they will switch you to a server with less population of actinic sites or faster system maybe.

[Mark Crisell]

Thanks for the advice, I'll see what Verio says.

[Mike Hughes]

Are you sure it's not just the stage after they confirm where people are asked to "please wait to be returned to the page you came from" (or whatever).

Mike

[Mark Crisell]

I had stewed over that very thought for some time, I wondered if the "wait" was about 10 seconds and it was that I was seeing in the site monitoring report. However, it shows an average time of 2.2 seconds, and a peak of 15.9 seconds for the page to load. And all the site monitoring is doing is running a "journey" (macro) to view product page, add product to basket, and hit confirm. It does this journey every ten minutes from a set of 5 or 6 different "servers" across the UK and reports back to us if a page isn't responding, etc. etc.

Looking at a large number of peaks shows it is this last page that is taking so long - no regular pattern to the time of day, etc.

[Mike Hughes]

Sounds like a comprehensive test. If it's a regular occurence then it might be worth trying to recreate it personally. At least this way you'd get a feeling for how often it occurs and how bad the delay feels to a user.

There's no real reason I can think of for why this particular script is taking so long. I assume it must be updating the session file and cart summary cookie but whether this is significant or not I haven't a clue.

I assume the monitoring macro is capable of accepting cookies.

mike

[Mark Crisell]

I couldn't be sure if it could accept cookies or not, but that could probably be ruled out as it shows a minimum time for this last page of just under a second. So some times this last page in the journey gets done in a very short time, and some times it can take in excess of 15 seconds... with it going from one extreme to another I can only assume it's a server issue.

[Mark Crisell]

Still looking into this, and one of the monitoring company's techies has said:-

If their page has a delay in processing then it is possible we do show it. It depends how that delay happens. Can you ask him to provide technical details of this delay mechanism (e.g. is it using Javascript, or is it using code in the CGI script, etc). I presume one of his tech guys can provide more info.

I'm struggling to find an answer for them. I've looked at the source code of the page that is showing the "Continue Shopping" button, that automatically forwards after a few seconds, but I don't see any obvious JavaScript, or a meta tag to auto-forward.

Is anyone able to explain how this delay/auto-forward happens?

[cdicken]

The 'Please wait to be forward or click here' bounce page is built dynamically by the perl scripts and uses a meta refresh - so they delay could be caused by the perl not responding quick enough due a resource availability issue on the server. That's all I can suggest.

[Mark Crisell]

Thanks Chris, I've now fired off emails to the hosting company to see if they can offer any assistance.

We are seeing generally the "time taken to process" is around half a second, but extremely frequent times of 15 or 20 seconds. That results in customers getting bored, closing the browser, buying from a competitor... lost sales... etc etc.

Maybe a balance issue with our co-habitants on the VPS.