Jump to content

1-Click Upgrade

Pyanepsion

By Pyanepsion
in Discussion générale

 Share

Recommended Posts

Pyanepsion Newbie

Pyanepsion

Posted
Posted

Bonjour à tous.

La mise à jour de 1-Click Upgrade ne se fait pas, car le délai de latence est trop important. J’ai été obligé de faire la mise à jour à la main.

Citation

PHP's max_execution_time setting has a high value or is disabled entirely (current value: 165 seconds)

Le site est hébergé sur un serveur mutualisé OVH.

Comment corriger cette valeur ?

Merci pour vos explications.

 

1-click-upgrade.jpg

Link to comment
Share on other sites
Pyanepsion Newbie

Pyanepsion

Posted
  • Author
Posted

😃 Merci, Magicbel, pour cette remarque de bon sens, mais la question n’est pas de changer d’hébergement. Il s’agit ici de résoudre le problème de l’utilisation de 1 -Click Upgrade qui exige bizarrement un temps d’exécution PHP supérieur à 165 s. Il s’agit tout de même de 2 min 25 s.

(L’hébergement est un hébergement web Performance à 12 € par mois vendu comme étant « optimisé pour Prestahop ». J’aurais bien proposé l’hébergement du site sur mon propre serveur, mais Prestashop ne respecte pas le standard de programmation, ce qui le rend incompatible avec NGinx, et il ne fonctionne pas sur PHP 8, ni même sur PHP 7.4, ce qui m’obligerait à installer une version PHP un peu ancienne.)

Il doit bien y avoir une solution pour corriger ce problème de 1 - Click Upgrade. Comment faire sans obliger à une installation manuelle ?

Link to comment
Share on other sites
Pyanepsion Newbie

Pyanepsion

Posted
  • Author
Posted

Pour faire plus court, OVH n’est pas à blâmer.

☺️Je dirais plutôt qu’il est ahurissant que le lève-vitre de ma voiture nécessite d’être branché en permanence sur une centrale nucléaire juste pour obtenir la puissance nécessaire à son action. Obliger à un max_execution_time supérieur à 165 s pour une simple mise à jour, faut quand même pas pousser.

Link to comment
Share on other sites
Johann Contributor

Johann

Posted
Posted

il existe aussi d'autres modules de mise à jour, qui ne font pas tout le traitement de manière atomique, donc ne nécessitant pas un execution_time délirant

autre piste : dupliquer le site en local (wamp ou autre), mettre un time de 1800, faire l'update en local, et réuploader tout (ftp + bdd) chez l'hébergeur après. Chiant mais efficace

Link to comment
Share on other sites
solsol69 Proficient

solsol69

Posted
Posted (edited)
Il y a 14 heures, Pyanepsion a dit :

L’hébergement est un hébergement web Performance à 12 € par mois vendu comme étant « optimisé pour Prestahop

OVH sont des spécialistes pour trouver des noms accrocheurs a leurs hébergement merdique.

Vous payez plus  de 150 € à l'année Pour un hébergement qui est même pas foutu d'être un minimum paramétrable.

Edited by solsol69 (see edit history)
Link to comment
Share on other sites
magicbel Community Regular

magicbel

Posted
Posted
Il y a 3 heures, Johann a dit :

autre piste : dupliquer le site en local (wamp ou autre), mettre un time de 1800, faire l'update en local, et réuploader tout (ftp + bdd) chez l'hébergeur après. Chiant mais efficace

Sans parler que ca évite de crasher son site en direct live 🤣

Faire un update sur un site en production, faut être motivé ! (et avoir une confiance aveugle dans le module 1click) 🙄

  • Like 1
Link to comment
Share on other sites
Mediacom87 Grand Master

Mediacom87

Posted
Posted
Il y a 4 heures, magicbel a dit :

et avoir une confiance aveugle

je dirais même plus dans toute la chaine technique, serveur, base de données, électricité, humain, ovh ainsi de suite, tout peut planter à tout moment alors, la moindre action doit être sécurisé par une sauvegarde intégrale avant avec une procédure maitrisé pour la restauration.

 

Link to comment
Share on other sites
doekia Community Regular

doekia

Posted
Posted
Il y a 9 heures, Pyanepsion a dit :

Obliger à un max_execution_time supérieur à 165 s pour une simple mise à jour, faut quand même pas pousser.

J'aime les phrases qui claquent mais n'ont aucune réalité technique. Une prestashop, c'est 400 tables que la mise à jour va convertir/manipuler/ajuster pour qu'elles correspondent au nouveau schéma. On multiplie par le nombre de version dans le up, et on s’aperçoit alors que 165s c'est pas tant que ça.

Faut arrêter avec avec l'effet Dunning-Kruger, et autre punch line toutes faites

Link to comment
Share on other sites
Jean Francois G Explorer

Jean Francois G

Posted
Posted
On 4/14/2021 at 7:39 AM, Pyanepsion said:

