Idée pour diminuer les requêtes

[ordidomi]

Bonjour a tous !
Voilà, j'ai dernièrement passé de 60gp à 240gp pour gagner 15 000 requêtes journalieres. Malgré cela, certains jours sont overquotés :D . Alors dans la FAQ OVH j'ai trouver la définition de requêtes ou hits et elle dit cela :

"Plans concernés : xxlplan, mediaplan, 720planNT, 720plan, 240plan, 90plan, 240gp, 60gp, 20gp, mailplan
Catégories : Web

Q: Qu'est ce que représente une requête (hits) ?
--------------------------------------------------------------------------------
R: Une requête est un fichier téléchargé depuis votre site. Ce peut être une image, un fichier html, ou une feuille de style.

Par exemple, une page HTML avec 3 images et une feuille de style (CSS) demandera 5 hits."


La phrase magique que je voudrai bien comprendre avant de trouver mon idée lumineuse :rolleyes: est celle ci :
"Une requête est un fichier téléchargé depuis votre site"

Depuis votre site signifie depuis notre hebergement OVH ou même une image par exemple stocker sur un autre server ?

J'aimerai la réponse car comme beaucoup de forum les smilies sont bien utiliser et créer beaucoup de requetes. Pourtant ce sont des images ne demandant que peu de temps de chargement et les héberger chez notre espace FAI ne ralentirai pas le forum, au pire l'affichage des smilies...mais cela diminuerai considérablement les requêtes...SAUF si bien sur même une image affichée avec un lien externe à OVH soit comptabiliser comme une requête...Dans le premier exemple ca me sera très utile dans le second cas oublier mon idée géniale qui n'en été pas une :D Une réponse d'OVH ou d'un membre ayant déjà tenter cette technique m'enchanterai ;)
Merci:)

[L.Boggio]

Un hit est une ressource-fichier demandée sur le serveur OVH. Donc, dans le cas que tu soulignes, les avatars et autres images qui s'affichent sur TON site mais qui sont réellement hébergées sur d'autres sites NE sont PAS comptabilisées en hits de TON hébergement, rassures-toi.

[ordidomi]

ok, merci ! J'aimerai optimiser encore plus en hébergant les images du dossier templates/images de subsilver, car le css de phpbb génére une foule de requêtes...qqun a une idée ou a déjà essayer ?
;) merci.

[JalaL]

ordidomi écrivait :
ok, merci ! J'aimerai optimiser encore plus en hébergant les images du dossier templates/images de subsilver, car le css de phpbb génére une foule de requêtes...qqun a une idée ou a déjà essayer ?
;) merci.

Bonjour

J'ai essayé avec les emiticons de phpbb directement depuis l'ACP et ca a marché, il faut mettre l'URL exacte du dossier des emoticons... pour les images du thème il faudra mettre l'URL externe dans la variable $current_template_path dans le fichier nom_template.cfg dans la racine du template.

Mais attention, quelques images requièrent une modification du fichier .tpl lui même.

[planete95]

L.Boggio écrivait :
Un hit est une ressource-fichier demandée sur le serveur OVH. Donc, dans le cas que tu soulignes, les avatars et autres images qui s'affichent sur TON site mais qui sont réellement hébergées sur d'autres sites NE sont PAS comptabilisées en hits de TON hébergement, rassures-toi.

les smileys de son forum, donc heberger sur son hebergement, sont contabilisés avec autant de smileys affichés, c'est à dire, quand on click sur " tous les smileys", on a donc 100 smileys à 3ko pour ma part, ca coûte 100 requetes par personne ? :(

[ordidomi]

merci pour le nom de la variable JalaL ;)

[L.Boggio]

planete95 écrivait :
les smileys de son forum, donc heberger sur son hebergement, sont contabilisés avec autant de smileys affichés, c'est à dire, quand on click sur " tous les smileys", on a donc 100 smileys à 3ko pour ma part, ca coûte 100 requetes par personne ? :(
Ben oueh... C'est balot, mais c'est comme ça. Une page HTML qui contient 2 pages CSS externes, et qui affiche 100 images, ça va fonctionner comme ça :
Le client (navigateur) demande la page index.html.
Le serveur la lui envoie.
Le client l'interprète, et voit qu'elle nécessite ces 2 CSS et les 100 images. Il envoie donc 102 requêtes au serveur (pas toutes en même temps) pour récupérer ces fichiers, et affiche la page dans sa fenêtre.
Donc, au total, 103 hits.

[ordidomi]

Maintenant c'est ma base qui est trop "lourde" :( elle passera sans doute en sql.bdb...qqun a déjà passé sa base dans ce mode ? il suffit de modifier le config.php et de remplacé le sql1 par sql.bdb ?? je suis un peu hors de mon sujet de départ....:D mais bon...si qqun a connu le meme sort pour sa base je serai :D de connaitre la manip, un peu marre du succés :cool: :D

