Pages : 1
#1 Le 22/09/2024, à 07:50
- Barthandelous
[APACHE] Optimisation des logs et du cache.
Bonjour !
Je suis doté d'un Raspberry Pi 5 (tournant exclusivement sur SSD !) et d'un serveur dédié chez OVH.
Le premier tourne en tant que préproduction, et le second en tant que production pour des projets personnels.
Ces projets utilisent quasiment exclusivement la technologie AJAX (via JQuery) car ce sont des projets demandant d'obtenir de façon constantes des données du serveur (API Youtube pour permettre aux utilisateurs de regarder des vidéos ensemble, chatrooms, et même des jeux par navigateur, RPG Tour par tour).
Ces projets utilisent aussi de (très) nombreuses banques d'images car il y a un très gros aspect roleplay.
Ces deux points me posent cependant soucis.
Le premier point me pose soucis car cela fait de nombreux appels et donc des logs qui grimpent à vue d'oeil.
Le second point me pose soucis car les images sont statiques - elles ne sont pas attendues pour être changées et elles ne sont pas mises en cache.
Les deux points ensemblent peuvent être infernales : Par exemple pour charger la banque d'image, j'ai une demande d'accès en AJAX qui se fait puis un appel sur l'ensemble des images (parfois plus de 100 à la fois), ce qui surchage mon fichier access.log.
Si ça m'intéresse de savoir que l'utilisateur a charger l'interface, ça ne m'intéresse pas de savoir quels images ont étés chargées.
Concernant le premier point, est-il possible via le fichier 000-default.conf d'empêcher de mettre les lignes dans le fichier pour certains types de fichier (image, ou via extension ?).
Concernant le second point, j'ai vu qu'il y avait un module "Expires" (a2enmod expires), est-ce la solution la plus adaptée ? Est-ce que ça peut se configurer via le fichier 000-default.conf pour les images, ou uniquement via .htaccess ? Dans le cas ou l'image est prise du cache, est-ce qu'une requête est tout de même envoyé par le navigateur au serveur ? Comment fonctionne cette requête ? Est-ce qu'un md5() du fichier est fait et ça renvoit la clé ? Cette clé est-elle stockée ou régénérée à chaque fois ? L'objectif étant d'optimiser au maximum, le mieux serait de transmettre au navigateur de ne même pas communiquer vers le serveur, tant l'image sera toujours statique pour ces projets (100% des images).
Bien entendu je suis conscient que les navigateurs peuvent eux aussi simplement ignorer les indications fournies par le serveur, mais au moins j'aurais fait le maximum.
Dernière modification par Barthandelous (Le 22/09/2024, à 07:53)
Hors ligne
#2 Le 22/09/2024, à 11:57
- Vobul
Re : [APACHE] Optimisation des logs et du cache.
Perso je suis plutôt team nginx, donc j'ai cherché "apache prevent log assets" puis j'ai trouvé https://confluence.jaytaala.com/display … pache+logs
Sinon pour le cache, il faut que t'envoies un header de cache control au client pour qu'il ne re-télécharge pas l'image à chaque fois.
Oublie le .htaccess, au passage (https://www.net7.be/blog/article/htacce … mance.html).
Bon après je ne vais pas répondre à toutes tes questions car il y en a beaucoup
Dernière modification par Vobul (Le 22/09/2024, à 11:57)
Vobul
Utilisez le retour utilisable de commandes !!!
J'aime la langue française, mais je parle franglais, deal with it.
RTFM
Hors ligne
#3 Le 25/09/2024, à 10:14
- krodelabestiole
Re : [APACHE] Optimisation des logs et du cache.
le choix de jQuery et Apache (donc je suppose PHP ?) me semble un peu (beaucoup) dépassé en 2024 pour le genre d'application dont tu parles.
avec es6 l'intérêt de jQuery est devenu inexistant (de la même manière que CSS 3 rend bootstrap obsolète, presque aussi catégoriquement et heureusement que HTML5 a enterré flash) : les conventions ouvertes sont au point. plus besoin de passer par des bricolages tiers lourds et inélégants.
côté front les paradigmes de développement ont évolué vers de vrais frameworks comme react et vue (je suppose en attendant qu'un truc comme HTML6 les balaye peut-être de la même manière), qui simplifient énormément la vie, et permettent d'imaginer des choses inconcevables à l'époque de jQuery, avec une organisation de code impeccable.
Aujourd'hui on parle plus de websockets que d'ajax. (pas qu'on l'utilise plus, mais ajax est devenu invisible tellement il est intégré à vue par ex.)..
de son côté nodeJS évite d'avoir à réécrire des briques similaires côté client et serveur en différents langages.
et avec une API REST ou (mieux) GraphQL, je crois que les problématiques que tu soulèves n'existeraient simplement pas.
donc si ce sont de nouveaux projets je te conseillerais surtout de bien choisir tes outils. je pense que vite est un bon engrenage dans lequel mettre un premier doigt.
si ce sont d'anciens projets à dépoussiérer faute de mieux, tu peux ignorer ma réponse.
nouveau forum ubuntu-fr on en parle là : refonte du site / nouveau design
profil - sujets récurrents - sources du site
Hors ligne
#4 Le 25/09/2024, à 12:11
- Barthandelous
Re : [APACHE] Optimisation des logs et du cache.
Bonjour,
Perso je suis plutôt team nginx, donc j'ai cherché "apache prevent log assets" puis j'ai trouvé https://confluence.jaytaala.com/display … pache+logs
Sinon pour le cache, il faut que t'envoies un header de cache control au client pour qu'il ne re-télécharge pas l'image à chaque fois.
Oublie le .htaccess, au passage (https://www.net7.be/blog/article/htacce … mance.html).
Bon après je ne vais pas répondre à toutes tes questions car il y en a beaucoup
C'est bon à savoir pour le .htaccess !
Je testerais ce soir pour bloquer les logs sur les images. Pour le cache, j'ai put trouver mon bonheur via StackOverflow mais via des instructions en PHP. Je n'ai pas encore réussi à trouver une équivalence en Apache sans utiliser le module que j'ai cité plus haut.
A titre d'information personnel, quels sont les plus gros avantages de nginx vis à vis d'apache ?
le choix de jQuery et Apache (donc je suppose PHP ?) me semble un peu (beaucoup) dépassé en 2024 pour le genre d'application dont tu parles.
avec es6 l'intérêt de jQuery est devenu inexistant (de la même manière que CSS 3 rend bootstrap obsolète, presque aussi catégoriquement et heureusement que HTML5 a enterré flash) : les conventions ouvertes sont au point. plus besoin de passer par des bricolages tiers lourds et inélégants.
côté front les paradigmes de développement ont évolué vers de vrais frameworks comme react et vue (je suppose en attendant qu'un truc comme HTML6 les balaye peut-être de la même manière), qui simplifient énormément la vie, et permettent d'imaginer des choses inconcevables à l'époque de jQuery, avec une organisation de code impeccable.
Aujourd'hui on parle plus de websockets que d'ajax. (pas qu'on l'utilise plus, mais ajax est devenu invisible tellement il est intégré à vue par ex.)..
de son côté nodeJS évite d'avoir à réécrire des briques similaires côté client et serveur en différents langages.
et avec une API REST ou (mieux) GraphQL, je crois que les problématiques que tu soulèves n'existeraient simplement pas.
donc si ce sont de nouveaux projets je te conseillerais surtout de bien choisir tes outils. je pense que vite est un bon engrenage dans lequel mettre un premier doigt.si ce sont d'anciens projets à dépoussiérer faute de mieux, tu peux ignorer ma réponse.
Il s'agit en effet d'un ancien projet que je migre. Par contre, ce n'est pas pour autant que j'ignorerais ta réponse !
Surtout qu'elle est intéressante.
Je vais me renseigner sur les websockets (vu qu'on parle de socket, j'imagine qu'on peut faire des choses bien plus rapides / en direct ? ça pourrait être sympa avec ThreeJS), l'objectif du projet est aussi de desservir en étant le plus optimisé possible - en utilisant le moins de bande passante, car le projet est adapté à l'usage pour téléphone et doit fonctionner même en Edge. Par contre, j'ai toujours cette sensation qu'utiliser un Framework permet de travailler plus vite au détriment des performances, même si je n'ai que l'expérience backend sur ce point. Est-ce que je dois redouter quelque chose sur des librairies front ? J'entends énormément parler de NextJS en ce moment.
Deuxième point qui me fait peur, c'est d'apprendre une technologie qui va devenir obsolète - C'est déjà le cas avec JQuery, j'ai peur d'apprendre un framework front comme React pour qu'au final tout comme JQuery, ça ne serve plus. Pour des librairies comme ThreeJS qui, je trouve, apporte réellement quelque chose d'inédit, je trouve ça justifier. Mais j'ai l'impression sur le marché que les framework JS Front se font très, très nombreux. J'imagine que si tu me parles de ces technologies, c'est que tu en maitrises, tu penses quoi de toutes les bêtises que je peux penser et comment tu procèderais me faire changer d'avis ?
Hors ligne
Pages : 1