Discussion :

[nabouill]

Bonjour,

Il y a 3 semaines j'ai migré mon site web vers un serveur Ubuntu 16.4 avec LAMP. Ce serveur dispose de 4 cpu de 2.4 Ghz et de 8 Go de RAM.
Celui-ci fonctionne pas trop mal en journée, mais le soir, dès qu'il n'y a pas mal d'internautes dessus, le site se met à ralentir énormément. Et bizarrement, j'ai l'impression que c'est dès que les barre des 400 utilisateurs simultanés et dépassé que ça deviens critique, je vois les CPU qui plafonnent à fond avec une grande quantité de processus MySQL (mais la ram elle ne monte jamais à plus de 3,5 GO et jamais de swap) alors qu'à 380/390 utilisateurs il n'y a pas trop de problèmes, et passée la barre des 500 utilisateurs simultanés c'est la catastrophe, il faut plus de 30 secondes pour afficher une page qui en prend que 3 en journée.
J'ai essayé de montée mon serveur à 8 CPU pour tester, c'était à peine mieux.
Au départ, j'avais un peu cet effet-là dès les 150 internautes simultanés, en cherchant sur le net j'ai réussi à optimiser un peu tout ça mais ce n'est pas suffisant.

Voici mon fichier my.cnf: (ma base de donnée est en myisam)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
 
[mysqld_safe]
socket		= /var/run/mysqld/mysqld.sock
nice		= 0
 
[mysqld]
#
# * Basic Settings
#
user		= mysql
pid-file	= /var/run/mysqld/mysqld.pid
socket		= /var/run/mysqld/mysqld.sock
port		= 3306
basedir		= /usr
datadir		= /var/lib/mysql
tmpdir		= /tmp
lc-messages-dir	= /usr/share/mysql
skip-external-locking
 
bind-address		= 127.0.0.1
 
thread_stack		= 192K
 
myisam-recover-options  = BACKUP
 
log_error = /var/log/mysql/error.log
 
expire_logs_days	= 10
max_binlog_size   = 100M
 
 
#####   mes ajouts   ######
 max_connections=1000
 max_user_connections = 1000
 
 long_query_time = 0.1
 
 
 query_cache_type = 1
 query_cache_size = 512M
 query_cache_limit = 16M
 
 join_buffer_size=1M
 read_rnd_buffer_size=1M
 max_allowed_packet = 10M
 
 tmp_table_size=25M
 max_heap_table_size=25M
 
 table_open_cache = 7500
 thread_cache_size = 25
 
 
 key_buffer_size = 500M
 myisam_sort_buffer_size = 256M
 
 
innodb_file_per_table=1
innodb_buffer_pool_size = 1G
innodb_log_file_size = 64M
innodb_log_buffer_size = 8M
 
sort_buffer_size=32M 
read_buffer_size=8M

Le problème c'est que je ne comprends pas tout dans ce fichier, donc j'ai beaucoup de mal à l'optimiser. Quelqu'un pourrait-il m'aider à trouver ce qui ne va pas ?
Je suis d'autant plus inquiet car avant de migrer sur ce serveur, il n'était pas rare de monter à 700/750 internautes simultanés, ce qui n'est plus arrivé depuis, mais je pense que c'est simplement parce que les pages n'arrive plus à s'afficher assez vite et donc les gens s'en vont.

Par avance, merci pour votre aide.

[Artemus24]

Salut nabouill.

Ce serveur dispose de 4 cpu de 2.4 Ghz et de 8 Go de RAM.

Non, il dispose d'un seul processeur et de quatre coeurs, soit huit threads.

J'ai essayé de montée mon serveur à 8 CPU pour tester, c'était à peine mieux.

Et vous faites comment pour augmenter le nombre de coeurs ?

Pour otimiser votre serveur MySql, c'est long à faire et il y a beaucoup de tests à faire :
--> https://wiki.deimos.fr/MysqlTuner_:_..._serveur_MySQL

