Advanced search  


cpg1.5.48 Security release - upgrade mandatory!
The Coppermine development team is releasing a security update for Coppermine in order to counter a recently discovered vulnerability. It is important that all users who run version cpg1.5.46 or older update to this latest version as soon as possible.

Pages: [1]   Go Down

Author Topic: High Performance/ High Traffic feature: Config Freeze / Config Cache  (Read 4360 times)

0 Members and 1 Guest are viewing this topic.


  • Coppermine newbie
  • Offline Offline
  • Posts: 10


I don't know how you guys do it, but I think it is quite common that you fiddle around with
a new app until you have it working and once it is in production, then the amount of changes
is limited - at least for some time.

The fact that Coppermine runs in many different environments and on many different platforms
(which is great) comes with a price ... there are numerous condition checks to find out the
platform, php API, and many other things too, and of course there are the extra DB queries to
get the config information from the database.  So for each and every request these checks and queries
are performed and on a running production system will always come out with the same results.

So I thought it would save lots of resources if there is  some kind of config cache file. In a more
simplistic approach, the  owner would manually create a file (like includes/config_cache.php ) where all
the needed values are  listed as DEFINES or global variables. This file could be used  if present
( if file is there --> use values from file, if file is not there --> business as usual )

For those who do not use/create this cache,there is only one additional  file check which doesn't really
count compared to whats already being done. Whereas those who choose to use it will save a lot
of  queries, includes and checks upon each request.

A more sophisticated version of this idea would be some kind of "Freeze" or "Dump" button in the
admin interface, where the admin can create a cache file of all config values in the gui.

I guess this could make up for a good balance between versatility/flexibility and performance ... what
do you think?

BTW while searching this forum for high traffic/high performance optimization ideas, I didn't
find a lot of hints. However, there was a Post from Tranz'n'Dance (?) who said the dev team
thinks about whether to release some kind of "High Performance" version. Obviously, this
did not happen. Was it a matter of missing resources or a fundamental decision?



  • Guest
Re: High Performance/ High Traffic feature: Config Freeze / Config Cache
« Reply #1 on: August 30, 2005, 06:26:51 pm »



  • Coppermine newbie
  • Offline Offline
  • Posts: 10
Re: High Performance/ High Traffic feature: Config Freeze / Config Cache
« Reply #2 on: August 31, 2005, 01:05:51 am »

There is already discussion about this.

Yes I know, and guess who made the most recent post (at this time) over there ...... ;-)

However, that discussion has a very different topic - it's about optimizing the
amount and structure of the display-related functions.  What _I_ am talking about here
is to reduce the amount of resources that are wasted, ahem, spent upon each
request just to load config data and examine the environment.

Both kinds of optimization are necessary for better perfomance, but they are
quite different. The config freeze feature is much "smaller" and less intrusive
compared to a global change of DB and query structure.  You know there
is somebody round here who insists on the "one issue per thread" rule ;-))
So i think this is a clear case for a new thread of its own.


Joachim Müller

  • Dev Team member
  • Coppermine addict
  • ****
  • Offline Offline
  • Gender: Male
  • Posts: 47843
  • aka "GauGau"
Re: High Performance/ High Traffic feature: Config Freeze / Config Cache
« Reply #3 on: August 31, 2005, 09:00:06 am »

The discussion about cached queries was lead in the closed developer board as far as I remember, s you can't access it. There's a lot of stuff going on for cpgNG in terms of optimization. Distant future though...
Pages: [1]   Go Up

Page created in 0.019 seconds with 19 queries.