Astuces de Webmaster

Si votre site est lent, il peut y avoir plusieurs raisons :
- ça peut être un problème serveur, un problème de connexion Internet ou une lenteur d’affichage

Pour les problèmes de connexion Internet, on ne peut pas faire grand chose
Pour les problèmes de lenteur d’affichage, les outils Yslow et PageSpeed (en ligne via gtmetrix.com ou couplés à Firebug pour Firefox) vous donneront toutes les informations utiles pour optimiser votre site, la CSS, les images, etc.
On s’intéressera ici à la partie Serveur, les raisons sont souvent parmi les suivantes :
- des requêtes trop lourdes ou trop fréquentes, ou les deux
- des processus (tâches, générations de fichiers) trop longs (parfois à cause des requêtes)
- des serveurs « extérieurs » qui appellent vos scripts/images trop souvent (un gros site qui appelle vos images fera planter votre serveur si vous n’êtes pas dimensionné pour son trafic)

Requêtes trop lourdes

Connectez-vous en ligne de commande (SSH) à votre console MySQL (ou via phpMyAdmin dans l’onglet processus sur l’accueil) et regardez les processus en cours (commande SQL « SHOW FULL PROCESSLIST; »), vous en verrez peut-être des récurrentes, ou des longues. Maintenant, vous savez quoi optimiser.

Si votre processlist est souvent vide ou pleine de « sleep », tout va bien. S’il y a trop de sleep avec une durée trop longue, réduisez votre timeout ou utilisez mysql_connect plutôt que mysql_pconnect. 2mn peut être une durée honnête pour un timeout.

Identifier les scripts consommateurs

Pour identifier les scripts consommateurs, il est intéressant d’utiliser un petit programme : Apachetop (apt-get install apachetop sous debian – comment installer ?)

Pour voir l’état du serveur, il est bon d’utiliser htop (apt-get install htop sous Debian),

Identifier les extérieurs

Pour voir les extérieurs qui appellent vos scripts, rien de tel qu’un bon vieux tail -f /var/log/apache2/error.log (à modifier par votre nom de fichier d’erreur)

Optimiser mySQL :

