ShopWindow API and server CPU usage

[authcode]

My hosting provider keeps going on at me about how much server CPU time my 2 Shop Window sites are using. They are both custom written in PHP using the API (they share most of their code) and use 4 or 5 soap calls and a few extra database lookups per page load.

To me this is fairly bog standard PHP and shouldn't tax a web server to the point of using 45% of its CPU. Traffic on both sites is modest and pages are simple lookup-format-output affairs, not too disimilar from the client software (in fact, probably a lot fewer lines of code).

Can anyone with more PHP/web server experience shed any light on what might be causing high CPU loads when using the API? Or what causes high CPU loads generally? What should I be looking to optimise because I'm getting pretty fed up with being nagged about it when it seems to me there's not a lot I can change.

[Andy]

there's a few things you can do to speed up a script, which will probably have the desired effect on your cpu.

(excuse me if I'm telling you what you already know)

When a php script ends, the server automatically unsets all variables connected with it in the memory. However unset() will do this during the script execution.
Go through your files and unset variables once you're done with them, this should start freeing up some memory and hopefully cpu cycles.

If you really think hard, you'll see alot of variables become redundant rather early on in most scripts, unsetting them will clear the memory for something else.



Output wise, there is no difference between this (String variable parsing):

<?PHP

echo "<a href=\"$variableURL\" title=\"$variable\">$variable</a>";
?>
and this (string concatenation):

<?PHP

echo '<a href="'.$variableURL.'" title="'.$variable.'">'.$variable.'</a>';
?>
however in the first example, the line is read completely (stored in memory), then the memory is checked for variables associated with it. The server treats the entire line as PHP and tries to make sense of it. It's almost as if it gets read twice.

Whereas with the second example, you are telling the server what is PHP and what is straight output. So in my opinion, it's always better to use the second format.
The php docs state:
Parsing variables within strings uses more memory than string concatenation. When writing a PHP script in which memory usage is a concern, consider using the concatenation operator (.) rather than variable parsing.


Last idea I've got in my head is to go through your error logs. You might find some undefined indexes or pretty much anything really (this is shopwindow after all) that could be slowing things down and eating up your CPU.

Good Luck. let us know what you end up doing!

[Confuscius]

One other thing you can do is put a crawl delay in your robots file for the likes of msn! Peaks on my VPS's are always caused by MSN!

Check you logs for who is hitting you hard.

What sort of hosting have you got? If it is shared then I am not surprised - you will probably find that if you generate full indexing speed on one site then this will probably require a VPS with some guaranteed memory - I started with 2 basic ones but both are not at their max memory and they still fall over occasionally and they each VPS runs a single installations. I use about 800,000 calls per day over the two.

Paul

[authcode]

Thanks guys.

Andy: some good tips there. I'm self-taught when it comes to PHP and although I'm a quick learner there's nothing like experience. My code has always done what I wanted it to but as personal projects I've never been too bothered about optimisation until now. I'll take another look through my code with what you've said in mind.

Confuscius: I am on shared hosting as I'm unwilling to cough up the money for VPS until I'm certain my sites can pay for themselves. It's a chicken and egg scenario. I also suspect it's robots causing the problem so I'll go ahead with a crawl-delay but my concern was that if robots can cripple my sites then high traffic will too - again raising the issue of optimisation.

Does anyone know if SOAP as a technology puts extra strain on a server's CPU compared to PHP/MySQL alone? If it really is the SOAP stuff causing most of the problem I'll have to look at caching more data or upgrading to VPS.

[Andy]

Self taught too Authcode!!

I found that one robot in particular was hammering me last year, it was called irlbot http://irl.cs.tamu.edu/crawler/

It's an educational tool rather than a search engine spider, so it's fine to block it. The link will give you more info.