[Conseil]Language web pour site web lourd

Bonjour à tous,

Je me suis lancé dans un gros projet sur le web avec mon frère et avant le début de celui-ci, je me renseigne un peux sur les plus puissants languages web.

Je m'y connais déjà pas mal en html, php, javascript, sql.

Le site web en lui même ne va pas avoir un fort trafic, mais le service ui. Il y aura une bannière, avec un script derrière (calculs + base de donnée 3-4 requètes) qui sera affiché un max de fois. Genre 4-5 million mois.

Je me renseigne sur le net et j'ai trouvé plusieurs solutions pour coder cela :
php, pas assez rapide?
cgi, mais pas assez rapide à ce qu'il parrait -> perl
fastcgi
servlet

Base de donnée :
Mysql 5.1
PostgreSQL
Oracle

Que pensez-vous que je dois utiliser?

Merci pour vos conseil !

Si je comprends bien, c'est juste un script de régie publicitaire que tu vas faire ?
En gros, un script qui en quelques requêtes récupère l'adresse de la bannière à afficher et mets à jour les statistiques ?

Si c'est ça et que tu comptes faire ~5 millions de bannières par mois, reste sur PHP/MySQL.

Déjà tu connais, c'est déjà un énorme avantage.
Ensuite 5 millions d'affichages par mois, ça fait en gros une dizaine par seconde, ou un peu plus pendant les pointes (disons 50), et ce genre de charge est évidemment tout à fait gérable avec PHP.
Une centaine de requêtes par seconde, c'est bien-sûr dans les cordes de MySQL (les autres DB que tu cites aussi, mais PostgreSQL est un peu moins bon sur les INSERT que MySQL, et Oracle est très cher).

Après, il s'agit surtout de bien concevoir tes tables et tes requêtes, de bien configurer ton serveur MySQL, et surtout surtout surtout d'avoir du hardware en conséquence (surtout au niveau es disques durs, le reste semble moins important pour ce que tu veux faire).

PHP c'est véloce. C'est à toi à optimiser lors de la programmation.

par exemple si une page est très fréquentée et quelle affiche des informations qui proviennent d'une base de données + calculs long en temps MAIS dont la source (la DATABASE) est mise à jour seulement une fois par jour, alors au lieu de faire une page php qui recueil toujours les mêmes infos, les calculs et les affichent, tu peux faire une page PHP qui génère une page HTML, et c'est cette page que les gens visualiseront. Ca te fait des énormes économies si c'est réalisable...

Après tu peux rajouter des trucs sur PHP http://developpeur.journaldunet.com/tutoriel/php/040209php_systemes_cache1a.shtml pour encore améliorer.

Sinon je crois que les poids lourd sont a peu près identique en terme de vitesse (php, java, .net). Les trucs en ruby etc je connais pas mais c'est peut-être mieux

Ce n'est pas le language qui fera réellement la différence. Par ordre d'importance d'aprés ce que tu dis :

