[Jeremy Smith]

It's really essentially the logic within X Cart's that's the problem.

The default problem with v4.1.11 is that say you have about 1,200 approx products you categorise them right?

You might still have say 600 products which show on a root category, the base category say for our example Brother Lasers and Inks, it has to then index those pages (providing your database indexes are up to date), but even then it's got to show them then paginate the results which takes allot of time up on the servers side for processing.

That is the main dilemma with X Cart's way of searching.

Even if you're not using a search field, it's probably doing about 3-5 things at once which providing how many processors you have on the actual server or processing power on a VPS or Hosted solution like just an ftp login and no actual remote shell access then you're going to struggle if it's too low.

Even on our data centre stored own server the forum we run for our company works fine with searching which has far more entries than even our webstore and that works perfectly fine, it's just a case of working out (profiling your searches), what part of your code is causing the problem.

Which is what I am going to really get glued into right now really as this needs sorting, I am sure that with some effort we can come to an assumption and a possible remedy.

Going to even try mocking the search up myself and see what happens on a sandbox version of X Cart I run so the live site doesn't break (even that's as slow as our live site), it's simply awful the search, but to be fair with the developers of X Cart you don't pay all that much for it and the likes of Google have spent thousands if not millions on perfecting searches.