OVH Community, votre nouvel espace communautaire.

alpha-test mutucache


Lennie_boy
05/09/2013, 15h49
Bonjour
Je utilise OSCommerce 2.3.3 Impossible de ecrire une commentaire sur Facebook. http://monsite.cluster015.ovh.net/catalog/ Le support technique OVh propose de changer l'url du site par nom de domaine:ecobebecouche.fr mais c'est ovh qui ont fait le cluster015etc.
Comment changer le nom ?
Merci pour tout aide.
Cordialement
Len

huilletboutique
07/09/2012, 17h45
Salut je suis aussi sous prestashop et dans le meme souci

pat007
03/09/2012, 15h06
Salut à tous.
J'aimerai testé ça sur un site Prestashop, mais je sais pas ce qu'il faut modifier dans les paramètres pour que le :84 soit pris en compte?
D'avance merci!

zola2
12/06/2012, 14h18
@Tony : Des news concernant ce projet ?

jeanlou
05/06/2012, 00h23
ah ok, effectivement j'ai pas compris ça, le support m'a expliqué que je pouvais utiliser ce service pour optimiser les temps de chargement de mon site mais visiblement c'est pas une solution technique viable pour le moment.

Will
04/06/2012, 15h26
Le :84 c'est juste pour tester toi de ton côté, pas pour la prod bien sur...

En plus comme ce n'est pas un port standard, il a de fortes chances d'être bloqué dans les hot spot Wifi, les cybercafés, etc...

jeanlou
04/06/2012, 14h40
la question est : quelles sont les incidences sur le référencement existant d'un site si rajout du ":84" à la fin de chaque urls??
Quelles conséquences dans le cas d'utilisation d'un composant externe de ré-écriture d'url (genre sh404)??

tony
10/05/2012, 11h38
On a trouvé un bug "à la con", faut qu'on fixe ça avant de pouvoir passer en prod.

Tony

zola2
03/05/2012, 13h16
Ca sera en prod fin mai avec les nouvelles offres mutu ?

Guillaume.S
26/04/2012, 12h03
Bonjour,

IP française du cluster012/1000gp ajouté à Varnish.

Merci à ceux sur ce cluster de nous remonter leurs impressions.

Cordialement,

vaporisator
25/04/2012, 22h12
Citation Envoyé par tony
En fait indirectement il y aura un impact quand même parce que ça va faire moins de requêtes sur les filers, donc des fichiers servis plus rapidement et comme un script wordpress c'est dans les 300 appels de fichiers, ça aura un impact

Tony
Tout à fait, c'est justement sur les CMS comme wordpress et Joomla que ce sera hyper efficace si ce cache travaillé bien... Cacher les JS c'est un bonheur ABSOLU...

tony
25/04/2012, 19h20
Citation Envoyé par zola2
Ah... s'il cache uniquement : png, gif, jpg, jpeg, css, js aucun intérêt pour ma part et il n'y aura logiquement aucune amélioration concernant les problèmes de ralentissement WordPress....
En fait indirectement il y aura un impact quand même parce que ça va faire moins de requêtes sur les filers, donc des fichiers servis plus rapidement et comme un script wordpress c'est dans les 300 appels de fichiers, ça aura un impact

Tony

Guillaume.S
25/04/2012, 18h19
Re,

C'est juste en test pour le moment, on veut voir comment les serveurs se comportent déjà rien qu'avec çà sur les différents clusters.

Là, les serveurs s'ennuyaient tellement que nous avons rajouté l'IP polonaise

Cordialement,

zola2
25/04/2012, 17h46
Ah... s'il cache uniquement : png, gif, jpg, jpeg, css, js aucun intérêt pour ma part et il n'y aura logiquement aucune amélioration concernant les problèmes de ralentissement WordPress....

Guillaume.S
25/04/2012, 17h19
Bonjour,

Nous allons reprendre quelques tests avec Varnish.

Il est actuellement activé par défaut sur le cluster012/1000gp pour certaines IPs géolocalisées (hors IP française et IP polonaise)
http://travaux.ovh.net/?do=details&id=6431

Son fonctionnement est fait pour être le plus transparent possible, et nous ne cachons que ces types d'ojets (png, gif, jpg, jpeg, css, js)
N'hésitez pas à nous remonter toutes vos remarques.

Cordialement,

zola2
04/04/2012, 13h03
Le projet suit il toujours son chemin ?

J'ai énormément de WP pour mes clients... qui commencent sérieusement à s'impatienter...

Le temps de réponse n'allant qu'en se dégradant, j’espère vivement que ce projet va voir le jour rapidement !

Merci

Guillaume.S
21/03/2012, 09h34
Bonjour,

zola2 : Oui, en stand-by.

Des modifications d'architectures sont à faire.
Nous étudions les différentes possibilités, puis nous pourrons continuer les tests.

Cordialement,
Guile.

zola2
21/03/2012, 08h48
up +1

zola2
12/03/2012, 10h39
C'est en stand-by ?

Guillaume.S
06/03/2012, 16h40
Bonjour,

Nous effectuons quelques modifications réseaux sur les serveurs de cache.

Ils ne seront plus disponible pour le moment sur le port 84.

Nous vous informerons de la suite des opérations.

Cordialement,
Guile.

Guillaume.S
06/03/2012, 11h16
Bonjour,

@NicolasZ : J'ai testé "Varnish HTTP Purge", mais même sans, cela marche déjà très bien.
Wordpress n'a pas l'air de poser trop de problème avec Varnish.

