Jump to content

Lafuente

Members
  • Content Count

    26
  • Joined

  • Last visited

  • Days Won

    12

Lafuente last won the day on October 6 2017

Lafuente had the most liked content!

Community Reputation

9 Neutral

About Lafuente

  • Rank
    Newbie

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Bonjour, Ça devait être quelque chose comme ça puisqu'en ré-initialisant mes extensions, dont "NoScript", j'ai à nouveau accès au manager. Question pour la culture personnelle : quel est l’intérêt d'un captcha transparent ? Merci, Manu Edit : je pense que le problème était plus lié à crisp.im et/ou crisp.chat qui était bloqué
  2. Bonjour, J'essaie de me connecter au manager iwall depuis Firefox mais je n'y arrive pas. J'ai essayé avec deux systèmes différents : Firefox 67.0.2 (x64) Firefox 67.0.1 (x86) Dans les deux cas après m'être identifié, j'obtiens une page blanche. Est-ce un problème de mon coté ou bien coté firefox/iwall ? Il y a moins d'un mois, sur les mêmes configurations, je n'avais aucun problème. Sur les deux machines test, en utilisant IE cela fonctionne correctement. Merci du retour, Manu Edit : dans les deux cas de non fonctionnement, je ne reçois pas de mail confirmant ma connexion comme c'est habituel, comme si je n'étais pas loggué
  3. Bien que PDO soit actif dans iwal, lorsque je tapes "php -m" dans putty, voici ce que j'obtiens : Donc pas de PDO
  4. Bonjour, Je suis face à ce même problème. Lorsqu'on lance la commande OCC, que ce soit directement ou bien par PHP, on obtient systèmatiquement le message d'erreur suivant : PHP Fatal error: Class 'PDO' not found in /datas/vol1/fenixecu.com/var/www/cloud.fenixecu.com/htdocs/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/DriverManager.php on line 172 J'ai essayé en v7.0 et v7.2 de PHP sans changement. Dans l'interface iwall j'ai bien les extension PDO présentes dans mon php.ini. Que faire svp ? Cordialement, Manu
  5. Bonjour, Je rencontre un problème sur le site https://www.fenixecu.com du au passage en https. Dans le menu à droite de la homepage il y a un lien vers l a page des téléchargements. Cette page contient plusieurs catégories. Dans ce même menu il y a des liens directs vers les derniers fichiers. Lorsque l'on clique sur le lien "téléchargement" la page proposant les différentes catégories s'affiche correctement. Le problème : Si l'on veut rentrer dans une catégorie, ou si l'on veut télécharger un fichier en cliquant sur son nom sur la homepage, il y a une erreur. Le système rajoute un :80 après le nom du site ce qui aboutie à une erreur. Ainsi, par exemple, https://www.fenixecu.com/remository/Megasquirt/Guide-du-Microsquirt-Module-v2.2/ devient https://www.fenixecu.com:80/remository/Megasquirt/Guide-du-Microsquirt-Module-v2.2/ J'ai beau chercher dans l'interface admin, je ne trouve pas de réglage susceptible de créer cette ré-écriture. Le site est en jommla 1.5 et l'extension est remository. J'ai également regardé le .htaccess sans trouver quoi que ce soit. Je n'ai pas forcement le temps de refaire ce site avec un CMS plus récent et j'aimerais bien comprendre ce qu'il se passe. Par avance, merci.
  6. Bonjour, Je suis désolé de constater que les ralentissements reviennent. Aujourd'hui quasi impossible de travailler en BO. Ce problème n'est pas "constant". Autant desfois une mise à jour produit va se faire en 2 clicks, autant elle ne se fera jamais car le système "hang". Merci de prendre en compte le problème. Cordialement, Manu
  7. Bonjour tout le monde. je rejoins Plow, depuis hier ca tourne très bien ! Question : moi je n’ai rien changé sur mon « applicatif », donc j’en conclu que quand ça tourne mal le problème n’est pas de mon coté ? Je croise les doigts pour que cet état de fonctionnement perdure !
  8. @Alex je ne suis pas sûr que l'herbe soit plus verte à coté et comme je ne suis pas joueur de poker, je déteste l'idée de "payer pour voir" 😳 Pour les vps, on en parle beaucoup mais honnêtement l'administration quotidienne d'un vps n'est pas une tâche facile, surtout dans mon cas pour une boutique ou l'aspect "financier" est primordial, donc l'aspect "sécurité" qui va avec. Et la sécurité en informatique est un emploi à plein temps. Y'a pas de chomage dans cette branche ! Une faille dans le système est c'est une société entiere qui est en danger... Ne rien faire ? C'est à nouveau une société entiere qui est en danger car la concurrence elle n'attend pas (elle a plus de moyens). De plus l'attente des utilisateurs évolue également, et pas à la baisse. C'est pour cela que j'essaie d'optimiser mon site au maximum. Maintenant c'est vrai que quand je regarde le rapport temps investi/resultat je suis un peu déçu. Et de plus je suis maintenant à la limite des mes possibilités techniques, sauf à refaire un nouveau site ce qui est hors de question. Il est ou le bon temps des prestashop 1.3 qui tournaient sur un céléron 😞
  9. @Benoît GEORGELIN merci pour cet éclaircissement. C'est effectivement le principe du mutualisé et je l'entends ainsi. Cependant il y a des variations que je ne m'explique pas que par l'augmentation des connexions simultanées. En effet le temps de chargement de la page n'est jamais régulier, mêmes à des heures de faible charge. N'y aurait-il pas des corélations possibles entres certaines tâches de l'infra (backup, resync, etc...) ? Vous semblez avoir un ou plusieurs reverse-proxy. N'y a t'il pas un impact de ce coté là ? Les ressources sont-elles remise à dispo assez rapidement après utilisations (sockets) ? @plow personnellement ce n'est pas le backoffice qui me dérange le plus mais plutôt le frontend. Et d'ailleurs le backoffice prestashop est relativement confortable en utilisation. Évidement beaucoup moins rapide que sur un vps mais comme je suis le seul à l'utiliser ;-) Enfin je souligne que mon expression de ce constat n'est pas un jugement négatif de Yulpa.io et que je suis conscient du travail fourni par l'équipe. On essaye de faire mieux avec ce qui existe et je sais que ce n'est pas facile. merci à tous. Manu
  10. Enfin pour conclure, il est notable que sans modification de l'applicatif, les temps d'accès varient dans le temps. Il semble y avoir une période "lente" assez quotidienne entre 19h et 21h, et on constate une variation régulière des temps de chargement d'un jour à l'autre. Benoit dit : Il est donc important de se demander pourquoi on constate des écarts significatifs sur un même site, donc a applicatif égal, dans le temps.. Je souhaite ce débat constructif ;-)
  11. Et pour finir un site WP/Woocommerce pas du tout optimisé mais avec un vps : 6 Mo en 6s... Il serait intéressant de trouver un juste milieu
  12. Accessoirement, vous avez un bug dans l'affichage du temps depuis la dernière réponse sur votre forum lorsque l'on utilise une tablette apple. Il est écrit "%d" au lieu du temps ;-)
  13. Et pour les 2 sites wordpress : Dans ces 4 exemples, ce n'est pas le ping qui pour moi a de l'importance, mais le "Fully Loaded Time". J'ai constaté que ce temps de chargement de page est surtout impacté par le TTFB (Time To First Bit). Ce temps est effectivement maitrisable du coté de l'applicatif web en utilisant des techniques de cache, mais c'est complexe. N'y a t'il pas moyen de l'optimiser de votre coté ?
  14. Salut Aurélien, Il est évident que l'applicatif web est important. Mais je pense que les personnes ici présentes en sont conscientes et essaient d'en tenir compte. Moi je peux assurer en tenir compte et essayer d'optimiser mon applicatif. Pour le montrer, le troisième site que tu proposes, ultimaterra, nécessite 145 requêtes pour charger 2.85Mb de datas ! Mon propre site charge 1.86Mb en 71 requêtes. Je ne comprends donc pas pourquoi tu cite ce site en référence dans ta question. Pour le mauvais exemple ? Aurais-tu un exemple de site prestashop 1.6.1 afin que je puisse comparer si mon "applicatif" déconne ? Par avance merci, Manu
  15. Bonjour Aurélien, Pour moi également ce n'est pas le ping qui importe mais "l'expérience utilisateur". Et là je rejoins Alexis => le temps de téléchargement des pages est "long", même en back-office. Passer du temps à optimiser les images et le reste pour augmenter la fluidité d'un site a ses limites et encore faut-il en être conscient. Mr X n'optimise pas ses images par exemple. Moi je pencherais pour un problème applicatif serveur ou sécurité... Car je viens de faire le test suivant : Copie 1:1 d'un de mes sites internet sur un VPS SSD à 3€/mois (1vCore 2,4GHz, 2Go RAM et 10Go SSD). Distribution CentOS. Les résultats sont de loin sensibles... Sur le VPS les pages s'affichent, elles ne se "chargent" pas. Et idem en backoffice. Et je n'ai pas utilisé de module cache... ++ Manu
×
×
  • Create New...