Can Zen-Cart run with transaction-isolation=READ-COMMITTED?

Hello,

We're using MySQL 5.1.51, Zen 1.3.8a patched with InnoDB referential integrity support.

MySQL's default transaction isolation is READ-REPEATABLE and I am wondering if ZenCart would still work properly with READ-COMMITTED

Transaction isolation levels are listed here:
http://dev.mysql.com/doc/refman/5.1/en/set-transaction.html

If we can run READ-COMMITTED, our DB will run a bit faster with respect to locking queries.

Your thoughts?

-Eric

We're using MySQL 5.1.51, Zen 1.3.8a patched with InnoDB referential integrity support.

If we can run READ-COMMITTED, our DB will run a bit faster with respect to locking queries.
IMO this is a lot of stuff added where if you used defaults on a well tuned server this is not necessary

What are your parse times?

kobra:

IMO this is a lot of stuff added where if you used defaults on a well tuned server this is not necessary
Perhaps. I'm squeezing every ounce out of the backend.

What are your parse times?

quick, see the bottom:

https://www.techsupplyshop.com/index.php?main_page=product_info&cPath=2109_2113&products_id=67334

Parse Time: 0.136 - Number of Queries: 114 - Query Time: 0.044952376571655
Parse Time: 0.133 - Number of Queries: 145 - Query Time: 0.041715174179077
Parse Time: 0.290 - Number of Queries: 395 - Query Time: 0.18484237115479
Parse Time: 0.244 - Number of Queries: 395 - Query Time: 0.13091217424011
These are respectable if normal
My experience is that some of the "so called" query improvement mods actually add additional steps that must be run and are only a benefit on a slow/poorly configured server

You'll note that your parse times are significantly higher than any of the corresponding query times. Thus, your bottleneck is not the database at all. The query times are fast. It's your CPU processing the returned data that's your bottleneck ... if you call it a bottleneck.