@ddavid : J'ai demandé au Varnish de ne pas toucher ni à "Expires", ni à "Max-Age".
Ainsi, vous restez maître des valeurs assignées aux objets.
Varnish va calculer le TTL de l'objet en fonction soit du "Expires", soit du "Max-Age".
Si rien n'est définit, il mettra les valeurs par défaut que nous avons assignés à ces objets.

L'avantage : Votre application répondra comme vous l'avez souhaité.
L'inconvéniant : Si le TTL devient du coup trop petit, alors le Cache passera son temps à discuter avec le serveur Web pour remettre à jour l'objet.

Donc, ne définissez "Max-Age" et/ou "Expires" que si vous savez ce que vous faites

Cordialement,
Guile.

NicolasZ
06/03/2012, 06h59
Le cache a t'il été testé avec les plugins comme WP-Varnish?

ddavid
05/03/2012, 19h17
Bonjour Guillaume et merci de cette réponse.

Citation Envoyé par Guillaume.S
Pour le TTL des objets, je vais voir si je peux prendre en compte ceux des objets retournés par les serveurs.
Si oui, je les mets par défaut.
Une question que je me pose : ce cache mis devant le serveur ne devant pas perturber le fonctionnement des autres caches près du client (ou intégrés au client), quelles sont les modifications prévues pour que les headers envoyés vers le client soient cohérents.

Typiquement, un "Expires: Thu, 06 Dec 2012 16:00:00 GMT" pourrait être retransmis tel quel au client.

Par contre, que faire face à un "Cache-Control: max-age=3600" lorsque la donnée est en cache depuis déjà 1799 secondes ? Faut-il recalculer le max-age fourni au client pour lui indiquer 1801 secondes ? Ou faut-il laisser 3600 ? Les deux peuvent se comprendre...

De plus, que ce soit avec un "Expires" non modifié, ou un "Cache-control: max-age=" recalculé, si l'on arrive trop près de la date fatidique, faut-il mieux ne pas utiliser le cache côté serveur (le serveur de départ est alors moins soulagé mais l'on augmente les chances de donner au client des données qu'il pourra conserver longtemps en cache) ou alors faut-il l'utiliser (le serveur de départ étant ainsi soulagé au mieux, mais dans le cas hypothétique où le client redemande la donnée, c'est le client qui est pénalisé, client ne bénéficiant pas forcément d'une connectivité idéale...) ?

À mon avis, de la flexibilité et de la clarté s'impose sur ses choix, ce n'est pas dit que tout le monde souhaite avoir les mêmes réglages.

luluberlu
05/03/2012, 15h51
TTL
HTML (rendu de l'affichage) : 6 jours
Résultat requête : 0 ou 1 heure en fonction de la requête.

luluberlu
05/03/2012, 14h32
@Guillame.S : email envoyé avec toutes les infos.

Gaston_Phone
05/03/2012, 11h40
@ Guillaume.S, le problème de l'IP fixe 213.186.33.53 est-il résolu ?

Si l'IP est 213.186.33.53 avec comme adresse visiteur b3.ovh.net, cela ne m'intéresse pas du tout.

En effet, il sera très difficile de faire des statistiques sur :
  • Le nombre de visiteurs uniques,
  • La ville et le Pays du visiteur.


EDIT : Autant pour moi, je n'avais pas vu la réponse de Guillaume #85

Guillaume.S
05/03/2012, 10h56
Re,

@ddavid : Concernant le bouton pour vider le cache, je vais voir avec Tony, mais il fait partie des 3 boutons indispensables pour cette fonction :
- Utiliser le cache
- Ne plus utiliser le cache
- Purger le cache

Avec toujours en choix les enregistrements "A" des DNS.

Pour le TTL des objets, je vais voir si je peux prendre en compte ceux des objets retournés par les serveurs.
Si oui, je les mets par défaut.

A voir donc,

Cordialement,
Guile.

PS : Si vous avez sur vos sites un élément dont vous avez définis vous même le TTL, donnez -moi le lien, je pourrais regarder de quelle façon il est défini et comment l'implémenter.

Guillaume.S
05/03/2012, 10h50
Re,

@luluberlu : Tu pourrais me donné l'url de ton site et un accès pour que je regarde ce qui cloche ?

Merci,

Cordialement,
Guile.

Guillaume.S
05/03/2012, 10h47
Bonjour,

Comme je l'ai dit plus haut :
"Pour le b3.ovh.net, nous allons le régler rapidement, pour l'alphatest nous voulions éviter trop de modification dans l'archi interne."

b3.ovh.net a pour IP 213.186.33.53.

Cordialement,
Guile.

zola2
05/03/2012, 10h41
Tu as regardé dans ton phpinfo si y a pas moyen de chopper la bonne IP ? style avec HTTP_X_FORWARDED_FOR ?

Gaston_Phone
05/03/2012, 08h17
Oui, je capte toujours cette IP 213.186.33.53.

Nota, je ne travaille pas avec les logs OVH. Je travaille en temps réel en enregistrant les infos dans mes logs à moi.

ddavid
04/03/2012, 22h39
Tu captes toujours cette IP ou tu ne captes que cette IP ?

Est-ce bien dans les logs bruts pour la ligne correspondant au statut HTTP autre que 301/302 ? Es tu sûr que tu ne t'adresses pas à l'URL d'un élément déjà en cache ?

Personnellement, j'ai des tests concluant dans mes logs (par contre "petit piège" : c'est pas forcément facile à voir si il y a une rupture de l'ordre chronologique dans les logs, ce qui visiblement m'est arrivé).

