Erreur site internet www.myiallaparis.fr

[Thomas.C]

Bonjour,

Oui au temps pour moi, je n'avais pas vu le nom de domaine dans le titre.
Personnellement, je n'ai pas de problème pour accéder à votre site.
La page que vous m'avez fournie s'est chargée en une demi-seconde.

Cordialement,
Thomas C.

[MyriamA1]

quand on passe commande j'ai l'erreu gateway oublie de mot de passe aussi
et mes clientes pareil elle m'indique cette erreur

[MyriamA1]

que dois je faire j'ai des personnes qui souhaite passer commande et la c'est vraiment urgent

[Thomas.C]

Je n'arrive pas à reproduire vos erreurs. L'accès à la page de mot de passe perdu fonctionne.
Et je ne vais pas pouvoir commander pour tester..

Par contre je vois que vous n'êtes pas sur un SSLGateway mais sur un mutu.
Avez-vous fait des mises à jour sur votre site récemment ?

[MyriamA1]

non pas de mise à jours " j'ai rajouté un produit sur mon site uniquement "
la. connexion est très très lente

[kyodev]

ce n'est pas stable pour le moins:

23 requêtes   3,04 Mo / 2,34 Mo transférés   Terminé en : 52,17 s  load: 52,26 s

time wget -p -o /dev/null www.myiallaparis.fr
real	0m9,476s
real	1m1,735s
real	0m9,819s
...

et ça c'est un problème déjà vu:

Chargement des pages anormalement long

Ovh n'a pas les moyens de monitorer ses installations j'ai l'impression, et rien n'a été fait depuis

[kyodev]

