Que signifient les requêtes lentes SELECT GET_LOCK() sur ci_sessions ?

La table ci_sessions est destiné à stocker les sessions des visiteurs d’un site CodeIgniter. Celle-ci est notamment utilisée quand la session driver est configuré sur database.

Elle permet à CodeIgniter de stocker les informations de sessions de chaque visiteur dans la base de données. Selon les cas, cela peut présenter un avantage ou un désavantage.

Pourquoi la requête SELECT GET_LOCK() est lente ?

En vérité, la requête en elle-même n’est pas lente. Elle est juste suspendue pendant la période de verrouillage. En effet, cette requête fait justement ce qu’il est censé faire : verrouiller la session durant le chargement d’une page.

La constatation de lenteur survient lorsque la requête a été initiée alors qu’un autre chargement de page est en cours : il attend alors que l’autre page ait fini de charger pour obtenir à son tour le verrou sur la table de session.

Vous constaterez alors une entrée de ce type dans votre fichier log slow queries dans MySQL :

# User@Host: codeigniter[codeigniter] @ localhost [127.0.0.1]
# Thread_id: 12345  Schema: codeigniter  QC_hit: No
# Query_time: 22.040801  Lock_time: 0.000000  Rows_sent: 1  Rows_examined: 0
# Rows_affected: 0  Bytes_sent: 70
SET timestamp=xxxxxxxxxx;
SELECT GET_LOCK('653407ce5dddb2b0745d76a5f6dc73c0', 300) AS ci_session_lock;

Comment éviter que la requête SELECT GET_LOCK() empêche le chargement simultané des pages ?

Si vous souhaitez permettre à un utilisateur de charger simultanément plusieurs pages, vous devriez songer à utiliser un autre système de stockage de session qui vous permet un accès simultané à celui-ci.

Le plus simple est de basculer sur un stockage de session par fichiers. Pour cela, ajustez les paramètres suivants dans votre fichier de configuration CodeIgniter :

$config['sess_driver'] = 'files'; // was previously 'database'
$config['sess_save_path'] = sys_get_temp_dir();

Vous pouvez également envisager d’utiliser d’autres systèmes de stockage de sessions telles que Memcached ou Redis, notamment si votre application requiert un système de session centralisée.

Pourquoi les plugins WordPress désactivent le cache navigateur des pages HTML ?

WP Fastest Cache n’est pas le seul à le faire. Selon les plugins, la manipulation des headers Expires, Cache-Control et autres leur permettent de forcer le navigateur à faire une requête HTTP au serveur, et ainsi éviter que le navigateur ait des données obsolètes.

Cependant, puisque Varnish utilise aussi ces en-têtes HTTP pour prendre des décisions de mise en cache, cela désactive systématiquement le cache Varnish en marquant ces requêtes comme « uncacheable ».

En plus, les plugins comme WP Fastest Cache intègrent un mécanisme de purge de Varnish, ce qui permet donc de supprimer immédiatement les données de cache obsolètes sur Varnish, sans attendre que le cache expire.

Comment forcer la mise en cache ?

Il faut décomposer le problème en deux. D’abord, il faut marquer les réponses HTTP concernées pour éviter qu’on puisse forcer la mise en cache partout. Cela se fera au niveau d’Apache. Ensuite, il faudra détecter ce marquage au niveau de Varnish pour forcer la mise en cache.

Marquer les réponses HTTP servis depuis le cache WP Fastest Cache

WP Fastest Cache utilise mod_rewrite pour réécrire les URL vers les fichiers HTML préenregistrés dans le cache. Cela tombe bien, Apache sait ajouter des en-têtes HTTP selon la correspondance de dossier.

Dans votre VirtualHost (typiquement dans /etc/apache2/sites-available/domaine.com), ajoutez la directive suivante pour ajouter un header aux réponses servies depuis le dossier de cache de WP Fastest Cache :

<Directory ~ "wp\-content\/cache\/all(\/.*)*\/index\.html$">
    Header set Edge-Cache-Platform "wpfastestcache"
</Directory>

Redémarrez Apache ensuite :

systemctl restart apache2

À partir de ce moment, si vous faites une requête HTTP sur votre site et que la réponse est en cache par WP Fastest Cache, vous pourriez voir l’en-tête « Edge-Cache-Platform » (que vous pouvez d’ailleurs ajuster avec un autre nom, si vous souhaitez) :

$ curl -I http://www.exemple.com
HTTP/2 200
date: Sat, 01 Jun 2024 08:21:04 GMT
content-type: text/html; charset=UTF-8
server: nginx
vary: User-Agent,Accept-Encoding
last-modified: Fri, 31 May 2024 09:16:26 GMT
edge-cache-platform: wpfastestcache
cache-control: max-age=0, no-cache, no-store, must-revalidate
pragma: no-cache
expires: Mon, 29 Oct 1923 20:30:00 GMT
age: 0
accept-ranges: bytes
edge-cache-status: MISS

Détecter le marquage et appliquer les caches

Maintenant, dans votre VCL, ajoutez ceci dans la subroutine vcl_backend_response :