• Identifiez-vous en root sur le Shell du serveur considéré
• Pour optimiser MySQL, on va s’intéresser principalement au fichier /etc/mysql/my.cnf (généralement ainsi situé, notamment sur les distributions Debian, mais n’hésitez pas à faire un # locate my.cnf pour identifier la localisation de ce fichier et vérifier s’il n’y a pas de doublon)
• nano /etc/mysql/my.cnf (éditons la configuration)


[mysqld]
port = 3306
socket = /var/lib/mysql/mysql.sock
skip-locking
key_buffer = 16K
max_allowed_packet = 1M
table_cache = 4
sort_buffer_size = 64K
read_buffer_size = 256K
read_rnd_buffer_size = 256K
net_buffer_length = 2K
thread_stack = 64K
# pour utiliser moins de mémoire, si on n'utilise pas Berkeley DB on ajoute cette ligne
skip-bdb
# idem si on n'utilise pas InnoDB
skip-innodb
# de la même façon, si on n'utilise pas InnoDB, on peut commenter les lignes suivantes
#innodb_data_home_dir = /var/lib/mysql/
#innodb_data_file_path = ibdata1:10M:autoextend
#innodb_log_group_home_dir = /var/lib/mysql/
#innodb_log_arch_dir = /var/lib/mysql/
# Vous pouvez définir .._buffer_pool_size entre 50 et 80 %
# de la RAM mais attention à ce que l'utilisation globale de RAM par MySQL ne soit pas trop important (à suivre)
#innodb_buffer_pool_size = 16M
#innodb_additional_mem_pool_size = 2M
# Définissez .._log_file_size à 25% du buffer pool size
#innodb_log_file_size = 5M
#innodb_log_buffer_size = 8M
#innodb_flush_log_at_trx_commit = 1
#innodb_lock_wait_timeout = 50
[mysqldump]
quick
max_allowed_packet = 16M
[mysql]
no-auto-rehash
# Décommentez la ligne suivante si vous n'êtes pas familier avec SQL
#safe-updates
[isamchk]
key_buffer = 8M
sort_buffer_size = 8M
[myisamchk]
key_buffer = 8M
sort_buffer_size = 8M
[mysqlhotcopy]
interactive-timeout

Quelques paramètres qui nécessitent attention

query_cache_size

MySQL fournit une fonctionnalité qui peut s’avérer très pratique : un cache de requêtes. Lorsqu’une même requête est exécutée plusieurs fois, et retourne les mêmes résultats à chaque fois, MySQL peut mettre en cache le résultat, ce qui décharge assez le serveur.

key_buffer

La valeur de key_buffer_size est la taille du buffer utilisé pour les index. Plus il y a de mémoire tampon, et plus rapidement la commande SQL se termine et un résultat sera retourné. La règle de base est de régler le key_buffer_size à au moins un quart, mais pas plus de la moitié de la quantité totale de mémoire sur le serveur. Idéalement, il sera assez grand pour contenir tous les index (la taille totale de tous les fichiers .MYI sur le serveur).

table_cache

La valeur par défaut est 64. Chaque fois que MySQL accède à une table, il la place dans le cache. Si le système accède à de nombreuses tables, il est plus efficace d’avoir ces tables dans le cache. MySQL, étant multi-thread, peut exécuter de nombreuses requêtes sur une table au même moment, et chacune de ces requête va ouvrir une connexion avec la table. Examinez la valeur de open_tables aux heures de pointe. Si vous trouvez qu’il reste à la même valeur que la valeur de votre table_cache, puis que le nombre de opened_tables commence à augmenter rapidement, il faut augmenter la taille du table_cache si vous avez suffisamment de mémoire disponible.

sort_buffer

Le sort_buffer est très utile pour accélérer les opérations myisamchk (c’est pourquoi il est défini beaucoup plus haut dans les fichiers de configuration par défaut), mais il peut aussi être utile lors de l’exécution quotidienne un grand nombre de classements (fonctions comme sort(),…).

thread_cache

Si vous avez un serveur surchargé à force de recevoir un grand nombre de connexions rapides, définissez votre thread_cache suffisamment haut pour que la valeur threads_created de SHOW STATUS (commande SQL) cesse d’augmenter. Cela devrait décharger un peu le CPU.

Autres optimisations MySQL

Bien souvent, c’est sur les jointures que se jouent les lenteurs. Utilisez les jointures à bon escient, vérifiez que pour chaque clé utilisée dans les jointures, il existe bien un index sur ce champ clé, sinon créez-le tout de suite et ça fera une grande différence.

Les chiffres pèsent moins lourd dans les index que les lettres, par conséquent, préférez les clés numériques pour vos jointures de grosses tables pour éviter de trop surcharger vos index.

Apache

Le principal problème avec Apache est la quantité de RAM qu’il utilise. Nous allons voir comment baisser la quantité de RAM utilisée par Apache.

• Charger moins de modules
• Faire moins de demandes simultanées
• Recycler les processus Apache
• Utiliser les KeepAlive, mais pas pour trop longtemps
• Réduire vos timeout
• Créer moins de logs
• ne pas résoudre pas les Hostname
• N’utilisez pas les .htaccess

Qui n’a pas eu son serveur down alors qu’il était chez IKEA… je viens de mettre en place un simple script qui me permettra de recevoir un e-mail ou un SMS en cas de problème.

Cela nécessite d’avoir deux serveurs, puisque l’un doit faire un « ping » sur l’autre qui doit répondre (« pong »). Appelons le serveur à tester Frodon et celui qui le teste Gandalf.

Sur Gandalf, créez un script sh :
touch /home/checkFrodon.sh
chown u+rwx /home/checkFrodon.sh

Editez ensuite checkFrodon.sh (apt-get install nano si nano n’est pas installé) :
nano /home/checkFrodon.sh

Mettez-y ceci :

ping -c 1 "monsiteatester.fr" > /dev/null 2>&1
if [ $? -eq 0 ] ; then
echo "=> running"
else
echo "=> not running"
mutt -s "[MONSITE] Ping monsisteatester.fr nok - serveur down ?" monemail@gmail.com < /home/checkFrodon.sh
fi


Testez le script en question :
/home/checkFrodon.sh
Cela vous affichera dans le shell suivant les cas "=> running" ou "=> not running". Et si ça vous affiche not running, ça vous enverra un e-mail contenant le contenu du script SHELL pour rappel.

Pour l'automatiser, il vous suffit de créer un cron faisant appel au script en question toutes les minutes, toutes les 5 minutes, toutes les heures, comme vous voulez.

Enjoy !

Surtout, si vous avez mieux, n'hésitez pas !

Oh, je parlais de SMS également, parce qu'il suffit dans la condition de faire appel grâce à la commande wget à la requête explicitée ici : http://api.orange.com/fr/api/sms-api/imprimer

wget http://run.orangeapi.com/sms/sendSMS.xml?id=[votre API Access Key]&from=[numéro court d'émission]&to=[numéro de téléphone]&content=[votre message à envoyer]&long_text=[activer ou non le SMS long]&max_sms=[nombre maximum de "parties" d'un SMS long]&ack=[activer ou non l'accusé de réception]

8,36€ le crédit de 1000 SMS... ça se regarde ! (Cf grille tarifaire Orange)

Bonus : si vous voulez tester qu'une chaine apparaît bien sur une page web (car auparavant, on ne teste que le ping, et un serveur ping même si le serveur web est tombé, il vaut donc mieux tester que le rendu Web se fait bien). Ici, on teste que l'identifiant Google Analytics existe bien dans le code source de la page, mais ça pourrait être autre chose :

cd /tmp/
rm -f /tmp/index.html*
wget monsite.fr
if [ "$(cat /tmp/index.html | grep "UA-XXXXXX-1" )" = "" ] ; then
mutt -s "[MONSITE] apache or mysql down ?" monadresse@gmail.com < /home/checkFrodon.sh
echo "monsite.fr web not running"
else
echo "monsite.fr web running"
fi

Lorsque vous vous échangez des fichiers avec des partenaires, etc. il est plutôt de bon ton d’être synchro.

Pour cela, rien de plus simple, une commande vous permet de vous synchroniser avec un serveur donné.

Exemple :
ntpdate ntp.univ-lyon1.fr

Après, il vous suffit de programmer un cron (automate) tous les jours à 2, 3 et 4h et vous êtes relativement tranquilles.

Pour rappel, vous pouvez souvent programmer un cron grâce au webmin de votre serveur, rubrique Système > taches cron (si vous n’avez pas webmin, installez-le !) ou en ligne de commande (man crontab si ça vous amuse)

Pour vérifier l’heure de votre serveur, il vous suffit d’afficher la date courante :

echo $(date '+%H.%M.%S')

Je connais pas mal de développeurs plus ou moins bons qui ne savent pas commenter monter un FTP, j’ai décidé de suivre les étapes de bout en bout en suivant des tutoriels déjà rédigés, qui posent tous des problèmes du fait qu’ils sont datés. J’ai ici remis à jour tout ce qu’il faut avec les bonnes versions, etc. Vous devriez avoir dans cette page tout ce qu’il faut pour créer FTP à partir de rien. J’ai mis les tutoriels source par respect pour les auteurs. J’ai modifié les tutoriels d’origine en ajoutant des informations qui m’ont semblé utiles.

ATTENTION pour les débutants, si les commandes que vous faites ne fonctionnent pas, certaines nécessitent d’être connecté en « root ». Pour ce faire, tapez la commande « su » et tapez le mot de passe root pour avoir les pleins pouvoirs.

Nous allons utiliser Very Secure FTPd (autrement appelé vsftpd qui équipe des serveurs FTP tels que ceux Red Hat, Suse, OpenBSD, kernel.org et bien (bien sûr) Debian.

Loggez vous en root et tapez :
# apt-get install vsftpd

Une fois vsftpd installé, il faudra remplacer le fichier de configuration /etc/vsftpd.conf par le suivant :

# Nous voulons que le serveur fonctionne en mode standalone
listen=YES
#
# On ne veut surtout pas de connexions en mode anonymous
anonymous_enable=NO
#
# On veut que les utilisateurs locaux puissent se connecter
local_enable=YES
#
# On veut que les utilisateurs puissent remonter des fichiers sur le serveur
write_enable=YES
#
# On fixe le masque local a 022 (les fichiers remontés auront des droits en 755)
local_umask=022
#
# On interdit l’upload anonyme
anon_upload_enable=NO
#
# Idem pour la creation de repertoires
anon_mkdir_write_enable=NO
#
# On demande a ce que les actions des utilisateurs soient loggees
xferlog_enable=YES
#
# On verifie que la commande PORT provienne bien du port 20 de la machine cliente
connect_from_port_20=YES
#
# Les logs seront enregistres dans le fichier /var/log/vsftpd.log
xferlog_file=/var/log/vsftpd.log
#
# On declare les valeurs de timeout. Celles fournies par defaut sont ok pour notre utilisation
idle_session_timeout=300
data_connection_timeout=120
connect_timeout=60
accept_timeout=60
#
# Par securite, on interdit la commande ABOR
async_abor_enable=NO
#
# Les transferts en ASCII sont souvent source de confusions
ascii_upload_enable=NO
ascii_download_enable=NO
#
# Par securite, on change la banniere
ftpd_banner=Bienvenue sur le serveur Debian Addict
#
# On veut limiter les utilisateurs a leur repertoire
chroot_local_user=YES
chroot_list_enable=NO
#
# Les heures d’enregistrement des fichiers seront affichees a l’heure locale
use_localtime=YES

Une fois le fichier de configuration remplacé, on relance le serveur FTP en tapant en root :
# /etc/init.d/vsftpd restart

A partir de ce moment, les utilisateurs ont accès à leurs répertoires personnels via FTP et leurs actions sont enregistrées dans le fichier /var/log/vsftpd.log.

Il nous reste donc à créer un répertoire commun auquel chacun aura accès. Pour cela, on crée un utilisateur lambda que l’on appellera « commun » [1]. En root, tapez :
# adduser identifiantutilisateur

Le système demande ensuite le mot de passe de l’utilisateur puis différents renseignements qui sont à passer. Ce n’est PAS le mot de passe FTP, juste le mot de passe de l’utilisateur.

NB : Pour connaître les utilisateurs existants, en faisant cat /etc/passwd ou cat /etc/group, cela affiche les utilisateurs et les groupes qui existent dans ces fichiers, à savoir que les commandes getent passwd et getent group affichent en plus les utilisateurs de tous les annuaires connus.

Définition des droits sur le
# chmod -R 755 /home/identifiantutilisateur
# chown identifiantutilisateur:identifiantutilisateur -R /home/identifiantutilisateur

A ce stade, si on essaie de s’identifier avec un utilitaire FTP, le client arrivera à se connecter au serveur mais il proposera une belle erreur 530 vsftpd FAIL LOGIN: Client
Il faut donc continuer et préciser les utilisateurs/mots de passe que l’on veut pour le FTP

Nous allons utiliser une base de données pour les noms et mots de passe des utilisateurs virtuels.

On a besoin d’un utilitaire de base de données qui nous servira à hasher les couples identifiant/mot de passe.

Dans le répertoire /etc/vsftpd/ nous allons créer un fichier login.txt contenant les infos de login, il est formé sous cette forme :


user1
pass1
user2
pass2
user3
pass3


Attention, ici, l’éditeur de Winscp par exemple rajoute une ligne à la fin, même si on n’en a pas l’impression, ce qui affiche le message « db4.6_load: odd number of key/data pairs« , il suffit alors de vérifier en SSH en utilisant la fonction nano par exemple :

nano /etc/vsftpd/login.txt
une fois la dernière ligne vide supprimée s’il y en a une, faites Ctrl+X pour quitter, et confirmer avec un O majuscule puis entrée

Une fois le fichier fait, nous créons la base de données qui serat utilisé par PAM :
Installez db4.6 :
apt-get install db4.6-util
puis hashez les données du fichier login.txt dans un format sécurisé et compréhensible par vsftpd :

db4.6_load -T -t hash -f /etc/vsftpd/login.txt /etc/vsftpd/login.db

On sécurise les fichiers

chmod 600 /etc/vsftpd/login.db
sudo chmod 600 /etc/vsftpd/login.txt

Il faut informer le module PAM, dans le fichier etc/pam.d/vsftpd :

auth required /lib/security/pam_userdb.so db=/etc/vsftpd/login
account required /lib/security/pam_userdb.so db=/etc/vsftpd/login

Et voilà, vous pouvez vous connecter via le port 21 normalement.

Merci pour vos retours !

Sources :
http://www.debianaddict.org/article47.html
http://olange.developpez.com/articles/debian/installation-serveur-dedie/?page=page_5
http://www.cpasdemoi.fr/securisation-ssl-et-utilisateurs-pour-le-serveur-ftp-vsftpd-sur-debian-lenny/
http://doc.fedora-fr.org/wiki/Vsftpd_:_Installation_et_configuration
http://www.developpez.net/forums/d744109/systemes/linux/reseau/vsftpd-serveur-dedie/

ATTENTION : vérifiez bien les droits d’accès autres que SSH aux utilisateurs que vous créez !!
Lire ceci : Autorisations SSH pour les utilisateurs (compatible Debian)
En deux mots :
1. précisez grâce à un AllowUsers monutilisateur1 monutilisateur2 dans /etc/ssh/sshd_config qui est autorisé
2. vous pouvez faire idem avec les groupes (AllowGroups group1 group2)
3. redémarrez ssh avec /etc/init.d/ssh restart
4. Faites des tests !

MySQL est une des bases de données les plus utilisées sur Linux aujourd’hui, et une des problématiques les plus récurrentes est d’exporter sa base pour une raison ou une autre (exports sur d’autres serveurs, sauvegardes,…)

Une bonne commande pour faire cela est mysqldump, Pour faire cela, vous devez utiliser le shell (via putty par exemple) pour vous connecter sur votre serveur dédié ou sur votre poste de travail sous linux. Si vous êtes sur un serveur mutualisé, il faut que vous voyez avec votre hébergeur, pourquoi pas dans votre interface d’administration si vous en avez une.

MySQLDump prépare le script pour (re-)créer les tables et le contenu de celles-ci, prêt à être importé plus tard.

La commande au plus simple :

mysqldump -u [nomUtilisateur] -p [motDePasse] -B [nomBDD] > [fichierSauvegarde].dump

Si vous ne saisissez pas le mot de passe mais laissez -p il vous demandera de donner le mot de passe. Si vous souhaitez éviter de dévoiler le mot de passe dans l’historique, c’est mieux.

Vous pouvez également ajouter une option pour optimiser la requête.

mysqldump –opt -u [nomUtilisateur] -p [nomBDD] > [fichierSauvegarde].dump

Ceci permettra de supprimer les tables (DROP) avant qu’elles ne soient recréées puis remplies de leur contenu.

Pour des raisons évidentes de taille de base de données, il est parfois bien de compresser (gzipper) le fichier extrait :

mysqldump –opt -u [nomUtilisateur] -p [nomBDD] | gzip > [fichierSauvegarde].dump.gz

Le jour où vous souhaitez réimporter votre base, il suffit d’inverser la flèche. (Attention à dézipper le fichier au préalable – gunzip – s’il était gzippé)

mysql [nomBDD] < [fichierSauvegarde].dump

Pour savoir où sont les fichiers : commande pwd pour voir où vous êtes

La documentation Man de MysqlDump avec toutes les options :

http://www.manpagez.com/man/1/mysqldump/

Je viens de tomber sur un petit recueil d’astuces pour optimiser ses requêtes et sa base de données MySQL que j’aimerais partager avec vous.

Tout est ici : http://www.lephpfacile.com/manuel-mysql/mysql-optimization.php#tips

- vérifier les index / créés vs qui devraient exister
- types de tables (MyISAM,…)
- éviter les varchar et blob pour ce qui est régulièrement modifié
- pas forcément utile de scinder les grosses tables en plus petites
-…

Une petite check-list à se faire de temps en temps !

Kettle est un outil d’ETL (Extract, Transform, Load) de la suite BI de Pentaho Data Integration. Son principal intérêt est de récupérer diverses sources dans divers formats, de les traiter, de les transformer, et de former un résultat puis d’exporter dans le format souhaité vers une destination souhaitée.

Tout ceci se fait de façon visuelle en créant des étapes et en éditant le détail de chaque étape. (je sais, ça dépasse.. mais comme ça on peut tout voir )

Visuel de la préparation de scripts avec Kettle

Il est possible de faire des scripts personnalisés sous forme de script java (javascript)

Exemples de sources et exports possibles :

• Bases de données (37 bases de données disponibles dont MySQL, Oracle, SQLite, PostgreSQL, MS Access, MS SQL Server, Sybase, Firebird SQL, AS/400,…)
• Fichiers (XML, TXT, CSV, PSV, TSV ou autres séparateurs, instructions SQL dans fichier,
• Flux SOAP, REST
• Récupération ou envoi depuis ou vers des FTP/SFTP/FTPS/over SSH2
• Possibilité de dézipper ou zipper des fichiers en entrée ou en sortie
• Envoi / récupération depuis ou vers des e-mails / courriels (suivant sensibilité)

Comme les exemples sont souvent plus parlants, je vais vous donner quelques exemples bien pratiques de choses que l’on peut faire avec un ETL :

• récupérer un fichier XML à 10 niveaux de données depuis un FTP, l’aplatir sous forme de tableau, mettre à jour les données dans une table MySQL puis l’exporter sous forme de fichier CSV et l’envoyer par e-mail
• joindre trois fichiers excel (format XLS) et les entrées en base de données en comparant les sources, en dédoublonnant, et en faisant un fichier par type d’erreur possible
• prendre tout simplement un fichier, renommer des colonnes, en rajouter, normaliser la longueur des champs et le nombre de décimales, enlever les espaces vides et réexporter le tout dans un format souhaité

Les scripts réalisés visuellement sont exportables et installables comme tâches planifiées sur un serveur.

Bon, pour tout ça, je vous conseille de télécharger la version Pentaho Data Integration Spoon 4.0 (http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=spoon+4.0)

Je vous mets ici bientôt quelques exemples de scripts que vous puissiez jouer avec.

L’exemple en PHP est ici : PHP : distance en kilomètres, durée et étapes du trajet grâce à Google Maps API Directions

Il était amusant de voir que cette fonctionnalité était possible mais qu’elle était juste refusée au niveau de la requête par Google : si vous lisiez via le navigateur le flux JSON, vous y voyiez des informations intéressantes telles que la distance et l’itinéraire pour aller d’un point A à un point B, qu’on aurait tout à fait pu parser. Mais Google le refusait.

Cette annonce n’a l’air de rien : http://googlegeodevelopers.blogspot.com/2010/05/directions-web-service-arrives-at.html mais c’est une révolution pour ceux qui souhaitent intégrer des calculs de distance, ou faire des PDF avec des itinéraires ou ce genre de choses.

Concrètement, le flux que vous recevez ressemble à ceci :

{
« status »: « OK »,
« routes »: [ {
« summary »: « Massachusetts Ave, Massachusetts 2A W et Lexington Rd »,
« legs »: [ {
« steps »: [ {
« travel_mode »: « DRIVING »,
« start_location »: {
« lat »: 42.3585300,
« lng »: -71.0600700
},
« end_location »: {
« lat »: 42.3580200,
« lng »: -71.0604300
},
« polyline »: {
« points »: « ycpaGl|upLdBfA »,
« levels »: « BB »
},
« duration »: {
« value »: 4,
« text »: « 1 minute »
},
(…)

(http://maps.google.com/maps/api/directions/json?origin=Boston,MA&destination=Concord,MA&waypoints=Charlestown,MA|Lexington,MA&sensor=false
Enjoy !

Source : https://mail.google.com/mail/?hl=fr&shva=1#inbox/128b3a8d28ec3fd6
Autres API qui viennent de sortir : http://www.zorgloob.com/2010-05/google-fait-le-plein-dapi/

Le script PHP permettant de calculer l’itinéraire est ici : PHP : distance en kilomètres, durée et étapes du trajet grâce à Google Maps API Directions

Il est important pour tout responsable technique d’être rapidement informé, malgré lui, d’un changement important dans le trafic, notamment à la hausse.

Google Analytics a mis en bêta un système d’alertes qui permet d’être notifié (uniquement par e-mail pour l’instant) lorsque les conditions de ces alertes sont remplies. il s’agit de définir des critères et de remplir un seuil.

Ce qui permet par exemple de dire « si mon nombre de visiteurs uniques par jour est supérieur à X, me prévenir par e-mail ».

Tout simplement.

Reste à faire évoluer le système en fonction, pourvu qu’il soit agile !