Benoît G

Bonjour, Votre analyse est bonne. Nous devrions trouver un endroit ou indiquer cela. Merci pour cette remontée

Bonjour, Ca devrait être bon , nous avons mis l'outil sur les serveurs SSH. Vous devriez pouvoir l'utiliser correctement' /opt/alt/python36/bin/nextcloud-news-updater -v 10.0.0 Si vous voulez partager son utilisation plus en détail pour la communauté utilisant les services d'hébergement chez :yulPa ce serait un plus Merci

Il y a une différence dans la journée versus la nuit ou aux heures de pointe. Il y a du trafic plus important , cela à un impact sur le système de manière globale mais que je ne considère pas comme une "surcharge" . C'est un comportement normal , plus il y a de connexion , plus le système travaille . On le constate bien la nuit oui c'est beaucoup plus calme et pourtant il n'y a pas de différence du simple au double la nuit versus le jour . Le débat est constructif

Bonjour, nous avons mis à jour la tâche. Le problème est corrigé , retour à la normale au niveau NFS/FILER Nous sommes désolés pour ce problème

Bonjour, Je pense qu'on devrait faire un article de blog pour expliquer plusieurs points importants liés à un mutualisé en général. Ce qui explique souvent les grandes différences entre mutu/dédié Aussi, entre les mêmes sites d'un mutu, les configurations sont multiples, les impactes sur la performance aussi. Par exemple pour un hébergement mutualisé on va avoir des comportements différents avec: - La version de PHP utilisée - La configuration de PHP et principalement open_basedir - Le nombre de sous-repertoires ou est le htdocs . Plus il y a de répertoires plus ca prendra du temps - Le nombre de domaine sur l'hébergement. Plus de domaine, plus de requêtes simultanées , moins de performance Ensuite, le site lui même : - Nombre d'objet (local) par page (image, css, js, etc..) plus il y a d'objets, plus les impacts sont importants - Nombre d'object externe par page - Session PHP ( en base de données VS sur disque) - Moteur de cache ou pas - Gestion des "expires" sur les objets ou pas - Utilisation de la base de données (requêtes SQL) - Niveau de répertoire pour les éléments à charger (image,css,js) encore une fois, plus il y a de niveau , plus c'est long pour une requête. Globalement, je pense que toutes les personnes qui s'intéressent à la performance ont déjà connaissance de la majorité de ces aspects, mais il est bon de le mentionner Au niveau performance des serveurs du mutualisés, chez yulPa, on est loin d'être surchargés. Il est clair que nous avons de plus en plus de clients mutualisés, mais tout est fait pour assurer la monté en charge comme il faut. Si l'on regarde sur les 12 derniers mois par exemple, on peut constater plusieurs cas au niveau des temps de chargement : - Ceux qui n'ont aucune différence - Ceux qui ont une légère augmentation - Ceux qui ont une légère diminution Effectivement, on rencontre bien les trois cas de figure. Ce qui pénalise un client peut favoriser un autre justement à cause des paramètres de configuration de l'hébergement et ceux du site. Notre mutualisé doit répondre aux attentes de la majorité des clients, c'est certain que le temps de réponse et de chargement est important. Vos retours sont toujours pris en compte mais malheureusement, dans certains cas, il est possible que vous soyez dans un "entre-deux" qui fait que vous n'avez pas les performances que vous souhaitez. Dans ce cas la, l'idée est de pouvoir vous proposer une solution permettant de répondre correctement à vos attentes. On est capable de vous proposer des solutions performantes, isolées avec leur propres ressources . C'est ce que nous faisons par exemple pour des besoins comme des boutiques en lignes , des sites qui ne tolèrent pas la moindre augmentation du temps de chargement et qui cherchent quelque chose de constant et de personnalisé. Si demain on vous propose une offre d'hébergement en dehors du mutualisé, avec un serveur web dédié et une base de donnée dédiée , seriez-vous intéressé ? Sachant que les performances/impactes seront totalement différentes versus un mutualisé. On parle ici de quelque chose de plus adapté a certains besoins. Le mutualisé ne peut pas rivaliser avec une solution comme celle-ci, sinon le prix du mutualisé serait considéré comme bien trop cher pour espérer apporter des temps de chargement et de réponse identiques à une solution dédié . Le mutualisé doit garder une stabilité et un temps de chargement acceptable, ce que nous faisons et c'est important. Comme le mentionnait Aurélien, des sites à fort trafic sont en moyenne à 300 ou 400 ms de chargement (pingdom) , sur la même plateforme que des sites qui ont 2 ou 3 secondes de chargement. C'est pour nous des "aléas" du mutualisé suivant le contenu, les configurations client et les configuration de l'hébergement.

Bonjour, a quelle fréquence vous effectuez ceci sur des fichiers qui ont quelle durée de vie? Si c'est quelque chose de rapide, il est possible que le NFS joue un rôle important dans ce problème. Si vous créez un fichier A et que vous essayez de le supprimé dans la seconde qui suit , depuis un autre serveur WEB il est possible que fichier ne soit pas encore présent. Ou bien , le fichier est supprimé sur le serveur 1 et sur le serveur 9 vous faites la vérification si le fichier existe (il existe) et juste avant de le supprimer il n'est plus présent. Le délai est cependant très court normalement.

Entendu, merci

Par curiosité, des utilisateurs remontent ce problème ?