sub vcl_backend_response {
    if (beresp.ttl < 86400s && beresp.http.Content-Type ~ "text/html" && beresp.http.Edge-Cache-Platform ~ "wpfastestcache") {
        set beresp.ttl = 86400s;
        set beresp.grace = 86400s;
        return(deliver);
    }
}

Ceci détecte le header et le TTL (durée de validité du cache), et force celui-ci à 86 400 secondes (une journée) si elle est inférieure.

Notez également la présence de return(deliver), celui-ci est en place afin que le built-in VCL de Varnish n’entre pas en action si la requête correspond aux conditions du if. En effet, le built-in VCL va réajuster le TTL à 120s et le beresp.uncacheable = true si elle est exécutée, à cause des headers Cache-Control et autres.

Maintenant, la requête est bien mis en cache :

$ curl -I http://www.exemple.com
HTTP/2 200
date: Sat, 01 Jun 2024 08:26:04 GMT
content-type: text/html; charset=UTF-8
content-length: 85497
server: nginx
vary: User-Agent,Accept-Encoding
last-modified: Fri, 31 May 2024 09:16:26 GMT
edge-cache-platform: wpfastestcache
cache-control: max-age=0, no-cache, no-store, must-revalidate
pragma: no-cache
expires: Mon, 29 Oct 1923 20:30:00 GMT
age: 300
accept-ranges: bytes
edge-cache-status: HIT

Vous pouvez éventuellement décider de supprimer l’en-tête de réponse HTTP Edge-Cache-Platform au niveau de Varnish dans le if précédemment proposé, si vous souhaitez que cette information ne soit pas publique.

Dans les prémices des certificats SSL gratuits, cPanel n’avait pas proposé une intégration avec le service Let’s Encrypt qui est, jusqu’à maintenant, le service le plus populaire pour ce type de besoin. Pour palier à ce manque, FleetSSL a été créé. Ce plugin cPanel gère le processus complet de la création et de l’installation des certificats SSL avec le service Let’s Encrypt.

Aujourd’hui, cPanel a (enfin) intégré nativement Let’s Encrypt dans son outil nommé AutoSSL. Et comme FleetSSL est désormais un outil abandonné, il est intéressant de rebasculer sur AutoSSL.

Désinstallation de FleetSSL

Pour désinstaller FleetSSL, rien de plus simple. Dans le terminal root de votre serveur cPanel, désinstallez tout simplement le package :

yum -y remove letsencrypt-cpanel

À noter que sur la version 0.6.1 spécifiquement, la désinstallation peut échouer en raison d’un bug dans le script de désinstallation intégré. Dans ce cas précis, il va falloir le désinstaller manuellement :

rpm -e --justdb letsencrypt-cpanel-0.6.1-1

Remarque : la désinstallation de FleetSSL ne supprime pas les certificats SSL créés avec celui-ci. Les paramètres utilisateurs et paramètres systèmes sont également préservés, chose que vous pouvez supprimer manuellement :

