estimation puissance serveur

[houcine-b]

Bonjour,

pour une base de données mysql pesant un peux plus de 1 GO pour un projet qui fera au depart 300000 pages vue par jours, chaque page comportera des SELECT, UPDATE er des INSERT nous essayant de ne pas allourdir les requettes au maximum

je me demande quels sont les caractéristiques du serveur qui va accueillir cette base, avec une marge de securité pour absorber les pics de trafic

merci à vous

 

[Firewave]

/HS

Le logo de votre WWW reprend outrageusement celui d'Alibaba http://www.alibaba.com/
Même si l'entreprise est chinoise, ils risquent de vous tomber dessus.
/HS

 

[houcine-b]

<hs>

oui l'homme avec le sourire ressemble avec celui de alibaba malgré que je l'ai dessiné avec mes mains

je voulait un L majuscule souriante tenant un chariot

regardez si c'est bon maintenant sinon je fait appel a un graphiste pour une L souriante qui tient un chariot

</hs>

 

[Firewave]

HS/
Il y a plus de trois points de ressemblance entre les deux logos. Le leur étant déposé depuis des lustres, vous allez devoir changer grandement le votre.
Je vous conseille d'abandonner l'homme souriant et de mettre un autre symbole à la place. De plus ça donne plus un A qu'un L sous sa forme actuelle.
/HS

 

[Julia41]

pour une base de données mysql pesant un peux plus de 1 GO pour un projet qui fera au depart 300000 pages vue par jours, chaque page comportera des SELECT, UPDATE er des INSERT nous essayant de ne pas allourdir les requettes au maximum

je me demande quels sont les caractéristiques du serveur qui va accueillir cette base, avec une marge de securité pour absorber les pics de trafic