Bonjour, Ces derniers jours, nous avons passé beaucoup de temps pour essayer d'avoir quelque chose de plus linéaire, mais il ne faut pas oublier que c'est un service mutualisé. Nous pourront jamais avoir une configuration qui convient à 100% des sites hébergés. Suivant les CMS utilisés, avec cache ou sans cache etc.. certain sites sont plus optimisés que d'autres. Le plus souvent, nous constatons beaucoup d'appel à des contenus externes ralentissent énormément le chargement global du site. L'optimisation coté site est aussi importante que celle coté serveur, c'est pourquoi nous sommes sensibles à vos demandes et inquiétudes. Nous allons continuer à suivre les temps de chargement de près

Bonjour, quel est votre site?

Bonjour, que dit Doyouchek aujourd'hui ? Il devrait être content

Répondu par ticket

Bonjour, suite à la maintenance de demain sur le réseau (voir https://travaux.yulpa.io/task/33 ) les VPS en béta seront impactés . Une modification de l'adressage IP doit avoir lieu. Nous vous demandons de bien vouloir ouvrir un ticket au support pour traiter votre demande et avoir une nouvelle adresse IP publique pour votre container. Beaucoup de container en bêta sont délaissé et non utilisé. Après cette maintenance, tous les containers non utilisé (donc pas de tickets) seront détruits. Si vous souhaitez prendre de l'avance, vous pouvez aussi dès aujourd'hui nous contacter via le support . Nous pourront remettre en ligne votre container mais sachez que la coupure sera importante pour ce service en bêta test. Prenez vous disposition si vous utilisez votre container de manière quotidienne et que sa disponibilité est importante. Merci

On va essayer de suivre cela de près. Les relevés que vous avez sont effectivement intéressant. Le temps en revanche correspond à un timeout spécifique on dirait. J'ai mis à jour certain timeout, on va voir si le comportement est le même. Tenez nous au courant

Bonjour, Via la fonction mail() de php , nous ne bloqueront pas le compte si la qualité de l'envoi est correct. Si vous avez trop de bounce ou que le contenu est détecté comme SPAM alors effectivement il sera bloqué Concernant le nombre, il est préférable de faire des paquets plutôt que d'envoyer les 5000 d'un coup.

Bonjour, faut que l'on voit pourquoi ce n'est pas proposé effectivement

Bonjour, il y effectivement eu un pique de charge sur l'ensemble des HTTP, comportement étrange que nous surveillons qui n'a pas l'air de se reproduire. En dehors de quelques petites attaques que nous avons eu, rien à signaler.

Voila pour vous emacs est disponible .

Normalement, c'est géré dans les HEADERS , mais la en l’occurrence, je pense que c'est ton client mail qui connait le contact et l'a enregistré de cette façon

J'utilise Lychee depuis longtemps J'aime beaucoup cette solution. Simple et efficace si pas besoin de gestion de droits particulier. Les mises à jour sont faciles aussi , ce qui rend la solution simple à prendre en main et à maintenir . Le comparatif reste néanmoins très intéressant ! Merci

Bonjour, Vous devez modifier le fichier wp-config.php de votre site (via FTP ou via le manager de fichier iWal) pour lui indiquer les nouvelles informations de BD (user/mot de passe/nom de la nouvelle base/serveur/) Bonne journée

Bonjour à toutes et à tous, depuis le 15 avril 2017, yulPa a lancé ses services et assure la continuité des services anciennement publiés par Web4all. Afin de fêter cela et de vous présenter succinctement les services à venir, nous vous convions à une soirée dans le 5ème arrondissement de Paris, le jeudi 18 mai 2017 à 19H15 Benoit GEORGELIN, (demeurant à Montréal) sera présent pour l'occassion ainsi que Aurélien PONCINI. Merci de nous dire si vous serez présent et si vous êtes accompagné merci de le mentionner Nous serons ravi de pouvoir ainsi vous offrir un ou plusieurs verres sans oublier la nourriture qui va avec PS : l'adresse sera communiquée aux inscrits, le 15 mai. La soirée débutera à 19H15. Pour vous inscrire : https://events.yulpa.io/e/1/apero-yulpa

Bonjour, Pour toutes les nouvelles demande, je vous demande de bien vouloir passer par un ticket de support sur iWal svp Plus simple pour le suivi Merci !

Bonjour, c'est en cours de travail. Malheureusement, cette modification impose pour nous de travailler sur la création de nouveaux pool HTTP en apache2.4 Le monde de l'hébergement mutualisé est difficile en cas de changement majeur comme cette version de apache (htacces principalement) Dans le CMS à jour, on retrouve la prise en charge des deux règles de nommage pour certaines instruction qui permet d'assurer une compatibilité 2.2 et 2.4 + Mais de ce que j'ai vu, la grand majorité des .htacces seront non fonctionnels pour niveau gestion d'accès à une ressource. La question se pose donc . Basculer sur 2.4, et imposer aux clients de modifier leur .htaccess (sachant qu'il n'y à pas de risque d'exposer des données protégées par htaccess) une erreur 500 certainement sera affichée. Où mettre en place ce que nous voulons faire depuis 3 ans, diviser notre infrastructure HTTP en plusieurs pools . Des pools pourront rester en 2.2 et des nouveaux en 2.4 Donc, oui nous souhaitons passer en 2.4+ , prochainement oui, mais c'est quand même l'affaire de quelques mois.

Le dieu google dit : Donc effectivement on devrait faire du 301 au lieu du 302 Sachant que l'impact qu'il peut y avoir niveau SEO c'est quand un client qui à un site en HTTP indexé décide de le passer un HTTPS . Le 302 n'est la meilleure chose. A modifier