Reprise du message précédent :

 
Le fait que le Hamas soit effectivement un groupe de résistance et qu'il soit un groupe terroriste ne sont pas mutuellement exclusifs (les atermoiements de LFI sur la qualification terroriste des actes du Hamas est parfaitement navrante d'ailleurs).
Le Hamas n'est pas apparu spontanément par fluctuation du vide quantique, mais c'est une conséquence directe de l'occupation par Israël de territoires palestiniens.

 
Tu ne voudrais quand même pas jeter l'opprobre sur l'armée la plus morale du monde, qui est tellement morale qu'elle emploie le contre-espionnage israélien pour faire pression sur les juges de la CPI pour éviter des inculpations depuis 9ans alors que tout le monde sait que le conflit israélo-palestinien a commencé le 7 octobre avec l'attaque du Hamas

Ah non je pense que presque tout le monde en Israël est d'accord pour dire que cela a commencé en 48 par des attaques arabes
Le 7 octobre ca a juste permis à Bibi d'exprimer tout son potentiel pour le classement de chef d'état le plus incompétent du XXIème siècle, ce qui est particulièrement notable car il évolue, pour le moment, dans une démocratie.

j'ai du mal avec dion je sais jamais s'il est premier ou second degré

merci !

Les plaies c'est au 3ème degré

Les recruteurs ... ça faisait longtemps
 

On peut parler dev ?
 
J'aimerai quelques conseils pour la problématique suivante : code basique en php/mysql, pour faire un genre d'application d'agenda en ligne.
Il y a des plages récurrentes (disponibilités / indisponibilités), et là dedans des rendez-vous.
forcément pour l'affichage (c'est une vue par semaine), ça fait des boucles dans les boucles, des tests dans tous les sens, et plus il y a de rdv plus les perfs s'effondrent.
J'ai optimisé les requêtes autant que je pouvais (index, union...) mais il y a aussi de l'incompressible. Par exemple sur les récurrences (plage de disponibilité de telle heure à telle heure tous les lundi par ex) ça dépasse la centaine de ms dès qu'il y en a 7 ou 8, donc  pour quelqu'un qui a une semaine chargée j'aboutis à un temps total de génération de page de l'ordre de 2 secondes.  
Certes le serveur sur lequel ça tourne est une bouse (atom n2800) mais toujours est-il que je réfléchis à essayer de faire de la mise en cache un peu plus intelligente.
Le problème est donc qu'à tout moment un rendez-vous peut être ajouté par un élément extérieur à cet affichage (d'autres personnes via une autre source viennent ajouter un rdv dans l'agenda de l'utilisateur).
 
Donc ma question c'est, dans quelle direction aller pour essayer de faire du cache ?
Une idée comme ça qui m'est venue, c'est un genre de flag "date derniere modif" qui serait mis à jour dès qu'une action touche à l'agenda et me baser là dessus pour stocker par exemple l'intégralité du html généré pour l'agenda d'une semaine donnée. Si la date de modif est plus récente que celle associée au cache hop je regénère.
En même temps j'ai l'impression de réinventer la roue.
Des idées ? C'est du PHP de papa/maman, 1 clic 1 page, génération de tout en html direct, très peu de JS...
 
Sur le même principe, sur chaque page j'ai un petit encart qui affiche (basé sur l'heure courante) le rendez-vous actuel s'il existe et les 2 suivants. Comme ça peut changer à chaque rafraichissement de page, ça veut dire qu'il faut que je refasse la requête (un peu costaud, avec un left join...) et comme il y a NOW() dedans, 0 mise en cache...

Puisqu'on parlait nostalgie et culture récemment, petit article du WaPo qui dissèque ça aux USA