1. Les ressources et la bande passante du serveur;
2. La propreté du code derrière (l'optimisation).
3. Le language.

Je me suis gourré, car avec 5 million de bannière par moi j'irai pas loins! Enfin je veux dire par là, que le serveur, ou les serveurs (cluster?) doivent, je l'espere un jour pouvoir supporter 10 ou 15 * plus...

Dans ce cas là, il ne vaut mieux pas directement passer au servlet? Vous vous y connaissez là dedans? Est ce que ca a un vrai apport?

Le tout c'est d'optimiser le code php. Il existe des softs comme Zend optimizer qui permettent de généré du bytecode et ainsi réduire le temps d'execution.

Pour ton SGBD, d'après les discutions que j'ai eu avec d'autres sur ce forum, MySQL serait indiqué si c'est des requetes simple, PostGres si c'est des requetes plus lourdes... et si tu es vraiment au taquet avec ces deux là : Oracle, mais là $$$

Un élément qui peut accélérer les traitements c'est les serveur multi processeurs, vous deux serveurs (Appli-SGBD).

Il est possible de mesurer les temps d'executions de script php ainsi que des requetes ...

Et je pense que tu seras plus vite limité en bande passante que au niveau de l'execution du script.

Je crois que la partie protocole http est relativement lente, je ne sais plus où j'avais vu un outil qui permetait de donner le temps d'accès + temps de téléchargements...

Douby a dit:

Je me suis gourré, car avec 5 million de bannière par moi j'irai pas loins! Enfin je veux dire par là, que le serveur, ou les serveurs (cluster?) doivent, je l'espere un jour pouvoir supporter 10 ou 15 * plus...

Dans ce cas là, il ne vaut mieux pas directement passer au servlet? Vous vous y connaissez là dedans? Est ce que ca a un vrai apport?

Cliquez pour agrandir...

Comme l'a dit La Poubelle ce n'est pas le language à proprement parler qui te gènera

Il te faudra à mon avis deux serveurs : un pour le PHP, un pour MySQL
Optimiser au maximum tes requètes. Optimiser un maximum ton code ...

Donc deux serveurs seraient bien peut-être au futur ?

Pour faire tourner deux serveurs comme ça, il suffit d'ouvrir le serveur physique mysql sur le lan au lieu du localhost ?
Il y a t'il des gains exeptionnels?
Pour un serveur avec php, il vaut mieux priviliéger la ram et cpu, et le serveur mysql les hds ?

Il y a t'il moyen de mettre dans la ram un script php ? Si c'est possible, gagne t'on de la vitesse?

Grand merci pour vos réponses déjà très complètes

Douby a dit:

Donc deux serveurs seraient bien peut-être au futur ?

Pour faire tourner deux serveurs comme ça, il suffit d'ouvrir le serveur physique mysql sur le lan au lieu du localhost ?
Il y a t'il des gains exeptionnels?
Pour un serveur avec php, il vaut mieux priviliéger la ram et cpu, et le serveur mysql les hds ?

Il y a t'il moyen de mettre dans la ram un script php ? Si c'est possible, gagne t'on de la vitesse?

Grand merci pour vos réponses déjà très complètes

Cliquez pour agrandir...

Ca dépend l'utilisation que tu en fait ...

Pour travailler avec une paire de serveurs (SGBD+Appli) il suffit de configurer MySQL pour qu'il écoute sur le réseau local et permettre aux utilisateurs MySQL de se connecter depuis un hote distant.

Douby a dit:

Donc deux serveurs seraient bien peut-être au futur ?

Cliquez pour agrandir...

Deux, ou plus, les seules limites sont tes compétences et ton budget. A moins de connaître précisément la charge qu'entraîne ton application, je te conseillerais de commencer par un serveur bon marché, et d'aller crescendo en fonction de tes besoins.

Pour faire tourner deux serveurs comme ça, il suffit d'ouvrir le serveur physique mysql sur le lan au lieu du localhost ?

Cliquez pour agrandir...

Ca dépend ce que tu veux faire. Si c'est la séparation serveur web/server sql, alors "oui" (sous réserve que tu ne veuilles pas de redondance ni de load balancing).

Il y a t'il des gains exeptionnels?

Cliquez pour agrandir...

Ca dépend de la charge subie par les différentes parties. La différence entre un serveur "tout compris" et plusieurs serveurs peut être flagrante, oui.

Pour un serveur avec php, il vaut mieux priviliéger la ram et cpu, et le serveur mysql les hds ?

Cliquez pour agrandir...

Quelque soit l'application, privilégie (sans tomber dans l'excès) la RAM au CPU, et le CPU aux disques.
Plus de RAM il y a, moins les accès disques seront fréquents.
Plus de CPU il y a, plus le nombres de clients que tu peux servir sera grand.

A titre informatif, sache qu'un site relativement visité (30millions de hits et 180GB par mois) tourne sur un simple P3 866MHz/512MB RAM (serveur web) secondé par un P4 3GHz/1GB RAM (serveur sql, base de 600MB).

Il y a t'il moyen de mettre dans la ram un script php ? Si c'est possible, gagne t'on de la vitesse?

Cliquez pour agrandir...

