As great as Drupal 7 core can be, it doesn't scale well for Web sites with a lot of content and/or a lot of users. To make it perform better under these scenarios, it's necessary to make use of several strategies, tools and techniques.
Through my work as a Technical Architect, I recently did some DevOps consulting for client whose development process included steps to bundle all possible configuration changes though Features into a single feature. This bundling of all configurable data into a single Mega Feature was something they inherited from former consultants, who didn't bother to explain the ramifications of such an approach. It's a bad idea for several reasons.
If your site is left for a while, say throughout the night, and you find that hitting it for the first time in the morning (i.e. a cold start, an initial run) takes longer to load than after clearing your caches, then it's fair to assume that it's not merely a problem of caches expiring and refilling.
In Drupal 7, there's no forward-looking native method for managing hierarchical data. We do have the Book module, but it's old and hard-codes things that can be done in a more general way. For example, it's using its own database table instead of using the Field API.
We can do a better job of creating book sections and subsections, say, with some contributed modules and a little bit of recursion.
Versionable content in Drupal has always suffered from inefficient storage. Each new revision of a content item (historically a "node", but now anything that's fieldable, an "entity") is stored in its entirety in the database. For sites with lot of content, and continuous updates (new revisions) of that content, the database size can grow extremely large over time. This becomes a serious problem for maintenance and disk usage.
The Schema module, which I am now maintaining, lets you compare your actual database tables against the schema that your database is supposed to match. It's a useful tool that tells you when you've got extra tables (say from a previous version of Drupal), missing tables (that were mistakenly or maliciously dropped) or mismatched tables, ones whose implementations do not match their definitions.
I've recently added a feature which provides these lists through Drush for use on the command line or in scripts.
Drupal requires an SMTP client to send mail. You could install a full-featured mail transfer agent (MTA) like Postfix on your (virtual) machine to serve this function, but it's overkill if you only need to send mail through PHP. Instead, install msmtp. It's lightweight and much simpler to configure.
If you have a Date field that you had initially set up without a time zone, but realize later that you'd like to include it, it is possible to switch from "No time zone conversion" to "Date's time zone" even though the user interface doesn't recommend it.
