La société où je fais mon stage actullement est en prévision de l'achat d'un serveur pour l'appli Php avec une base SQL Server 2000.
Vous me conseillez quelle config (proc, ram, dd, os)
 
L'appli Php fait environ 50 pages de code (pour le visuel, après y'a les requêtes donc ca fe du 200 fichiers)
Pour SQL Server y'aura environ 15 tables et 2 000 000 d'enregistrements
Les serveur web c'est bien sur Apache
après ben je crois que c'est tout.
 
On avait pensé à un Intel Xeon 3Ghz, avec 1Go de ram, un dd de 73Go(c ptet un peu bcp) à 15 000 tpm, et puis Win Server 2003
 
Vous en pensez quoi ?

ben après ca dépend de la criticité de tes données, de la fréquence des appels, de la fréquence des MAJ, nb d'utilisateurs connectés simultanément, pics d'activité, si l'appli a des contraintes (genre doit jamais s'éteindre, ne peut s'éteindre que la nuit), etc......
 
si ca va faire bcp de queries du raid pour les disques peut accélérer les choses...si tu veux de la sécu faut faire un peu de redondance (là tu augmente sévèrement le prix du matos)...

 
Pour les données, ben ca gère tous leurs clients potentiels donc c plutôt important mais y'a des backup effectué régulièrement (a eux de les config sur une page php que je leur ai fait). Ces fichiers seront certainement sauvegardé sur un autre serveur (soumis  lui aussi a des backup de la totalité des fichiers).
La fréquence, je dirais pas énormément vu que l'appli n'est pas encore intégrée totalement, les accès concurentiels seront peu fréquents à mon avis. Les pics d'activté évalués le matin et parfois la nuit pour mise à jour de la base ou backup.

c quoi le nb total d'utilisateur, et le nb total d'accès concurrents ?
parce que si c'est pas bcp et que t'a peu de concurrence, vous etes surement parti sur des specs trop élevées...
 
y'a bcp de traitement coté serveur, ou c juste un frontal de BD ?

Y'a pas beaucoup d'utilisateurs (du moins pour le début) qui vont se connecter.
Par contre, y'a des procédures définie dans SQL qui peuvent durer 5 10 sec , et après avec l'algorithme défini dans php pour traiter tout ca, ca prend environ 20 30 sec pour lancer une impression, ou exporter les résultats dans un fichier.
Mais oui à mon avis c surement un peu trop, après faut que je vois ce qu'il compte y mettre en plus par la suite.

En gros :
- 1 seul HD : pas bien
- 1 Go de RAM : mal
- 3 GHz : inutile
 
Côté PHP, à moins que ce soit très intense, un vieux Pentium 100 sera toujours suffisant (bon, j'exagère un peu )
Niveau mémoire, idem, à moins que tu développes comme un goret.
Niveau taille de stockage, 73 Go pour stocker 73 Ko de fichier, c'est beaucoup
Niveau rapidité du disque, 160 Mbps de bande passante pour charger des fichiers de 2 Ko, c'est pareil ça fait beaucoup
 
Donc, côté Apache, te pose pas de question.
 
Côté BDD, par contre, c'est très différent :
- La RAM, plus on en a, et plus c'est mieu. 1 Go, ça me semble juste. Win2K3 + Apache + SQL Server, ça va rapidment bouffer la moitié de la RAM. Même si logiquement, avec le reste, ça devrait tenir, autant être sûr que ça bloque pas et investir 200 € de plus pour mettre un second Go
- Le CPU, là, étrangement, SQL Server est très peu consommateur. On obtient de très bonnes performances sur des vieux Pii. Donc c'est un point sur lequel tu peux économiser.
- Niveau HDD, SCSI 15Ktrm, c'est très bien. Par contre, si tu peux en prendre deux de 36 Go plutôt qu'un seul de 73 Go, tu démultriplieras tout simplement la vitesse de traîtement du SGBD (en séparant le fichier de logs et les data sur chacun des deux disques).
 
Voilà, en gros.
 
Bon, après, si y'a 2000 hits à la seconde, forcément, ça change la donne...

Ceci dit, j'ai fait différents tests sur différentes configs, et j'ai toujours obtenu des résultats étranges, notamment avec SQL Server.
 
Je me suis retrouvé devant des serveurs maxi-musclés, avec des traîtements hyper simple, et qui rammaient, alors que là, je suis sur un vieux tromblon (Pii@233MHz avec 384 Mo de mémoire), et j'obtiens de très bonnes performances sur des gros volumes de données (pas testé avec des requêtes complexes par contre )

Je te remercie pour les conseils, j'y vois un peu plus clair
Mais je me demandais, comment tu fais pour séparer SQL Server sur 2 dd, mettre les log d'un coté et les data sur l'autre ??
 
Parce que pour mon instal classique, j'ai pas choisi (g ptet loupé la ligne, et pis ca fait un ptit moment que je l'ai installé) !

