Background:
There are tradeoffs involved with caching (and with different caching mechanisms). There is no one "perfect" setting for all environments and stores. Some of the many factors include: your HTTP/HTTPS server settings, PHP settings, MySQL server settings, network / bandwidth limitations, the size of your database, available processing power, available memory, and desired site performance.
With this in mind, the ability of "Ultimate (SEO) URLs" to use multiple different caching mechanisms both internal and external (as well as disabling all supported cache mechanisms) can be configured. You can choose which to enable based upon the hosting environment and needs of an individual store.
Externally, this module will attempt to utilize and configured Zen Cart caching mechanisms if enabled in Zen Cart. There are two main types in Zen Cart 1.5.1. The first stores answers to the SQL requests in a file or an additional table in the database (is used across requests). The second is query cache which stores requests in memory (only for the current request). I will not discuss these further in this thread, but wanted to mention these will be used if configured globally for Zen Cart 1.5.1.
Internally, this module uses two different caching mechanisms if enabled. The first layer stores the result of generating the URL into memory (only for the current request). The second layer (where it sounds like you are running into issues) stores a compressed copy of entire blocks of generated URL results (such as products, categories, OR ez-pages). This second cache stores the data in the database and is used across multiple requests. Both layers can be enabled or disabled by changing this module's settings.
I've listed a couple of different items you may wish to experiment with when trying to find the settings which work best for your specific hosting environment and store needs.
Change the compression level:
By default this module only uses compression level 1 (on a scale from 0 = none to 9 = max). If your server can handle higher levels of compression w/o a large impact, you can try using higher levels of compression. To change the compression level find the "save_cache" function and bump the level up.
Disable the internal products SQL cache:
You can disable this plugin's internal product SQL cache (as this stores every product name into a single entry in the database). Other cache mechanisms will remain active. This will avoid attempting to cache a large number of generated URL fragments using a single SQL command.
Disable the internal cache completely:
You can disable all internal caches, both memory and SQL based, by setting "Enable cache (globally)" to true. This will leave any external cache mechanisms active. A little extreme and probably not necessary unless the server is getting hammered and exceeding memory limits.
Experiment with an external Zen Cart cache:
You can enable or disable these in your Zen Cart configure.php files. More information can be found by searching the forums and faqs on
http://www.zen-cart.com/. This typically is used by Zen Cart to store longer running SQL commands. This module uses the cache if enabled to store requests (can reduce the number of executed SQL JOINS).
Change the settings for MySQL (server and client):
MySQL can typically handle a packet size up to 1G (one would need to modify both the MySQL client and server settings). This is only an option if you have access to change server settings and have enough memory available to the server(s). I would not necessarily bump all the way up to 1G, but you could try 32M, 64M, or even 128M. Performance impact(s) will vary depending upon if MySQL is talking locally or remotely.
Configure other caching:
For a very large site (or site running on a cluster), it may be beneficial to configure separate caches (via proxy, memcached, etc). This is not something simple to set up, but for VERY busy websites the benefit may outweigh the costs. Changes to enable such as setup are outside the scope of this thread.
Bookmarks