SEO-G employs 3 different cache mechanisms. In this section we will examine the functionality and logic behind each of these cache methods how they expire and how they are maintained. SEO-G Renegade edition provides superior performance regardless of the database products, categories or other entities by proper caching of friendly URL and converted entities. In an nutshell the First Level Cache represents short term caching of links and it is memory based, while the Second Level Cache is a long term database based cache mechanism.

1. First Level Short Term Cache
Based on the navigation links structure of an e-shop links of higher importance maybe repeated several times within the same page. For example a home page link may appear at the header behind the logo image and at the footer behind the the store's copyright. The original osCommerce function will be called multiple times for the same link. Without a cache mechanism, SEO-G will have to check the link parameters, switch to the appropriate code logic and generate the same friendly URL. Instead, the first level cache is deployed at the memory level  and checks if the URL was previously generated for a given set of parameters. If a match is found, SEO-G will return the memory recorded URL without further processing. The first level cache of SEO-G, is applicable only within the same page and has no dependencies on the database, other than an on/off switch that controls it for development purposes. First Level cache employs a short term caching valid for the particular page load and it is activated during page construct.

Figure-1 shows the basic concept and processing of the first level cache in the SEO-G module.

The SEO-G First Level Cache has no direct update mechanism, because it is only active for the same page. First Level Cache is preloaded by the Second Level Cache.

2. Second Level Persistent Cache
The second level Cache of SEO-G is initiated during the root.php script processing. During early initialization of the SEO-G the module preloads the friendly URLs from the database into memory. These pre-recorded URLs are page based meaning the collection of URLs from each page that were converted by SEO-G earlier are simply loaded into memory and are ready to be processed by the First Level Cache. When the script terminates the SEO-G module converts the first level cache into the 2nd level storing the links into the database. The recording is only triggered if the cache time/date has expired. The second level cache also has a global on/off switch. It's objective is the long term caching of page links.

Figure-2 Second Level SEO-G Cache uses persistent storage via the database.

The SEO-G database cache is complex enough and requires proper maintenance . By default the module employs an semi-asynchronous cache flush mechanism so once a pre-defined period expires the module deletes cached page entries marked as older. This semi-asynchronous update mechanism is triggered by visitors or search engines during page access if the time period expires. Cron jobs can replace this part of SEO-G subject to the e-shop requirements.

3. SEO-G Signature Indexing
Each SEO-G url is marked by 2 separate signatures to accelerate friendly links retrieval and original osCommerce URLs comparison tests. The friendly SEO signature is used against URIs for the various redirection mehods SEO-G employs. The osC signature is used for SEO-G during structure of the osCommerce URL when this falls through the tep_href_link() function. The module returns the result immediately if a signature match takes place, therefore it suspends further processing of the URL parameters reducing the database process overhead. The SEO-G also provides configuration switches and periodic timers to void the signatures and update the links in the SEO_URL table and SEO_CACHE table. A third signature is also employed for the SEO_CACHE table and used for the First and Second level cache.

4. SEO-G Cache Efficiency
It is also important for the user to understand the efficiency of the SEO-G cache. Generated links are cached on a per page basis. This approach eliminates the need of intensive MySQL queries and at the same time the module dynamically prepares the links for the requested page in an array. Therefore the number of products or categories and other database entities in general do not introduce latency or timeout errors.

An e-commerce store may include hundreds of thousands of products and there will be absolutely no latency due to the SEO encoding/decoding mechanism. Other SEO modules attempt to use defines or arrays to load all products into the server memory and therefore are subject to the number of products. A high number of products can cause long delays for page loading, intensive queries and can bring a server down given just few requests from clients. And unlike what you read elsewhere that the SEO-G handles just few products is a myth; the SEO-G cache component has been thoroughly tested with over 100,000 products without latency issues.

Signature indexing along with the page cache mechanism, allow the module to efficiently preload the URLs on each page request regardless of page personalization options. URLs that are different for personalization purposes are added separately to the loaded URL array. This process implies only a part of the visible HTML links can ever be loaded into a single variable which equates to approxomately a hundred links.