24/08/2018 11:45:09 +0200	0 mn 7,520 s
24/08/2018 11:50:58 +0200	0 mn 56,570 s
24/08/2018 11:55:09 +0200	0 mn 7,999 s
24/08/2018 12:01:05 +0200	1 mn 4,191 s
24/08/2018 12:05:59 +0200	0 mn 57,618 s
24/08/2018 12:10:09 +0200	0 mn 7,217 s
24/08/2018 12:15:09 +0200	0 mn 8,204 s
24/08/2018 12:20:08 +0200	0 mn 7,206 s
24/08/2018 12:25:10 +0200	0 mn 8,937 s
24/08/2018 12:30:14 +0200	0 mn 7,010 s
24/08/2018 12:35:59 +0200	0 mn 57,244 s
24/08/2018 12:40:08 +0200	0 mn 6,481 s
24/08/2018 12:45:59 +0200	0 mn 56,530 s
24/08/2018 12:52:13 +0200	0 mn 57,061 s
24/08/2018 12:55:07 +0200	0 mn 5,333 s
24/08/2018 13:01:11 +0200	0 mn 58,107 s
24/08/2018 13:06:50 +0200	1 mn 47,431 s
24/08/2018 13:10:07 +0200	0 mn 5,131 s
24/08/2018 13:15:58 +0200	0 mn 56,660 s
24/08/2018 13:20:24 +0200	0 mn 22,435 s
24/08/2018 13:25:57 +0200	0 mn 56,092 s
24/08/2018 13:30:07 +0200	0 mn 5,579 s
24/08/2018 13:35:09 +0200	0 mn 7,625 s
24/08/2018 13:40:08 +0200	0 mn 6,333 s
24/08/2018 13:46:19 +0200	1 mn 9,420 s
24/08/2018 13:50:25 +0200	0 mn 23,436 s
24/08/2018 13:55:09 +0200	0 mn 5,925 s
24/08/2018 14:00:08 +0200	0 mn 6,231 s
24/08/2018 14:05:59 +0200	0 mn 57,981 s
24/08/2018 14:10:20 +0200	0 mn 12,384 s
24/08/2018 14:15:08 +0200	0 mn 6,611 s
24/08/2018 14:21:23 +0200	1 mn 10,883 s
24/08/2018 14:25:09 +0200	0 mn 5,945 s
24/08/2018 14:32:33 +0200	2 mn 25,004 s
24/08/2018 14:35:28 +0200	0 mn 20,565 s
24/08/2018 14:40:16 +0200	0 mn 8,120 s
24/08/2018 14:45:09 +0200	0 mn 6,466 s
24/08/2018 14:50:10 +0200	0 mn 8,617 s
24/08/2018 14:55:59 +0200	0 mn 56,778 s
24/08/2018 15:00:26 +0200	0 mn 23,932 s
24/08/2018 15:05:59 +0200	0 mn 57,803 s
24/08/2018 15:10:09 +0200	0 mn 6,189 s
24/08/2018 15:15:08 +0200	0 mn 6,897 s
24/08/2018 15:20:27 +0200	0 mn 24,782 s
24/08/2018 15:26:16 +0200	1 mn 13,607 s
24/08/2018 15:30:41 +0200	0 mn 38,778 s
24/08/2018 15:35:10 +0200	0 mn 8,808 s
24/08/2018 15:41:09 +0200	0 mn 57,699 s
24/08/2018 15:45:13 +0200	0 mn 9,631 s
24/08/2018 15:50:09 +0200	0 mn 6,932 s
24/08/2018 15:56:02 +0200	0 mn 52,686 s
24/08/2018 16:01:03 +0200	0 mn 54,817 s
24/08/2018 16:05:09 +0200	0 mn 7,206 s
24/08/2018 16:11:12 +0200	1 mn 10,481 s
24/08/2018 16:15:09 +0200	0 mn 7,231 s
24/08/2018 16:20:09 +0200	0 mn 7,473 s
24/08/2018 16:25:11 +0200	0 mn 9,025 s
24/08/2018 16:25:32 +0200	0 mn 21,132 s
24/08/2018 16:30:24 +0200	0 mn 22,865 s
24/08/2018 16:35:14 +0200	0 mn 11,140 s
24/08/2018 16:41:00 +0200	0 mn 58,112 s
24/08/2018 16:41:56 +0200	0 mn 56,534 s
24/08/2018 16:46:48 +0200	1 mn 47,448 s
24/08/2018 16:50:09 +0200	0 mn 7,013 s
24/08/2018 16:55:59 +0200	0 mn 57,412 s
24/08/2018 17:00:20 +0200	0 mn 17,389 s
24/08/2018 17:06:04 +0200	0 mn 54,790 s
24/08/2018 17:10:10 +0200	0 mn 7,698 s
24/08/2018 17:15:11 +0200	0 mn 9,754 s
24/08/2018 17:20:11 +0200	0 mn 8,948 s
24/08/2018 17:25:08 +0200	0 mn 6,921 s
24/08/2018 17:31:05 +0200	0 mn 55,946 s
24/08/2018 17:35:08 +0200	0 mn 6,787 s
24/08/2018 17:41:13 +0200	1 mn 2,870 s
24/08/2018 17:45:19 +0200	0 mn 17,421 s
24/08/2018 17:50:10 +0200	0 mn 7,373 s
24/08/2018 17:55:16 +0200	0 mn 14,135 s
24/08/2018 18:01:59 +0200	1 mn 46,219 s
24/08/2018 18:05:11 +0200	0 mn 8,456 s
24/08/2018 18:10:29 +0200	0 mn 13,332 s
24/08/2018 18:15:09 +0200	0 mn 6,542 s
24/08/2018 18:21:03 +0200	0 mn 54,528 s
24/08/2018 18:25:08 +0200	0 mn 6,639 s
24/08/2018 18:30:09 +0200	0 mn 7,251 s
24/08/2018 18:35:09 +0200	0 mn 7,013 s
24/08/2018 18:41:00 +0200	0 mn 57,768 s
24/08/2018 18:45:06 +0200	0 mn 5,097 s
24/08/2018 18:51:07 +0200	1 mn 6,601 s
24/08/2018 18:55:10 +0200	0 mn 8,664 s
24/08/2018 19:01:04 +0200	0 mn 55,052 s
24/08/2018 19:05:10 +0200	0 mn 7,712 s
24/08/2018 19:10:58 +0200	0 mn 55,885 s
24/08/2018 19:15:59 +0200	0 mn 57,644 s
24/08/2018 19:20:11 +0200	0 mn 8,601 s
24/08/2018 19:25:07 +0200	0 mn 4,954 s
24/08/2018 19:30:08 +0200	0 mn 6,298 s
24/08/2018 19:35:07 +0200	0 mn 5,615 s
24/08/2018 19:40:09 +0200	0 mn 7,417 s
24/08/2018 19:45:10 +0200	0 mn 7,792 s
24/08/2018 19:51:04 +0200	0 mn 55,920 s
24/08/2018 19:56:02 +0200	0 mn 55,441 s
24/08/2018 20:01:06 +0200	0 mn 56,137 s
24/08/2018 20:05:07 +0200	0 mn 5,681 s
24/08/2018 20:10:41 +0200	0 mn 38,921 s
24/08/2018 20:16:14 +0200	1 mn 12,528 s
24/08/2018 20:21:57 +0200	1 mn 45,828 s
24/08/2018 20:26:07 +0200	1 mn 2,915 s
24/08/2018 20:31:52 +0200	1 mn 45,032 s
24/08/2018 20:35:08 +0200	0 mn 6,866 s
24/08/2018 20:41:07 +0200	1 mn 4,384 s
24/08/2018 20:45:51 +0200	0 mn 39,445 s
24/08/2018 20:50:08 +0200	0 mn 6,020 s
24/08/2018 20:55:08 +0200	0 mn 5,788 s
24/08/2018 21:00:10 +0200	0 mn 7,633 s
24/08/2018 21:05:08 +0200	0 mn 6,454 s
24/08/2018 21:11:04 +0200	0 mn 55,616 s
24/08/2018 21:15:09 +0200	0 mn 6,011 s
24/08/2018 21:20:07 +0200	0 mn 5,756 s
24/08/2018 21:26:03 +0200	0 mn 55,098 s
24/08/2018 21:31:02 +0200	0 mn 54,793 s
24/08/2018 21:35:09 +0200	0 mn 7,547 s
24/08/2018 21:40:08 +0200	0 mn 5,767 s
24/08/2018 21:45:10 +0200	0 mn 8,106 s
24/08/2018 21:50:09 +0200	0 mn 7,531 s
24/08/2018 21:55:10 +0200	0 mn 8,054 s
24/08/2018 22:00:09 +0200	0 mn 6,913 s
24/08/2018 22:05:59 +0200	0 mn 56,494 s
24/08/2018 22:10:09 +0200	0 mn 7,200 s
24/08/2018 22:10:13 +0200	0 mn 4,277 s

