Ce week end, sous Spip 192e et serveur mutualisé, j’ai eu un souci de nombre maximal de connexions simultanées sur MySQL.
Le site est resté difficile d’accès quasi tout le week end.
Mon hébergeur me dit que j’ai sans doute atteint le nombre maximal de connexions simultanées sur MySQL.
Mais il me conseille également de vérifier au préalable que les connexions soient bien fermés à chaque fin d’exécution du script.
Je ne comprends pas le sens de cette dernière phrase ni comment vérifier ou corriger ce problème s’il y a lieu…
Est-ce que quelqu’un peut m’expliquer cette phrase :
« vérifier au préalable que les connexions soient bien fermés à chaque fin d’exécution du script »
et comment les vérifier ???
pour le moment quel est le cache de tes page ?
Si tu augmente la durée tu sollicitera moins la base ce qui pourrait rendre a nouveau le site accessible.
lessab a écrit :
Bonjour à tous,
Ce week end, sous Spip 192e et serveur mutualisé, j'ai eu un souci de nombre maximal de connexions simultanées sur MySQL.
Le site est resté difficile d'accès quasi tout le week end.
Mon hébergeur me dit que j'ai sans doute atteint le nombre maximal de connexions simultanées sur MySQL.
Mais il me conseille également de vérifier au préalable que les connexions soient bien fermés à chaque fin d'exécution du script.
Je ne comprends pas le sens de cette dernière phrase ni comment vérifier ou corriger ce problème s'il y a lieu...
Est-ce que quelqu'un peut m'expliquer cette phrase :
« vérifier au préalable que les connexions soient bien fermés à chaque fin d'exécution du script »
et comment les vérifier ???
Merci pour votre aide,
Cordialement,
J’ai mis un #CACHE{86400} sur le squelette Article et la page sommaire.
La taille du répertoire cache est de 50 mo pour une utilisation actuellement de 40.9 Mo.
Cordialement,
Les Sab
pour le moment quel est le cache de tes page ?
Si tu augmente la durée tu sollicitera moins la base ce qui pourrait
rendre a nouveau le site accessible.
lessab a écrit :
Bonjour à tous,
Ce week end, sous Spip 192e et serveur mutualisé, j’ai eu un souci de
nombre maximal de connexions simultanées sur MySQL.
Le site est resté difficile d’accès quasi tout le week end.
Mon hébergeur me dit que j’ai sans doute atteint le nombre maximal de
connexions simultanées sur MySQL.
Mais il me conseille également de vérifier au préalable que les
connexions soient bien fermés à chaque fin d’exécution du script.
Je ne comprends pas le sens de cette dernière phrase ni comment
vérifier ou corriger ce problème s’il y a lieu…
Est-ce que quelqu’un peut m’expliquer cette phrase :
« vérifier au préalable que les connexions soient bien fermés à chaque
fin d’exécution du script »
et comment les vérifier ???
Bonjour à tous,
Ce week end, sous Spip 192e et serveur mutualisé, j'ai eu un souci de nombre maximal de connexions simultanées sur MySQL.
Le site est resté difficile d'accès quasi tout le week end.
Mon hébergeur me dit que j'ai sans doute atteint le nombre maximal de connexions simultanées sur MySQL.
Mais il me conseille également de vérifier au préalable que les connexions soient bien fermés à chaque fin d'exécution du script.
Je ne comprends pas le sens de cette dernière phrase ni comment vérifier ou corriger ce problème s'il y a lieu...
Est-ce que quelqu'un peut m'expliquer cette phrase :
« vérifier au préalable que les connexions soient bien fermés à chaque fin d'exécution du script »
et comment les vérifier ???
Merci pour votre aide,
Cordialement,
Les Sab
Ce week end, sous Spip 192e et serveur mutualisé, j’ai eu un souci de
nombre maximal de connexions simultanées sur MySQL.
Le site est resté difficile d’accès quasi tout le week end.
Mon hébergeur me dit que j’ai sans doute atteint le nombre maximal de
connexions simultanées sur MySQL.
Mais il me conseille également de vérifier au préalable que les
connexions soient bien fermés à chaque fin d’exécution du script.
Je ne comprends pas le sens de cette dernière phrase ni comment
vérifier ou corriger ce problème s’il y a lieu…
Est-ce que quelqu’un peut m’expliquer cette phrase :
« vérifier au préalable que les connexions soient bien fermés à chaque
fin d’exécution du script »
et comment les vérifier ???
J’ai mis un #CACHE{86400} sur le squelette Article et la page sommaire.
La taille du répertoire cache est de 50 mo pour une utilisation actuellement de 40.9 Mo
Si je dois augmenter mon cache, quelle doit être la valeur qu’il faut que je choisisse pour moins solliciter la base ?
Merci pour ton aide,
Les Sab
pour le moment quel est le cache de tes page ?
Si tu augmente la durée tu sollicitera moins la base ce qui pourrait
rendre a nouveau le site accessible.
lessab a écrit :
Bonjour à tous,
Ce week end, sous Spip 192e et serveur mutualisé, j’ai eu un souci de
nombre maximal de connexions simultanées sur MySQL.
Le site est resté difficile d’accès quasi tout le week end.
Mon hébergeur me dit que j’ai sans doute atteint le nombre maximal de
connexions simultanées sur MySQL.
Mais il me conseille également de vérifier au préalable que les
connexions soient bien fermés à chaque fin d’exécution du script.
Je ne comprends pas le sens de cette dernière phrase ni comment
vérifier ou corriger ce problème s’il y a lieu…
Est-ce que quelqu’un peut m’expliquer cette phrase :
« vérifier au préalable que les connexions soient bien fermés à chaque
fin d’exécution du script »
et comment les vérifier ???
donc ça parait bien. le probleme n'est peut-être pas mysql.
En revanche si les articles ne sont pas modifiés après publication le cache peut toujours etre plus long.
A voir aussi le cache des includes s'il y en a.
lessab a écrit :
Merci Fred pour ta réponse,
J'ai mis un #CACHE{86400} sur le squelette Article et la page sommaire.
La taille du répertoire cache est de 50 mo pour une utilisation actuellement de 40.9 Mo.
Cordialement,
Les Sab
pour le moment quel est le cache de tes page ?
Si tu augmente la durée tu sollicitera moins la base ce qui pourrait
rendre a nouveau le site accessible.
lessab a écrit :
> Bonjour à tous,
> > Ce week end, sous Spip 192e et serveur mutualisé, j'ai eu un
souci de
> nombre maximal de connexions simultanées sur MySQL.
> Le site est resté difficile d'accès quasi tout le week end.
> Mon hébergeur me dit que j'ai sans doute atteint le nombre
maximal de
> connexions simultanées sur MySQL.
> Mais il me conseille également de vérifier au préalable que les
> connexions soient bien fermés à chaque fin d'exécution du script.
> Je ne comprends pas le sens de cette dernière phrase ni comment
> vérifier ou corriger ce problème s'il y a lieu...
> > Est-ce que quelqu'un peut m'expliquer cette phrase :
> « vérifier au préalable que les connexions soient bien fermés à
chaque
> fin d'exécution du script »
> et comment les vérifier ???
> > Merci pour votre aide,
> > Cordialement, > > Les Sab
Mais ou puis-je trouver le cache des includes pour modifier sa valeur ???
Cordialement,
Les Sab
donc ça parait bien. le probleme n’est peut-être pas mysql.
En revanche si les articles ne sont pas modifiés après publication le
cache peut toujours etre plus long.
A voir aussi le cache des includes s’il y en a.
lessab a écrit :
Merci Fred pour ta réponse,
J’ai mis un #CACHE{86400} sur le squelette Article et la page sommaire.
La taille du répertoire cache est de 50 mo pour une utilisation
actuellement de 40.9 Mo.
Cordialement,
Les Sab
pour le moment quel est le cache de tes page ?
Si tu augmente la durée tu sollicitera moins la base ce qui pourrait
rendre a nouveau le site accessible.
lessab a écrit :
Bonjour à tous,
Ce week end, sous Spip 192e et serveur mutualisé, j’ai eu un
souci de
nombre maximal de connexions simultanées sur MySQL.
Le site est resté difficile d’accès quasi tout le week end.
Mon hébergeur me dit que j’ai sans doute atteint le nombre
maximal de
connexions simultanées sur MySQL.
Mais il me conseille également de vérifier au préalable que les
connexions soient bien fermés à chaque fin d’exécution du script.
Je ne comprends pas le sens de cette dernière phrase ni comment
vérifier ou corriger ce problème s’il y a lieu…
Est-ce que quelqu’un peut m’expliquer cette phrase :
« vérifier au préalable que les connexions soient bien fermés à
chaque
fin d’exécution du script »
et comment les vérifier ???
J'ai eu exactement le même soucis jusqu'à ce que le système de fichier du serveur se décompose et que je perde définitivement l'ordinateur (formatage complet).
C'était à cause d'un cache trop gros. Maintenant j'ai pris un ordinateur plus puissant et j'ai supprimé le cache avec le couteau suisse. Depuis je n'ai jamais eu un site aussi rapide.
A l'époque il y a eu toute une discussion à propos du cache de Spip. en fait pour les gros site le temps d'aller retrouver les infos dans le cache va prendre plus de temps que de générer la page sans cache. Par contre sur les petits sites, c'est la taille du cache (temps avant renouvellement et taille max) qui va essentiellement poser des bugs.
Tina
lessab a écrit :
Bonjour à tous,
Ce week end, sous Spip 192e et serveur mutualisé, j'ai eu un souci de nombre maximal de connexions simultanées sur MySQL.
Le site est resté difficile d'accès quasi tout le week end.
Mon hébergeur me dit que j'ai sans doute atteint le nombre maximal de connexions simultanées sur MySQL.
Mais il me conseille également de vérifier au préalable que les connexions soient bien fermés à chaque fin d'exécution du script.
Je ne comprends pas le sens de cette dernière phrase ni comment vérifier ou corriger ce problème s'il y a lieu...
Est-ce que quelqu'un peut m'expliquer cette phrase :
« vérifier au préalable que les connexions soient bien fermés à chaque fin d'exécution du script »
et comment les vérifier ???
Merci pour votre aide,
Cordialement,
Les Sab
et aussi en augmentant la durée du cache local (de 24 à 72 heures).
Nous verrons bien le résultat…
C’est surtout les week-end que je rencontre ce genre de problème car l’audience du site est très forte sur 2/3 jours.
Cordialement,
Les Sab
J’ai eu exactement le même soucis jusqu’à ce que le système de fichier
du serveur se décompose et que je perde définitivement l’ordinateur
(formatage complet).
C’était à cause d’un cache trop gros. Maintenant j’ai pris un ordinateur
plus puissant et j’ai supprimé le cache avec le couteau suisse. Depuis
je n’ai jamais eu un site aussi rapide.
A l’époque il y a eu toute une discussion à propos du cache de Spip.
en fait pour les gros site le temps d’aller retrouver les infos dans le
cache va prendre plus de temps que de générer la page sans cache. Par
contre sur les petits sites, c’est la taille du cache (temps avant
renouvellement et taille max) qui va essentiellement poser des bugs.
Tina
lessab a écrit :
Bonjour à tous,
Ce week end, sous Spip 192e et serveur mutualisé, j’ai eu un souci de
nombre maximal de connexions simultanées sur MySQL.
Le site est resté difficile d’accès quasi tout le week end.
Mon hébergeur me dit que j’ai sans doute atteint le nombre maximal de
connexions simultanées sur MySQL.
Mais il me conseille également de vérifier au préalable que les
connexions soient bien fermés à chaque fin d’exécution du script.
Je ne comprends pas le sens de cette dernière phrase ni comment vérifier
ou corriger ce problème s’il y a lieu…
Est-ce que quelqu’un peut m’expliquer cette phrase :
« vérifier au préalable que les connexions soient bien fermés à chaque
fin d’exécution du script »
et comment les vérifier ???
D'un autre coté, je vois que tu as pas mal de place sur ton compte (l'offre Celeoalto propose 3 Go), donc un cache à 100 Mo peut être aussi un test intéressant.
As tu des squelettes très lourds ou au contraire des pages très légères?
Saurais tu estimer la fréquence de visite le WE lors des pics ?
lessab a écrit :
Merci Tina pour votre réponse.
Je vais faire plusieurs essais :
1) en désactivant le cache
2) en réduisant sa taille (de 50 à 20 mo)
3) et aussi en augmentant la durée du cache local (de 24 à 72 heures).
Nous verrons bien le résultat...
C'est surtout les week-end que je rencontre ce genre de problème car l'audience du site est très forte sur 2/3 jours.
Cordialement,
Les Sab
J'ai eu exactement le même soucis jusqu'à ce que le système de fichier
du serveur se décompose et que je perde définitivement l'ordinateur
(formatage complet).
C'était à cause d'un cache trop gros. Maintenant j'ai pris un
ordinateur
plus puissant et j'ai supprimé le cache avec le couteau suisse.
Depuis
je n'ai jamais eu un site aussi rapide.
A l'époque il y a eu toute une discussion à propos du cache de
Spip.
en fait pour les gros site le temps d'aller retrouver les infos
dans le
cache va prendre plus de temps que de générer la page sans cache. Par
contre sur les petits sites, c'est la taille du cache (temps avant
renouvellement et taille max) qui va essentiellement poser des bugs.
Tina
lessab a écrit :
> Bonjour à tous,
> > Ce week end, sous Spip 192e et serveur mutualisé, j'ai eu un
souci de
> nombre maximal de connexions simultanées sur MySQL.
> Le site est resté difficile d'accès quasi tout le week end.
> Mon hébergeur me dit que j'ai sans doute atteint le nombre
maximal de
> connexions simultanées sur MySQL.
> Mais il me conseille également de vérifier au préalable que les
> connexions soient bien fermés à chaque fin d'exécution du script.
> Je ne comprends pas le sens de cette dernière phrase ni comment
vérifier
> ou corriger ce problème s'il y a lieu...
> > Est-ce que quelqu'un peut m'expliquer cette phrase :
> « vérifier au préalable que les connexions soient bien fermés à
chaque
> fin d'exécution du script »
> et comment les vérifier ???
> > Merci pour votre aide,
> > Cordialement,
> > Les Sab