Performance de Zend_ACL

Suite à la suggestion de Matt O'Phinney, j'ai fait des tests de benchmark avec XDebug sur le composant Zend_ACL (Access Control List) qui permet de gérer des droits d'accès sous forme de rôles, ressources et privilèges. J'avais promis de publier les résultats alors les voici.

Pour réaliser mes tests, j'ai réutilisé un vieil exemple que j'avais publié en novembre 2008 alors que j'expliqueais le fonctionnement de Zend_ACL. Ce test n'a pas été mesuré sur un serveur mais sur mon vieux PC laboratoire Windows XP Home Edition SP3 avec processeur AMD Athlon 64 X2 Dual Core 4200+ avec 3 Gb de RAM (en d'autres mots, il date d'environ 4 ans).

Vous remarquerez dans l'exemple que je déclare :

• 1 instance de Zend_ACL
  
• 3 rôles sous forme d'objects Zend_Acl_Role (Programmeurs, Designers et Administrateurs Systèmes)
• 7 ressources distinctes avec Zend_Acl_Resource
  
• Plusieurs types de privilèges par ressource sont initialisés avec la méthode allow() (j'ai fait exprès de ne pas réutiliser les exemples classiques de CRUD et je me suis rendu compte en me relisant que j'avais réussi à placer une bonne joke dans le code. Même si vous n'êtes pas programmeur, vous serez en mesure de la trouver)
  

Ensuite, la méthode isAllowed() permet de vérifier si l'accès est autorisé ou non sur la ressource pour le privilège demandé. C'est quand même 11 instances d'objets et 17 fonctions d'initialisation qui sont appellées uniquement pour gérer les droits d'accès, et ce avant même de vérifier le premier privilège. À première vue, ça pouvait sembler gourmand, dépendamment de l'implémentation interne des objets (la réponse de M.O'Phinney m'a rassuré mais je voulais que ça soit mesurable).

Selon la configuration exacte présentée dans l'exemple, si j'isole uniquement les composants ACL, le temps d'exécution final avec une seule vérification est de 0,0021 seconde. En effet, très rapide.

Comme l'initialisation se fait une fois pour la page, c'est le nombre de requêtes à isAllowed() qui fera varier le temps. Si je l'appelle en boucle :

Itérations   Secondes
1            0,0021
10           0,0048
100          0,0324
1000         0,2965

À 1000 vérifications, on parle d'un peu moins que 1/3 de seconde. C'est assez rapide même si ça commence à paraître un peu plus à mesure qu'on augmente le volume (tout à fait normal). Mais soyons honnête : dans la plupart des cas d'applications web, 10 vérifications ou moins seront nécessaires. Dans le pire des cas, moins de 100 par page. À moins d'une utilisation abusive du composant, le coût de temps versus le gain de performance ne justifie pas le temps qui serait nécessaire pour tenter de faire mieux.

Rarement j'ai vu une implémentation des droits aussi facile à lire et à maintenir. ACL offre une granularité qui permet de changer complètement les droits, les rôles et les ressources pour faire une toute nouvelle combinaison. Les possibilités sont quasi infinies. J'insiste sur le fait qu'on peut indiquer textuellement par un verbe toute forme d'action possible sur une ressource et pas seulement le droit de Read, Insert, Update, Delete.

La plupart du temps, les autres systèmes de gestion de droits se contentent de gérer la relation entre un module et son droit d'accès binaire (accès à tout ou rien). Rien n'est clairement défini au niveau du rôle (niveau d'utilisateur), l'héritage de droits et les privilèges. C'est clair que si vous développez un système qui offre moins de possibilités, vous gagnerez légèrement en performance (c'est fort probable que le gain en PHP se transformera en perte à un autre niveau, comme la base de données par exemple). C'est quand même un beau défi à relever. Mais avant de commencer, posez-vous les questions suivantes :

• Est-ce que ma solution sera aussi flexible ?
• Sera-t-elle aussi performante ?
• Est-ce que je ferai mieux en terme d'implémentation et de lisibilité ?
• Combien de temps cela me prendra pour satisfaire mon ego ?

C'est le genre de choix que tout professionnel en programmation est confronté à tous les jours. Assurez-vous seulement de faire le bon.