vQMod Large Mod Cache

Hi All,

I've just moved my OpenCart installation over to AWS as a web host and overall really happy with how things are going. I have however had a bit of mare on the performance front. Some of it was self-inflicted as I've used a combination of Override Engine and vQMod to write my extensions which was causing unnecessary overhead. This has resulted in me rewriting a number of extensions into vQMod xml which does seem to be doing the trick on the speeding things up*.

The problem I have is that the memory usage has increased quite significantly. According to XHProf vQMod now uses anything between 7 and 18 Mb of RAM for each script. The mod.cache file is around 4 Mb in size currently (covering 110 active mod files) but I've not finished porting extensions across so it will grown further.

Not sure if there is anybody has managed to reduce the memory usage, but any ideas are welcome.

pete

* One other thing I did was to rewrite the vqmod.php to use DirectoryIterator if available which shaved even more time off.

The most simple way, to reduce 'overhead', is, to get rid of overhead, whereever possible.
But you seemengly tried it the opposite way, similar to those, now trying to get it done,
by Use of VqMod + OcMod, combined, on about 99.8 Percent of all V2-Installations.

Back to the Theme, whenever you think, to have your Shop, as you like it, you should start,
to implement ALL VqMod - Content, regularely used, into the Place, where it belongs. Into Source!
It's the only way to go, in a professionel Environment, at least, everything else ist Newbie-PATCHWORK.

One can CACHE, as much one Likes to, but in order to CACHE, and still keeping LATEST Value's, the
Source has to be 'compared' with the chached Content, so, what's the point, in running back and forth,
just to find out, if it can be done without going anyplace, to look for something, if I can do it in front of me !?

Many Roads lead to Rome, and if one has enough Server Power at hand, anything is possible. I always compare
it with Microsofts Windows, the first v.3.01 Version used 4 Floppie's, including Word, I believe to recall, to be installed. And my XP does really not so much more, or better, or faster, and it would not even function on a PC, built about 20 Years ago! Like an OC Shop, I assume..., on a server, then !

I hope, you see, what I mean. But OC is already full of 'too much', as it comes, by default. Things, and Options,
possibly never ever used, by very many Users worldwide. Therefore, if one has some Coding-Knowledge, one should concentrate on REMOVING, from Source, what ADD's as System Brake, if never planned to be used, and just uses Loading Time, because it exists, by default, in Places, where it acts, at best, as Brake!

I am doing such test on this site, at present, starting with the Header, like every Browser, and get everything out,
just wasting time, like Cart's, or Search Routines, whatever, slowing down the System, in the FIRST Place, by beeing realoaded with every single Pageload, whereever, again.
http://www.hitline.info/shop/

By nature of things, I still use many VqMod's, in a test environment, it's the only way to work efficiently.
So, don't understand me wrong, it's not a critic on VqMod's. It's not even meant to be critical as whole, you just wanted to know, what could be done..., technically

Good Luck
Ernie

Thanks for the reply. Completely get where you're coming from and in truth I could make significant improvements if I directly hacked the source code of OpenCart - we're never going to use the affiliates capability and it's unlikely the multi-store functionality either so could happily hack those bits out. This would simplify lots of areas and remove at least one SQL check from well over 50% of the queries run. In fairness it's really tempting to create a "LITE" branch of OpenCart that uses namepsacing and autoloading to more optimally handle what resources are loaded at any time - I even have a MVC framework that's loosely based on the OpenCart MVC, but hugely optimised.

However you're suddenly faced with a non-standard version of OpenCart. Should we employ another web dev or something happens to me, that developer is faced with having to unpick my hacks from the base code - regardless of how well I've documented them - "is this core code or customisation?". Equally if a new version comes out then implementing this is a complete and utter mare of a job - so you're faced with either re-factoring your hacks or stay running on an older version of the base code. There's also a "reassurance" factor when the core of your code is running on a proven system which is something the directors here are very keen on, we take thousands of orders online every month so I can understand their apprehension.

Sadly this means that vQMod is really the only option going.

Now one thing that's just flitted across my mind would be to create a vQMod pre-compiler. Basically before you push changes to the production server, you'd execute a "compile" from the back-end which would enumerate all of your mods and write to the vcache folder (if necessary). The production server would then just pull from the vcache folder and skip the checking and merging routines. It's not a great solution as it adds an extra step when you undertake any changes (in truth you should be checking any changes before making them live, but that doesn't always happen).

pete

ps - You really should upgrade from XP

> you really should upgrade from XP <
Sure not, as long as the auto-update works, it would be like changing a Car, not yet equipped with ABS, or whatever, just because ABS is a 'modern' way to keep the brakes from doing their job, my way ...
Ernie