[MyriamA1]

merci pour votre aide

[Buddy]

Ce serait quand même bien d'optimiser un peu le site.

GTmetrix Performance Report: F (32%) / D (61%)

La mise en cache des images se fait rapidement..

L'optimisation des images il y a des plugins pour ça normalement.

[kyodev]

l'optimisation du site ne changera rien sur un serveur qui sert une page en plus d'une minute au lieu de 5/6s ...

loi de pareto, il ne faut pas commencer par les détails ;)

[Buddy]

l'optimisation du site ne changera rien sur un serveur qui sert une page en plus d'une minute au lieu de 5/6s ...

Beh si c'est un dépassement de ressources qui entraîne le temps de chargement élevé si car la mise en cache libérera des socket apache..
Puis mettre en cache les images en ajoutant 20 lignes au htaccess ce n'est pas ce qui prend le plus de temps.. (5min maxi..)

Apres aussi sous quels environnement et version de php tourne le site ?

[kyodev]

oui, mais voilà, une rapide analyse dev tools, on voit sur quoi ça coince, sans avancer d'hypothèses
une expérience pratique d'une même site sur deux hébergements, la comparaison est sans photos, et c'est un souci commun.
(des détails ont été envoyés en MP, mais ce n'est pas l'objet du problème ici: lire posts initiaux)

[Buddy]

J'ai bien vu les posts initiaux, je ne vois nullepart les graphs de dépassement de ressources ou non chez Ovh.. (ou des requêtes distantes en timeout..)

Je n'arrive pas à reproduire son problème d'ailleurs..

Si c'est un dépassement de ressources/de timeout sur des requêtes exterieurs ce n'est pas anormal que ça marche mieux ailleurs sur un hébergement de test..

