Discussion :

[Dorube]

Bonjour à tous,

Je me pose une question technique concernant les forums et les BDD. Supposons que j'aie un forum f, il stocke naturellement ses threads, messages, membres... dans une BDD.
Je me demande ce qu'il se passe à chaque fois qu'un client web requête une de ses pages web? Est-ce qu'il y a à chaque appel de chaque client une requête faite à la BDD? Ca me parait très lourd comme traitement donc je suppose qu'en pratique ça se passe autrement.

Si quelqu'un peut m'éclairer, merci beaucoup.

[al1_24]

Et que penses-tu qui serait moins lourd comme traitement ?
C'est le travail d'un SGBD de répondre à des requêtes et il sait bien le faire.

[Dorube]

Merci pour la réponse. J'ai des connaissances assez vagues mais je pensais qu'il pouvait y avoir un système de mise en cache (Memcache par exemple) pour les pages les plus demandées. Ce n'est pas nécessaire dans le cas général donc?

[SQLpro]

Un SGBD Relationnel de type client/Serveur fonctionne exclusivement en mémoire. C'est donc un gigantesque gestionnaire de cache. En sus les bon SGBDR comme SQL Server font du parallélisme naturellement et sont donc capable de gérer plusieurs milliers de connexions simultanément.

Lisez les articles que j'ai écrit à ce sujet.

A +

[skuatamad]

DVP a installé un serveur de cache pour les invités récemment.
Amélioration des performances du forum, le retour

Mais dans le cas général ça n'est pas nécessaire, DVP vivait bien depuis de nombreuses années sans cache.

[SQLpro]

DVP a installé un serveur de cache pour les invités récemment.
Amélioration des performances du forum, le retour

Mais dans le cas général ça n'est pas nécessaire, DVP vivait bien depuis de nombreuses années sans cache.

Oui, mais depuis longtemps, DVP utilise l'un des SGBD non relationnel les plus mauvais du marché à savoir MySQmerde !

A +

[StringBuilder]

Si j'ai bien compris, pour certaines données, soit très statiques (donc pas de mises à jour, mais très solicitées, par exemple la structure des catégories des forums par exemple, la liste des smileys, etc.) ou au contraire très volatiles et ne nécessitant pas d'historisation (variables de session par exemple, liste des connectés, etc.), on peut aussi utiliser des stables "inmemory".

Le serveur ne stocke alors rien sur le disque, et n'alimente même pas ses journaux de transaction au moment des mises à jour (à quoi ça sert de récupérer l'état de session d'un utilisateur après un crash du serveur ? de toute façon l'utilisateur ne sera plus connecté).

[StringBuilder]

Oui, mais depuis longtemps, DVP utilise l'un des SGBD non relationnel les plus mauvais du marché à savoir MySQmerde !

A +

Rhô ! Mauvais réveillons ?

[SQLpro]

Si j'ai bien compris, pour certaines données, soit très statiques (donc pas de mises à jour, mais très solicitées, par exemple la structure des catégories des forums par exemple, la liste des smileys, etc.) ou au contraire très volatiles et ne nécessitant pas d'historisation (variables de session par exemple, liste des connectés, etc.), on peut aussi utiliser des stables "inmemory".

Le serveur ne stocke alors rien sur le disque, et n'alimente même pas ses journaux de transaction au moment des mises à jour (à quoi ça sert de récupérer l'état de session d'un utilisateur après un crash du serveur ? de toute façon l'utilisateur ne sera plus connecté).

Le In Memory sera intéressant pour des données très fréqumment mis à jour. Par pour des données statiques. En effet, le In Memory c'est un gain de performance du fait que l'on n'écrit plus sur le disque. Or les disques sont entre 1 000 et 10 000 fois moins rapide que la RAM....

A +