Hi,
Have a site with:
-CacheRouter with db caching
-APC on the server, but not used with CacheRouter
-Boost with default-agressive settings, crowler enabled
-JS minify + gzip
-CSS gzip
-block cache module enabled
-"Normal" drupal cache
-Paged are gzipped by drupal
-GA code is in footer
-Google Analytics module was used with "cache locally" and without - but no change.
-All the internal Google Analytics indicators is showing that everything is ok, some stats is available.
-JS minify+gzip is enabled, but I clearly see the .js file, which is accesible.
Today I had a doubt on one of my drupal6 sites (other simple brochure site) and tested it with http://sitescanga.com tool - everything was fine.
After that - I tested the site I desribed above with the same tool and got "Tracking Code Installation - Problem" "0% pages tagged properly". When deleted the cache and did some minor adjustments in GA module, got "29%, x out of y pages are tagged properly".
On the report there are some pages, where GA is disabled - a few percent of false errors, but the other are proper node links. Found no system in those results.
I will do some of the troubleshooting disabling performance modules one by one, but before that:
-Have any of you had similar problems?
-Do you know any simple (free) tool to check if GA is ok on particular site/page? Browser plugin? Other external tool like http://sitescanga.com ?
-Which performance modules to disable first?
Offtopic:
-is Cacherouter with db caching useful, if I use Boost?
Comments
Perhaps maybe JS minify is
Perhaps maybe JS minify is breaking the JS, or there is some JS that doesn't like to be minified and ends up breaking everything? I'd start there.
Note that since GA is so simple you can simply hard-code it into page.tpl.php which will be real easy. But if something is breaking GA, it may be breaking other things as well and you probably want to find the cause.
Note that Boost + Drupal cache is not recommended. They do the same thing (cache full pages for anonymous users) one stores in the DB, one uses files. Boost will be faster.
And yes Cacherouter is still useful if you use Boost. Cacherouter gives you the ability to use different storage options for the Drupal cache tables (APC, Memcache, etc.). If you setup cacherouter correctly these options are faster than using the database. This will help mostly authenticated users, but also for anon users when they view a page that has not been cached yet by Boost.
--
Dave Hansen-Lange
Director of Technical Strategy, Advomatic.com
Pronouns: he/him/his
ok, that GA issue is pretty
ok, that GA issue is pretty much gone, but I am curious about your answer:
quote: Note that Boost + Drupal cache is not recommended. They do the same thing (cache full pages for anonymous users) one stores in the DB, one uses files. Boost will be faster.
In my case, I have Cacherouter 'engine' => 'db', as I cannot make it stable on APC on that server...
So, I have Normal caching + Boost. Site for anonymous is just flying, but not for registered. If I disable core Drupal caching will it be faster for registered?
drupal+me: jeweler portfolio
Logged In Users
Very doubtful it will get faster for registered users. See what you can do to speed up your queries for MySQL, or try something like authcache.
everything is more or less
everything is more or less fine with mysql, the only question is to enable Drupal core caching on "Normal" or disable it in my conditions
(Boost + Cacherouter=>db)
drupal+me: jeweler portfolio
If I disable core Drupal
As mikeytown mentioned, no it won't be faster. But with both enabled you are doing more work than you need to be. A page will almost never be pulled from the Drupal page cache because Boost intercepts things before PHP is loaded. But with both the page cache and Boost in place, because they have different cache clearing strategies, you may in fact be serving up stale content at times. Take this scenario:
Basically you have two technologies solving the same problem, but with slightly different approaches, so there may be competition at times. This situation could be rare or common, I don't know. Even if it never happens then you are still doing more work than necessary:
The page is never retrieved from the Drupal cache so why are we doing the work to save it there?
Basically with both caches in place you are either doing more work than is necessary or are creating a situation where sometimes stale content is served.
--
Dave Hansen-Lange
Director of Technical Strategy, Advomatic.com
Pronouns: he/him/his
optimizing my.cnf the mysql
optimizing my.cnf the mysql config file will give you a nice performance boost when you set up the query cache properly. I would also take a look to memcache d.
Are you on a shared hosting or dedicated machine?
Drupal Rocks !!!
on low-end vps, mysql is
on low-end vps, mysql is tuned properly. I do not think I have enough ram for memcached...
drupal+me: jeweler portfolio
If you're using Boost and
If you're using Boost and have disabled drupal core caching then, the remaining cache tables might be less than one or two MB per site for cache_menu, cache_filter, cache_variables, etc.
Memcached itself has fairly low overhead. Though memcached may not be any faster than a local mysql query from the query cache, it might mitigate contention.
I have a 6MB memcached process for that stuff, but it's difficult to say whether it improves performance.
perhaps i'll give a try to
perhaps i'll give a try to memcached as site for registered is really slower than boosted for anonymous
drupal+me: jeweler portfolio