Is it better Msql or Msqli? Why?
http://www.restaurantsupplies.eu Restaurant Supplies
Opencart 1.5.6.4 VQMOD 2.4.1
Languages: Italian, French, German, Hungarian, English, Russian, Polish and Spanish
Msqli is newer and has more features -> http://php.net/manual/en/mysqli.overview.php
that said, PDO would be a better option
that said, PDO would be a better option
+ 1 on that.that said, PDO would be a better option
Dedication and passion goes to those who are able to push and merge a project.
Regards,
Straightlight
Programmer / Opencart Tester
Faster is usually 'better', independent from what one uses. At least, if it works.
This could be good reason to check into the matter more from the point of existing
'enhancements', possibly not available for different DB-Types. I explain:
I am not sure yet, but after I found the Link below and heated up very heavy, so, i immediately
converted my MySQL DB Storage Engine from MyISAM to InnoDB, it sure just looks like I moved
from an old VW 34 hp Beatle up to a 340 hp Audi Quattro, after creating first tests on a larger Product scale.
(...without any saving before, I was just TO hot to see results. But don't do such ever,
if you have any REAL Data on your DB...! If one deletes the 'first shot' of Products, for any reason,
all products, existing before using the 'one' found OC 'Mass-Product-Generator', are gone..)
Not here, after the DB-Upgrade/Mod, everything worked as before:
http://forum.opencart.com/viewtopic.php ... 84#p602699
http://www.ipc.li/os/opencart-turbo-master.zip
Since I added some other indexing/caching-routines before as well, I am not sure, wheter
the DB-Change on itself, or then the 'combined' action with other cache/indexing-Mod's,
is finally responsible for the dramatic speed increase, even allowing to 'leave' Product Counting alive!
I autouploaded 5'000 Products in english language as well as 5'000 Products in German (the tool cannot do both in one step), creating exactly 10'000 DB Product Lines (eventually many more in other DB sections as well, I did not check). In category View, it now builds a (from lowest priced up) not default SORTED ~750 Product-Display Cat-Page internally usually below 3 seconds. By nature of the web-transport-Delay, using (Swiss) DSL, it takes 2-5 times longer to get the full 13'832 line page displayed on the Browser Screen. So, it comes closed to what one could expect from an 'grown up' software.
http://www.ipc.li/shop/index.php?route= ... &limit=999
just to mentioned it here. It, therefore, can be done! And I am sure, it's even possible to tune the Engine near 400 hp, if indexing will be used, wherever possible, as well as caching, but here, limit's exist, i.E. within a Header-Section, in a multi-language Shop. There, it may prevent Language-Changes in the MAIN Category-Links Header Line as well as correct Product Re-Counting/Linking, eventually even displays links to sections (and their Products), existing (possibly, and therefore displayed) in one language only (like after using the generator). Exept one would write a piece of code, clearing ALL Cache-Files BY DEFAULT, if any (clicked on) language change occurres. Something like this..., one always has to consider the worst possible case...
PS. I left the Product-Counting ON, on purpose, I want it to stay in my HEADER MENU-Cat-Links, Visitors MUST have a chance to see, if and where something exists. Still, don't look at the Numbers, displayed in the Menu-Section, the Auto-uploader used does not get along well with a multi-language Shop. Therefore, it displays (probably) just the amount of Products, collected from the english Products, but it possibly displays (some) Products as well, not belonging to the english language Selection. Since, in the RUSH, I used the same language sheet for both entries, so, I cannot say, wich belongs to wich..., I just see them in the DB, numbered either with a '0' or then a '1', defining, in wich language to be 'active'...
I just know that it does the same with Product Pages as well, I experienced some unreachable Link-entries, they showed up as not valid, when called in this language, or then, it broke some Product Pages in Peaces, because of trying to include (clicked on) options (my fault!), not existing, or miss-interpreting 'my' Source, therefore leaving 'open' sections and broken following content on the Page-Display...
The tool has problems, since it's made for a DEFAULT OC, in my shop, certain 'listings', like featured, latest, etc., display not longer in bother languages, any added stuff, like VqMods or hardcoded things, can make the tool to screw up a little - here and there. But this is no Problem, it's a testing Devise, just preset for most needed content, and with some DEFAULT Option settings built in, nothing else, after uploading and deleting a few thousand items, one will get used to it! It was a great Help in order to create such an amount of Sample Products to test the shop in real. Thank you , iSense, for this very great Tool !
Sorry, but it needs to be explained in detail, OC goes around the world, and not everybody is english PRO...
...neither am I!
Good Luck!
Ernie
This could be good reason to check into the matter more from the point of existing
'enhancements', possibly not available for different DB-Types. I explain:
I am not sure yet, but after I found the Link below and heated up very heavy, so, i immediately
converted my MySQL DB Storage Engine from MyISAM to InnoDB, it sure just looks like I moved
from an old VW 34 hp Beatle up to a 340 hp Audi Quattro, after creating first tests on a larger Product scale.
(...without any saving before, I was just TO hot to see results. But don't do such ever,
if you have any REAL Data on your DB...! If one deletes the 'first shot' of Products, for any reason,
all products, existing before using the 'one' found OC 'Mass-Product-Generator', are gone..)
Not here, after the DB-Upgrade/Mod, everything worked as before:
http://forum.opencart.com/viewtopic.php ... 84#p602699
http://www.ipc.li/os/opencart-turbo-master.zip
Since I added some other indexing/caching-routines before as well, I am not sure, wheter
the DB-Change on itself, or then the 'combined' action with other cache/indexing-Mod's,
is finally responsible for the dramatic speed increase, even allowing to 'leave' Product Counting alive!
I autouploaded 5'000 Products in english language as well as 5'000 Products in German (the tool cannot do both in one step), creating exactly 10'000 DB Product Lines (eventually many more in other DB sections as well, I did not check). In category View, it now builds a (from lowest priced up) not default SORTED ~750 Product-Display Cat-Page internally usually below 3 seconds. By nature of the web-transport-Delay, using (Swiss) DSL, it takes 2-5 times longer to get the full 13'832 line page displayed on the Browser Screen. So, it comes closed to what one could expect from an 'grown up' software.
http://www.ipc.li/shop/index.php?route= ... &limit=999
just to mentioned it here. It, therefore, can be done! And I am sure, it's even possible to tune the Engine near 400 hp, if indexing will be used, wherever possible, as well as caching, but here, limit's exist, i.E. within a Header-Section, in a multi-language Shop. There, it may prevent Language-Changes in the MAIN Category-Links Header Line as well as correct Product Re-Counting/Linking, eventually even displays links to sections (and their Products), existing (possibly, and therefore displayed) in one language only (like after using the generator). Exept one would write a piece of code, clearing ALL Cache-Files BY DEFAULT, if any (clicked on) language change occurres. Something like this..., one always has to consider the worst possible case...
PS. I left the Product-Counting ON, on purpose, I want it to stay in my HEADER MENU-Cat-Links, Visitors MUST have a chance to see, if and where something exists. Still, don't look at the Numbers, displayed in the Menu-Section, the Auto-uploader used does not get along well with a multi-language Shop. Therefore, it displays (probably) just the amount of Products, collected from the english Products, but it possibly displays (some) Products as well, not belonging to the english language Selection. Since, in the RUSH, I used the same language sheet for both entries, so, I cannot say, wich belongs to wich..., I just see them in the DB, numbered either with a '0' or then a '1', defining, in wich language to be 'active'...
I just know that it does the same with Product Pages as well, I experienced some unreachable Link-entries, they showed up as not valid, when called in this language, or then, it broke some Product Pages in Peaces, because of trying to include (clicked on) options (my fault!), not existing, or miss-interpreting 'my' Source, therefore leaving 'open' sections and broken following content on the Page-Display...
The tool has problems, since it's made for a DEFAULT OC, in my shop, certain 'listings', like featured, latest, etc., display not longer in bother languages, any added stuff, like VqMods or hardcoded things, can make the tool to screw up a little - here and there. But this is no Problem, it's a testing Devise, just preset for most needed content, and with some DEFAULT Option settings built in, nothing else, after uploading and deleting a few thousand items, one will get used to it! It was a great Help in order to create such an amount of Sample Products to test the shop in real. Thank you , iSense, for this very great Tool !
Sorry, but it needs to be explained in detail, OC goes around the world, and not everybody is english PRO...
...neither am I!
Good Luck!
Ernie
My Github OC Site: https://github.com/IP-CAM
5'600 + FREE OC Extensions, on the World's largest private Github OC Repository Archive Site.
Who is online
Users browsing this forum: No registered users and 26 guests