Aller au contenu

Benoît GEORGELIN

Administrateurs
  • Compteur de contenus

    27
  • Inscription

  • Dernière visite

  • Jours gagnés

    4

Benoît GEORGELIN a gagné pour la dernière fois le 2 novembre

Benoît GEORGELIN a eu le contenu le plus aimé !

Réputation sur la communauté

7 Neutral

À propos de Benoît GEORGELIN

  • Rang
    Associé yulPa | Expert infrastructure
  • Date de naissance 14/01/1886
  1. 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
  2. ralentissement dans les temps d'accès

    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
  3. Ralentissements

    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
  4. ralentissement dans les temps d'accès

    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.
  5. Comportement bizarre de file_exists() en php

    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.
  6. Ralentissements

    Entendu, merci
  7. Ralentissements

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

    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
  9. Ralentissements

    Bonjour, quel est votre site?
  10. Ralentissements

    Bonjour, que dit Doyouchek aujourd'hui ? Il devrait être content
  11. [VPS-LXC] Lancement Pré-Béta des VPS sous LXC

    Répondu par ticket
  12. [VPS-LXC] Lancement Pré-Béta des VPS sous LXC

    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
  13. Ralentissements

    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
  14. Newsletter

    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.
  15. Signification du .io

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