https://www.washingtonpost.com/busi [...] ding-data/

 
Tu as une manière fiable de détecter les modifs pour invalider ton cache? Perso je mettrais du cache sur le résultat des requêtes, pas sur le html généré. Une approche qui marche bien c'est d'avoir du cache avec des tags sur tes éléments, qui te permettent lors de modifs d'aller invalider tous les éléments impactés par les tags concernés par les modifs en cours.
Et quitte à pas réinventer la roue tu dois pouvoir utiliser directement symfony/cache : https://symfony.com/doc/current/components/cache.html

 
Alors pour l'instant je n'ai rien en place, donc tout est possible.
Je pensais à 1 niveau de cache, genre dès qu'il y a la moindre modif de rendez-vous ça invalide tout l'agenda.
Ca pourrait s'affiner à la semaine, mais ça devient plus complexe, notamment à cause des récurrence (typiquement une zone d'indisponibilité c'est comme un rendez-vous mais qui aurait été créé il y a 2 ans, pour le lundi de 12 à 14h avec une récurrence "toutes les 1 semaine" ), donc une modif d'un rdv récurrent d'il y a 2 ans peut impacter la semaine courante.
Après la mise en cache à proprement parler, je ne sais pas trop la forme que ça pourrait prendre (memcached, mysql, fichier...), mais l'idée du html c'est de zapper le maximum de calculs et d'être au plus proche du résultat. Comme je le disais, pour le calcul des récurrences (est-ce que ce rdv d'il y a 2 ans impacte la semaine courante), j'utilise une librairie en php, et donc ce truc est lent (et pourtant c'est une version optimisée d'une autre lib que j'utilisais avant). Donc si je ne cache que les requêtes sql, je me coupe d'une partie d'optimisation.
J'ai aussi constaté que par exemple sur un agenda chargé, j'ai 1500ms d'écoulés pour faire tous mes calculs et appeler mon template d'affichage (smarty), et au final la page prend 2150ms. Donc la génération de tout le html (plein de boucles et de div dans tous les sens) ça prend visiblement beaucoup de temps (genre ça peut générer 250 div sans souci).
Bref si je pouvais court-circuiter le plus gros de tout ça ça me semble le plus efficace non ?

Question à 100 balles et peut être que c'est une très mauvaise idée (jamais vraiment eu à implémenter un agenda), tu pourrais pas juste dénormaliser ton bousin ?
 
Genre si t'as un event qui se répète tous les lundi du mois, bin au moment de la création tu vas générer tous les lundis sur les N prochaines années un event "normal" qui correspond à ça et basta. Tu gardes un trace que ces events sont issues d'une récurrence (pour pouvoir les edit/supprimer tous d'un coup si besoin).  
Même pour les 5 prochaines années, 10 events recurrents par semaine, ça fait 2500 lignes dans ta BDD, autant dire rien du tout aujourd'hui si t'as pas 1M d'users.
 
Du coup au moment de l'affichage t'as plus que à gérer que des event "normaux" ce qui me parait beaucoup plus simple.
Note que ça part du principe que tu vas avoir beaucoup plus de lectures que d'écritures sur ton agenda, ce qui a priori me parait pas déconnant.

Ca me semble une usine à gaz à maintenir, genre régulièrement il faut voir s'il ne faut pas "prolonger" la récurrence en ajoutant des nouveaux évènements, tout en les maintenant liés à l'évènement original, éventuellement supprimer les anciens si on veut faire un peu de place...
Mais l'idée est intéressante. Bon après à première vue ça me permettrait de gagner 100-150ms sur 2 secondes... il y a encore de la marge.
 
Tu as raison sur le côté ratio lecture/écriture. Ca doit être de l'ordre de 100 ou 1000 lectures pour 1 écriture.

ca parait brutal, mais difficile de savoir ce qui est pertinent pour ton besoin
 

 
...mais ton cache peut avoir plusieurs usages, et changer une virgule dans ta mise en page ne shoote pas le cache pour rien.
 

 
Pour le coup si tu fais du smarty (fichtre, ça existe encore?), dans mes souvenirs il y a des méthodes de cache prévues si mes souvenirs sont bons...mais je sais pas si tu peux invalider les choses finement avec ça.

IME c’est infiniment plus simple que des événements virtuels qui sont une merde noire, d’autant plus qu’un cas fréquent est de vouloir modifier certaines récurrences (genre t’as un 1:1 à 10h toutes les semaines mais une semaine c’est retardé d’1h pq ton boss a un empêchement ou quoi), ou toutes après une certaine date.  

À noter aussi l’élément fun du planning / calendaring: tu peux pas bosser en UTC

this
 

D'accord avec Mask et Flo.
 
Tu appliques ton algo compliqué (parce que les cas de reccurence, genre "tous les premiers lundis du mois mais décalé au mardi si le lundi est ferié", c'est compliqué), une seule fois à la création au lieu de le faire à chaque consultation. Tu va gagner du temps.  
 
(et après rien ne t'oblige non plus à stocker chaque événement dans l'agenda de chaque personne : tu peux avoir des événements reccurents à part, et une table de jointure pour y ajouter des participants, plus une table d'occurences.
 
Les occurences sont calculées à l'avance sur une période donnée (genre t'as un trigger qui te calcule ça sur les X prochaines semaines/mois/années),  
 
Quand un participant veut afficher son agenda sur une semaine, tu fais un join entre ses événements reccurents et les occurences filtrées sur la période.
 

La prolongation, c'est un cron a faire une fois tous les X semaines/mois (en fonction de jusque quand dans le future tu génères les events) et qui appelle le même bout de code que quand une nouvelle récurrence est ajoutée, modulo le début et la fin de jusqu’à quand tu génères tes events récurrents (mais donc t'as déjà normalement 80% du code en commun).
Le lien a l'event "original", tu dois de toutes manières l'avoir vu que tu veux pas forcer les users a delete les 2000+ events des 10 prochaines années s'ils suppriment une récurrence
 
Et comme dit masklinn, c'est a mon avis infiniment plus simple pour gérer les cas particuliers. Autre cas par exemple, l'event toutes les semaines que tu veux mettre en pause pendant 2 semaines de vacances ? Tu fais comment avec des event virtuels sans que ça devienne usine a gaz ? Avec la denormalisation, t'as juste a delete les 2 events crées pour cette semaine.
 
Note aussi que l'invalidation de cache, c'est notoirement un problème pas simple en informatique en général: tu sembles partir sur une invalidation totale a chaque écriture, mais pas sur que cette solution simple tienne dans la durée. Et si si ca se complexifie un peu, je pense que ca deviendra rapidement plus complexe que la denormalisation.
 
 
 
Après j'ai peut être mal compris ton problème de performance initial, parce que j'ai du mal a voir comment afficher sur une semaine même 100+ events pourraient prendre 1.5 sec. Si t'as que des events "standards" (et pas virtuels avec donc l'algo complexe qui va avec derrière) avec un jour, une date et heure de fin, générer 100+ divs bien places ça devrait pas prendre autant de temps.