Il n'y a pas de solutions toutes faites car cela repose sur le nombre de coeurs, la taille de votre RAM, du rapport lecture/écriture ...

Dans ce lien : http://www.jcz.fr/mysql/
vous avez les anciens fichiers my.ini dont vous pouvez vous servir pour configurer le votre.
Cela sera un modèle de départ pour améliorer vos performances.

Peux-on connaitre le nom de votre site et l'heure de cette influence.
J'aimerai voir par moi-même les ralentissements que vous rencontrez.

@+

[nabouill]

Merci pour votre réponse.

En effet les liens que vous m'avez donnés me semblent bien intéressant et effectivement tout ceci me parait assez long à faire, mais s'il faut... il faut.
Et je vois bien que tout le monde dit que cela dépend du nombre de CPU / RAM ... dommage qu'il n'existe pas de "calculateur" qui permettrait de "dégrossir" un peu des paramètres à mettre en place en fonction d'une config matérielle, mais le deuxième lien que vous m'avez envoyé devrait je pense pas mal m'aider.

Je vous envoie le lien du site en MP (car je ne suis pas là pour faire la promotion de mon site^^)

J'ai plus qu'a me mettre au travail. Je repasserais vous donner le résultat.

Encore merci.

Juste pour info:

Non, il dispose d'un seul processeur et de quatre cœurs, soit huit threads.

Non il s'agit enfaite de VCPU, et donc bien 4 VCPU avec un seul cœur chacun.

Et vous faites comment pour augmenter le nombre de cœurs ?

C'est un serveur virtuel qui tourne sous hyperv 2012, donc je puis lui enlever/ajouter de la RAM ou du CPU à mon bon vouloir.

[Artemus24]

Salut Nabouill.

Merci pour le lien en MP.

Je viens de faire le test d'accès à votre site et comme réponse, j'ai eu un time out !
Après quelques essais, j'ai enfin pu me connecter à votre site !

Il y a trop d'images dans votre page principale !!!
Je ne sais pas trop ce que vous faites dans cette page principale, mais je pense que mysql n'est pas en cause.

J'ai fait un "tracert" pour accéder à votre site, et il m'a indiqué "cluster011.ovh.net".
Donc j'accède bien au site, mais je pense que vous avez un problème de bande passante !

@+

[nabouill]

Je viens de faire le test d'accès à votre site et comme réponse, j'ai eu un time out !

Humm, ce genre de chose met déjà arrivé le soir aux heures de pointe mais jamais en après-midi, je suis de plus en plus inquiet du coup.

Il y a trop d'images dans votre page principale !!!
Je ne sais pas trop ce que vous faites dans cette page principale, mais je pense que mysql n'est pas en cause.

Cette page est assez light enfaite en requête, d'ailleurs celle ci me pose très peu de problème, et malgré la petite vingtaine d'image, c'est page peut être très rapide à s'afficher quand le serveur n'est pas surchargé, c'est plus si vous prenez le menu en haut pour afficher le VF ou VO que là la page va être très longue parfois à s'afficher (beaucoup plus de requête sur ces 2 pages là avec des filtres et tout) , mais enfaite plus il y a du monde sur le serveur et plus c'est long, comme je le disais, si on prend une de ces 2 pages là le matin vers 9H (donc site non surchargé) la page met moins de 3 secondes à s'afficher (et je vois bien mes CPU tous aux repos) alors que le soir vers 23H (heure de rush) la même page peut mettre plus de 30 secondes (et je vois bien mes CPU gonflés à bloque avec plein de processus MySQL). D'où mon penchant pour un problème MySQL.

J'ai fait un "tracert" pour accéder à votre site, et il m'a indiqué "cluster011.ovh.net".

Oui c'est normal, mon serveur est chez OVH en loc.

Donc j'accède bien au site, mais je pense que vous avez un problème de bande passante !

