Je rate peut-être un truc, mais je ne trouve pas la demande dénuée de sens....

Clairement, c'est plus un "relou qui change d'avis comme de chemise" qu'un réel PEBCAK... Et encore, il reste à prouver que le PEBCAK n'est pas celui qui a développé un cache sans bouton "réinitialiser le cache".

pas vraiment un relou qui change d'avis, mais plutôt quelqu'un qui ne sait pas comment ça va se comporter à l'avance et qui demande des fonctionnalités au fur et mesure. le problème que je vois ici c'est que tout celà aurait du être prévu à l'avance, lorsque l'étude a été faite, le client aurait du être prévenu du temps d'exécution, et être conseillé pour le cache et le bouton de mise à jour manuelle.

Oui bien sûr, on ne l'a pas prévenu, on n'a rien dit, on n'a rien fait, on lui a fait pousser le cache comme un champignon dans son appli, en mode furtif.

Franchement, vous pensez qu'on a fait comme ça ?

«Je travaillais sur une application qui collectait des informations et affichait un résumé (principalement des compteurs, via un simple « SELECT COUNT(*) ») en page d'accueil.»

Heu, tu vends du temps de calcul ?

Personnellement je comprends le client ; alors, j'ai mis "c'est toi le PEBKAC". En effet, le rôle du chef de projet est de comprendre le besoin client et de mettre en œuvre une solution adaptée. Vous vous doutiez bien que le cache aurait des effets secondaire sur la mise à jour des compteurs en temps réel, il fallait donc proposer une meilleure solution.

Si un count(*) est lent, c'est que vos indexes sont mal fait. Bon... admettons qu'ils étaient bien fait, un simple trigger pour mettre à jour une variable en mémoire aurait été une solution élégante, optimale, efficace, fiable, et simple a déployer.

Bah la demande est légitime, je vois pas vraiment le PEBKAC...

Un détail, je ne suis pas le chef de projet ;)

Et oui on s'en doutait. Oui on lui a dit. Oui il voulait absolument un cache (texto).

Avec un cache de 3 min de recharge, c'est un peu se moquer des gens que d'insister lourdement pour en avoir un, plus le bouton ...
Avant il attendait une seconde de plus, maintenant il spamme le bouton et enchaîne ces secondes à la main, je ne trouve pas ça mieux.

Mais bon, visiblement ce point de vue n'est pas partagé :o

Dans ce cas prenez ça comme un bonux pour lui facturer la mise en place du bouton "Rafraichissement manuel", coût de la semaine de développement : 5000 euros.

Si, c'est juste que le PEBKAC n'est pas très bien raconté. Il aurait fallu mettre tous ces petits détails importants dans le post. :)

je vais résumer pour les mals comprenants
-Etat 1 : pas de cache, état fixé par le cahier des charges rédigés avec client
-Le client demande à passer à l'état 2
-Etat 2 : ajout d'un cache
-Le client trouve que le cache devrait être réactualisé plus fréquemment
-Ajout d'un bouton permettant de simuler l'Etat 1
=> pebkac et perte de temps

C'est pour ça qu'il fallait ajouter un bouton qui ne fait RIEN. Tu gardes l'efficacité du cache tout en offrant une béquille psychologique à l'utilisateur.

Ben Memcache objet en php (PECL) pour faire des variables en application scope. Donc tu mets à jours avec le script qui en modifie le nombre. Ca coûte moins cher qu'une requête sql. Tu peux charger de la base à la première vue.

Aucun intérêt de faire la requête à chaque consultations.

Ce n'est pas en PHP, mais merci pour l'info, c'est toujours bon de se cultiver.

Ben vu comment c'est écrit, c'est le client qui est à l'initiative des demandes d'évo, pas ton équipe qui est force de proposition.

pas exactement :
-état 1, tu appelles une page qui met une plombe à charger
-le client demande un état 2
-état 2, ajout du cache, la page se charge instantanément, mais les valeurs sont comprises entre 0 et 3min
-le client demande un rafraichissement du cache, ce qui permet de voir l'évolution en temps réel

conclusion : un PEBKAC qui n'en est pas un car l'équipe de dev n'est pas capable de fournir une solution qui convient au client.

Plutôt un client difficile vu qu'il n'écoute pas les développeurs.

Le pebkac est clairement du côté de votre équipe si vous n'avez pas été capables d'anticiper les demandes (légitimes) du client.
Et ce n'est pas à vous de décider si l'appli est "mieux" ou pas en l'état, c'est quand même au client de décider, et à vous de l'aiguiller dans le bon sens (ce que vous n'avez a priori pas réussi à faire).

Depuis quand un client est sensé écouter les développeurs ?

Sinon juste pour info, la requête "SELECT COUNT(1) FROM..." est plus performante que la requête "SELECT COUNT(*) FROM...". Après niveau ordre de grandeur je ne sais pas si c'est suffisant dans votre cas.

Pour info aussi, un select count(*) prend un temps fou car il est obligé de parcourir la table séquentiellement. En général, il existe des moyens utilisant les tables système pour faire le même travail beaucoup plus rapidement mais ces moyens dépendent du SGBD utilisé

ah? c'est exactement la même chose. COUNT(1) est plus efficace que sur les anciens sgbd, sinon il est interprété de la même manière que COUNT(*).

Certainement, c'est au client de nous demander une Ferrari à 3L/100 et pour 5000€, livrée en deux jours, et avec le sourire s'il vous plaît.

Au moins un projet que tu n'a spas abandonné :-P
(De rien, c'est gratuit mini :D)

Complètement rien à voir avec le problème.
Le client te demande une page de stats qui rafraichit lorsque tu charges la page, tu dois l'alerter pour lui dire que ça risque de prendre du temps, et que tu peux faire un cache toutes les 3min à la place. Là il ne semble pas y avoir eu ce genre de retour de votre équipe. C'est là que je trouve qu'il y a un problème.
Laisser le client s'apercevoir tout seul que ce qu'il veut ne marche pas, sans l'avoir vu soi même, c'est un manque de professionnalisme.

Vu que vous n'avez pas l'air de savoir lire, cf mon deuxième commentaire de la page.

Je ne vois pas en quoi ton deuxieme message éclaircit la chose ?

"Et oui on s'en doutait. Oui on lui a dit. Oui il voulait absolument un cache (texto)."

Le seul problème que je vois, c'est que ce n'est pas vous qui avez proposé le cache dès le début.

Je comprends tout-à fait le cas de mini pour le vivre au quotidien (pour le contexte : hébergement de sites web à plusieurs millions de pages vues par jour) : dès qu'on commence à mettre en place de la mise en cache de contenu (cache interne au CMS + Varnish + CDN + cache navigateur), forcément, ça se sent au niveau de la charge des Apache / MySQL et de la bande passante consommée. Sauf que, "ooops", forcément, les pages ayant une durée de vie de 3 jours (en cache navigateur), bah forcément, si y'a des mises à jour dessus toutes les 5 minutes, le visiteur ne les voit pas (le visiteur ne connait pas CTRL-F5). Donc le client demande en urgence de repasser la durée de cache à 5 minutes. Sauf que la charge système et la facture de bande passante augmentent aussi, donc rebelote.
Le PEBKAC, c'est le client qui ne veut pas comprendre (et encore moins choisir) que le cache ne peut être qu'un compromis entre la fonctionnalité (fournir une page web mise à jour fréquemment) et les contraintes matérielles. Parce que sinon, on pourrait aussi ajouter 15 serveurs et ça tournerait TRES bien aussi :-D