I test all modules (custom + contrib) in one drupal base itself which has resulted in lot of variables.
I was just curious what happens if live site had 3k variables ?
Since all variables will be eventually global variables will it not require huge amount of PHP memory ? or is it not limited at all ?
What is the alternate here ? cache_get with new cache table instead of variable_get every where
Add a comment
|
3 Answers
Yes, large variable tables are a problem.
Variables should only be used for small configuration flags and settings and not to store large structures for example.
But given a large amount of modules, dynamic variables like per-content type things you will sooner or later get into trouble.
No, there is no solution to this problem. The variables system will be replaced with the new configuration system from the CMI initiative for Drupal 8 which will hopefully be better at dealing with this.
My suggestion is,
We should not use cache_get or cache_set.Because this will reduce the php memory, but highly increase the slow down the site by querying the DB.
Your mentioned case is very rare.so use variable_get.
-
Considering memory advantages , going for cache_get makes sense , and I checked with timers it indicates 0.50 ms avg for cache_get and variable_get is also the same ! So in this case cache_get turns out good isnt it ? Commented Feb 24, 2012 at 14:17
-
-
yeah localhost that s where I have a huge collection of variables Commented Feb 24, 2012 at 14:21
-
in localhost it may be same time.Why i am saying is, the variable_get is a simple function but cache_get is oops functionality written in php(drupal 7).Another one reason is each cache_get using a mysql query which will take time in live site. Commented Feb 24, 2012 at 14:26
The solution is to use something other than your DB to hand off info like this to your application. If you're on a shared or VPS host this will likely be memcached if you have the option I recommend using Redis.
Your cache, cache_bootstrap, and as of about D.22 your field info will be served from in-memory caching nicely.