Donc ça se compte plutôt en "gueule de tes requêtes" et si tu peux afficher des pages (parmis les 300'000) en ne faisant qu'une seule requête SQL ça fait 300K de Req/j soit 3.47 requêtes par secondes.

A toi de voir combien de requête seront nécessaire si elles sont lentes ou non, mais si tu arrives à ta requête par page, un kimsufi de base fera largement l'affaire.

 

[OTP]

Comment on arrive à faire 1 Go de base ???

 

[Julia41]

Comment on arrive à faire 1 Go de base ???

Ca va très vite, 50K d'users chez moi ça fait 800Mo et ils n'ont pas trop d'options.

 

[jcaron]

C'est clair que la gueule et le nombre des requêtes ont une influence énorme. Ce n'est pas la même chose de faire un select * from table where id=X (en supposant évidemment qu'il y a un index sur table(id)) et une grosse jointure de plusieurs tables avec des like qui obligent à lire toute la table et tout le pataquès. Le ratio lecture/écriture est aussi important.

Il faut aussi voir quelle partie de ta base est accédée de façon régulière: sur beaucoup de bases énormes, seuls quelques % sont effectivement utilisés régulièrement.

En gros, ce qu'il faut faire, c'est déterminer pour chaque page vue:
- le nombre d'accès en lecture
- le nombre d'accès en écriture

Ca exige de savoir assez précisément quelles sont les requêtes à effectuer, la structure de la base, la taille des tables, etc.

Pour la lecture, si tu as assez de RAM, tu peux aller assez loin, la seule limite ça va être le CPU (et éventuellement le tables temporaires que mysql a l'air d'affectionner). Si tu n'as pas assez de RAM pour tout avoir en RAM, il faut déterminer quelle proportion des accès devront aller jusqu'au disque, et voir si ça tient.

Pour l'écriture, pas de miracle, il faut que les disques suivent.

Si tu pars sur une page de 300 000 pages par jour, ça fait en moyenne 3.47 pages/seconde, mais la plupart des sites n'ont pas un trafic réparti de façon uniforme sur la journée, donc il faut compter 3 à 4 fois plus que la moyenne en pointe (quelquefois plus sur certains sites), soit jusqu'à 14 pages/seconde. Si toute ta base tient en RAM, on ne va considérer que les accès en écriture. Imaginons que chaque page implique un update de une ligne dans une table qui a un seul index. Ca fait un minimum de deux accès en écriture par page (1 pour la table, 1 pour l'index -- en fait un peu plus parce qu'il va falloir régulièrement faire des modifs dans les niveaux supérieurs de l'index), donc tu montes à 28 écritures/seconde. Ca ça tient normalement sans souci sur n'importe quel disque. Si tu as plus d'écritures que ça tu vas saturer ton disque (un disque SATA courant ça monte à environ 100 écritures/seconde), et dans ce cas il faut commencer à envisager des setups en RAID, etc.

Bref, il est totalement impossible de te répondre sans savoir plus précisément ce que tu fais avec ton serveur. S'il y a 90% de lectures "simples" (bien indexées), une machine avec 2 Go de RAM et un disque unique devrait largement suffire. S'il y a beaucoup d'écritures, des requêtes plus complexes, etc, c'est une autre histoire.

Au delà de la base SQL, il y a évidemment aussi le code PHP: suivant ce que tu fais, ça peut aussi bien tenir sur un petit Celeron que réclamer un quad-quad core...

Jacques.

 

[jcaron]

Comment on arrive à faire 1 Go de base ???

1 Go c'est une misère, j'ai des bases de plusieurs centaines de Go qui traînent quelque part...

Jacques.

 

[OTP]

Ca m'épate. On ne doit pas faire les mêmes choses !

 

[jcaron]

C'est clair que tous les sites n'ont pas les mêmes besoins... Un site statique avec juste un peu de contenu, pas d'inscription, pas de UGC ça consomme forcément moins que Twitter...

Jacques.

 

[houcine-b]

Merci bcp Jacques vous m'avez éclairci bcp de choses

oxado c'est à vous ?

en effet je me demande comment font les régies publicitaires pour gerer le trafic enorme, qui se compte en millions pour certaines, pour le php on pourra faire la répartition de charge mais pour la base de données on ne peut pas faire du load balancing pour le mysql par exemple, comment font-il ?

 

[jcaron]

On répartit les tables à usages différents sur plusieurs serveurs, on partitionne les tables, on met des serveurs plus gros avec pas mal de RAM et pas mal de disques (genre des RAID de 14 disques...), on utilise des processus intermédiaires pour "agréger" les opérations pour limiter le nombre de transactions...

Pour Oxado il y a:
- 2 routeurs/firewalls/passerelles VPN
- 2 load balancers
- 20 frontaux qui comportent chacun un httpd+mod_perl, un serveur memcached, un serveur postgresql "local", un crawler et un processus de transmission de la base locale aux bases communes
- 7 serveurs de base de données postgresql, dont 3 paires en réplication via Slony-I
- une palanquée d'autres équipements divers et variés

A part dans les parties d'admin, les processus web sur les frontaux n'écrivent jamais rien directement sur les bases communes, ils stockent uniquement dans la base locale, et il y a des processus en tâche de fond qui vont lire dans ces bases et mettre à jour dans les bases communes (logs, stats, nouvelles pages, annonces, mots-clefs, etc.).

Ce fut bien amusant à mettre en palce tout ça, c'est dommage que Yahoo nous ait lâchés...

Jacques.

 

[houcine-b]

Impressionnant !
je me demande toujours pourquoi oxado ne gère pas directement les annonceurs ? ça améliore énormément le ciblage et le eCPM du coté des affiliés

est il possible d'afficher oxado sur une page de contenu qui souvre en popunder ?

Bonne continuation pour Oxado

 

[finstreet]

Comment on arrive à faire 1 Go de base ???

Ah ben tiens. Vu qu'on est dans la phase "on répond et on détaille gentiment" Je vais détailler un peu. J'ai une base d'1 G depuis peu Cool

En fait j'y arrive en deux tables

Une table de plus de 600 Mo qui contient dans les 60.000 actualités (mais vu que y'a deux champs Contenu, c'est plutot du 120000 en terme de place)

Et une table de 300 Mo où il y a un an de cotations boursières

Sinon pour ma table membres, je tourne à 7 Mo pour 30.000 membres

 

[OTP]

Oui, vu comme ça, je comprends mieux comment on en arrive là.
Merci pour les explications.