Notifications

@Nibbler: Concrêtement c'est quoi qui "pèse" sur le serveur autre que la sauvegarde de toutes les boxs ?

@MonsieurCanard: Les notifs qui "pop" ça impliquerait une vérification client<->serveur toutes les x secondes, dont un flux de données plutôt important multiplié par le nombre de clients.

@Vaillant: Il y a moyen de faire ça en push, et donc au final consommer moins de ressourcse que quelqu'un qui va faire F5 toutes les 5 minutes

@Pouki: En push ?

@Vaillant: Oui, plutôt que ce soit le client qui demande toutes les x secondes "hey, tu a du nouveau pour moi ?", c'est le serveur qui envoie automatiquement au client dès qu'il y a eu du nouveau contenu.

@Vaillant: https://fr.wikipedia.org/wiki/Server_push

@Pouki: T'as une solution facile pour mettre ça en place avec du PHP ? Car je vois pas de meilleures solutions que faire des appels AJAX en boucle client -> serveur. C'est ce que font la majorité des sites dailleurs.

Garder une connexion persistente entre le serveur et le client (de chaque utilisateur) c'est inenvisageable.

@Pouki: Justement non, parce que tu vas push à tous les clients connectés au site (avec un onglet qui traine toute la journée) et pas seulement ceux qui vont faire f5.

D'autant que si le feed de l'utilisateur est bien généré en PHP (donc côté serveur - j'ai jamais été vérifié), tu vas donc notifier avec un push, puis regénérer la page comme si tu faisais f5 (impliquant de facto une augmentation de l'utilisation des ressources)

Ce serait différent si tu recevais les datas de toutes les box liées à ton compte avec une génération de la page en JS ensuite via une API en fait (là, la page pourrait se regénérer partiellement avec juste les infos des box créées/modifiées/supprimées).
Mais là ça demande une refonte de toute l'architecture technique du site, et une analyse des performances dans les deux cas afin de voir si une telle refonte vaut vraiment le coup.

Et je parle pas de la complexité engendrée côté serveur (donc augmentation d'utilisation des ressources) pour répondre à la requête "T''as des news ?" là où la génération PHP actuelle bourrine car elle met en place le même algorithme.

Par contre, un système de caching de la page générée et push de nouveautés (juste côté serveur) concernant ce qui touche au g/all ferait gagner des performances puisque tu sers la même page à tous les utilisateurs, donc pas besoin de la regénérer entièrement. (Dans ce cas, le feed du g/all est généré à chaque nouveauté côté serveur, et une copie courante est livrée à chaque requête client - contrairement à ton feed personnel qui, sans optimisation, devrait être regénéré à chacune de tes requêtes)

@MonsieurCanard:
"Concrêtement c'est quoi qui "pèse" sur le serveur autre que la sauvegarde de toutes les boxs ?"

C'est une question de performances processeur du serveur, le plus lourd est de devoir générer la page HTML affichée par ton navigateur, en utilisant le PHP.
La sauvegarde des box elle ne coûte presque rien par rapport à cela, elles sont stockées en base de données, sûrement SQL.

Quand tu te connectes au site et que tu demandes l'affichage de ton feed personnel, le serveur va récupérer tes informations dont les groupes auxquels tu es inscrit, et les box associées.
Ensuite celui-ci va faire sa petite tambouille pour en faire une page HTML que tu peux voir en regardant le code source de la page.

La notion de push implique l'utilisation de Javascript pour la génération de page (c'est à dire que la page HTML fournie par le serveur inclut du code Javascript, qui va alors depuis ton navigateur générer le même code source de ta page).

Cependant, ces calculs sont alors faits par ton navigateur, ce qui explique que les besoins de performances serveur soient allégés, ce calcul étant distribué chez le client.
Ce sont des architectures techniques différentes, avec leurs avantages et inconvénients

ps: C'est bien sûr une explication d'ordre générique, je ne sais pas ce qui tourne sur le serveur, ni quels algorithmes d'optimisation, ceci n'étant pas accessible au client :)

@MonsieurCanard: En poussant un peu, mais de manière simplifiée, dans le cas d'une attaque par déni de service (DDOS), le serveur a tellement de requêtes, et donc de génération de pages, à traiter par rapport à ses capacités qu'il s'en retrouve paralysé.

Et ne fournit alors plus rien à personne.
Je parle d'attaque, mais si les performances serveur ne tiennent plus la charge usuelle (nouveaux utilisateurs etc, mauvaise mise à jour du code serveur qui augmente les besoins de performance par utilisateur, etc), il arrive exactement la même chose.
L'attaque exploite seulement ce fait

@gowap: J'ai pas forcément tout compris mais c'est déjà plus clair, merci de ton explication :)

@MonsieurCanard: Hésite pas,ce sera un plaisir d'éclaircir :)

ah bizarre il me semblait que c'était le cas, pour les notifs de commentaires au moins

@gowap: étrange ce que tu dis, je pensais qu'avec un truc genre websockets ça aurais effectivement pas changé grand chose niveaux perf
et «push implique l'utilisation de Javascript pour la génération de page» je vois ce que tu veux dire mais c'est quand même moyennement vrai, ça t'obliges à utiliser du js pour le truc que veux update oui mais ça s'inclut très bien dans un système avec des pages générées, genre la pour les notifs ce serais ajoutable relativement facilement (pareil je connais pas le code donc je dis ça un peu au pif)

@etpuismerde: Oui bien vu :)
Pour les commentaires, c'est bien le cas, mais ça arrive pas aussi souvent qu'une box qui pop ou modifiée sur ton feed, et c'est au final juste un tout ptit changement dans le header. On est loin de toutes les datas à retrieve dans le cas du feed de box.
J'irai d'ailleurs revoir les websockets, j'ai encore jamais trop touché, c'est lointain pour moi

Par contre, pour la génération, ça s'inclut en effet très bien, mais il faut que l'architecture soit prévue pour ça, et je crois pas que ce soit le cas de CB. (Je veux dire aussi bien l'architecture de l'affichage du front-end, mais aussi la façon dont les données du feed sont transmises, donc le back-end).
Pour être plus clair, dans le cas actuel supposé (only PHP), ton webservice dit en gros : "File moi la page HTML complète!".

Tandis que dans le cas dynamique, tu requêtes et reçois d'abord la page HTML, qui va ensuite interroger le serveur sur les données à afficher via des appels Ajax en JS. Et ensuite ton JS, forme la page à partir de ces données.

Un tel changement de paradigme demanderait beaucoup de taff, avec tous les bugs qu'une migration impliquerait. Et comme je disais, même pas sûr que les gains en performances justifient la migration. (Tu gagnes au final le temps processeur de création de la page PHP, car tu files la même la page HTML à tout le monde, mais tu introduis de la complexité au niveau du Web service de récupération des données, ainsi que des problématiques de sécurité d'accès)

J'sais pas si jsuis très clair ^^

@gowap: c'est sur ce serait du taf
et effectivement non les notifs commentaires pop pas tout seuls faut refresh

@etpuismerde: Bien vu, il me semblait qu'elles popaient à la volée comme tu le disais aussi, you really got me !