J'ai un débit théorique de 250mb/s descendant et 100mb/s montant. (enfin c'est le montant qui nous intéresse ici). Mon firewall m'indique un débit utilisé moyen de 3 mb/s avec des pics maxi à 8 mb/s sur les 10 dernières minutes avec 400 internautes simultanés. J'ai lancé une série DSL speedtest pour voir, j'ai effectivement un débit réel de 90 mb/s montant à chacun des tests. Je ne suis donc pas inquiet pour la bande passante.

[Artemus24]

Salut nabouill.

Cette page est assez light en faite en requête, d'ailleurs celle ci me pose très peu de problème, et malgré la petite vingtaine d'image, c'est page peut être très rapide à s'afficher quand le serveur n'est pas surchargé

Qu'est-ce que vous faites comme requête dans cette page dite light ?

Et s'il n'y a aucun accès à MySql est-ce que les temps d'accès sont aussi long ?

Je vous assure que le chargement de la page dit light a été très très long.
Je n'ai pas mesuré le temps, mais c'est au moins 2 à 3 minutes avant l'arrêt du sablier.

J'ai un débit théorique de 250mb/s descendant et 100mb/s montant.

Ça, c'est très bien quand on travaille seul.
Mais si vous êtes 400 à travailler, vous vous retrouvez avec du 0.625mb/s descendant et 0.250mb/s montant.

Mon débit chez moi est de 8.5mb/s descendant et 0.8mb/s en montant et c'est assez fluide.

@+

[nabouill]

Bonjour,

Qu'est-ce que vous faites comme requête dans cette page dite light ?

c'est juste 3 requêtes qui vont chercher les 9 ou 6 derniers articles mis en lignes.
Alors que si on prend dans le menu en haut la catégorie VF par exemple, des requêtes vont chercher dans la base tout ce qui est en VF + leurs genres + ... donc beaucoup plus lourd à exécuter.

Et s'il n'y a aucun accès à MySql est-ce que les temps d'accès sont aussi long ?

Je n'es pas de page qui ne font aucune requête, mais si on prend la page de contact par exemple qui va juste chercher 2-3 info dans une mini table, ça marche pas trop mal.

Je vous assure que le chargement de la page dit light a été très très long.
Je n'ai pas mesuré le temps, mais c'est au moins 2 à 3 minutes avant l'arrêt du sablier.

Il y a 2 choses bien distinct qui génère le faite que le sablier tourne parfois longtemps, enfaite la page se charge (par exemple en 5 secondes) puis va charger des JavaScripts sur d'autre site (bannière publicitaire, chat ...) et suffit que un de ces serveur de javascript soit un peu mou, le sablier tourne et tourne et tourne... tant qu'il ne sont pas fini de charger ou jusqu'au timeout mais cela n'empêche que la page du site en elle même est bien fini de charger (un bon adblock, tel que celui de la dernière version d'opéra, permette de vérifier ça) Mais sinon oui, en heure de pointe, la page en elle même est longue.

Ça, c'est très bien quand on travaille seul.
Mais si vous êtes 400 à travailler, vous vous retrouvez avec du 0.625mb/s descendant et 0.250mb/s montant.
Mon débit chez moi est de 8.5mb/s descendant et 0.8mb/s en montant et c'est assez fluide.

Non, ce n'est pas vraiment ça, car vous disposer de 18 mb/s en download OK, et nous de 100 mb/s en upload OK, mais quand vous venez charger une page sur notre site avec votre périphérique, cela ne dure pas plus de 1 ou 2 secondes, donc pendant ce temps là effectivement vous allez prendre peut-être 18 mb/s (théorique) de notre débit montant, mais une fois cette page chargé vous pouvez rester 15 minutes dessus, il n'y a aucun transfert de données de fait entre votre poste et notre serveur. On pourrait même éteindre le serveur que vous ne vous en rendriez même pas compte tant que vous ne rafraichissez pas la page (mise à part certains scripts qui peuvent faire du rafraichissement en temps réel) . c'est même d'ailleurs pour cela que je précise que notre firewall n'a des pics que d'environ 11 mb/s de temps en temps mais plutôt un débit moyen de 3-4 mb/s.


Mais avec les 2 premiers liens que vous m'avez envoyés, après quelques modifications et tests je vois déjà une amélioration (le problème est juste que je ne peux valider mes tests qu'entre 21H00 et 0H00) l'optimisation finale risque d'être longue mais ça avance.
Merci