Un OS potable garde en général pas mal de choses en RAM si cette même RAM n'est pas nécessitée par autre chose.
Cependant, dans le cas de fichiers temporaires, tu peux voir un gain (flagrant) à utiliser la RAM plutôt que le disque comme espace de stockage.


Comme déjà dit, une partie de la solution réside dans la propreté et dans l'optimisation du code. Ca passe aussi par quelques heures d'analyse des requêtes SQL générées (le fameux 20/80).

D'autres paramètres entrent en jeu, comme le filesystem, la bande passante, ...

N'oublie pas de faire des trigger et des fonctions (si cela est possible) ainsi tu décharge php d'une partie de la logique métier...

En feuilletant la doc MySQL, j'ai vu qu'il y avait deux méthode pour effectuer des requetes
- mysq_query() : execute la requete et prépare un résultat.
- mysql_unbuffered_query() : execute la requete et ne prépare PAS de résultat.

Ca optimise l'utilisation de la mémoire en fonction de tes requetes.

(Si tu le savais déjà, dsl... moi j'm'en suis rendu compte hier )

grosnours a dit:

Quelque soit l'application, privilégie (sans tomber dans l'excès) la RAM au CPU, et le CPU aux disques.
Plus de RAM il y a, moins les accès disques seront fréquents.
Plus de CPU il y a, plus le nombres de clients que tu peux servir sera grand.

Cliquez pour agrandir...

C'est vrai pour un serveur web (PHP ou autre), mais certainement pas pour un serveur de DB !
Pour PostgreSQL, c'est clairement Disques > RAM > CPU ! Les disques sont la chose la plus importante du système ! Pour PostgreSQL, des utilisateurs ont fait des benchmarks, et c'est le RAID 10 (RAID 0+1) qui est favori.
Il faut au minimum 4 disques pour du RAID 10, et un bon contrôleur (Areca par exemple).
Pour MySQL aussi, très probablement.

En fait, ce genre de conseil ne vaut que si on connait l'application.
Si la base de données est utilisée principalement en lecture, et sur de petites tables, les disques n'importent plus du tout : les tables seront cachées en mémoire par l'OS, et il n'y aura presque pas d'accès disque.
Dans le cas présent, je suppose que chaque appel du script sera loggé (dans une table de statistiques par exemple). Du coup, il y aura une certaine charge sur les disques en écriture.

Il faudrait en savoir plus pour donner des conseils plus précis.
Toujours est-il que PHP / MySQL sur un serveur assez basique pour commencer, ça supportera déjà un grosse charge. Si ça monte en charge, tu verras tout de suite où est le goulet d'étranglement (CPU, mémoire ou disques), et tu sauras ce que tu dois upgrader.
Si un serveur ne maintient plus la charge, tu passes à deux serveurs (Web d'un côté, DB de l'autre). Dans ce cas il faut faire attention à la qualité de ta liaison entre tes machines (du Gigabit semble approprié).

Bingo a dit:

C'est vrai pour un serveur web (PHP ou autre), mais certainement pas pour un serveur de DB !
Pour PostgreSQL, c'est clairement Disques > RAM > CPU ! Les disques sont la chose la plus importante du système ! Pour PostgreSQL, des utilisateurs ont fait des benchmarks, et c'est le RAID 10 (RAID 0+1) qui est favori.
Il faut au minimum 4 disques pour du RAID 10, et un bon contrôleur (Areca par exemple).
Pour MySQL aussi, très probablement.

Cliquez pour agrandir...

