alexisju

Ah non, le problème web ne serait pas lié au déménagement (en tout cas pas planifié) : https://travaux.yulpa.io/task/142

Yep idem, nos sites web sont injoignables... Sans doute liés aux interventions d'infrastructures... mais bon.. là je sais pas bosser... https://travaux.yulpa.io/tasklist/proj0?order=lastedit&sort=desc Généralement, les prestataires de services IT font ce genre de chose hors des heures de bureau.... ... et puis quelle message d'erreur bien pro, hum 😕 Incident technique en cours Un incident technique rend indisponible la visualisation de ce site. Sur un autre site, j'ai : 504 Gateway Time-out The server didn't respond in time. Si l'erreur persiste, merci de contacter un administrateur Web4all.

Bonjour Aurélien, Merci pour ces précisions. Peut-on néanmoins espérer que les interventions sont planifiées en soirée ou de nuit ?

Plusieurs intervention sont prévues des jours de semaine. Les heures d'interventions ne sont pas mentionnées (ni dans l'article, ni sur l'outil de suivi des travaux). Quelles sont-elles? Peut-on espérer que les coupures ne se passent qu'en dehors des heures bureau, en soirée ou de nuit? Merci d'avance!

Oui, c'est bien la question que les clients se posent. Mais je ne comprends pas bien que cette "question" provienne du prestataire de service... et soit adressée en retour aux clients.

@Aurélien PONCINI quelle est la question, au juste?

Bonjour, Je suis partagé sur votre réponse. J'ai l'impression que la plupart des personnes qui s'expriment ici le font en connaissance de cause. On connaît l'implication d'une plateforme mutualisée et la multiplicité des facteurs. Pour ma part, je n'attends pas des performances top niveau, mais constate une dégradation sensible. Mais 5-8 secondes en backend quand on crée un article WP n'est pas acceptable...

Pour ma part, je ne mesure pas tant le temps de réponse directe du site (ping), mais le temps de chargement des pages. Dans le backend WP, j'en suis souvent autour des 5 secondes (parfois c'est 3s - rarement en dessous -, mais je suis vite à plus de 8s en load). J'obtiens ces mesures avec le debugeur réseaux de Firefox.

Même constat de mon côté, au quotidien sur plusieurs instances Wordpress hébergées sur Yulpa. Les temps de chargement des pages a sensiblement augmenté ces dernières semaines. La différence est flagrante comparé à d'autres WP que je gère sur d'autres plate-formes... Je reçois également de nombreuses alertes d'Uptime robot ces derniers jours ...

En partant de la NextCloud 11.0.0 (production channel). J'ai réessayé de lancer la mise à jour en ssh : php occ upgrade Mais j'ai systématiquement un message d'erreur du type PHP Fatal error: Class 'PDO' not found J'ai refait des modifications du php.ini via iWal pour activer des extensions supplémentaires (cfr liste des modules théoriquement requis). Mais ça ne semble pas mieux, ni en commande, ni via l'interface graphique de NextCloud...

Zimbra, c'est sympa, mais c'est bien plus qu'un webmail... Et niveau look, on aime ou on aime pas... Pas contre, si on a pas besoin de l'agenda et d'autres fonctionnalités avancées, on peut se contenter d'utiliser le webmail Roundcube. Simple et efficace. Mais Roundcube, ça donne parfois l'impression de retourner 10 ans en arrière. Pourquoi pas lui privilégier un webmail plus moderne, comme Rainloop par exemple? (C'est pas non plus "juste" un "bête" webmail, il y a beaucoup de fonctionnalités qui en font un choix très intéressant)... Je vous laisse tester (par ailleurs, sachez qu'il est tout à fait possible de l'installer sur un hébergement mutualisé)...

Bonjour, J'essaie de mettre à jour une instance de NextCloud hébergée sur la plateforme. Sur iWal, j'ai préalablement modifié le php.ini de l'hébergement concerné, pour augmenter les valeurs (timeout, mémoire, etc). Cependant, la procédure de mise à jour automatique échoue à chaque fois, je dois alors modifier le fichier de configuration pour désactiver le mode maintenance et retrouver un accès. C'est vrai que NextCloud est un peu gourmand pour un hébergement mutualisé (et les procédures de mises à jour manuelles sont généralement décrite pour des serveurs sans restrictions). Mais ça devrait quand même fonctionner dans un environnement un peu plus "limité". D'autres utilisateurs rencontrent-ils également ce problème? Est-ce que vous avez une astuce pour faire la mise à jour facilement et de manière fiable (via SSH)?

C'était attendu depuis longtemps et c'est en effet très appréciable. Merci! :-)