Gaston_Phone
04/03/2012, 22h08
Citation Envoyé par ddavid
Euh, si rewrite tel que j'ai indiqué le navigateur reçoit une redirection HTTP vers la version sans cache, donc 213.186.33.53 n'apparait que pour la requête ayant produit la redirection, le log restant normal pour la requête après redirection.
J'ai déjà testé et capte toujours l'IP 213.186.33.53.

ddavid
04/03/2012, 22h00
Citation Envoyé par Gaston_Phone
Cela n’enlèvera en rien que l'on aura toujours l'IP visiteur figée à 213.186.33.53 avec comme adresse visiteur b3.ovh.net
--> Un seul visiteur unique par jour.
Euh, si rewrite tel que j'ai indiqué le navigateur reçoit une redirection HTTP vers la version sans cache, donc 213.186.33.53 n'apparait que pour la requête ayant produit la redirection, le log restant normal pour la requête après redirection.

Gaston_Phone
04/03/2012, 17h55
Citation Envoyé par ddavid
Sinon, visiblement rien n'interdit de faire un peu de Rewrite pour se débarrasser de la version sur port 84 : dans le .htaccess
Cela n’enlèvera en rien que l'on aura toujours l'IP visiteur figée à 213.186.33.53 avec comme adresse visiteur b3.ovh.net
--> Un seul visiteur unique par jour.

ddavid
04/03/2012, 17h23
Citation Envoyé par Guillaume.S
Quel serait selon vous la valeur par défaut (TTL) pour un type d'objet donné ?
Bonjour,

Pour moi, dans tout système de cache intéressant il y aurait nécessairement un système de purge sur demande via le manager au minimum, qui permettraient de s'en sortir sans attendre la fin du TTL.

Ensuite, il serait intéressant que la durée de mise en cache soit au plus égale à celle indiquée par l'en-tête d'expiration renvoyée par le serveur de départ, et ce quelque soit le type de fichier.

ddavid
04/03/2012, 17h11
Citation Envoyé par manud
Gaston,

On va créer un groupe de "ceux qui pensent que le mutucache est très intéressant mais qu'il est nécessaire de pouvoir le maîtriser site par site".
J'aurais même dit le groupe de ceux qui pensent que ça n'aurait du être activé que pour ceux qui l'ont explicitement voulu.

Sinon, visiblement rien n'interdit de faire un peu de Rewrite pour se débarrasser de la version sur port 84 : dans le .htaccess :

Code:
RewriteEngine on

RewriteCond %{SERVER_PORT}  ^84$
RewriteRule ^(.*)$ http://votresite.example.net/$1 [L,R=301]
(Vérifier que ça couvre bien partout, cf le Inherit en cas de .htaccess dans des sous-dossiers, de plus dans le cas où le dossier de l'hébergement couvre plusieurs FQDNs, il faut soit choisir vers quel FQDN rediriger, soit faire une règle plus complexe.)

Attention : ne tester que vers des URLs qui ne sont pas déjà servies par le cache, sinon ça ne marche pas !

Par ailleurs, petite question : le système de cache actuel est-il compatible avec les multi-domaines localisés sur une IP dite étrangère ?

luluberlu
03/03/2012, 13h03
Un problème avec Drupal :
1) je ne suis pas identifié, j'ai sur l'écran un certain nombre d'onglets correspondant au menu "anonymes".
2) j'affiche une liste en cliquant sur un onglet
3) je reviens sur la page d'accueil
4) je m'identifie
5) s'affiche le menu "anonymes" plus des menus/onglets spécifiques
6) j'affiche la même liste que précédemment
7) les Menus/onglets spécifiques ne sont plus affichés. Seuls le menu "anonymes" et la liste sont visibles.
8) réaffichage de la page précédente pour récupérer la totalité de la vue (menus "anonymes" et spécifiques) et pouvoir me déconnecter.

Guillaume.S
02/03/2012, 15h22
Re,

Rien n'est encore validé de ce côté là.

Cela devrait se faire par enregistement "A" des DNS.

Par exemple :

toto.fr A IP.Cache.ClusterXXX
www.toto.fr CNAME toto.fr
coucou.toto.fr A IP.ClusterXXX
www.coucou.toto.fr CNAME coucou.toto.fr

=> toto.fr et www.toto.fr seront cachés
=> coucou.toto.fr et www.coucou.toto.fr ne le seront pas

zola2
02/03/2012, 15h12
Question importante, si lors du lancement on choisi entre cache / pas cache ca sera pour tout le domaine et les sous domaines ? Ou bien on pourra choisir selon ?

zola2
02/03/2012, 14h59
Ca remarche

Guillaume.S
02/03/2012, 14h56
Bonjour,

Quelques soucis réseaux apparement de notre côté vers les VHs.

Je m'en informe.

Cordialement,
Guile.

Guillaume.S
02/03/2012, 14h37
Re,

@zola2 : je t'ai remis un MP.

Cordialement,
Guile.

zola2
02/03/2012, 14h26
Le site que je teste n'est pas à la racine, mais domaine.com/wp/ (c'est une copie du site de la boite)

Guillaume.S
02/03/2012, 14h23
Bonjour,

Nope, Zola2, je n'ai pas encore refait de modifs, donc il y a autre chose.

Je t'ai indiqué en privé, il y a quelques temps que, je tombe toujours sur une page blanche lorsque je vais sur ton site.