Par expérience, je préfère RAM > CPU > disques, surtout vu la vitesse (débit et temps d'accès) des disques actuels et les solutions de RAID (même software).
Avec mon GB RAM et ma base de 600MB-qui-est-totalement-en-cache, je n'ai quasi aucune lecture disque. Du coup, même si le stockage est effectivement un RAID10 (sur un controleur en carton), les performances des disques n'ont pas vraiment n'importance.

Comme tu l'as dit, ça dépend de chaque application, mais personnellement, je n'ai jamais vu de goulot d'étranglement au niveau des disques.

Je pourrai bientot faire la comparaison entre le système actuel et un système plus puissant en RAID5 sur Areca, si ça se met à ramer, je saurai pourquoi

grosnours a dit:

Par expérience, je préfère RAM > CPU > disques, surtout vu la vitesse (débit et temps d'accès) des disques actuels et les solutions de RAID (même software).
Avec mon GB RAM et ma base de 600MB-qui-est-totalement-en-cache, je n'ai quasi aucune lecture disque.

Cliquez pour agrandir...

Si tes tables tiennent en mémoire, c'est évidemment la RAM et le CPU qu'il faut priviliégier.

Comme tu l'as dit, ça dépend de chaque application, mais personnellement, je n'ai jamais vu de goulot d'étranglement au niveau des disques.

Cliquez pour agrandir...

J'ai des tables de plusieurs dizaines de millions de lignes avec des données spatiales dedans (des polygones et polylines essentiellement).
Autant te dire que la RAM ne m'est d'aucune utilité quand je fais des requêtes dessus !

Sur une application web, en général les tables tiennent en mémoire, et dans ce cas tes priorités sont justes !

Mettre la bd en cache dans la ram... Cela se fait automatiquement ou bien il y a une manipulation spéciale?

Le trigger mysql ca consiste en quoi ? Je suppose que c'est assez récent vu que la gestion complète de ceux ci est prévue pour la version 5.1 de mysql...

Merci de toutes vos réponses pertinentes et rapides

Douby a dit:

Mettre la bd en cache dans la ram... Cela se fait automatiquement ou bien il y a une manipulation spéciale?

Cliquez pour agrandir...

L'OS cache automatiquement les fichiers qu'il lit.
Si tes tables sont petites et sont accédées souvent, il y a de très fortes chances pour qu'elles soient en cache.

En plus de ça, dans MySQL tu peux créer des tables en mémoire.
Elles sont détruites si le serveur s'arrête, ce n'est donc pas évident à gérer, mais tu es sûr que ta table sera toujours en mémoire.

Le trigger mysql ca consiste en quoi ? Je suppose que c'est assez récent vu que la gestion complète de ceux ci est prévue pour la version 5.1 de mysql...

Cliquez pour agrandir...

En gros, une trigger (déclencheur en français), c'est une action qui est associée à une table (ou si le SGBD le permet, l'action peut être associée à un champ), et qui se déclenche lors d'une activité particulière sur cette table (INSERT, UPDATE, DELETE).
Regarde ICI pour l'utilisation de triggers dans MySQL.
Si tu comptes utiliser ce genre de fonctionnalités avancées, tu devrais jeter un oeil à PostgreSQL. Ces fonctionnalités y sont implémentées depuis longtemps, elles fonctionnent très bien et tu peux écrire tes fonctions ou procédures dans le langage de ton choix (C, Perl, Java, Python, PHP ...).

Firebird pourrait être la solution complète et gratuite entre MySQL et Oracle qui satisfierait tes besoins.

[EN] http://www.firebirdsql.org/
[FR] http://www.firebird-fr.eu.org/
[FR] http://interbase.developpez.com/

PunkDeLouxe a dit:

Comme l'a dit La Poubelle ce n'est pas le language à proprement parler qui te gènera

Il te faudra à mon avis deux serveurs : un pour le PHP, un pour MySQL

Cliquez pour agrandir...

heu question??? pkoi deux serveurs ????
à la limite deux serveur en load balancing.. ok mais là je vois pas. (mais l'explication m'nterresse).

Pour répartir/séparer la charge du serveur SQL et la charge du serveur web.

Calvin80 a dit:

heu question??? pkoi deux serveurs ????
à la limite deux serveur en load balancing.. ok mais là je vois pas. (mais l'explication m'nterresse).

Cliquez pour agrandir...

Quand tu fais du load balancing, tu répartis meme charge sur plusieurs serveurs.

Or, l'appli dont on parle ici se compose de deux parties : le programme et le stockage des données (modèle simpliste).

Donc avant de se lancer dans du load balancing, l'idéal est d'avoir un serveur dédié à chaque partie. En l'occurence, un serveur pour le programme et un autre pour la BD.

Le tout est d'utiliser le serveur de BD un maximum pour répartir la charge au mieux.