I am investigating site slowness on a client site and I see that variable_init() is taking a long time because the client has so many variables that need to be unserialized on every single page request. Ubercart offers tons of dials which can be tweaked which is very helpful. But there is a cost to all these variables. I recommend that ubercart use its own table for storing its variables. Further, I recommend preloading only the variables which are frequently used and leaving the rest as on demand. If anyone is feeling pesky, feel free to address this in core drupal at #79008: make variable prefetching optional
Comments
Comment #1
rszrama commentedThanks, Moshe. I always wondered about how many variables is too many. Are you suggesting a unique uc_variables table that functions similarly to the core variables table? Or just doing something like more individual tables for the different types of settings we have?
I'll see if I can point someone pesky to the core issue. : )
Comment #2
cha0s commentedThe proposed solution does nothing to mitigate the overhead of variables stored by system_settings_form().
That said, we could improve variable usage to help with the amount of unserialize() calls that must take place. I'll benchmark an approach I'm considering, and if there are significant gains, I'll post it here.
Comment #3
cha0s commentedAfter profiling a site with over 400 Ubercart variables (I submitted each configuration form to set the variables), I find that variable_init takes a fifth of a millisecond to load.
I'm interested if I can get your cachegrind file, or maybe some special considerations dealing with the site that aren't normal.
I'm wondering if your bottleneck is actually (Ubercart?) variables, or something else.
Comment #4
melon commentedJust for the heads-up: I believe many multilanguage Übercart stores use multilingual variables set up (for in-store messages, etc.) so while designing any related changes, keep in mind that the multilingual functionality should be kept if possible.
Comment #5
tr commentedUbercart is using the variable table mostly through system_settings_form(), which is the Drupal-blessed way of doing things. So IMO if this is causes performance problems (and according to #3 it's not clear it does ...) the way to fix it would be to change the way Drupal handles variables instead of trying to re-architect Ubercart to avoid the perfectly good and Drupal-recommended way of handling system settings. I'm marking this as won't fix - hopefully core issues like #79008: make variable prefetching optional will eventually work their way through and benefit every module that uses the Drupal system_settings_form() mechanism.