The page I am working on has a javascript function executed to print parts of the page. For some reason, printing in Safari, causes the window to somehow update. I say somehow, because it does not really refresh as in reload the page, but rather it starts the "rendering" of the page from start, i.e. scroll to top, flash animations start from 0, and so forth. The effect is reproduced by this fiddle: http://jsfiddle.net/fYmnB/ Clicking the print button and finishing or cancelling a print in Safari causes the screen to "go white" for a sec, which in my real website manifests itself as something "like" a reload. While running print button with, let's say, Firefox, just opens and closes the print dialogue without affecting the fiddle page in any way. Is there something with my way of calling the browsers print method that causes this, or how can it be explained - and preferably, avoided? P.S.: On my real site the same occurs with Chrome. In the ex
Going to the admin/settings/performance page, turning on CSS and JS aggregation, and page caching with a minimum lifetime of 1 minute, will give you an immediate boost on a high traffic site. If you're writing your own code and doing any queries, consider writing your own discrete caching for expensive functions. The linked article covers Drupal 5, not 6, but the only change in d6 is the elimiation of the serialization requirement and the function signature for the cache_set() and cache_get() functions. (Both noted in comments on the article)
ReplyDeleteOn large scale sites also consider dropping a memcached server onto the network: Using the memcached module, you can entirely bypass the drupal database for cached data. If you have huge amounts of content and search is a hot spot, you can also consider using lucene/solr as your search indexer instead of drupal's built-in search indexer. It's nice for a built-in indexer but it's not designed for heavy loads (hundreds or thousands of new pieces of content an hour, say, with heavy faceted searching). The apache solr module can tie in with that.
If you're making heavy use of Views, be sure that you've checked the queries it generates for unindexed fields; sorting and filtering by CCK fields in particular can be slow, because CCK doesn't automatically add indexes beyond the primary keys. In D6, preview the View in the admin screen, copy the text of the query, and run it through EXPLAIN in mysql or whatever query analysis tools you have.
Tools like YSlow and Firebug can also help you spot slow stuff like massive image files, JS hosted on remote servers, and so on.
Drupal 6, out-of-the-box, provides css and javascript aggregation --- most css and js files will be combined into a single file (and thus a single HTTP request), and are also whitespace-shortened (to reduce bandwidth consumption). You can enable this under /admin/settings/performance .
ReplyDeleteAlso on that screen are controls for Drupal's (very effective) cache, which helps reduce the number of database queries.
Additionally, because Drupal (and all the modules you'll probably have installed) has a ton of PHP source, using a PHP opcode cache such as APC helps significantly decrease the request time.
The boost module also provides a huge performance gain. I'd recommend using that aswell
ReplyDeleteI strongly second Benedict's recommendation of the Boost module - it alone will make your website fly on shared hosting, if configured correctly, and is not really buggy at all.
ReplyDeleteTurn on CSS/JS aggregation, turn on Boost, and your site can perform very well for anonymous users.
If your site deals with mostly logged-in users, you're going to have to do a lot more work making sure sessions are cached well, and probably consider using memcached and more SQL query caching.
The biggest performance gains always come from caching—but monitoring and adjusting your slow queries, monitoring and adjusting apache and PHP configurations, and being smart about the modules you use are very important as well.