Pour les suppressions ponctuelles, j'ai prévu le cas, ça pose la question de ce qu'on veut faire (tout supprimer, supprimer que cette occurrence, supprimer celle là et toutes les suivantes), et en effet la suppression ponctuelle = modif de date de fin de l'ancienne occurrence + création d'une nouvelle. Mais ça marche.
 
Bon je viens de brute forcer le calcul des récurrences  ($data c'est ce qui vient des rdv récurrents en bdd) :

Comme ça ça génère une date de début au plus proche de la plage de l'agenda à afficher.
Vous apprécierez le mélange franglais, et encore je vous épargne le bordel des variables avec des underscores, le camelCase, ...
 
En tout cas ça a bien réduit le temps de calcul. En fait j'ai 2 endroits où ça utilise ce système, donc c'est sur 2x 150ms que je peux gratter. Edit : en pratique la 2e utilisation était encore pire que la premère, donc il y a plus à gratter encore.

Merci pour les autres réponses.
Mes récurrences sont simples : l'utilisateur créé une pause déjeuner tous les lundis par exemple, donc le jour où il s'en est occupé, imaginons le 1er janvier 2020, il a mis lundi de 12 à 14 c'est indispo, récurrence tous les 1 semaine (ou 7 jours s'il préfère) et basta.
Donc pour afficher cette plage la 1ère semaine de mai 2024, il faut que le calculateur PHP-RRULE calcule toutes les récurrences existantes depuis le 1er janvier 2020, donc le 7 janvier 2020, le 14 janvier 2020... donc plus le temps passe, plus ce truc prend du temps.
 