Ah je crois que c'est bon, en fait ca doit être dans les propriétés de la base qu'on veut. Suffit de définir les chemin d'accès des fichiers : nom_base_Data.mdf et nom_base_Log.ldf.
 
Sinon c'est pas ca dit le moi. La mes fichiers font respectivement 3Mo et 1Mo pour le 1/1000 de lignes insérées.

je suis pas du tout compétent en admin système...mais normalement c'est un paramétrage. De mémoire, dans SQL serveur tu peux séparer les bases, les logs et les backups, et y'a suremenbt moyen de faire ca plus finement, mais là j'en sais rien...
 
mais Arjuna c son rayon ca

C'est tout à fait ça
 
Selon la version, il te demande aussi le répertoire par défaut de ces deux fichiers pendant l'install, avec un message d'avertissement à la validation, hurlant tout ce qu'il peut si tu met le même disque dur
 
Mais on peut toujours l'overrider lors de la création de la base en spécifiant manuellement le chemin.

question pour culture perso : on peut séparer par table ? genre je sais pas tu gardes tt les tables de prod sur un disque, et t'a une table dans laquelle tu enregistre des logs de l'applis (donc potentiellement des Go) et tu voudrais el sortir sur un autre disque...c possible ?

Sans aucun problème : tu crées un second groupe de fichier sur un autre disque, et tu met ta table dans ce nouveau groupe de fichiers.
 
C'est ce que j'ai fait chez moi, dans une autre optique :
C: Système
D: SQL Server
E: Fichier "PRIMARY" (contient que les tables)
F: Fichier "INDEX" (contient les index)
G: Fichier du log des transactions
H: Application IIS
 
(avec évidement un disque SCSI différent pour chaque unité)
 
Et Ca marche du feu de Dieu

Je suis en train de regarder les serveurs DELL.
 
http://commerce.euro.dell.com/dell [...] tore=frbsd, il m'a l'air simpa, seulement je veux connecter 2 dd de 36Go, en SCSI je pense. Est-ce que je dois rajouter des cartes controleur RAID ou SCSI pour le faire ou par défaut c'est possible de les monter ?
Et quelle connectivité des diques durs je dois choisir ?
 
Merci de votre aide

A froid, je dirais que vu qu'il y a de base :
 
Un contrôleur bi-canal U320 (un peu mieu que ce que j'ai)
-> Tu peux connecter jusqu'à 30 disques durs SCSI sans RAID.
 
Deux cartes RAID, tu peux aisément faire au moins deux chaînes de 15 disques avec n'importe quel type de RAID.
En combinant les deux interfaces RAID, si c'est possible (vu qu'elles sont installées de base, je pense que ça l'est) tu peux même t'amuser à faire une chaîne RAID 50 de 30 disques.
 
Donc, OUI, y'a pas de souci, tes deux disques durs en RAID vont même se sentir un peu seuls à mon avis
 
Pour la connectivité, ce qu'il y a de plus courant actuellement, c'est ces trois normes :
 
U3W, U160 et U320. Les deux premières normes sont quasi-équivalentes (il y a une subtilité qui les différencie, mais ne je sais plus laquelle). Quand à la dernière, elle est tout simplement deux fois plus rapide.
 
Pour 2 disques seulements, n'importe laquelle de ces interfaces fera l'affaire, et toutes les interfaces du serveur que tu as retenu les supportent. (fait bien gaffe à ce que ce soit du 68 pin et non du 72, sinon t'as plus qu'à t'acheter un adatateur, ou un boîtier hot-plug...)
 
Si t'as une occasion pour des disques U2W de récup, saute dessus, ça fera aussi l'affaire, et si tu peux avoir plus de disques, tu pourras au moins faire du RAID 10 ou 5, ce qui est bien mieu que du RAID 1 ou 0, seuls possibles avec deux disques.
 
A noter que pour une occaz, tu peux y aller les yeux fermés pour du SCSI. Ce sont des disques increvables, dont la garantie oscille généralement entre 5 et 10 ans, donc même d'occaz, ils sont certainement encore sous garantie.

15 tables de 2.000.000 enregistrements chacune, ou 2.000.000 enregistrements toutes tables comprises ?