Note : le problème des lecteur RSS en PHP (et une possible solution)
dimanche 13 septembre 2015 à 16:27Un des problèmes des lecteurs RSS en PHP, et la raison pour laquelle j’utilise le mien en local et non sur mon site (même ça m’empêche de pouvoir lire mes flux en dehors de chez moi — chose qui ne me gène pas), c’est à cause de la latence des requêtes.
Une requête réseau, c’est lent : on a parfois largement le temps de lire un autre post (ou au moins cliquer sur "marquer comme lu") pendant que la réponse à la requête précédente nous revient.
Dans le cas de Blogotext, ceci génère une erreur : BT a besoin de la réponse précédente pour lancer la suivante. La raison à cela est la protection contre la faille CSRF : j’envoie un "jeton" unique à chaque requête, et la réponse m’en donne un nouveau (les jetons sont à usage unique).
Avec un lecteur RSS, on a ainsi beaucoup plus de requêtes réseau : à chaque fois qu’on marque un élément comme lu, en fait, ce qui dans une liste de sites suivis comme la mienne, représente ~300 posts par jour.
Si je n’ai pas vu d’erreurs sur les autres lecteurs RSS (j’ai pas regardé comment se passait la gestion des jetons de validation, non plus, mais si ces derniers ne font pas d’allers-retours entre serveur et navigateur à chaque requête, alors ils ne sont pas uniques et donc pas sécurisés au maximum), j’ai vu le problème de latence réseau sur chacun d’entre eux (et c’est vraiment quelque chose de chiant).
La solution à ça et que j’essaye d’implémenter actuellement, c’est de tenir (côté navigateur) une liste des éléments lus (en JS), et de n’envoyer la requête au serveur qu’une fois que la liste atteint une certaine longueur (10 éléments) : la liste des 10 éléments lus est envoyée au serveur en une seule fois. On divise ainsi le nombre de requêtes réseau par 10 (et le nombre de requêtes SQL également, du coup).
Une autre façon de faire serait de patienter un certain temps, et d’envoyer les requêtes toutes les X minutes, plutôt que tous les X éléments lus.
Bien-sûr, si je ferme mon onglet et qu’il reste moins de 10 éléments dans la liste côté navigateur, il faut envoyer une dernière requête (avec le JS "onUnload", par exemple).
Bref, ceci est juste une idée pour ceux qui veulent faire ou qui codent un lecteur RSS (ou autre chose qui demande beaucoup de ressources réseau) en PHP et hébergé sur un serveur distant, et qui veulent améliorer l’ensemble au niveau de l’utilisation.
Une requête réseau, c’est lent : on a parfois largement le temps de lire un autre post (ou au moins cliquer sur "marquer comme lu") pendant que la réponse à la requête précédente nous revient.
Dans le cas de Blogotext, ceci génère une erreur : BT a besoin de la réponse précédente pour lancer la suivante. La raison à cela est la protection contre la faille CSRF : j’envoie un "jeton" unique à chaque requête, et la réponse m’en donne un nouveau (les jetons sont à usage unique).
Avec un lecteur RSS, on a ainsi beaucoup plus de requêtes réseau : à chaque fois qu’on marque un élément comme lu, en fait, ce qui dans une liste de sites suivis comme la mienne, représente ~300 posts par jour.
Si je n’ai pas vu d’erreurs sur les autres lecteurs RSS (j’ai pas regardé comment se passait la gestion des jetons de validation, non plus, mais si ces derniers ne font pas d’allers-retours entre serveur et navigateur à chaque requête, alors ils ne sont pas uniques et donc pas sécurisés au maximum), j’ai vu le problème de latence réseau sur chacun d’entre eux (et c’est vraiment quelque chose de chiant).
La solution à ça et que j’essaye d’implémenter actuellement, c’est de tenir (côté navigateur) une liste des éléments lus (en JS), et de n’envoyer la requête au serveur qu’une fois que la liste atteint une certaine longueur (10 éléments) : la liste des 10 éléments lus est envoyée au serveur en une seule fois. On divise ainsi le nombre de requêtes réseau par 10 (et le nombre de requêtes SQL également, du coup).
Une autre façon de faire serait de patienter un certain temps, et d’envoyer les requêtes toutes les X minutes, plutôt que tous les X éléments lus.
Bien-sûr, si je ferme mon onglet et qu’il reste moins de 10 éléments dans la liste côté navigateur, il faut envoyer une dernière requête (avec le JS "onUnload", par exemple).
Bref, ceci est juste une idée pour ceux qui veulent faire ou qui codent un lecteur RSS (ou autre chose qui demande beaucoup de ressources réseau) en PHP et hébergé sur un serveur distant, et qui veulent améliorer l’ensemble au niveau de l’utilisation.