Pour l'idée de crééer autant d'évents physiquements en bdd, ok, pourquoi pas, je garde ça dans un coin de ma tête. Dans l'immédiat, mon petit hack a déjà bien calmé le problème, faut que je m'attaque à la suite, comment je passe de 300-350ms (vs quasi 1 seconde au départ, en fait ça a carrément mieux marché que prévu mon hack) pour tout calculer, à 800-900 ms en fin de page (après avoir généré le html.

J'ai tout de suite pensé à https://zachholman.com/talk/utc-is- [...] ing-events
Bon courage

lol c'est tout à fait ça... enfin quand j'ai codé le truc des récurrences il y a une dizaine d'années.
Il y a un truc relou en développement : programmer avec les dates. Mais quand tu ajoutes la récurrence, ça n'est plus juste pénible, ça devient un cauchemar.
D'où le fait que j'avais rapidement délégué le gros du truc à php-rrule, qui utilise le format évoqué dans l'article ("daily","weekly"...)
Ça marche plutôt très bien, sauf en terme de performances quand la date courante s'éloigne de la date de création.
 
Bon sinon j'ai fait un petit tour de mon code de template html (oui smarty ça existe encore, surtout parce que c'est une vieille appli codée au départ en 2005). Il y avait énormément de "vide" généré dans le template, mais tout compacter (il y a un tag {strip} pour ça, n'a pas changé grand chose. Certes le html passe de genre 20 000 lignes à 500, mais en perfs pures ça ne change rien.

Bah non, c’est encore plus de travail, c’est pas envoyer le html qui coûte généralement, et il est peu probable qu’un éventuel compresseur gzip soit plus lent que le php.

Ce que je voulais dire c'est qu'on pourrait imaginer que manipuler un objet "template" de 20 000 lignes ça pouvait ralentir le binz, mais même en compactant ça n'a rien changé.
Sachant qu'on peut en effet imaginer que l'usage de {strip} rajouter du travail à php.
Après c'est quand même plus propre: )

https://www.service-public.fr/parti [...] roits/F987
 
Il y a des experts en indemnités de licenciement ici ?  
 
Visiblement le montant de l'indemnité se calcule assez simplement en fonction du salaire brut lors de la dernière année, et après ya pas mal d'exonérations (impôts, csg) mais du coup j'ai du mal à savoir ce qu'on touche à la fin   J'imagine que c'est proche du montant brut du coup.

Si tu fais que le balader c’est un gros buffer derrière un pointeur, la taille du buffer joue pas vraiment si tu rajoutes pas du post-processing supplémentaire.

Pourquoi tu ne décales pas la date de création à une date liée à la période que tu affiches (idem pour la date de fin) ?
Visiblement la lib php-rrule se vante d'être rapide. Donc je penche pour une implémentation de ta part perfectible
T'as passé un coup de profiler type Blackfire sur ton code ?

Je comprends pas trop ta problématique, si tu utilises le format la RFC  RRULE avec des sets, ça devrait rouler tout seul ?
 
https://github.com/rlanvin/php-rrule/wiki/RSet

Y a des vieux pas trop rouillés qui se sont mis au Rust ?
 
Ca m'a l'air un peu compliqué et le curseur est pas trop évident à mettre entre se hazarder dans les recoins un peu sombres (et même pas forcément stables) ou bien faire confiance aux composants dispos au risque de choisir des trucs pas forcément adaptés à son besoin.

Ya pas à dire, on a beau le savoir depuis des années et recevoir fréquemment des rappels, on ne peux qu'être admiratif devant ce savoir faire unique au monde  

Oui.

Bon ben Paul a eu son troisième cycle de conservatoire avec mention très bien a l'unanimité du jury, plus les félicitations.

Ça consistait à monter entièrement un spectacle avec sa promo (14 ados de 15 à 17 ans).

Ça c'est fait, demain c'est parcoursup.

Ça permet à tout le monde de de-culpabiliser un peu

 
J’ai essayé.
 
C’est très intéressant pour moi qui ait jamais fait de langage bas niveau, ça oblige à se poser des questions que je me pose pas normalement en Python.
Le langage est bien foutu, par contre il est psychorigide (c’est aussi ce qui fait sa force). Le dicton “si ça compile c’est que ça marche” est très vrai.
 
Pourquoi tu veux te mettre à Rust ?

 
nous le nôtre il nous a fait des cœurs avec les doigts sur la scène aujourd'hui
bon ça l'a tellement occupé qu'il a quasiment fait que ça

Je ne connais pas ces technologies, c'est grave ?
 
Edit : effectivement j'ai jamais regardé Google Cloud

Félicitations  

Dans les trucs qui m'intéressent (web et data processing) l'écosystème me semble assez robuste bien que parfois un peu immature.

J'étais dans une équipe avec des gros jobs distribués où Spark est vraiment dur à battre, mais là les pipelines sont plus raisonnables et j'espère avoir l'occasion de récrire certains composants, mes juniors sont motivés en tout cas.

 
Alors si je peux te rassurer, c’est exactement pareil en interne. A tel point qu’il y a un meme interne qui représente une autoroute qui se sépare avec d’un côté deprecated, et de l’autre “not ready yet” qu’on sort chaque fois que ça arrive.
 
J’ai vécu ça de toute les manières : en tant que client B2B, B2C (perso), en tant que consultant technique sales qui se fait poudrer par un client que ça amuse moyen, et même côté Eng quand ça déprécie des trucs qui marchent pour les remplacer par des trucs pas secs.
 
Vous reprendrez bien un peu de colle avec votre pizza ?

 
Feloches.
 
Il est dans un conservatoire national de région ? Il va tenter le sup de Paris et/ou de Lyon ?

Bravo.
 
Parcoursup où comment remplacer un outil (APB) qui avait le bon algo mais qui n'a pas été expliqué aux parents par un truc moins bon mais qu'il comprennent : https://www.youtube.com/watch?v=dO1pLi2Dedw