Salut,
Je viens de recevoir un mail de Carlo Mayer, activiste du Forum Social Italien. Leur problème principal est de devoir supporter un traffic énorme. D'après vous, est-ce que le système de cache de SPIP est suffisant?
ARNO*
bonjour,
je suis d'accord avec Antoine...
je ne pense pas que Spip ait des limitations concernant le nombre de
connexions simultanées. Je pense que si problèmes il devrait y avoir, ce
sera plutôt du côté du serveur ou de la B.P. que ça pourrait coincer. Mais
bon, les amis Italiens doivent avir l'habitude du gros traffic alors les
machines doivent tenir le coups... non?
à +
je connais rien en programmation, dommage !, mais je reprend la demande du
forum social , pour la recherche de personne susceptible de les aidées sur
la construction de leur portail
je colle , si tu n'y vois aucun inconvénient leurs mais dans mon site
jc colombani
ps:je suis de loin en loin vos débat , j'ai crus comprendre qu'il existe une
nouvelle version de spip , est -elle opérationnel pour un nul , et
téléchargeable sur uzine
amicalement
Sinon les "visites" ça correspond à quoi ? Le Diplo fait deux millions de
_pages_ par mois et ça n'a pas une grosse incidence sur la machine.
Non, elle passe en effet son temps à attendre. En mars on a fait plus de 3
millions de pages (ne pas regarder que le site français !) sans souci.
De toutes façons la question est "combien de connexions simultanées ?". Et
là, on sait déjà que spip n'est pas un facteur limitant (avec 100 serveurs
fils qui spipent en parallèle, ça roule). Il faut qu'ils mettent dans leur
serveur suffisamment de mémoire RAM pour que
MaxServers * 16 Mo < RAM
(16 Mo : la taille d'un process apache bien chargé)
Sinon apache risque de swapper, et là ça déconne...
Ils peuvent aussi améliorer les choses, question bande passante et CPU, en
mettant les images fixes et les gros documents (films, sons, etc.) sur un
deuxième serveur.
-- Fil
De toutes façons la question est "combien de connexions simultanées ?". Et
là, on sait déjà que spip n'est pas un facteur limitant (avec 100 serveurs
fils qui spipent en parallèle, ça roule).
PS: à condition tout de même d'utiliser une version récente (1.4x) qui
inclue les modifs que j'ai faites sur l'ouverture/écriture/fermeture des
fichiers en une seule passe. Sinon des accès concurrents peuvent mettre des
fichiers vides dans le cache, et la page est morte pour une durée de
$delais.
Sur le Diplo je n'ai plus constaté ce problème, qui auparavant se produisait
de temps en temps.
-- Fil
Fil wrote:
De toutes façons la question est "combien de connexions simultanées ?". Et
là, on sait déjà que spip n'est pas un facteur limitant (avec 100 serveurs
fils qui spipent en parallèle, ça roule). Il faut qu'ils mettent dans leur
serveur suffisamment de mémoire RAM pour queMaxServers * 16 Mo < RAM
(16 Mo : la taille d'un process apache bien chargé)
C'est plus simple de régler le MaxClients, non ?
>Il faut qu'ils mettent dans leur
>serveur suffisamment de mémoire RAM pour queC'est plus simple de régler le MaxClients, non ?
Si le nb de req simultanées sur le serveur est supérieur à MaxClients, tes
clients attedent leur tour... ça peut être long, et finir par atteindre la
timeout et te déconnecter. Pas terrible. Donc tu ajoutes de la RAM, et tu
ajustes le MaxClients de manière à ne pas risquer de swapper.
-- Fil
Le Saturday 20 April 2002 16:58, tu écrivais :
Il faut qu'ils mettent dans leur
serveur suffisamment de mémoire RAM pour queMaxServers \* 16 Mo < RAM
Ou, si ne peut/veux pas utiliser cette quantité de RAM, mettre un
MaxRequestsPerChild très bas (2-3) de manière à maintenir basse la taille des
processus apache. Avec un MaxRequestsPerChild à 2, ils dépassent rarement
3-4 Mo.
Le Saturday 20 April 2002 22:42, tu écrivais :
Non, c'est complètement fou !
C'est aussi ce que je me suis dit avant d'essayer... 
Après avoir servi deux requêtes, le fils meurt, et il faut en faire naître
(forker) un nouveau...
Ca consomme du temps CPU, certes, mais sur les serveurs modernes, ce n'est
pas ce qui est le plus critique. La mémoire est plus précieuse, surtout
lorsqu'il y en a peu à disposition.
J'ai eu l'exemple d'un serveur récent (Celeron 900 Mhz), mais ne disposant
que de 256 Mo de RAM. Le fait est qu'avec des paramètres 'conventionnels'
(MaxClients à 150 et MaxRequestsPerChild à 100), dès qu'il y avait un peu de
fréquentation, ben ça swapait, forcément.
Ne pouvant ajouter de RAM (prix de location chez l'hébergeur très nettement
supérieur), cela forçait à ramener beaucoup trop bas le MaxClients et
bloquait donc un certain nombre de visiteurs. En mettant à 2 le
MaxRequestsPerChild, l'utilisation CPU est légèrement montée, mais ça restait
raisonnable, et surtout sans aucune mesure avec le load généré par le
swaping. Et ça a divisé par deux la mémoire totale utilisée.
Ceci dit, je te l'accorde, ça reste extrème comme solution...