Mettre en cache des images ou mettre un php plus récent ne prend pas longtemps... Et de toute façon il faudra le faire un jour ou l'autre donc autant le faire.

[kyodev]

ok tu dois savoir tout

j'ai pourtant montré comment je teste, un wget c'est pas compliqué.
une comparaison à l'identique entre hébergeurs, doit être trop simple(t) pour toi.
si tu tolères de telles variations, ma foi, le syndrome de Stockholm doit intervenir et moi je sors de mes domaines d'interventions ;)

[Buddy]

Je ne dis pas que je le tolère ni que c'est normal (je n'ai pas de mutualisé d'ailleurs..) mais que si les sockets apache sont saturés - i.e. dépassement de ressources - (trop de requêtes ou des timeout sur des connexions sortantes) c'est exactement le résultat que l'on obtient.. Il y a plein d'exemples sur le forum.

Après tu lis/comprends ce que tu as envie de lire/comprendre..

[kyodev]

alors moi je comprends:

• j'optimise, je suis doué, je gagne 3s sur un nominal de 6s
• si le serveur, et ce depuis des semaines, sort la page en 60-3=57s... quelle affaire !

et j'ai constaté des temps de deux minutes, sur des pages deux fois fois plus légères. là aussi, suivre les liens donnés

[Buddy]

L'optimisation ne fera pas gagner que 3 s.. Car il faut savoir si la requête qui mets 57sec dure réellement
57sec de generation
Ou
55s en attente, 2 sec de génération

Le serveur mutualisé chez Ovh dispose d'un nombre limité de worker apache/php (qui varie selon l'offre)

Prenons l'exemple de 10 workers.

Si 9 workers sont utilisés pour générer une page php, alors il n'en reste qu'un qui peut gérer les images/css et autres ressources statiques. (les requêtes entrantes sont donc en attente le temps qu'un worker se libère et ça peut bien prendre plusieurs dizaines de secondes..)
Si il faut générer une 10eme page php alors ce n'est pas impossible que même un fichier statique soit en attente d'un socket apache soit disponible.

Donc 1) si php est "optimisé" (par exemple php 7.2 qui est 30% plus rapide que php 5.6, les pages php sont générées plus rapidement et donc un worker peut gérer plus de requêtes par minute) il y aura peut être que 6 workers utilisés pour générer des pages php et donc 4 disponibles pour traiter les requêtes de fichiers statiques.

2)si les images et autres fichiers statiques sont en cache, ça fait autant de requêtes en moins et donc la page chargée plus vite.

3) avec l'environnement stable, ça évite les timeout/rejet pour cause de TLS 1 non suffisamment sécurisé sur des requêtes en https au lieu de TLS 1.2

Je ne dis pas que le problème vient forcément de là mais si il y a des dépassement de ressources oui et ce genre d'optimisation est relativement facile /rapide à mettre en place et tester.

[kyodev]

c'est ça, blabla théorique, juste, mais théorique

encore faut il suivre, j'ai testé sur un site, pas compliqué, html only + js embarqué.
page deux fois moins lourde, temps couramment 2x fois plus long (2mn!)

sur autre hébergeur, sans retouches, temps constant et stable correspondant à la vitesse basse soit 2s.

alors les optimisations... (voir pareto)
maintenant, une fois transféré j'ai loisir d'optimiser, l'utilisateur est beaucoup plus serein.

depuis, je perds même plus de temps à observer finement, tout le monde voit bien la différence si un transfert est fait.

faut observer un problème dans son contexte, car là bingo, tu centres, je ne sais par quel intérêt, le débat sur du détail mineur, là, présentement, sur cet hébergement.

[Buddy]

Avec les informations disponibles ici, c'est difficile d'éviter la possible surcharge des workers, après si tu as plus d'informations et que tu as récupéré une cliente tant mieux pour toi, je ne vends rien moi donc je m'en moque.

[kyodev]

allez, encore des paroles gratuites...

• je ne vends rien
• les infos je vais les chercher, dev tools, curl et expérience/habitude
• et j'hésite pas à lire tout