Minimiser les accès à la base de données est à mon avis le premier axe de travail à mettre en chantier immédiatement.

Chaque événement système, même le plus anodin comme par exemple une adresse ip visitant le site, crée un événement système, et alimente des statistiques, elles-mêmes re-stockées dans la même base de donnée.

Mais n'est-ce pas justement complètement inutile d'enregistrer les événements système dans la base de donnée ? Pourquoi ne pas les mettre dans un fichier, type syslog ? Allez, zou c'est fait.

Si j'avais à peu près 10000 visites par jour, et des centaines de connexions simultanées, j'aurais de sérieux problèmes, avec ma base de donnée mutualisée car chaque visiteur en plus d'ajouter des nouveaux événements systèmes, met en action un module "statistique" qui crée des multiples accès supplémentaires à la base de donnée pour y stocker des jolies stats ; donc certes "ça marche" mais aïe qu'est-ce que c'est relou... ; le plus stupide dans cette affaire c'est que les visiteurs les plus actifs sont ces pu... de robots, qu'ils soient des robots de moteurs de recherche ou des robots de spammeurs ; ces robots produisent des milliers d'accès à la base de donnée, lors de leur passage : ça correspond à un petit ourangan invisible et l'effet est très simple : le surf pédale dans le yahourt, grave.

Pour couronner le tout, drupal (le framework de travail de départ) est réputé pour créer beaucoup d'accès base de donnée (même trop pour certains) et, pas mal de professionnel du développement web admettent que s'il est très intéressant et très flexible, son module statistique "interne" a un impact catastrophiquement lourd dur la performance globale ; donc, si nécessaire, je vais plutôt m'appuyer sur un module d'analyse de trafic externe du type "google analytics", ce qui "déleste" ma base de donnée du boulot nécessaire de devoir stocker les stats - stats qui, franchement, ne sont pas fondamentales, dans la mesure où la quantité d'utilisateur et de visiteurs par jour est trop restreinte pour en avoir réellement besoin.

Enfin, la cession ; par défaut, une fois l'utilisateur loggué, il conserve sa session et son cookie de connexion ok, dont la durée de vie est quasi illimitée. Or, ça me pose un problème, surtout quand on est en mode "bande passante de merde en heure de pointe" ; un utilisateur qui s'est déconnecté, est mieux loti que celui qui a gardé sa session active ; en effet un visiteur utilise le cache qui est performant et très rapide, tandis que l'utilisateur loggué ne l'utilise pas ; j'aimerais donc au moins qu'un utilisateur enregistré qui a fermé son navigateur/onglet de surf, et qui retourne sur le site en heure de pointe, puisse juste "lire" le contenu du site et pas tomber sur une page blanche qui tourne à vide. Donc supprimer le cookie quand l'utilisateur enregistré ferme l'onglet ou le navigateur, c'est un bon moyen de s'assurer qu'il bénéficie par défaut du système de cache - relativement performant -  dans un premier temps. Donc si vous constatez que vos cessions expirent systématiquement : c'est normal, mettez ça sur le compte des optimisations nécessaires.