[Artemus24]

Salut Nabouill.

Je n'es pas de page qui ne font aucune requête, mais si on prend la page de contact par exemple qui va juste chercher 2-3 info dans une mini table, ça marche pas trop mal.

J'ai fait le test, et c'est très long aussi.

Vous ne pouvez pas me donner un lien depuis votre site avec une page web qui ne contient presque rien.
Je parle bien sûr de html et css. Pas de Php et encore moins de MySql !
C'est juste pour voir le temps d'accès à la page.

Vu l'extrême lenteur, je soupçonne plus un problème de bande passante que la lenteur des accès à MySql.

@+

[Artemus24]

Salut Nabouill.

Merci pour le MP.

J'ai fait le test avec le nouveau lien et c'est toujours aussi long.
Je maintiens mon opinion que vous avez un problème de bande passante et non d'une mauvaise configuration de MySql.
Il y a sûrement un goulot d'étranglement chez OVH.

Avez-vous échangé avec OVH sur la nature de votre problème ?
Il se peut que l'offre VPS dont vous disposez n'est pas adapté à ce que vous faites.

@+

[nabouill]

Je viens de vous renvoyer un autre lien en MP avec uniquement du html.
Et ce n'est pas un vps ovh, mais un serveur dédié. Et divers serveurs chez eux dont je dispose pour bien autre chose ne pose aucun problème de bande passante.

[Artemus24]

Salut Nabouill.

Avec le nouveau lien, c'est toujours aussi long.
J'ai quand même pu y accéder, mais il m'indique "La page requise est introuvable !".

Et divers serveurs chez eux dont je dispose pour bien autre chose ne pose aucun problème de bande passante.

J'ignore totalement votre configuration.
Mais ce que je peux constater, c'est l'extrême longueur du temps de chargement.

Si vous désirez que je fasse des tests plus poussés, vous pouvez m'indiquer la procédure à entreprendre.

@+

[nabouill]

