Bonjour,
Il y a du cache pour les pages php chez ovh ?
c'est ce qui explique le délais entre l'envoi ftp et la mise a jour effective sur le site ?
et ça sert a quoi le cache en php… car le php est fait pour être dynamique donc ne pas avoir de cache…
le php est interprété, donc le cache php, c'est la mise en cache code généré
une seule analyse à faire de la page php
https://www.php.net/manual/fr/book.opcache.php
ok mais bon donc si le fichier php change le cache n'a pas lieu d'être ? donc c'est pas la raison pour laquelle il y a un délais entre l'envoie en ftp et la mise a jour sur le site ?..
non, je pense que tu mélanges les notions, heu les caches
là tu parlais de cache de code
il y a aussi le cache de pages générées, mais c'est au niveau du script
voire un cache de ressources statiques (cdn)
pour le ftp, c'est dans l'infrastructure d'ovh où il faudrait creuser, et je n'ai pas d'idées/compétences
ce n'est pas un serveur monobloc chez eux, tu as des serveurs Ftp, des serveurs Apaches, des serveurs de disques… et des serveurs pour répartir la charge sur tout ça (load balancers)
voir un cache reverse proxy servant de tampon entre les load balancers et les serveurs web?
(genre varnish, mais je ne sais pas si employé ici)
lol non je ne mélange rien t'inquiete
c'est juste que c'est la réponse du support lollllll
donc je venais voir ici si j'étais le seul à trouver cette réponse comme idiote ![]()
voici leur réponse :
> Concernant les délais de prise en compte des modifications en FTP, aucun
> changement n'a été fait. Cependant, si vous effectuez des modifications FTP en
> mode "production" au lieu du mode "développement", un certain temps peut alors
> être nécessaire pour que la modification soit visible (à cause des systèmes
> basiques de mise en cache).
je leur ai bien préciser que c'était des page php qui était impacté par ce délais ![]()
Même problème pour moi et c'est insupportable je suis en mode développement et il faut que j'upload 20fois chaque fichier avant qu'il ne soit pris en compte!!
c'est une manière de mesurer le temps ![]()
à la 20e fois, ton 1er est pris en compte
je confirme, le mode development ne change rien
seul les php sont impactés, config php-fpm?
même sans développer, quand on dépanne, c'est génial de ne pas savoir quand une modif est prise ou pas en compte ![]()
Surtout que j'ai des dizaines de mutualisés chez eux et je ne constate ce bug que depuis quelques temps… je crois que je vais finir par orienter ma clientèle vers un autre hébergeur à force ![]()
hé oué moi aussi ça fait quelques semaine que je le constate… mais je l'avais également constaté il y a quelques années de ça ils nous avaient fait le même coup et après ça avait été arrangé… Je vais retrouvé le post ![]()
le voila : https://forum.ovh.com/showthread.php/97607-D%C3%A9lai-de-prise-en-compte-des-modifications-via-FTP
J’espère que ça va s'arranger car en plus c'est totalement aléatoire des fois update du premier coup des fois faut uploader 20 fois, du coup on ne sais jamais sur quelle version du fichier php on travail.
Du coup j'suis obligé de faire du echo "ok" "ok1…" pour savoir !!! ![]()
Mêmes constatations pour ma part. La team OVH pourrait nous éclairer sur ce changement ?
Bonjour à tous,
Effectivement il y a bien un délai (variable) entre les modifications effectuées via FTP et la prise en compte effective par le serveur web (Ces délais sont bien inférieurs à la minute !).
Je parle bien-sûr ici des changements niveau fichier, que ça soit un php ou n'importe quelle autre ressource.
Cette latence s'explique par le fait que les serveurs FTP, les serveurs web , et les machines de stockage sont différents.
Dans un fonctionnement nominal d'un site web, l'opération effectuée en permanence sur les fichiers est la lecture. Donc en baissant le niveau de cache entre les serveurs web et le stockage, on viendra dégrader considérablement les performances de lecture, et pas uniquement pour chaque site de façon indépendante, car vu que plusieurs sites sont hébergés sur un même serveur de stockage (filerz), ils viendront plus souvent consommer les IOPS et donc ralentir les accès sur l'ensemble de l'infra.
Nous comprenons parfaitement la frustration que ça engendre pour un développeur ou quand un changement doit être effectué en urgence, mais c'est dans l'unique but de garantir un fonctionnement stable des sites.
Dans l'absolu, le meilleur environnement de développement reste une machine locale, puis publier en une seule fois la version modifiée.
Pour ceux qui ont eu ce ressenti que récemment , il y a bien eu des modifications sur les paramètres de cache, et depuis nous avons nettement amélioré la stabilité et l'efficacité des serveurs de stockage surtout en période de forte activité.
Finalement, il y a bien le produit cloudweb qui offre tous les composants nécessaires pour un hébergement sur une même machine locale (ftp, ssh, disque, DB, et serveur web) si jamais c'est un critère primordial pour la solution de l'hébergement que vous souhaitez choisir.
> il y a bien le produit cloudweb
et allez, du commerce, venir nous parler de performances en lecture, alors que le cloudWeb est le plus lent en disque…
https://community.ovhcloud.com/t/43309
En effet bosser en local est souvent la meilleure solution, mais souvent les environnements diffèrent et très souvent tester sur le vrai serveur est plus que nécessaire. La solution du ovhconfig était d'ailleurs une bonne option à l'époque mais mettre en cache le php est pure aberration désolé.
Je vous met au défit de dév un site actuellement, je perds un temps fou 30upload à chaque ; oubliés… plaisenterie !! ![]()
et je répète, ce phénomène, visible depuis peu ne concerne que les fichiers php
depuis peu AUSSI, 2 WE, plus de mise à jour possible non plus en php pendant 1 jour ou deux…!
les ressources sont préservées ![]()
https://community.ovhcloud.com/t/36605
> et je répète, ce phénomène, visible depuis peu ne concerne que les fichiers php
Dans ce cas je n'ai pas de réponse dans l'immédiat.
Dans ma précédente réponse j'ai juste éclairci le délai de propagation lié au transfert via ftp.
Mais je confirme que les comportements décrits sont anormaux (fichiers non visibles pour des heures / weekend) et nous regarderons pour la résolution
techniquement j'y comprend rien
mais ça marchait bien avant !
et les autres hebergeur en mutualisé n'ont pas ce soucis
donc pourquoi ovh doit subir ce genre de problème alors que pendant 20 ans vous ne l'aviez pas ?!