We recently conducted a performance assessment for a client, and the main problem was something really simple, but also very detrimental to the site.
The site used the Service Links module, version 6.x-2.x.
The following are the performance figures for the site, in seconds, before any tuning.
3.67 http://example.com/product/215 2.64 http://example.com/product/572 68.32 http://example.com/list1 65.11 http://example.com/list2
Have a page load in 3.6 seconds is bad, but having another take 68 seconds is, well, obscene.
The main problem here was something we wrote about before: How relying on connections to third party servers can be detrimental to performance.
In this case, the Service Links module was used to display a block for each node that generates a link for each of Facebook, Twitter, LinkedIn, and Digg.
But the key was this configuration:
Use short links: Always How generate short links: Use TinyURL.com Service
This means that for each node, your web site has to make four accesses over the network to TinyURL.com to generate short URLs.
For each node, this took over 1 second to generate.
On pages that are lists of nodes of 50 or so, this takes a lot of time, hence the over 60 seconds generation time.
After changing the configuration for Service Links to use a short URL of node/xxx, these were the performance figures:
2.04 http://example.com/product/215 2.04 http://example.com/product/572 4.93 http://example.com/list1 6.51 http://example.com/list2
A 10 X improvement over the original.
Comments
Justin Ellison (not verified)
Been that way for awhile now...
Sat, 2011/11/05 - 21:10Good to see your posts again! I wrote about this very problem a year and a half ago: http://sysadminsjourney.com/content/2010/03/11/tracking-drupals-outbound-http-requests-using-tcpdump
I opened an issue for it, but can't seem to track it down now. Caching the results would help tremendously I would think.