Pensez vous qu'il est possible que je communique ce dernier lien directement publiquement ici pour que d'autre personne me confirme que c'est lent aussi pour eux (ou pas) car personnellement ce lien se charge en moins de 1 seconde pour ma part en faisant des tests depuis divers sites (Bretagne, Paris Bruxelles). Donc, sans vouloir vous mettre en cause, j'aimerais avoir d'autre avis.
(je demande car je suis nouveau sur ce forum et je ne veux pas que l'on pense que je suis venu ici pour faire de la pub)
Merci

[Artemus24]

Salut Nabouill.

Le mieux serait de poser la question à un modérateur.
Les règles du forum : http://club.developpez.com/regles/

personnellement ce lien se charge en moins de 1 seconde pour ma part en faisant des tests depuis divers sites (Bretagne, Paris Bruxelles).

Je vous ai indiqué le résultat des tests d'accès depuis vos liens. Je n'ai aucun intérêt à vous raconter des conneries.

Donc, sans vouloir vous mettre en cause, j'aimerais avoir d'autre avis.

Il est tout à fait normal d'avoir d'autres avis. Mais il faudrait cerner le problème d'une manière plus précise.

Je pense que j'ai trouvé la nature de votre problème !!!

Vu que je travaille toujours en IPv6, et que j'ai déjà eu des problèmes d'accès vers des sites chez OVH, je vais basculer en IPv4.
Je viens de refaire le test en IPv4, et c'est instantané ! Le message dans la page web est : "Welcom to MVF".
Idem, pour la page principale de votre site, c'est instantané aussi.

Donc le problème est l'IPV6 qui n'est pas géré de la même façon que chez SFR.

@+

[nabouill]

Je n'ai aucun intérêt à vous raconter des conneries.

Oui je sais bien, je n'ai jamais pensé que vous me racontiez de connerie, mais je sais que sur divers postes et/ou lieux du poste on peut avoir divers résultats.

Je pense que j'ai trouvé la nature de votre problème !!!

Vu que je travaille toujours en IPv6, et que j'ai déjà eu des problèmes d'accès vers des sites chez OVH, je vais basculer en IPv4.
Je viens de refaire le test en IPv4, et c'est instantané ! Le message dans la page web est : "Welcom to MVF".
Idem, pour la page principale de votre site, c'est instantané aussi.

Donc le problème est l'IPV6 qui n'est pas géré de la même façon que chez SFR.

Et bien en voilà d'une excellente nouvelle, je vous remercie beaucoup pour cette information car effectivement tous mes tests ne se font qu'en IPV4 (je n'ai pas encore redirigé l'IPV6 vers mon serveur (comme un âne))
Mais cela ne corrige pas encore mon problème de départ, je viens pour un problème et je repars avec 2 mais il y en a un moins un qui ne va pas tarder à être corrigé.

Pour l'autre, j'avance doucement sur mes tests MySQL (car je reste persuadé que ça viens de là, et non je ne suis pas têtu, mais juste un peu borné) Je vous laisse si vous le souhaitez faire des tests d'accès au site ce soir vers 22H-23H si vous voulez constater la surcharge.

En attendant je vous remercie très sincèrement d'avoir pu m'aider car une mauvaise blague comme celle de l'IPV6 aurait pu durer très longtemps.

Je repasserais quoi qu'il arrive vous donnez l'avancer des travaux sur mon MySQL.

A bientôt.

[Artemus24]

Salut Nabouill.

je reste persuadé que ça viens de là, et non je ne suis pas têtu, mais juste un peu borné

Mais vous avez entièrement raison de persévérer dans votre démarche !
D'ailleurs, c'est vous qui avez la connaissance de votre site. On est jamais mieux servi que par soi-même.

je viens pour un problème et je repars avec 2

Désolé mais ce n'était pas volontaire.

si vous le souhaitez faire des tests d'accès au site ce soir vers 22H-23H si vous voulez constater la surcharge.

Je vais vérifier la dégradation de vos performances, ce soir.

Concernant l'optimisation, je ne suis pas du tout un spécialiste, vu que je ne fais que bidouiller dans mon environnement chez moi.
A la base, je crois que les exemples "my.ini" sont optimisés pour 4 Go de RAM.

Il y a aussi un autre point que l'on ne tient presque jamais en compte : la persistance des connexions.
--> http://php.net/manual/fr/features.pe...onnections.php
Ceci permet artificiellement d'augmenter le nombre de connexions.

A très bientôt

@+

[Artemus24]

Salut Nabouill.

Comme promis, j'ai fait des tests d'accès à votre site, à partir de 22H00, ce vendredi 19 août 2016.
Le temps d'attente est de trois minutes, avant de voir apparaître le message suivant :

504 Gateway Time-out

The server didn't respond in time.

Voici le commentaire de cette erreur :

504 : Gateway timeout

Temps d'accès à la passerelle expiré. Le serveur n'a pas répondu à la requête transmise par le proxy ou le serveur intermédiaire dans le temps qui lui était imparti. Là aussi, c'est un problème temporaire. Réessayez un peu plus tard.

J'ai fait aussi une tentative par un ping, à peu près à la même heure, et j'ai toujours le même problème, autrement dit aucun accès.

Il me semble qu'il n'y a plus de connexions disponibles au serveur !!!

Puis vers les 23H00, j'ai pu enfin entrer dans le site. L'accès n'est pas instantané comme cet après-midi, mais elle est assez courte, environ 15 secondes.

En résumé, j'ai eu un "504 : Gateway timeout" entre 22H00 et 23H00 !
Ça ressemble beaucoup à un ddos (distributed denial of service attack).
J'ai fréquemment le même problème sur un forum dont l'accès ne se fait plus à peu près aux mêmes heures.

@+

[nabouill]

Bonjour,
Veuillez m'excuser pour cette réponse tardive,

504 Gateway Time-out

The server didn't respond in time.

Oui, mas là c'est un peu de ma faute, car voulant corriger le problème d'IPV6, j'ai fait 2-3 bricoles sur les DNS vendredi en fin d'après midi, puis je ne sais pas pourquoi, une heure après je reçois un mail de l'hébergeur qui me dit qu'ils ont reset tout les paramètres d'hébergement, donc je remet à jour mes DNS mais avec la chance que j'ai la propagation a durée plus de 20H00, donc génial, le site carrément inaccessible de 19H00 vendredi à 15H00 samedi.

[Artemus24]

Salut Nabouill.

mais avec la chance que j'ai la propagation a durée plus de 20H00, donc génial, le site carrément inaccessible de 19H00 vendredi à 15H00 samedi.

Non, car après 23H00, ce vendredi, j'ai pu accéder à votre site sans problème.
Soit il y avait un embouteillage, soit un autre problème.

Les points à améliorer :

1) Résoudre le problème des connexions avec persistance.
Comme vous vous servez de MySql pour construire votre page web, vous pouvez libérez cette ressource.
Cela permet aux autres utilisateurs de se connecter.

