Displaying posts with tag: Optimisation (reset)
Sortie de MariaDB 5.5.39 : Analyse des améliorations

I – Quoi de neuf dans MariaDB 5.5.39 ?

Avec MariaDB 5.5.39, les améliorations principales listées par la release notes sont assez succinctes :

  • Mise à jour de  XtraDB en utilisant la version incluse dans Percona Server en version 5.5.38-35.2
  • La variable système timed_mutexes a été dépréciée et n’a plus aucun effet
  • TokuDB a été mis à jour en version 7.1.7

Rien de bien excitant donc, et pourtant pas mal d’améliorations de …

[Lire plus]
Quel impact vos performances applicatives ont-elles sur vos coûts homme?

I – Le coût homme, une variable souvent oubliée

Lorsqu’un site internet tombe en panne (downtime), on pense tout de suite au coût associé à la perte de revenu (particulièrement dans le cas d’un site e-commerce).

Pourtant cette panne a également un coût humain qui ne doit pas être négligé. Il est donc important de pouvoir évaluer son impact.

 

II – Quels sont les points à prendre en considération ?

 

A- Le nombre d’employés qui sont dans l’incapacité totale de travailler :

Par exemple, pendant que votre site de E-commerce n’est plus disponible, les équipes chargées de la gestion des catalogues ainsi que celles en charge des commandes et des livraisons ne peuvent plus travailler.

Utilisez la formule suivante :

 

[Lire plus]
Sortie de MariaDB 10.0.12 : Analyse des améliorations

I – Des nouvelles fonctionnalités rajoutées en douce ?

Jusqu’à maintenant les différentes versions GA (Generaly Available) stable n’introduisaient pas de nouvelles fonctionnalités dans MariaDB.

 

Il semblerait que la version 10.0.12 soit une exception à cette règle, car elle comporte une nouvelle fonctionnalité qui n’est pas visible dans les Release Notes., en plus des optimisations de performances que nous allons analyser avec attention.

 

II – Analyse des petites surprises offertes par MariaDB 10.0.12

 

1) Arrivée des fonctions INET6_ATON() et INET6_NTOA() …

[Lire plus]
Comment améliorer les performances de vos applications PHP / MySQL ?

I – Les performances Front-End :

CAUSES DES MAUVAISES PERFORMANCES :

Les causes des problèmes de performances front sont connues et bien maitrisées. Les plus significatives sont :

  • taille de vos pages et de des éléments qu’elles contiennent
  • nombre d’éléments chargés
  • ordre de chargement des éléments

 

SOLUTION EXISTANTES :

Il existe de nombreux outils permettant d’analyser et d’améliorer la performance « perçue » par vos utilisateurs. Le plus connu est probablement Google Pagespeed qui vous fourni une analyse de vos pages, et la liste des points à …

[Lire plus]
MySQL est-il WebScale ?

I – WebScale, ca veut dire quoi ?

WebScale est un terme à la mode que l’on rencontre de plus en plus fréquemment.

On entend par exemple que Mongo DB est WebScale. En pratique, WebScale signifie simplement qu’une application (un gestionnaire de base de donnée par exemple) est conçue pour « scaler » facilement, c’est à dire supporter plus de charge et de trafic en augmentant par exemple la puissance CPU, le nombre de machine etc…

Dans le cas de MySQL, les développements de ces dernières années ont été beaucoup centrés sur l’amélioration de la « scalabilité » comme nous …

[Lire plus]
Doit-on désactiver ou non le query cache de MySQL ?

I – Qu’est ce que le query cache

Le query cache de MySQL a été introduit à partir de la version 4.0 de MySQL. Son principe de fonctionnement est simple : c’est une table de hash géante qui associe des requêtes SQL brutes à un ensemble de résultats.

Cela signifie que si vous rajoutez un espace ou changer une majuscule à votre requête SQL, elle sera différente du point de vue du query cache.

Cette approche simple signifie aussi qu’à la moindre modification / écriture dans une table, il faut que toutes les entrées du query cache concernant la table en question soient invalidées.

Dans des applications qui utilisent de la lecture de façon intensive, sans beaucoup d’écriture, …

[Lire plus]
Choisir le système de fichier optimal pour InnoDB

I – Pourquoi le système de fichier est important

InnoDB a besoin à la fois de bonnes performances en lectures et écritures aléatoires, mais aussi séquentielles.

En effet, pour essayer de garder des performances optimales, InnoDB a le système de fonctionnement suivant : il écrit dans ses fichiers de log (ib_logfile0 / ib_logfile1) de façon séquentielle, et réalise de façon régulière du « checkpointing » qui consiste à écrire les pages modifiées du buffer pool sur le disque.

Cela peut entrainer …

[Lire plus]
MariaDB 10.1 est maintenant sur GitHub

I – Que permet de faire GitHub ?

GitHub est un service d’hébergement du code source et de gestion de projet, basé sur Git. Il permet à la communauté de voir très facilement toutes les modifications effectuées sur un projet, mais aussi de créer ses propres branches du projet, qui peuvent être réintégrées sur simple demande.

C’est donc un très bon moyen de faciliter la participation de la communauté opensource à un projet.

 

II – Pourquoi c’est une bonne chose pour MariaDB

L’interface de GitHub facilite grandement le suivi des modifications effectuées sur le code, et l’interaction avec les équipes de MariaDB au fil du développement.

[Lire plus]
Sortie de MariaDB 10.0.11 : Analyse des correctifs

I – Pas de gros changements à l’horizon ?

Les mises à jour mineures (10.0.9, 10.0.10, 10.0.11) sur une version GA (Generaly Available) stable ne doivent pas introduire de nouvelles fonctionnalités, et se contentent de corriger les bugs découverts dans les versions précédentes.

Chez Codizy, nous sommes très attentifs à ce qui touche aux performances de MySQL et ses forks, nous analysons avec attention les modifications apportées qui pourraient avoir un impact sur les performances.

Cette version 10.0.11 en comporte quelques unes qui ne sont pas visibles directement dans les Release Notes.

 

II – Analyse des changements les plus significatifs

Les Release Notes …

[Lire plus]
MariaDB 10 : Zoom sur les statistiques de tables

I – Les statistiques de tables, pour quoi faire ?

Lorsque vous exécutez une requête SQL qui utilise un index, fait une jointure, ou d’autre opération complexe, MySQL va lire les statistiques lié aux index de ses tables, qui vont lui permettre de choisir le plan d’exécution optimal.

Pour InnoDB par exemple, ce comportement est contrôlé par les variables de type innodb_stats_% :

show variables LIKE 'Innodb_stats_%'; 
+--------------------------------------+-------------+
| Variable_name                        | Value       |
+--------------------------------------+-------------+
| innodb_stats_auto_recalc             | ON          |
| innodb_stats_method                  | nulls_equal |
| innodb_stats_on_metadata             | OFF         |
| …
[Lire plus]