Soucis de redirection/réécriture ? (Le cache envoie bien des données, ou va les chercher sur les Webs, mais j'ai toujours une page blanche :/ y compris sans le :84)

Cordialement,
Guile.

zola2
02/03/2012, 14h18
Bon j'ai toujours des timeout c'est signe que ca bosse

zola2
02/03/2012, 14h16
Il me semble difficile de définir des temps pour l'ensemble de mes sites, actuellement je définis le temps selon la fréquentation du site...

Pour un site très peu fréquenté, une durée min de 86400 tiens logiquement la route... car si on part sur 3600, s'il y a un visiteur par heure (et oui sur certains sites ça arrive ), il se tape chaque fois la régénération du cache, donc aucune utilité

Mais... si on prend un compte qu'il est possible facilement via un plugin ou l'envoi d'une entête de purger le cache, faut avoir une mise en cache de durée maxi !

Moi j'veux bien une mise en cache indéfinie et uniquement faire des appels lors de modification

Guillaume.S
02/03/2012, 13h59
Bonjour,

@zola2 : J'ai fais pas mal de changements ce matin.
J'ai du relancer Varnish une bonne 20taine de fois sur les serveurs (Je teste une règle : OK, alors une autre, ...)
Les VHs ont été relancés pratiquement tous en même temps, donc tu peux avoir eu un timeout.


Quel serait selon vous la valeur par défaut (TTL) pour un type d'objet donné ?
- Type HTML : Xs en cache
- Type CSS : Xs en cache
- Type IMAGE (jpg, png, ...) : Xs en cache
- ...
- Valeur par défaut pour le reste : Xs en cache (TTL très petit)

Donnez les valeurs qui vous semble OK, et indiquez pour quel utilisation (Wordpress, Drupal, Home Made, ...)
(Pour les CMS, vous pouvez utiliser un plug-in compatible avec Varnish pour purger du cache les MAJ.)
(Pour les sites fait-maison, vous pouvez simplement envoyer/retourner un requête HTTP Purge après votre MAJ pour qu'elle soit prise en compte)
(Cela permet d'avoir des TTL longs pour les différents objets, et donc de rester plus longtemps en cache, sans problème de MAJ)

Pour le b3.ovh.net, nous allons le régler rapidement, pour l'alphatest nous voulions éviter trop de modification dans l'archi interne.

Dans un premier temps, je pense que vous ne pourriez qu'activer et/ou désactiver le cache pour vos sites. (une IP_sans_cache/Cluster et une IP_avec_cache/Cluster)

Personnaliser par site demanderait du coup, une règle de Varnish par vhosts (pour tous ceux qui le voudraient, il faudra faire une règle indiquant que pour ce vhost là, il faut utilisé l'ensemble des règles là bas, faite juste pour lui), soit davantage de serveurs Varnish sinon ils vont passer leurs temps à chaque requête à étudier les 1001 règles pour décider ce qu'ils doivent en faire.

Mais ce ne sont que des hypothèses/études, tous les tests ne sont pas terminés et Tony décidera de ce que nous en ferons.

Cordialement,
Guile.

zola2
02/03/2012, 11h31
J'ai quelques soucis avec le cache ce matin : time out sur certaines pages (celle qui semblent non mise en cache)

luluberlu
01/03/2012, 18h33
Mutucache testé avec Drupal 6.25, port 84 : tests OK. Les performances semblent meilleures (une fois le premier chargement effectué). Actuellement j'utilise un cache "fichiers" pour bypasser le cache DB de Drupal ; je ne l'ai pas inactivé pour les tests, car ils n'ont pas la même fonction (Varnish étant un front-end qui permet de ne pas aller jusqu'au serveur Apache pour satisfaire à une requête). Je ne suis pas en mesure de donner des précisions quant au cumul des 2 systèmes (reverse proxy Varnish et Cache router de Drupal). Je suppose qu'il faudra substituer à "Cache router" le module "Varnish HTTP accelerator integration" qui permet d'invalider les entrées de cache obsolètes. Ou bien, devrais-je cumuler le tout (pour éviter un retour au cache DB de Drupal) ? Et dans ce cas comment régler la durée de vie d'une page dans le cache fichier ? Beaucoup de questions pour le moment. C'est pourquoi il me semble souhaitable de laisser à chaque site la possibilité d'utiliser ou non Varnish.

Donc +1 pour le groupe.

manud
29/02/2012, 12h38
Gaston,

On va créer un groupe de "ceux qui pensent que le mutucache est très intéressant mais qu'il est nécessaire de pouvoir le maîtriser site par site".

Gaston_Phone
29/02/2012, 12h15
Citation Envoyé par manud
Me concernant, j'utilise un cache PHP "maison" mais aussi un système de stats PHP qui m'est indispensable et qui est couplé à mon système de cache. Je veux donc maîtriser complètement l'activation ou non du système de cache OVH.
Enfin quelqu'un qui me comprend et qui a les mêmes soucis que moi.

manud
29/02/2012, 09h36
Bonjour Tony,

Serait-il possible de faire un résumé des actions en cours sur ce cache ?
Je commence aussi à m'inquiéter sur la notion de "test en live". Est-ce bien désactivé si on continue de passer par le port 80 ou est-ce activé par défaut ?
Me concernant, j'utilise un cache PHP "maison" mais aussi un système de stats PHP qui m'est indispensable et qui est couplé à mon système de cache. Je veux donc maîtriser complètement l'activation ou non du système de cache OVH.

Merci d'avance pour ton retour.

jonas39
28/02/2012, 13h54
temps diviser par 2, je dis que c'est plus pas mal!

Gaston_Phone
28/02/2012, 12h22
Citation Envoyé par Will
bah c'est le port 80 standard qui est utilisé donc où est le problème ?
Si tu relisais tous les Messages de ce POST, tu comprendrais les soucis que j'expose et justement aussi avec le port 80.

Will
28/02/2012, 12h08
Citation Envoyé par Gaston_Phone
C'est le terme "test en live" qui me fait peur.
bah c'est le port 80 standard qui est utilisé donc où est le problème ?

Gaston_Phone
28/02/2012, 12h06
C'est le terme "test en live" qui me fait peur.

Will
28/02/2012, 11h25
Citation Envoyé par Gaston_Phone
Si l'IP est 213.186.33.53 avec comme adresse visiteur b3.ovh.net, cela ne m'intéresse pas du tout.

En effet, il sera très difficile de faire des statistiques sur :
  • Le nombre de visiteurs uniques,
  • La ville et le Pays du visiteur.
Si tu relis plus haut tu verra que la réponse a déjà été donné : c'est provisoire et ça ne sera pas comme cela en prod.

Gaston_Phone
28/02/2012, 11h23
Citation Envoyé par tony
On lance un test en live jeudi sur cluster012 (anciennement 1000gp)
Tony
Si l'IP est 213.186.33.53 avec comme adresse visiteur b3.ovh.net, cela ne m'intéresse pas du tout.

En effet, il sera très difficile de faire des statistiques sur :
  • Le nombre de visiteurs uniques,
  • La ville et le Pays du visiteur.

tony
28/02/2012, 11h16
Pour l'instant oui
Si les tests sont pas concluants on essayera autre chose

L'infra s'appuie aussi sur les load balancers et sur un autre système de cache pour les gros fichiers.

Tony

Will
28/02/2012, 11h06
Bonjour,

Vous utilisez quelle techno pour faire tourner le cache ? Varnish ?

tony
28/02/2012, 10h59
On lance un test en live jeudi sur cluster012 (anciennement 1000gp)

Tony

zola2
27/02/2012, 16h12
Bon bah j'ai fais plein de tests, vivement que ca soit mis en prod

NicolasZ
24/02/2012, 08h47
Citation Envoyé par zola2
Le gros avantage c'est que les plugins de cache de WP alourdissent considérablement le côté backoffice de l'outil... alors quand il n'y en aura plus besoin, ca sera top
Je vais faire des essais de comparaison avec et sans plugins de cache côté front et je te dis.
Merci Là malheureusement je ne suis pas en position de pouvoir tester, mais ça m’intéresse au plus haut point.
C'est sûr que virer les outils de cache, enfin au moins le cache disque, ça sera top et plus performant

zola2
24/02/2012, 08h29
Le gros avantage c'est que les plugins de cache de WP alourdissent considérablement le côté backoffice de l'outil... alors quand il n'y en aura plus besoin, ca sera top
Je vais faire des essais de comparaison avec et sans plugins de cache côté front et je te dis.

NicolasZ
24/02/2012, 08h20
Bonjour,
Quelqu'un a mesuré le Time To First Byte avant / après mutucache sous un Wordpress avec / sans cache?
En tout cas vivement la mise en prod

zola2
23/02/2012, 09h02
Je pense qu'il sera important de pouvoir définir un délai de mise en cache : chaque site ayant une "vie" différente : le délai de mise en cache, à mon avis, devra être estimé par chacun selon le nombre de visiteurs de son site et les modifs du site.
Ça serait sympa

Guillaume.S
22/02/2012, 15h35
Bonjour,

Information utile :
Si vous utilisez un système pour protéger le vol de vos images, vidéos, ..., via par exemple un .htaccess, vous pouvez avoir des surprises.
Le serveur de cache ne pourra pas récupérer les éléments, et il ne pourra ni les mettre en cache, et encore moins les transmettre au client.
Je pense que certains d'entre-vous ont du avoir le tour avec leur site.
Je regarde si cela peut se by-passer, et si oui, comment.


Sinon, n'hésitez pas à partager la méthode que vous avez employé pour tester le cache.
Site codé vous-même, CMS, mixte ?
Quelle modification ? (Modification de l'url du site en rajoutant :84, modification du .htaccess, ...)
Ceci permettra à ceux qui ne savent pas quoi modifier de pouvoir aussi test le cache.

@hplig : comment as-tu procédé pour tester le cache avec prestashop ?

Cordialement,
Guile.

Guillaume.S
22/02/2012, 11h20
Bonjour,

Je fais quelques essais sur le comportement des serveurs de cache et de notre infrastructure réseau dans le cas où l'un des serveurs devient indisponible, voir le cas où ils sont tous HS.

Il peut donc y avoir des coupures plus ou moins longues

Cordialement,
Guile.

RobertG
21/02/2012, 14h14
Le site impacté était www.robertg.fr et les choses sont rentrées dans l'ordre avec le vidage du cache en effet.
Et sur ce site en 2.5.1, l'identification est bien prise en compte côté site, avec le port 84.

Guillaume.S
21/02/2012, 13h43
Re,

@RobertG : pourrais-tu me donner l'url du site impacté ?
J'ai relancé les services de cache, peux-tu me dire si c'est OK ?

Cordialement,
Guile.

RobertG
21/02/2012, 12h20
Je n'avais apparemment pas de soucis pour l'identification avec un site en Joomla! 2.5, mais ce matin, en voulant le vérifier, impossible d'y accéder ! Un paramètre du fichier de configuration a été changé (par qui ? parce que rien ne permet de le faire ainsi depuis l'administration du site) et je me retrouve avec ce joli message, en passant par le port 84 :
Unable to load session storage class: files
Impossible d'accéder à l'administration du site, impossible de vider le cache.
J'interviens donc manuellement sur le fichier de configuration et je peux accéder au site et à son administration par le port 80 : aucun paramètre "files" n'est sélectionnable pour la gestion des sessions...
Et toujours impossible, faute de pouvoir vider le cache, d'utiliser le port 84 qui conserve cette notion de "files" dans la configuration et empêche donc la version 2.5 de fonctionner !

Guillaume.S
21/02/2012, 11h59
Bonjour,

Je teste les différentes url qui passent par le cache, afin de regarder ce qui se mets en cache ou non, et je m'aperçois bien souvent que je suis revenu sur le site normal sur le port 80.

Attention donc lorsque vous effectuez vos tests, si le :84 disparait de l'url, vous êtes revenu sur votre site normal, et vous ne passez donc plus par le cache.
(Relisez le premier post de Tony de ce topic à ce sujet)


Lorsque vous cliquez sur un lien sur votre site, si vous êtes le premier à aller dessus (ou que les éléments ont été supprimés du cache entre temps), les données ne sont pas encore/plus en cache.
Cliquez alors ailleurs sur le site, puis revenez.
L'affichage devrait alors être "instantanné" s'il n'y a pas trop d'éléments dynamiques et/ou non cachable.

Cordialement,
Guile.

tony
21/02/2012, 11h49
Citation Envoyé par zola2
Question, le cache est renouvelé tous les combien ? peux-t-on intervenir dessus ?
C'est pas encore décidé

Tony

acam
21/02/2012, 11h16
Guillaume.S> Pas de problème de mon côté pour l'identification sous Joomla 2.5.1 (avec l’identification par défaut sous joomla)

Guillaume.S
21/02/2012, 11h16
Bonjour,

@hphilg : Pas de soucis lorsqu'un visiteur fait un achat ?
Panier OK, commande validée, payée, tu as une trace de la transaction ?

C'est aussi le type de problème qu'il peut y avoir avec le cache si le cookie n'est pas vu/pris en compte.

@zola2 : Je laisse Tony répondre là dessus.

Cordialement,
Guile.

zola2
21/02/2012, 08h58
Citation Envoyé par hphilg
salut à tous,
je teste un test sous prestashop sur le port 84 et tout fonctionne correctement à priori. Doit-on voir un réel gain avec ce script E-commerce ou est-ce un gain spécifique pour les cms du type wordpress et joomla? (car je vois qu'on ne parle que de ca dans ce post).
Merci de me dire si vous souhaitez que je fasse des tests spécifiques. En effet je souhaites vivement des améliorations de perf...
A+
Prestashop utilise un système de cache avec Smarty, donc tout dépend si tu l'as déjà activé ou pas.
Et Prestashop n'est pas codé de la même façon.
Le gain va surtout se faire sentir sur les applis qui ont enormement d'inclusions...
WordPress est le champion des includes

Question, le cache est renouvelé tous les combien ? peux-t-on intervenir dessus ?

RobertG
20/02/2012, 19h32
Je confirme : loggué en passant par 84, mais pas reconnu comme tel, l'administration du site sait que l'utilisateur en question s'est bien identifié. C'est donc uniquement côté site que l'information de connexion réussie n'est pas prise en compte. cookie ?

Pour ce qui est du module d'identification, celui-ci (Core Design) a été ajouté pour remplacer celui de Joomla! après constatation du phénomène, et ne change rien (ce qui paraît logique dans la mesure où il n'est qu'un intermédiaire entre le plugin d'authentification Joomla! et le visiteur.

Guillaume.S
20/02/2012, 18h50
Bonjour,

@RobertG : Tu serais me dire quel module est responsable/s'occupe du login ?
Est-ce le module de base de joomla ou une extension rajoutée ?

Avec joomla 1.5 / 1.6 / 2.5, nous n'avons pas rencontré de problème particulier.

De ce que nous avons pu constater jusqu'à maintenant :
[Port 80]
- Un nouvel utilisateur arrive sur le site :
* création d'une session
- Il se loggue :
* création d'une nouvelle session pour l'utilisateur, lorsque la page se rafraichit, il est bien connecté

[Port 84]
- Un nouvel utilisateur arrive sur le site :
* création d'une session
- Il se loggue :
* pas de nouvelle session pour l'utilisateur, il conserve l'ancienne, la page s'affiche comme pour un nouvel utilisateur.

Pourtant les informations d'identification arrivent bien au serveur.
Si le login n'est pas correct, le site affiche l'erreur.


Info intéressante :
- Tu te loggues sur le port 80
- Tu vas sur le site avec le port 84, tu es bien authentifié, puisque la session a bien été crée en BDD.

Nous restons bloqué la dessus :
Pourquoi en passant par le cache, si on s'authentifie, et que la requete arrive au serveur (test du login), une nouvelle session n'est pas crée ?

Cordialement,
Guile.

zola2
20/02/2012, 18h23
Citation Envoyé par ddtddt
Si le script php gère déjà son propre cache y a il réellement gain ?
Moi j'dirais : oui mais gain plus faible. Techniquement j'en sais rien Tony va répondre, mais selon les tests que j'ai fais je penche pour ça et j'imagine que le temps gagné dans ce cas c'est le temps d’exécution du script php qui va chercher le contenu de ta page.

ddtddt
20/02/2012, 18h04
je viens de faire quelques essais et pas de problème particulier avec le cache

Si le script php gère déjà son propre cache y a il réellement gain ?

RobertG
20/02/2012, 16h03
Le site est fontanyl.robertg.fr (il a la particularité d'être un clone de fontanyl.info dont j'ai abandonné le nom de domaine)
Tu peux tester avec le module "login" dans la colonne de gauche, utilisateur=TestOVH, mot de passe "test84"
Le statut de visiteur ne change pas côté site (le module de login propose toujours de s'identifier), mais côté administration, la session est bien prise en compte.

Guillaume.S
20/02/2012, 15h58
Re,

@robertG : Tu peux me donner l'url de ton site ? (Un de ceux dans ta signature ?)
Je vais voir ce que je peux faire.

Cordialement,
Guile.

RobertG
20/02/2012, 15h29
@Guillaume.S
Non, la connexion côté site est toujours inactive sur le site en 1.5, après vidage du cache de mon navigateur (Firefox 10 sur PC) et suppression des cookies du site.

Coroebus
20/02/2012, 15h17
Bonjour,

Je viens de tester sur notre site en J1.5 et et notre dev en 2.5.
C'est redoutable d'efficacité, le site est très vif.
Je n'ai rencontré aucun souci d'authentification.

Guillaume.S
20/02/2012, 14h48
Bonjour,

Si vous avez des retours sur Joomla 1.X et 2.X, je suis preneur.

Je n'ai pas vu de problème particulier sur mes tests avec Drupal, mais je ne suis pas un utilisateur avancé.


@robertG : Le bug t'empêchant de te connecter est-il résolu ?

@paul1 : Tu peux me donner lien de ton forum, je vais faire quelque test

Merci pour vos retours

Cordialement,
Guile.

zola2
20/02/2012, 14h06
Citation Envoyé par Guillaume.S
Bonjour,

Nous avons apportés quelques optimisations spécifiques à wordpress.

Rencontrez-vous d'autres erreurs sur ce framework ?

Cordialement,
Guile.
Tout à l'air ok : plus de soucis d'identification sur le backoffice + plus de barre d'outil admin sur le front dans le cache

tony
20/02/2012, 14h02
Citation Envoyé par manud
Tony,

Peut-on déjà savoir si ce cache sera actif par défaut ? L'idéal serait que chaque webmaster puisse l'activer/désactiver à volonté, site par site, via le .htaccess par exemple.
Merci.
C'est pas encore décidé, ça va dépendre des tests, par contre ce sera pas via .htaccess, vu que ça se passe en amont de apache.

Edit : ce sera toujours possible de désactiver/activer d'une façon ou d'une autre, ce qu'il faut décider c'est de l'option par défaut surtout

Tony

Guillaume.S
20/02/2012, 13h55
Bonjour,

Nous avons apportés quelques optimisations spécifiques à wordpress.

Rencontrez-vous d'autres erreurs sur ce framework ?

Cordialement,
Guile.

Gaston_Phone
20/02/2012, 13h00
Citation Envoyé par manud
Peut-on déjà savoir si ce cache sera actif par défaut ? L'idéal serait que chaque webmaster puisse l'activer/désactiver à volonté, site par site, via le .htaccess par exemple.
+1

manud
20/02/2012, 12h54
Tony,

Peut-on déjà savoir si ce cache sera actif par défaut ? L'idéal serait que chaque webmaster puisse l'activer/désactiver à volonté, site par site, via le .htaccess par exemple.
Merci.

manud
20/02/2012, 12h51
Tony,

Peut-on déjà savoir si ce cache sera actif par défaut ? L'idéal serait que chaque webmaster puisse l'activer/désactiver à volonté, site par site, via le .htaccess par exemple.
Merci.

zola2
19/02/2012, 19h40
Aaaaah enfin la béta : trop bien

Les premiers retours via des tests sur des WordPress :

- plus rapide, 2 fois environ
- impossible de s'identifier sur l'admin du WP, faut donc revirer les :84 via la BDD
- si on navigue la première fois sur le site en étant identifié (avec la ch'tite barre d'outil noire de WP en haut), elle est mise en cache et affichée à n'importe quel visiteur, même si après il doit s'identifier... c'est moyen

Pour bien tester ça et avoir des chiffres et infos plus précise je vais installer un WP dédié à ça, la sur des sites en prod c'est un peu risqué pour le référencement...

En tout cas le début semble bien prometteur

spykeer
18/02/2012, 18h12
Citation Envoyé par ekozan
en gros c'est un proxy qui donne une page html et qui épargne l'utilisation de php+mysql pour certaine page
Je doute qu'il n'y est que sa

On auras une explication complète lors de sa mise en service

@tonyatovh sur twitter m'as informé comme ceci, donc je penses que c'est un peu plus complexe qu'un simple proxy tel Vernish ou nginx

ekozan
18/02/2012, 14h11
en gros c'est un proxy qui donne une page html et qui épargne l'utilisation de php+mysql pour certaine page

mehdib
18/02/2012, 09h39
J'ai essayé avec ce port, et tous va bien, mais j'ai voulu savoir le fonctionnement de ce service ??

tony
17/02/2012, 23h51
Citation Envoyé par Gaston_Phone
Et qui est b3.ovh.net à l'adresse 213.186.33.53 ?

Il ne serait donc plus possible de connaitre l'adresse IP et le FAI du visiteur ?
Si si mais la on est encore en alpha hein

Tony

spykeer
17/02/2012, 23h24
Il est possible de transiter les IP's réelles, j'ai eu le même soucis avec mon Varnish, si la technique utilisé et similaire a la mienne.

Gaston_Phone
17/02/2012, 22h42
Et qui est b3.ovh.net à l'adresse 213.186.33.53 ?

Il ne serait donc plus possible de connaitre l'adresse IP et le FAI du visiteur ?

RobertG
17/02/2012, 22h35
Curieusement, sur un autre site Joomla! (2.5), pas de problème de connexion (il utilise le module de login de Core Design et pas celui de Joomla!)

Édit : sur le site 1.5, le remplacement du module d'identification par celui de Core Design est inactif en accès 84 alors qu'il est bien pris en compte dans le site en accès standard, donc sous Joomla! 1.5, l'ajout d'un module et la suppression d'un autre ne sont pas interprétés par le système de cache qui continue à livrer la version précédente des modules.

paul1
17/02/2012, 22h34
C'est un forum un peu maison à base coolforum un peu comme phpbb avec des templates le chat est intégré au forum le tout n'est pas très lourd,ce n'est pas une usine à gaz !! mais bon marrant après mon essai les réponses arrivaient avant les questions, un forum de devin ! et puis tout a coincé plus de connexion pendant 1 minute tout à l'air d'être revenu dans l'ordre, j'ai réinitialisé le temps GMT mais je doute qu'il y ait un effet

tony
17/02/2012, 22h19
@robertG ok, on va regarder pour le bug sur joomla.

@paul1 il tourne sous quoi ton forum ? PhpBB ? Et le chat ?

Gaston_Phone
17/02/2012, 22h17
Sur mon site, l'affichage des pages est beaucoup plus rapide.

paul1
17/02/2012, 21h53
Bonjour
sur le forum avec des cookies ! certains membres ne sont plus visibles, et sur le chat les réponses se chevauchent un entre autre un passe son temps à remonter

JEYY
17/02/2012, 21h40
je viens de tester sur mon site (joomla) avec le plugin "page speed" et "firebug" et bin ça divise toutes les resources par 2 en gros donc ça vas juste fois plus vite

RobertG
17/02/2012, 20h59
Résultat de tests sur Joomla! (1.5.25) : le cache m'empêche de m'identifier sur le site. Sur les pages publiques du site, le formulaire d'identification est toujours affiché comme si j'étais un simple visiteur, alors que l'administration me reconnaît comme étant connecté.
Par ailleurs, la suppression d'autorisation de création de compte sur le site fait bien disparaître le lien sous ceux d'identifiant et de mot de passe oubliés si j'accède au site avec seulement son adresse, mais ce lien reste présent si j'utilise le port 84.

Il a fallu que je simule la création de nouveau compte utilisateur pour provoquer une erreur 403 et faire ensuite disparaître le lien de création de compte.

Par contre, une modification de titre et de contenu d'article (en utilisant le port 84) a bien été prise en compte instantanément.

RobertG
17/02/2012, 19h15
Pour info : sur un des sites dont j'ai parlé dans une autre discussion comme étant long à se charger (pratiquement 10s), l'ajout de ce port à l'URL a divisé à peu près par 3 le temps de chargement de la page ! Par contre, sur un autre site plus rapide, pas vraiment d'impression d'accélération.
Maintenant, est-ce que ça n'impactera pas la prise en compte des modifications du contenu (site Joomla! en l'occurrence) ?

tony
17/02/2012, 18h30
Cookie et en-têtes HTTP

Tony

ekozan
17/02/2012, 17h54
comment le systeme détermine que la page est lié " à un système de session ou d'authentification." ??

tony
17/02/2012, 16h56
Hello,

On travaille sur un système de cache pour les hébergements mutualisés, et on aurait besoin que vous le testiez pour avoir du feedback sur ce qui va bien et ce qui ne va pas surtout.

C'est testable sur tous les hébergements mutualisés OVH. Pour tester, il suffit de passer par le port 84

Comment faire ?
Si votre site est sur http://www.monsite.com/, vous mettez dans votre navigateur http://www.monsite.com:84/
Si c'est pour un sous-dossier, http://www.monsite.com/dossier/ deviens http://www.monsite.com:84/dossier/

Attention, certains cms réécrivent automatiquement l'URL, donc il faut aussi changer la conf de votre CMS pour pouvoir tester.

Par exemple, avec Wordpress, il faut aller dans votre panel Admin, puis :
- cliquez sur "Réglages"
- cliquez sur "Général"
- modifiez les champs "Adresse web de Wordpress (URL)" et "Adresse web du site (URL)" en ajoutant :84 à la fin de votre nom de domaine (comme expliqué ci-dessus)

N'oubliez pas de remettre votre CMS sur la config d'origine après avoir testé, le système est en alpha, et donc peut être pas encore stable.

si le :84 disparait de l'URL, c'est qu'il y a surement une modif à faire au niveau de votre site/CMS/.htaccess pour pouvoir tester.

Info sur le principe : Le système de cache garde en mémoire les pages de votre site, sauf si elles sont liées à un système de session ou d'authentification. Cela permet si il y a plusieurs visiteurs consécutifs sur la même page d'accélérer considérablement l'affichage de la page concernée. Aussi, le système ne change rien pour le premier visiteur, mais uniquement pour les suivants, donc pour le tester, il faut visiter plusieurs fois la même page


Merci pour les feedbacks,

Tony