2) mettre des index sur vos tables si ce n'est pas déjà le cas.

3) Revoir les requêtes afin de les perfectionner.

4) utilisez MySqlTuner pour optimiser votre serveur.

@+

[nabouill]

Non, car après 23H00, ce vendredi, j'ai pu accéder à votre site sans problème.

ceci n'était qu'une illusion, car enfaite, vu qu'ils ont reset les paramètres DNS, les DNS se sont remis à pointer vers l'ancien espace d'hébergement qui lui sature à tout niveau (apache, MySQL...) c'est d'ailleurs pour cela que j'ai du prendre un serveur dédié, car il n'avait aucune offre capable de supporter un site avec tant de connexion simultané (ce qui m'exaspère un peu car au lieu de juste devoir m'occuper de la partie web je dois en plus m'occuper de la partie hard, soft, config...)

1) Résoudre le problème des connexions avec persistance.
Comme vous vous servez de MySql pour construire votre page web, vous pouvez libérez cette ressource.
Cela permet aux autres utilisateurs de se connecter.

Pouvez être plus clair, je ne comprend pas bien ce que vous voulez dire par "libérez cette ressource"

2) mettre des index sur vos tables si ce n'est pas déjà le cas.

C'est déjà la cas.

3) Revoir les requêtes afin de les perfectionner.

oui j'y pense, mais la tâche me semble un peu lourde pour l'instant, mais c'es sans aucun doute une chose que je ferais un peu plus tard.

4) utilisez MySqlTuner pour optimiser votre serveur.

Je travail justement à fond la dessus.


Encore merci pour votre aide.

[Artemus24]

Salut Nabouill.

Pouvez être plus clair, je ne comprends pas bien ce que vous voulez dire par "libérez cette ressource"

Une connexion persistance, c'est une astuce pour optimiser les accès à MySql pour un utilisateur donné.
Sauf que vous vous servez de MySql pour créer votre page, mais après, vous n'en avez plus besoin.
Donc remplacer vos "mysql_pconnect()" par "mysql_connect()Ne pas oublier de fermer vos connexions :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

mysql_close().

A faire avant de rendre la main à l'utilisateur.
Car quand celui-ci est en train de regarder une vidéo, la connexion doit être fermée.

Dans php.ini, mettre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

mysqli.allow_persistent = Off

@+