[L.Boggio]

ordidomi écrivait :
Maintenant c'est ma base qui est trop "lourde" :( elle passera sans doute en sql.bdb...qqun a déjà passé sa base dans ce mode ? il suffit de modifier le config.php et de remplacé le sql1 par sql.bdb ?? je suis un peu hors de mon sujet de départ....:D mais bon...si qqun a connu le meme sort pour sa base je serai :D de connaitre la manip, un peu marre du succés :cool: :D
J'y suis passé, il m'a, en effet, suffit de passer slq1 en sql.bdb. Les autres paramètres étaient restés inchangés.
Et sinon, pour réduire ta base, tu as pensé à la suppression des vieux messages ou désactuver la fonction de recherche (Si, bien sur, c'est applicable à ton cas) ?

[ordidomi]

merci ca me rassure de savoir qu'il n'y aura qu'une ligne a modifiée ! ;)
Je pourrai effacer de vieux messages mais l'explosion de participation au forum ferai que la manip ne tiendrai pas longtemps....Sinon qu'elle différence il y a eu pour toi? meme vitesse ? meme quotas de requetes que pour l'hebergement ? ( 45 000 pour le 240 gp par exemple). J'ai un peu peur que ca ralentisse, a moins que ca accelère (bien que plus la base sera grosse plus elle sera lente...). La fonction recherche est indispensable pour le forum (11 000 messages sur des sujets très differents)...
Merci pour toutes ces infos, j'attends ton avis sur la migration en big base :D
Bonne soirée à tous :)

[L.Boggio]

ordidomi écrivait :
merci ca me rassure de savoir qu'il n'y aura qu'une ligne a modifiée ! ;)
Je pourrai effacer de vieux messages mais l'explosion de participation au forum ferai que la manip ne tiendrai pas longtemps....Sinon qu'elle différence il y a eu pour toi? meme vitesse ? meme quotas de requetes que pour l'hebergement ? ( 45 000 pour le 240 gp par exemple). J'ai un peu peur que ca ralentisse, a moins que ca accelère (bien que plus la base sera grosse plus elle sera lente...). La fonction recherche est indispensable pour le forum (11 000 messages sur des sujets très differents)...
Merci pour toutes ces infos, j'attends ton avis sur la migration en big base :D
Bonne soirée à tous :)
Je suis passé sur sql.bdb lorsqu'il a été mis en service, et pas très longtemps, car j'ai corrigé rapidement les bases incriminées. A l'époque, ce serveur était horriblement lent.
Par-contre, à lire tes questions, tu fais une confucion entre serveur Web (45.000 requêtes) et serveur MySQL (taille des bases) Il n'y a pas de quota de requêtes en MySQL.
Le but de sql.bdb est de ne pas pénaliser les utilisateurs en mutualisé de MySQL dits 'raisonnables' façe à une utilisation 'déraisonnable' de MySQL.
Donc, OVH a décidé de migrer sur sql.bdb toute base qui
- Dépasserai la taille indiquée
- Génèrerai des requêtes qui perturbent le fonctionnement des serveurs MySQL mutualisés, et donc les autres utilisateurs. L'exemple de ce genre de requêtes, ce sont des WHERE sur des champs non-indexés, par-exemple.
Si ta base devient trop grosse, ton hébergemnt restera, avec toutes les caractéristiques (hits, ...), mais le serveur qui hébergera ta base deviendra sql.bdb, avec lequel tu risques d'avoir de gros problèmes de performances (requêtes longues à exécuter, parfois pas de réponse), et donc, des pages très longues à charger, voire des messages d'erreurs. En tout cas, au début, c'était ainsi. Connaissant OVH, ils ont sûrement du améliorer les perormances de ce serveur, mais n'oublie pas que se trouve dessus tous les utilisateurs 'déraisonnables' de MySQL, longues requêtes, lourdes, etc...

[ordidomi]

Ok, merci !
C'est vrai que le mail précise que ce server "big base" est une machine performante...Je verrai bien et posterai mon avis sur les performances...La taille conseillée quand on prends un 240 gp et de 15 mo, le mail que j'ai recu indique un depassement de 80% sur la base conseillée de 20 mo :confused: , surtout que ma base fait 16 mo.....:rolleyes:

[Jérémie]

A noter que pour la plupart des browsers, ils cachent les images et certains fichiers, donc si un utilisateur demande deux fois la même page qui contient 100 images il ne devrait pas faire 200 hits au compteur. Mais réduire le nombre de fichiers (images comprises) par page de ton site est une bonne idée en effet.

[ordidomi]

Il me semble tout de meme que tous les explorateurs verifie chaque fichier en cache pour connaitre si une différence a eu lieu depuis la dernière connexion, ce qui equivaut a une requete...:( Cette optimisation est seulement utile pour accelérer le surf sur des sites souvent visités...