The server is very slow. i've talked furiously to the people at dediserve and they seem to just reboot apache and claim its fixed. they claim to be 'logging' and nothing gets done. its pretty frustrating becasue even when i ssh to the system and do: #top it shows no real activity spikes and low cpu all the way. i'm thinking its some sort of crash or badlt configured php.
so i guess my question to all the linux people is, how do i trace slow php? how can i find out on a linux box what is bottlenecking the execution of php?
Also, you haven't got ay ridiculous variations on the site, have you? We have some which create something like 2000 variations (ie. different customisations), which caused issues in previous releases. Also, a lot of the 'cleaning up' thing I do, involves cleaning out old useless variations, for which I posted the SQL somewhere on here back in the ol' VB days...not sure where it is though. This initially reduced our database (which was intact from development to launch) by 70%, at the same time I installed eAccelerator (I've now figured X-Cache is better though) and these efforts combined caused pages with variations to load much quicker (products with a lot of options did load very slowly beforehand).
Is the admin running just as slow? What happens when you try to Exports your products or variations to CSV, getting any errors from there or is it verrrrry slow? That caused a lot of our early issues with ISC on a dedicated box.
My final port of call would be setting up Xdebug and/or KCacheGrind, neither will be much fun to integrate with ISC, but is do-able relatively straightforward.
I upped the ram to 4gb for the domains ind it seemed to go well.
I eventually tracked the slowness down to MASSIVE log tables. various errors due to problems we had not detected were being held in the log table, it was 250mb. I deleted them and we got some speed back. Errors of various kinds were happening on almost every pageview.
This large table (and the furious logging) caused another problem that crashed the sessions table (the one that holds carts and things) and stopped people adding to the cart, stopping business altogether.
A quick blast in the console to repair the table and all is well. Both tabled TRUNCATE and we're back up to full speed. Orders came in straight away as savvy customers fanatically add to cart and slap their card details in.
Our ISC site recently went down due to disc space (although we didn't know that was the reason until NuBlue support took over)
Turned out the system log table was taking up a ridiculous amount of space in the database. We outgrew our 10gb allowance and, when the logs were trimmed down (and set to only log for a rolling 500 records) we went down to using 2.9gb! ALL that extra space was store logs!
Settings > Store Settings > Logging > 'Restrict Log To' for both System and Staff.
Sorry I didn't suggest this one earlier, especially because it's a problem I've had to resolve on numerous ISC installations and this is one of the more common issues with the cart, which is down to poor configuration rather than failure of the software.
Once you've got the cart all built, you might want to take a look at the post I put up about variations - the variations combinations table gets rather quite big once you start dabbling with 2+ option groups on a product. The SQL cleans out unused variations and various other clean ups - definitely one of my (relatively) regular manual fixes I apply to ISC carts to speed things up.