Bonjour à tous,
 
J'utilise actuellement un serveur virtuel pour héberger un site intranet basé sur PHP 5.5 (Intel Xeon E5-2670 à 2.60GHz, un seul core, 4Go de ram).
La vie du site c'est : 550 utilisateurs qui utilisent un service d'annuaire, de forums et de transfert de fichiers. Il faut noter que la page d'accueil, qui est un portail assez complet, pèse... 2,5Mo. (je sais c'est énorme)
 
Les utilisateurs sont répartis sur une dizaine de sites distants (Paris, Nantes, Bordeaux, Lyon, etc...), les bandes passantes sont différentes suivants les sites (100Mo en fibre à Paris, 4Mo en ADSL à Lorient). Bref pas très homogène...
 
Voilà pour le contexte...
 
Maintenant le problème qui me préoccupe est le suivant, si je branche le moniteur de ressources du serveur et que j'appelle une page, mon processeur grimpe à 100% pendant 1 seconde avant de redescendre. Je ne sais pas si c'est le fonctionnement normal d'un serveur web? Le problème c'est que je ne suis pas seul à l'utiliser, nous sommes plus de 500, donc le proc est énormément sollicité.
 
De plus quand j'effectue un transfert de fichier (limité à 780Mo) le proc oscille pendant toute la durée du transfert entre 80% et 90% de charge, et consomme l'équivalent du poids du fichier transféré en mémoire vive (si j'upload un fichier de 500Mo le serveur consomme 500Mo de mémoire vive pendant tout le temps du transfert).
Là non plus je ne sais pas si c'est un comportement normal?
 
Bref, je me demande si mon serveur n'est pas sous-dimensionné, ou si le code du site intranet n'est pas optimisé.
 
Pouvez-vous me dire ce que vous utilisez comme type de serveur, et si les comportements décrits vous semblent normaux?
 
Merci d'avance pour le temps consacré.

Les pics du CPU, c'est pas forcément gênant.
 
Ce qui compte c'est le nombre moyen d'utilisateurs connectés en même temps (et pas le nb d'utilisateur enregistrés ou potentiels) et le temps de réponse du serveur. Si les utilisateurs ont leur page affichée en moins de 5 secondes (8s max), alors je pense que c'est bon.
 
Pour vérifié ça si c'est pas déjà fait, il existe des outils de test de charge d'applis web
 
T'as quoi comme OS ?

Salut !
 
Pour savoir si ton serveur supporte la charge, il faut faire des... tests de charges
 
Regarde JMeter (gratuit, codé en java, par apache)
http://jmeter.apache.org/
 
C'est très bien fait et tu peux vite avoir les résultats à tes questions !
 
(Perso mon serveur aussi fait des pics à 100% pendant une seconde, mais en même temps si l'utilisateur est tout seul, vaut mieux que cela soit rapide pour lui )
 
Il me semble, comme l'a si bien dit rufo, que ton serveur ne dit pas charger une page ne plus de 4/5 secondes

Un petit top(htop), le load average indique trois chiffre.
Sachant que tu disposes d'un seul core, grosso merdo le chiffre ne doit pas > 1. Le premier indique la charge sur les 60 dernierèes secondes, le second sur 5 minutes, et le troisième sur 15 min.
 

Est-ce que tu es sûr d'avoir un problème de performance ressentie (i.e. temps de réponse perçu par les utilisateurs) ? Tu peux brancher Google Analytics, augmenter son taux d’échantillonnage et observer les temps clients (mesurés sur les navigateurs). GA peut être utilisé dans un intranet du moment que les navigateurs ont accès au web et que l'intrusion de Google ne te déranges pas.
 
Quels sont les niveaux de service attendus (les temps de réponse). Les études montrent que 5s c'est problématique pour un utilisateur. Mais dans ton cas ?
 
La supervision ne s'intéresse pas aux valeurs absolues, mais aux tendances. Là on ne sait pas si tu as des mauvaises courbes et si un deuxième cœur s'impose pour couvrir tous tes cas d'utilisation. Pour les serveurs web, si tu es au dessus de 80% cela veut dire que tu auras du mal à accepter les pics de charge supplémentaires.
 
Il faut que tu arrives à distinguer si le problème (s'il y en a un) vient du code PHP ou de la base de données. En scrutant htop ou en faisant un essai gratuit d'un outil d'analyse profonde tel que newrelic. Cela guidera tes optimisations (newrelic te dira directement quelles sont les pages et les requêtes les plus coûteuses).
 
Après tu as plusieurs possibilités :
 - Optimiser code/SQL, mais c'est coûteux en temps.
 - Sans changer de serveur et si ton application est compatible passer à une architecture nginx/hhvm. Les pages ne seront pas plus véloces, mais la charge CPU va diminuer d'enviorn 20%.
 - Dans le cas où ta base bouffe du CPU, séparer la base de données du serveur web en louant un VPS supplémentaire pour la BDD.
 
Pour les tdc avec JMeter il faut que tu collectes les métriques systèmes en même temps pour que cela ait du sens, cf. http://jmeter-plugins.org/ Mais faire des tests de charge ça coûte aussi du temps et cela ne s'improvise pas.

 
Clairement ça je ne ferai plus marche arrière.
 
Depuis que j'ai migré le vieux xeon qui faisait tourner notre système sur une infra virtualisée avec des vm pour apache, des vm pour les SGBD, il n'y a plus jamais eu aucun ressenti de pic de charge, au pire une requête mal optimisée mettra du temps à renvoyer son retour, mais en aucun cas le système ne peine à afficher son contenu aux centaines d'utilisateurs.
 
J'avais des doutes au début, mais comme les machines sont sur un lan entre elles, l'échange de données est ultra fluide ..