Hi,
CJPinder:
The problem is that the URI Mapping add-on is doing full table scans on every query. This is due to the lack of indexes.
Yes, I always thought indexes would be a good idea to speed things up and as I said I was expecting that someone with more database expertise would contribute their thoughts eventually. The fact that it has taken several years for anyone to say anything made this remain a low priority for me to look into.. with no complaints about speed came no motivation to add the indexes.
The index you posted.. would it benefit from having the current_uri field indexed or not? I don't know enough about these things to make that decision and don't have the time to try out various options to see what's best so if you know about these things your advice would be appreciated.
CJPinder:
It also uses REGEXP which means a very slow full table scan.
I don't think it *means *a very slow table scan, but it certainly will result in a *slower *table scan. I decided that since it was such a simple regular expression (a text string with one single optional character at the end) that a query using it as opposed to two LIKES would be probably quicker. I didn't do any tests to see if that is true, again as I'm not an expert in this field and have limited time.
CJPinder:
When an index was added to the ceon_uri_mappings table the query time for the homepage dropped dramatically.
That's exactly what would be expected of course but as no-one has previously mentioned any speed issues I never added the index.. which I was taking as the original speed of the queries being sufficiently fast anyway that people didn't feel the need for an increase.
Personally I always want things to work as flexibly as possible first, then as efficiently as possible second and in this case an index will definitely give extra efficiency without impinging upon the flexibility/functionality of the software so it's definitely a good addition. As I said, I've been waiting for someone with more expertise than me in this area to comment so I'll be interested to hear your thoughts about the question I've asked above.
CJPinder:
The product and category pages are still slow because of the full table scan using REGEXP. The additional of a LIKE with wildcard that I suggested should hopefully speed that up. We won't know for sure until fadwad123 tests it and reports back.
A LIKE with a wildcard won't work as it will mean that categories will be matched instead of subcategories as the category's URI is a subset of the subcategory's URI. As I was saying, the one REGEXP could be changed into two LIKES but I'd have imagined that that would be slower. I don't know though. The other option I talked about previously is simply to drop support for storing URIs with a slash at the end in the DB, that way a single LIKE could be used.
CJPinder:
Using to LIKEs without wildcards and with an index is also an option. It was going to be my second suggestion after I had heard back about using the additional LIKE with wildcard.
Sorry you've already said what I just said.. I mustn't have read the post properly before starting to comment on a point by point basis.. that's that rushing things thing again! :|
CJPinder:
Now, it may be that on a fast server with lots of memory and a well tuned MySQL server the full table scans won't show as an issue. However, they are an issue and they are unnecessary. It may be that fadwad123's MySQL server is not fully tuned and that is showing up the problem with the Mapping Add-On. Tuning the server may mask the problem but the problem will still remain.
I do agree that making things as efficient as possible is very important (again as long as that's not at the cost of functionality) but I don't see how this one server can be so slow when no-one else has reported problems and the person himself said that his site was faster on a shared server.
When I tested a site with almost 1000 products mapped recently it was on a desktop Pentium D PC with the standard versions of Apache for windoze, PHP5.3 and MySQL 5.1.. there was no noticeable difference between the site with 1000 mappings and a similar one which only had 5 mappings, so for a site with a few thousand more mappings to take 16 seconds to build a page just sounds like the server itself must have a problem. Which is why I suggested loking at SQL connections etc.
Certainly making URI Mapping more efficient is great and should definitely be done but I still don't think it could be the main problem this person is experiencing. The factor their site is slowed down is just too huge.
CJPinder:
I provided my suggested fixes in this thread for continuity.
I only encountered this thread because its title had been changed to mention Ceon URI Mapping, I would never have seen your suggestions otherwise.
CJPinder:
I'm sorry if you take offence that I believe that your add-on is only suitable for small stores. However, while it continues to do full table scans and use slow queries I will stick with that opinion.
It uses one single query with a REGEXP for each page on a site that is loaded. It then uses an additional lookup or two for each link being built for a Zen Cart page using the zen_href_link function.
The REGEXP can be changed to a LIKE OR LIKE but I can't see any way anyone could write URI mapping software to use fewer queries without sacrificing functionality. How can URI Mapping software not carry out a table scan?! (Indexing aside, which as you se I totally agree the software should have).
As this is the first person to mention speed being an issue it is indeed disappointing to hear someone else advise others that the software is "unsuitable" for anything but "tiny" sites. How do you define a "tiny" store? I personally wouldn't call a store with 1000 products in it tiny and that is handled with ease by the module.
CJPinder:
I have nothing personal against you Conor.
Thanks, I'm glad to hear that.. your last post sounded like you thought I was lying when I said the software is used without issue on sites with thousands of mappings so it kind of gave the impression that you had a problem with me. I definitely am open to hearing how it can be made better and am glad we've got that cleared up! :)
Thanks also for the nice comments, I'm getting better thankfully, it's simply frustrating to have so little time day to day, there's never enough time even when days are 24 hours! :)
All the best..
Conor
ceon