😃 Merci, Magicbel, pour cette remarque de bon sens, mais la question n’est pas de changer d’hébergement. Il s’agit ici de résoudre le problème de l’utilisation de 1 -Click Upgrade qui exige bizarrement un temps d’exécution PHP supérieur à 165 s. Il s’agit tout de même de 2 min 25 s.

(L’hébergement est un hébergement web Performance à 12 € par mois vendu comme étant « optimisé pour Prestahop ». J’aurais bien proposé l’hébergement du site sur mon propre serveur, mais Prestashop ne respecte pas le standard de programmation, ce qui le rend incompatible avec NGinx, et il ne fonctionne pas sur PHP 8, ni même sur PHP 7.4, ce qui m’obligerait à installer une version PHP un peu ancienne.)

Il doit bien y avoir une solution pour corriger ce problème de 1 - Click Upgrade. Comment faire sans obliger à une installation manuelle ?

Magicbel fait juste remarquer que les hébergement mutualisés OVH ne sont pas à la hauteur de ce qu'ils annoncent. De plus dans la majorité des cas, vous n'avez aucun acces au paramétrage de PHP.ini. Si vraiment vous souhaitez rester sur du mutualisé pour vous simplifier la vie, d'autres solutions comme o2switch ou consoeurs vous propose  du mutualisé vraiment paramétrable via cpanel pour moins de 70€ par an. Vous ferez des économies.

Link to comment
Share on other sites
Pyanepsion Newbie

Pyanepsion

Posted
  • Author
Posted

Merci pour toutes ses explications.

Cela dit, il convient de revenir à la question initiale. 1-Click-Upgrade estime que 165 s sont insuffisantes pour réaliser sa tâche. Comment déterminer la bonne valeur ?

165 s, c’est évidemment beaucoup par rapport à d’autres outils. Les 100 s que j’ai fixées arbitrairement pour chaque site qui en a besoin sur mon propre serveur suffisent très largement. Beaucoup de ces sites sont pourtant bien plus conséquents que le mini site PrestaShop dont on parle ici et qui n’est jamais que la version initiale de PrestaShop, un thème et quelques modules.

Puisque OVH limite fort heureusement ses mutualisés à 165 s sinon quelle pagaille, j’ai donc installé un PrestasHop de base sur mon propre serveur.

J’ai tout d’abord cherché la valeur minimale de max_execution_time permettant d’ouvrir PrestaShop. 3 s.

Voici plus précisément ce que déclare 1-Click-Upgrade :

max_execution_time-3.thumb.png.91019d0ac95a238e5b6b79ef49e80164.png

J’ai ensuite mis une valeur de 100 s que j’ai doublé à chaque essai. J’ai arrêté à 102 400 s (1 jour 4 h 26 min 40 s) en estimant qu’il ne faut quand même pas exagérer : après tout, la mise à jour à la main en FTP ne demande jamais que quelques secondes.

IRegardez : il a de la constance ce 1-Click-Upgrade. ☺️

max_execution_time-102400.thumb.png.8339f50e97a24dbd62b15f759021b41a.png

1- Click-Upgrade dit systématiquement : 

Citation

Le paramètre max_execution_time de PHP a une valeur élevée ou est entièrement désactivé (valeur actuelle : xxx secondes).

On croirait du miel chinois (Fabriqué dans ou hors EU). Alors, comment faire pour trouver la bonne valeur ?

Link to comment
Share on other sites
doekia Community Regular

doekia

Posted
Posted

Au lieu de perdre son temps à faire des milliers de test: 

                    <td>
                        {% if maxExecutionTime == 0 %}
                            {{ 'PHP\'s max_execution_time setting has a high value or is disabled entirely (current value: unlimited)'|trans }}
                        {% else %}
                            {{ 'PHP\'s max_execution_time setting has a high value or is disabled entirely (current value: %s seconds)'|trans([maxExecutionTime]) }}
                        {% endif %}
                    </td>
                    <td>
                        {% if maxExecutionTime == 0 %}
                            {{ icons.ok }}
                        {% else %}
                            {{ icons.warning }}
                        {% endif %}
                    </td>

Le seul cas pour avoir un icone OK est de mettre 0 en max_execution_time

 

Considerer donc ce message comme une alerte pour servir à se rappeler que le max_execution_time peut bloquer la mise à jour.

Donc oui ce message est un peu idiot mais n'a pas de vraie importance en soit.

  • Like 1
Link to comment
Share on other sites
Pyanepsion Newbie

Pyanepsion

Posted
  • Author
Posted

😉Je disais plutôt dans le premier message que selon 1-Click-Upgrade, le script de mise à jour ne peut pas fonctionner avec 165 s, et effectivement il ne fonctionne pas. J’ai dû faire la mise à jour à la main pour passer de la 1.7.7.2 à la 1.7.7.3.

Dans le dernier message, je demandais comment déterminer la bonne durée puisque 1-Click-Upgrade affiche apparemment toujours le même message, quelle que soit la valeur utilisée pour max_execution_time.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share
Go to topic listing
×
×
  • Create New...