/home/*/.cpanel/nvdata/letsencrypt-cpanel
/etc/letsencrypt-cpanel.conf
/etc/letsencrypt-cpanel.licence

Activation de Let’s Encrypt dans AutoSSL

Vous pouvez configurer Let’s Encrypt comme fournisseur de certificat SSL dans WHM > SSL/TLS > Manage AutoSSL si ce n’est pas déjà le cas.

Si Let’s Encrypt ne figure pas sur la liste, il sera nécessaire de l’installer manuellement avec la commande suivante :

/usr/local/cpanel/scripts/install_lets_encrypt_autossl_provider

Mettre à jour les certificats SSL

Une fois AutoSSL configuré, vous pouvez cliquer sur « Run AutoSSL for all users » pour exécuter AutoSSL. Ceci permettra d’anticiper le remplacement des certificats SSL Let’s Encrypt créé par FleetSSL qui sont proches de la date d’expiration.

1. Créer des index sur les tables. Sélectionner les colonnes plus utilisées avec WHERE et les indexer.
2. Utiliser la fonction EXIST() au lieu de COUNT() pour vérifier l’existence d’un enregistrement dans la table.
3. Ne sélectionner que les champs utiles (éviter SELECT *)
4. Eviter les sous-requêtes dans WHERE
5. Eviter SELECT DISTINCT autant que possible
6. Utiliser WHERE au lieu de HAVING
7. Créer des jointures uniquement avec INNER JOIN (éviter des jointures avec WHERE)
8. Utiliser LIMIT pour limiter le volume de résultat
9. Utiliser UNION ALL au lieu de UNION autant que possible
10. Utiliser UNION WHERE au lieu d’un long WHERE … or … or …
11. Exécuter les requêtes de maintenances pendant les périodes calmes en trafic (par exemple les requêtes de nettoyage de la base de données)
12. Eviter l’utilisation de OR avec les jointures
13. Utiliser des tables temporaires
14. Supprimer les index avant d’importer une large set de données et remettre après cela
15. Eviter les opérateurs de négation (!= ou <>)
16. Réduire la quantité de sous-requêtes

Que contient _wp_attachment_metadata ?

_wp_attachment_metadata contient les métadonnées associées à votre image dans un format sérialisé pour se permettre d’être stocké dans un champ « string » (texte).

Pour constater la taille utilisée par ce dernier, vous pouvez exécuter la requête SQL suivante sur votre base de données (depuis phpMyAdmin par exemple) :

SELECT SUM(LENGTH(meta_value)) as meta_size FROM wp_postmeta WHERE meta_key = '_wp_attachment_metadata';

À noter que la valeur indiquée est en octets. Ce type de métadonnées ne devrait être disponible que pour les posts de type « attachment », autrement dit que les médias. Cela se vérifie assez facilement avec la requête SQL suivante :

SELECT wp_posts.post_type, meta_key FROM wp_postmeta INNER JOIN wp_posts ON wp_posts.ID = wp_postmeta.post_id WHERE meta_key = '_wp_attachment_metadata' GROUP BY wp_posts.post_type;

Vous ne devriez alors voir qu’un seul post_type qui est attachment.

Prenons maintenant une ligne au hasard :

SELECT meta_key, meta_value FROM wp_postmeta WHERE meta_key = '_wp_attachment_metadata' ORDER BY RAND() LIMIT 0,1;

Si nous regardons son contenu, nous verrons que celui-ci contient entre autres :

• Les métadonnées EXIF de l’image (modèle de caméra, paramètres de la prise …)
• Les miniatures existantes et leurs tailles

Comment réduire la taille de _wp_attachment_metadata ?

Réduire la quantité d’images sur le site

Cela ne vient pas forcément à l’esprit, mais plus il y a d’images, plus il y aura de métadonnées d’images. L’action le plus simple et de supprimer les médias inutilisés sur votre site web. Le plugin Media Cleaner est justement là pour effectuer cette tâche.

Réduire la quantité de miniatures sur votre site

Étant donné que chaque format de miniature rajoute des données pour chaque image sur _wp_attachment_metadata, réduire la quantité de miniatures vous aidera également à réduire les données.

Pour commencer, vous pouvez lister les formats de miniatures existantes sur votre site grâce à WP-CLI (disponible en ligne de commande) :

wp media image-size

Commencez alors par identifier les formats et leur origine : thème ou plugin. En effet, vous allez devoir faire un peu de recherche pour savoir quel plugin ou quel thème a introduit ce format de miniature.

Le plugin ou le thème aura à utiliser la fonction WordPress add_image_size() pour effectuer cette action, vous pourrez alors rechercher les fichiers PHP utilisant cette commande pour constater les plugins et thèmes impliqués. Vous pouvez donc utiliser la commande « grep » pour rechercher rapidement ces fichiers :

cd /home/monsite/public_html/wp-content
grep -r -H 'add_image_size'

(assurez-vous de remplacer « /home/monsite/public_html » par la racine de votre site web)

Désactivez et supprimez ensuite le plugin et/ou le thème de votre site web pour supprimer ce format de miniature, et regénérez vos miniatures avec WP-CLI :

wp media regenerate --yes

IMPORTANT !!! Cette commande prendra plusieurs minutes, voire plusieurs heures pour s’exécuter, et sera gourmand en ressources CPU.

Supprimer les données EXIF de vos images

Vous pouvez aussi supprimer vos données EXIF de vos images pour réduire la taille de la métadonnée _wp_attachment_metadata.

Malheureusement, je n’ai aujourd’hui retrouvé aucun outil pour appliquer cela sur les images déjà existantes sur votre site. Je ne pourrais que vous conseiller de supprimer ces informations en amont, avant d’ajouter l’image sur le site. Vous pouvez faire cela avec votre éditeur de photo (Photoshop, Paint.NET, …) ou avec ce genre d’outil en ligne : verexif.com.

Conclusion

Si vous avez un problème avec _wp_attachment_metadata, c’est sûrement que votre site web contient beaucoup d’images et/ou votre thème et vos plugins demandent à ce que WordPress génère beaucoup de miniatures.

Un nettoyage de cette métadonnée allègera votre table wp_postmeta et améliorera vos performances, toutefois si vous n’avez pas la possibilité de réduire cela et que cela vous pose un problème, il sera nécessaire d’envisager un serveur MySQL (et donc probablement une formule d’hébergement web) avec plus de ressources.

La sécurité par l’obscurité

Cette pratique de sécurité consiste à déplacer l’URL effective pour se connecter à WordPress. Dans les dessous des plugins comme WPS Hide Login se trouve des directives pour déporter l’URL wp-login.php vers un autre URL, en passant par la réécriture d’URL. Quant à l’accès à l’URL wp-admin, ce type de plugin remplace la redirection vers la page de connexion en une erreur 404 ou en une redirection vers la page d’accueil.

Certes, cette pratique peut rebuter pas mal de robots qui sont programmés à n’utiliser que les URLs par défaut, mais ce n’est pas pour autant que votre site web soit sécurisé. Déjà, il est assez rare que les hébergeurs limitent les erreurs 404 ni par adresse IP, ni par nom de domaine. Donc, votre site web n’est probablement pas immunisé de robots qui tenteraient d’accéder à l’URL en testant différentes combinaisons possibles (une attaque par bruteforce).

Les accès machines (API)

Mais le pire, c’est que wp-login.php n’est pas le seul moyen de se connecter à WordPress. Aujourd’hui, nous avons le REST API et le vieux XML-RPC qui permet également de se connecter au site. Vous ne pouvez donc tout simplement pas vous reposer sur vos lauriers après avoir déplacé wp-login.php. Et, vous ne pouvez malheureusement pas déplacer le REST API. Déjà, déplacer wp-login.php présente des risques d’incompatibilités avec certains plugins (notamment ceux qui pourraient proposer des mécanismes de connexions comme les plugins d’espace membre, de forum ou d’espace client) ; désactiver le XML-RPC se fait, mais quelques vieux plugins risquent d’en avoir toujours besoin ; et REST API, malheureusement, vous ne pouvez pas le déplacer sans casser WordPress.

Vous pouvez remarquer rapidement en ayant un plugin qui comptabilise le nombre de connexions échoué que même si vous déplacez wp-login.php, vous continuez à avoir des robots qui tentent de se connecter.

Alors, qu’est-ce qu’il faut faire pour sécuriser WordPress ?

Au lieu de dépenser vos efforts pour cacher les pages de connexion, vous devriez miser plus sur la sécurisation de la page de connexion lui-même.

Limiter les adresses IP

Autant que possible, limitez l’accès aux pages de connexion et au REST API / XMLRPC par une liste d’adresse IP / géolocalisation. Si vous vivez en France, par exemple, vous pouvez restreindre l’accès uniquement à ce pays.

Il y a plusieurs techniques possibles, que ce soit avec un plugin, avec un .htaccess, dans les configurations serveurs voire même au niveau du proxy CDN (comme Cloudflare). A titre personnel, je recommande toujours de régler ce problème le plus tôt possible : donc au niveau du CDN, ou au niveau de la configuration serveur.

Limiter les accès robots

Si vous êtes dans l’obligation d’exposer votre page de connexion (site ayant un accès membre, par exemple), assurez-vous de bloquer les robots sur ces pages.

La méthode la plus classique est d’y activer un système captcha. Malheureusement, le captcha peut être relou pour l’expérience utilisateur et en plus, il est aujourd’hui facilement outrepassé par les robots grâce à de l’IA et aux fermes de clics.

La solution que je recommande est de se baser sur une solution de réputation. Beaucoup de services proposent aujourd’hui (gratuit ou payant) une certaine liste d’adresse IP qui ont déjà attaqué d’autres sites WordPress. Il suffira d’ajouter cette liste dans vos listes de blocages.

C’est d’ailleurs pour cette raison que les solutions de pare-feu en proxy comme Cloudflare et Sucuri sont puissants. En effet, ils peuvent détecter, sur une très large échelle, le comportement d’une adresse IP sur des millions de sites et repérer ainsi les robots d’attaques pour pouvoir ensuite les bloquer à échelle globale.

Vous pouvez aussi bloquer les adresses IP non résidentielles (adresses IP qui sont dans des datacenters), qui représente une masse non négligeable des attaquants. Malheureusement, je n’ai trouvé à ce jour aucune liste assez fiable.

Limitez les tentatives infructueuses

On ne dirait pas comme ça, mais WordPress n’en est pas immunisé, de nature. Il faut implémenter vous-même une solution pour limiter les tentatives infructueuses. Personnellement, j’ai implémenté cela par le biais de scripts LUA sur mon serveur NGINX, mais c’est une solution qui peut aussi être implémenté avec un simple plugin.

Certains hébergeurs proposent également cette solution sous forme de règles ModSecurity ou de limitation de trafic L7 sur son serveur web, ou encore les CDN proxy orienté sécurité comme Sucuri.

Utiliser un mot de passe fort et l’authentification à deux facteurs

Évidemment, si votre ensemble nom d’utilisateur / mot de passe est facilement identifiable, alors c’est nécessaire d’améliorer cela en mettant un mot de passe fort (long et complexe) et surtout de mettre l’authentification à deux facteurs afin que, même si les robots passent la page de connexion, l’authentification à deux facteurs vont les garder derrière une autre porte.

Les conditions de réception des uploads

Déjà, à la réception, les deux plateformes n’ont pas les mêmes critères de réception. Chez YouTube, les formats compressés à perte (lossy encoding) sont accepté à partir de 128 kbits/s de bitrate. Sur Spotify, le format doit être impérativement sans perte (lossless encoding) : .WAV (non compressé) ou .FLAC (compressé mais sans perte).

Bref rappels sur les caractéristiques des formats audionumériques

• L’échantillonnage est la fréquence donc les échantillons sont débités à la lecture (ou sont capturés à l’écriture). Il faut savoir que même avec le format non compressé, l’importation d’un signal audio sur un appareil numérique passe forcément par un échantillonneur qui se chargera de prendre le niveau de signal audio à une fréquence précise. Les deux taux d’échantillonnage les plus utilisés sont le 44.1 kHz puis plus tard le 48 kHz (qui a permis une synchronisation plus facile avec les vidéos qui à l’époque avait une norme de 24 images par secondes, ce qui fait que chaque image valait deux échantillons audio).
• Le profondeur de bits qui indique combien de de bits on utilise pour représenter l’amplitude du signal sur un échantillon.

Le bitrate réunit les deux paramètres : c’est le nombre de bits utilisés pour représenter une seconde de son. Vu les définitions précédentes, pour un format .WAV (sans compression) à 44.1 kHz d’échantillonnage avec 24 bits de profondeur de bits, on a 44 100 x 24 = 1 058 400 bits/s soit près de 1 Mbits/s.

Maintenant, parlons de compression. Rien à voir avec la compression audio lors d’un mixage avec le CL-2A. La compression, dans le monde numérique, consiste à réduire le nombre de bits qui représente, « approximativement » ou non, les mêmes données.

Grâce à des algorithmes tel que le AAC ou le Vorbis, la quantité de bits pour représenter un ensemble d’échantillon peut être baissé sans altérer ou en altérant très peu le signal représenté. Ceci permet de baisser le bitrate sans baisser le taux d’échantillonnage ni le profondeur de bits, et ainsi permettre, par exemple, un téléchargement plus rapide.

Les formats audios à la lecture

Les formats envoyés aux internautes sont différentes. Pour Spotify, les formats sont :

• Ogg/Vorbis (96, 160 ou 320 kbits/s)
• AAC (128 ou 256 kbits/s)
• HE-AACv2 (24 kbits/s)

Le format envoyé par YouTube est principalement du AAC aux alentours de 128 kbits/s VBR (le bitrate varie selon les moments de la vidéo, par exemple, un gros silence de 20s ne prend que quelques bits par rapport à une grosse ambiance varié de 20s). Les vidéos hautes définitions semblent avoir un peu plus de qualité audio.

Youtube semble également utilisé des encodages différentes selon le nombre de vues. Plus un vidéo est regardée, plus ils tentent d’utiliser de meilleurs codecs qui ont un meilleur rendement et donc un bitrate plus faible pour un maximum de profondeur de bits. C’est une pratique assez courante, permettant d’économiser les ressources nécessaires à la compression : faire un compression rapide pour tous les vidéos pour ne pas boucher la file d’importation de vidéos sur la plateforme, puis réencoder en mieux les contenus les plus demandés pour faire baisser la consommation de bande passante induite.

L’impact du profondeur de bits

Contrairement à ce que l’on tend à penser, le profondeur de bits est plus important que l’échantillonnage qui est aujourd’hui quasiment standard (entre 44.1 et 48 kHz). De plus, nos appareils d’écoutes sont généralement limité à 48 kHz. Moi même je dispose d’interface audio supportant jusqu’à 192 kHz à 24 bits de profondeur, et je préfère rester à 48 kHz en 24 bits, plutôt que d’aller à 96 kHz par exemple, mais à 16 bits. Pour une meilleure écoute, un profondeur de bits important doit être en place pour représenter plus fidèlement les niveaux de variations du signal sonore.

Mais surtout, le profondeur de bits influe (légèrement pour les non audiophiles) sur l’intensité sonore ressentie, mesurée en LUFS. Notre cerveau et nos oreilles ont tendance à s’accommoder d’un niveau signal ambiant, et ressent donc mieux les variations plus que les niveaux eux-mêmes. Or, moins il y a de profondeur, moins il y a de détails dans la variation.

C’est ainsi que s’explique la qualité de Spotify. Grâce à un bitrate constant et haut, ils peuvent proposer un profondeur de bits plus haut que celui de YouTube, et ainsi une sensation d’intensité plus raffinée.

Gérer la directivité de vos enceintes de retour

C’est LA première chose à faire. Si votre enceinte de retour émet des sons dans la zone de captation d’un microphone, c’est impérativement le larsen assuré. Avant même de tenter de corriger avec des EQ ou diminuer le gain sur la console, assurez-vous de bien placer vos enceintes.

Les enceintes de retour se placent habituellement devant l’instrumentiste (n’oubliez pas, la voix est aussi un instrument) et dirige le son vers son visage (et plus particulièrement ses deux oreilles). Dans le cas d’un chanteur ou d’une chanteuse, le micro utilisé pour la performance est naturellement dirigé de la même façon : le micro se place devant sa bouche et se dirige vers son visage également.

Le micro étant conçu pour la performance sur scène (comme le cas du célèbre Shure SM58), la polarité du micro empêche généralement la captation (du moins, la forte captation) des sons provenant de l’enceinte qui devraient donc actuellement provenir à 180° :

Evitez donc à partir d’aujourd’hui de placer des enceintes de retour à gauche ou à droite de votre chanteur. Comme vous pouvez constater sur la graphe, ceci peut augmenter considérablement les chances d’un larsen.

Utiliser des micros adaptés à la condition de captation

La deuxième chose à améliorer, c’est de choisir le bon micro pour la bonne condition de captation. S’il y a tant de micros sur le marché c’est que chacun répond à une demande précise. Comme on a vu sur le précédent paragraphe, la polarité d’un micro joue sur le larsen.

Evitez donc à tout prix de prendre des micros à forte « bleed » qui capterait des sons autour de son environnement, comme les retours de scène. C’est par exemple le cas des micros à condensateurs qui, comme par hasard, sont rares sur scène.

Dans le cas d’un batteur qui chante, par exemple, privilégiez plutôt un micro serre-tête avec peu de bleed au lieu d’un micro sur pied/perche immobile où vous allez devoir mettre un micro à forte bleed pour capter la voix pendant que le batteur bouge.

Envisagez même de mettre des shields sur les zones à forte ambiance sur scène (comme le cas de la batterie) pour protéger certains micros de certains sons inutiles. Par exemple, si votre chanteur se place trop près de la batterie, envisagez de mettre des drums shields autour de la batterie.

N’envoyez pas les rooms et les ambiances sur les retours de scène

Bien évidemment, des micros d’ambiances et de rooms nécessitent généralement une captation généralisée qui, dans ce cas, nécessite des micros très sensibles et très captatives. Ceci engendre malheureusement la captation non intentionnelle des retours de scène.

Mais fort heureusement, les rooms et les ambiances ne sont pas nécessaires sur scène. Revenons aux sources : pourquoi il vous faut des micros de rooms et d’ambiances ? C’est pour reproduire l’ambiance ressentie sur scène sur une autre condition d’écoute : dans le public, en transmission broadcast, ou dans votre salon en regardant un DVD du live. Ces ambiances sont généralement les réflexions sonores des éléments du scène.

Inutile donc de remettre sur scène ce qui y est déjà, ceci ne fait que boucler une boucle et inciter les larsens.

Adoptez les in-ears monitors

Les in-ears monitors sont des pépites qui évitent les larsens. Vu que ce que vous jouez ou chantez sur scène n’est plus renvoyé dans l’environnement ambiant de la scène mais directement dans vos oreilles, il est physiquement impossible pour votre micro de recapter ce qu’il envoie vers la console.

Toutefois, il est important de capturer tous les sonorités de la scène et de les envoyer dans vos in-ears monitors, sans quoi votre performance serait bizarrement légère et impuissante, du point de vue du performeur : l’envoi des micros d’ambiances et de rooms sont obligatoires. Vous serez même peut-être amené à ajouter d’autres micros d’ambiances (notamment les micros pour capter les cris du public).

Baisser la sensibilité de votre préamplificateur

Une fois tous les précédents problèmes réglés, et que le problème se manifeste toujours, il est temps d’ajuster la console.

La première chose à vérifier est le gain apporté par la préamplification et la compression (via son make-up gain). Si votre préamplificateur est trop sensible, il captera facilement des sonorités ambiantes provenant de votre source. Si c’est le cas, il est temps de baisser le gain.

Mieux vaut un gain faible pour isoler l’instrument à capter, puis remonter plus tard dans la chaîne de mixage le volume.

Régler les problèmes de directivités et de réflexions de la façade

C’est également possible que votre problème d’ingénieur de son/retour soit lié à un ingénieur système maladroit. Les enceintes de façades sont particulièrement puissantes et si elles sont mal configurés et mal positionnés, elles risquent de renvoyer du son ambiant trop important vers la scène.

Ce type de problème se manifeste principalement quand vous avez des façades trop reculés, ou bien des façades de balcons dirigés à +/- 90° et que les périphériques de gestions d’enceintes n’ont pas été correctement configurés pour les déphasages et retards (pour mettre toute la salle dans la même phase et donc la même directivité).

Il est aussi possible que l’ingénieur système pousse les enceintes de façades trop fort et que leurs sons se réfléchissent sur des surfaces (comme les murs, le sol, les gens de la salle, …). Les cathédrales sont particulièrement connus pour ces réflexions qui engendrent des échos puissants, même juste avec votre voix.

La première arme possible serait de baisser le volume. Oui, inutile d’avoir un gros bouilli sans nom, si à un volume plus bas, vous évitez les réflexions tout en gardant l’intelligibilité du son : vous évitez à la fois les larsens, mais vous gardez aussi une clarté de votre mixage.

Si vraiment une salle a une géométrie complexe qui induit des réflexions, investissez sur les panneaux acoustiques ciblant les points les plus problématiques.

Eliminez les points sensibles avec un EQ

Si vraiment rien n’y fait, il est temps d’éliminer les points sensibles avec un EQ. Un larsen se compose souvent d’une fréquence fondamentale et quelques harmoniques. Il suffit de baisser légèrement ces EQ sur la source pour essayez de couper le larsen. Sachez toutefois que cela altère inévitablement la qualité de la captation et devra être utilisé assez subtilement et à compte gouttes.

Vous pouvez également essayer de gérer cela sur le système des retours de scène uniquement, si le problème peut s’y régler. Cela permettra de garder un son non charcuté sur les façades.

Que veut dire optimiser les images ?

Plus un image est grand en terme de taille de fichier (mesuré en octets), plus il sera lent à transférer sur Internet. L’optimisation consiste à réduire la taille d’un fichier d’image au maximum possible sans affecter visuellement sa qualité.

Les avantages de l’optimisation d’images

En effet, posons nous deux secondes. Pourquoi s’emmerder à vouloir optimiser ses images sur le web ? Car oui, optimiser les images d’un site Internet n’est pas une mince affaire. Ceci peut impliquer des ressources et des coûts, conséquent ou pas, selon la taille du site et la manière dont l’optimisation est faite.

D’après le site HTTP Archive, les images représentent en moyenne 56% de la taille totale d’une page web en 2021, en excluant les vidéos qui, évidemment, n’entre en jeu que sur des cas de pages spécifiques. C’est donc une pierre angulaire de la consommation de trafic sur Internet après les vidéos.

Vous avez définitivement du pain sur la planche si vos dépassez ces 56%. Et quand bien même vous êtes proches, grapiller quelques octets ne fera que vous mettre en position avantageuse pour le SEO.

J’ai donc énuméré pour vous quelques avantages obtenus grâce à l’optimisation d’image :

• Ceci améliore efficacement le temps de chargement de vos pages web et évitent ainsi vos visiteurs voire les bots de Google de se lacer et annuler le chargement de la page.
• Les moteurs de recherches apprécient les pages rapides et donc ceci améliore votre référencement SEO.
• La taille des images stockés sur votre serveur sont réduits et ainsi l’espace disque utilisé par votre site est plus petite, la création de backup devient plus rapide et vous risquez moins de saturer la bande passante (notamment si vous êtes sur une formule d’hébergement web mutualisé).

Les méthodes pour optimiser les images pour le web

Il n’existe pas 36 solutions : il faut savoir trouver un compromis entre une image de qualité et une taille de fichiers raisonnable. La méthode restera toujours sur la compression d’image, mais il sera nécessaire de définir le type de compression et le seuil d’efficacité.

Déjà, il y a différents formats d’images qui proposent alors des types de compressions différentes :

• Les images au format JPEG (extension de fichier .jpg ou .jpeg) : ceux-ci proposent des compressions d’images lossy, c’est-à-dire des compressions à perte.
• Les images au format PNG (extension de fichier .png) : ceux-ci proposent principalement des compressions d’images lossless, c’est-à-dire des compressions sans perte. Toutefois, les images de ce format pourraient aussi être en compression lossy. Tout dépend de la configuration du logiciel d’édition au moment de sauvegarder le fichier.
• Les images vectorielles .SVG : contrairement aux images traditionnelles fait de matrices de pixels, les images vectorielles indiquent des tracés. Ceci permet, par exemple, d’indiquer un carré de 1000 pixels x 1000 pixels sans devoir indiquer tous les pixels concernés, il suffira d’indiquer 4 points (donc 4 pixels), indiquer s’ils se relient, et indiquer le couleur de bordure et de remplissage.

Choisir la bonne taille d’image

Avant de s’attaquer aux algorithmes de compression, posez-vous déjà la question à chaque fois que vous ajoutez une image sur votre site : à quel taille, au maximum, cette image sera affichée ? Inutile d’envoyer une image de 4000 x 2000 pixels si finalement elle ne sera affichée qu’à 400 x 200 pixels.

Naturellement, il existe dans WordPress le mécanisme de miniatures qui fait que WordPress redimensionne automatiquement les images durant le téléversement (upload) en se référant aux tailles indiqués par le thème actif. Toujours est-il que certains thèmes mal développés mentionnent vouloir utiliser une image de 1000 x 500 pixels, alors qu’ils les affichent sur une zone de 500 x 250 pixels.

Si nécessaire, faites modifier votre thème par un développeur WordPress pour ajouter les tailles d’images adéquates sur le fichier functions.php et ensuite les utiliser au bon endroit.

Utiliser le bon format d’image

Une fois les images à la bonne taille, triez-les pour cibler les deux formats de compression :

• Les photos, images à forte variations de couleurs et images à forte résolution seront au format .JPEG. La perte de qualité dû à la compression est généralement très peu visible sur ces types d’images.
• Les assets, boutons, logos et autres éléments du thème devront être au format .PNG voire .SVG.

Optimiser le ratio de compression des formats

Une fois les images mis au bon format, vous pouvez utiliser des outils automatisés comme jpegoptim ou optipng pour calculer le bon ratio de compression (maximum de compression, très peu de perte de qualité voire aucun).

L’installation se fait depuis la console SSH en root sur votre serveur dédié VPS. Pour Debian/Ubuntu :

apt-get install jpegoptim optipng

Pour CentOS/AlmaLinux et autres dérivés de Red Hat :

yum install jpegoptim optipng

Une fois installé, vous pouvez lancer un optimisation massif des fichiers. En supposant que vos fichiers images se trouvent dans /home/monsite/public_html/wp-content/uploads :

find /home/monsite/public_html/wp-content/uploads -name "*.jpg" -exec jpegoptim {} \;
find /home/monsite/public_html/wp-content/uploads -name "*.jpeg" -exec jpegoptim {} \;
find /home/monsite/public_html/wp-content/uploads -name "*.png" -exec optipng {} \;

Optimiser les images avec un plugin WordPress

Si malheureusement vous n’avez pas accès SSh sur votre serveur ou si vous êtes sur une formule dépourvu de cette fonctionnalité (notamment les formules mutualisés), il vous est toutefois possible d’optimiser vos images avec un plugin WordPress.

Je vous rappelle toutefois que ce type d’opération effectue énormément de calcul et donc consomme énormément de CPU. La lecture et écriture des images pourrait aussi engendrer une forte hausse d’opérations disques. Je vous recommande par conséquent d’effectuer cela quand vous aurez le moins de visiteurs. Votre hébergeur pourrait également couper systématiquement les longues opérations et/ou les opérations lourdes en CPU trop persistante, notamment sur les formules mutualisés et peut-être aussi sur certains formules VPS. Renseignez-vous sur les Conditions Générales d’Utilisation et de Vente (CGUV) et demandez éventuellement au support leurs recommandations vis-à-vis de cela.

Mais surtout, évitez de faire des optimisations de masse avec un plugin, ou pire, effectuer des optimisations à la volée (optimisation faite uniquement quand un visiteur accède à l’image). Optez plutôt une optimisation durant le téléversement.

L’optimisation à la volée peut augmenter considérablement votre TTFB et ainsi ralentir le chargement de l’image. Oui la taille est petite, mais votre site prend plus de temps à le fournir au visiteur.

L’optimisation de masse pourrait saturer votre formule d’hébergement ou votre serveur durant l’opération et ainsi causer des problèmes de lenteurs voire d’inaccessibilité. Si elle est initié par PHP au moyen d’un plugin WordPress, le headroom en ressources augmente car PHP lui-même consomme beaucoup plus pour initier l’opération.

Vous voilà maintenant prévenu, je vous propose donc l’outil reSmush.it qui me semble fournir le meilleur compromis. Ce plugin WordPress :

• Effectue les optimisations au téléversement.
• Effectue l’optimisation des images marqués non optimisés au compte goutte (grâce aux crons jobs). Ceci vous permet d’écouler petit à petit la liste d’image à optimiser sans pour autant risquer de saturer votre serveur.
• Aucune optimisation à la volée n’est faite, l’image, une fois optimisée, est gardée en stockage, par conséquent le TTFB n’augmente pas.

Conclusion

L’optimisation d’image avec WordPress n’est pas une mince affaire. Des optimisations mal faites pourrait, au mieux ne pas améliorer votre situation, et au pire dégrader vos performances. Procédez toujours avec prudence.

Le diagnostic

Le diagnostic n’était pas facile. C’est un HDD qui contenait que principalement le système d’exploitation de mon PC. Et il était particulièrement lent. Le souci étant que j’ai eu une coupure de courant lors de mon premier démarrage du PC, donc lors de l’installation de Windows.

Ayant possédé le PC depuis très peu (que quelques jours) et ayant très peu de RAM (4 Go), j’ai toujours pensé que le HDD travaillait trop à cause du swap (mémoire de pagination). Mais finalement, après réception d’une nouvelle barrette de RAM que j’ai commandé pour palier au problème, je me rend compte que ce n’était pas de ce côté là.

J’ai alors commencé à soupçonner le HDD. J’ai alors pris un vieux HDD qui traînait pour voir si le même problème se manifestait aussi avec celui-ci. Visiblement, non, c’est bien une panne de disque.

J’ai donc ouvert CrystalDiskInfo qui m’affichait bien un disque dur tout rouge, juste à cause d’un secteur réalloué. Mais ça je m’y attendais, un secteur réalloué serait la réparation de Windowsavec chkdsk face à un secteur endommagé par un arrêt brusque du PC.

Il m’a fallu plusieurs heures pour faire des recherches sur la signification de chaque élément des données SMART pour finalement s’arrêter sur « Current Pending Sector Count ». D’après ce que je lis, ce sont des secteurs qui, la modification reste dans la mémoire RAM du HDD, mais que le microcontrôleur du disque n’arrive pas à faire appliquer sur les plateaux. Ce sont généralement des secteurs partiellement abîmés où l’opération d’écriture ne fonctionne plus. Et cela expliquait bien mon problème, mon HDD continue sans cesse d’écrire quelque chose, sans s’arrêter, même quelques fois quand je redémarre le PC et que je vais dans le BIOS.

La réparation en quelques heures

Vu que j’ai déjà essayé de formater et de réinstaller Windows, je me suis dit qu’il faut impérativement rescanner l’ensemble des secteurs, retirer les secteurs endommagés (réallocation de secteurs) sur lesquels on n’arrive plus à réécrire et recréer proprement les partitions.

Plusieurs façons sont possible, le low level format en est un, mais j’ai voulu faire le disque entier, sachant que les secteurs endommagés pourraient être ceux qui gardaient les informations de partitionnement, et donc ne pourrait être atteint avec un simple formatage à bas niveau.

J’ai donc commencé par réinitialiser le disque avec Partition Wizard pour remplir tous les secteurs de zéros, avec la fonctionnalité « Wipe Disk ». Ceci permettait au microcontrôleur du disque d’écrire sur tous les secteurs existants, et ainsi recomptabiliser les secteurs endommagés et refaire les réallocations en cas de détection de nouveaux secteurs endommagés.

Notez que cette opération supprimera tous les données du disque, y compris les partitionnements. Les données écrites importent peu, remplir le disque avec des uns, des uns et des zéros voire les autres algorithmes plus complexes de nettoyage pourraient tous fonctionner.

Et miracle! Une fois réinitialisé, le disque fonctionnait « de nouveau » correctement. Le nombre de secteurs endommagés n’a pas augmenté sur les données SMART, ce qui veut dire que les secteurs qui ont eus des problèmes d’écritures étaient donc des secteurs déjà décomptés comme HS, ou bien des secteurs qui se sont réparés en les remplissant de zéros.

A rappeler tout de même que c’est un disque neuf et qui a subit une coupure électrique lors de son premier démarrage. J’ai quand même placé le HDD dans une agrégation RAID tolérant la panne totale d’une disque parmi plusieurs, pour ne pas le jeter, tout en sécurisant les données par dessus.