Reprise du message précédent :
skyrock : 1 serveur, skyblog : 1 serveur. (xeon 2,4ghz)

Hu
Sur le même serveur, ils stockent les forums, chat, sites, images ?

Yep

Enfin tout ce qui est images est stocké ailleurs.

et les 70disques durs en raid10 tu les oublies?

 
smarty est l'un des plus rapides (sinon le plus rapide) quand tu actives la compilation php (genre Turck MMCache).

il n'y a que 4 disques dur de 250go.

j'ai tenté d'appliquer ma technique au listing des topics et ça marche: 3ms sur la requête au lieu de 32ms (qui était avec un LIMIT également).
 
Inconvénient: le up de vieux topics: ça forcerait un update sur tous les topics entre le plus récent et celui uppé (en gros j'ai tapé un numéro d'index continu sur la table des topics) Et pour éviter la corruption de données: lock table à chaque fois  Je crains que ces optimisations apportent une certaine lourdeur

Une personne qui taffe à skyblog m'a parlé d'une baie d'une 60aine de DD en Raid 10.  
 
Et franchement 18M de pap/jour sur un seul serveur c'est pas possible. En plus si c'est des DD de 250Go c'est du IDE? donc c'est clairement pas possible.
 
Aceboard fait quasi 3M de pap par jour, et on est obligé d'être en RAID5 avec des DD scsi donc si on multiplie le trafic par 6 jpense pas qu'un seul serveur soit possible

on s'en branle, non ?

 
J'ai egalement appliquer une technique pour eliminé les LIMIT a mon forum et etant donnée que nos methodes etaient  presques similaires je m'inquietes car je ne comprend pas ton probleme : le up du vieu topic ?

disons que j'ai 2000 topics dans une cat. J'ai un champ dans la table des topics, qui contient des valeurs de 1 à 2000, et ces valeurs sont dans le même ordre que l'id de dernier message pour chaque topic (sinon qu'elles se suivent). Lorsque je poste dans le topic identifié dans ce champs par la valeur 1900, il va passer à la valeur 2000, et tous les topics de 1901 à 2000 doivent donc être décrémentés d'une valeur 1. Durant toute l'opération, pour éviter la corruption des données, il faudrait mettre un lock sur la table pour empêcher même le read. Voilà ce qui me fait un peu peur

J'ai exactement le méme systeme pour mes topic et aussi pour mes message mais vu que je fais ce update en une seul requete le lock est fait avec cette seule requete regarde
 
UPDATE message SET numero = numero -1 WHERE id_message>".id_suppression." AND id_sujet = ".$id_sujet_en_cours."
 
La mise en jour etanty faites avec uen seule requete le lock est fait par monsoieur mySQL

si ce n'était qu'un update à faire, je passerais sur le lock, mais il faut que la table soit lockée entre le moment où je prends connaissance de l'identifiant pour le topic, et le moment où je fais l'update, car une autre connexion peut aussi lire/mettre à jour sans que je m'aperçoive de rien (faut que je fasse quelques calculs avant, ptet que je me prends la tête pour rien )
 
bref, j'étudierai ça plus en détail ce weekend  (vivement mon test de charge )

Mon moteur de templates est 2 fois plus rapide que smarty, meme avec son cache (caching=true et is_cached() et compile=true).

Drashe, sinon ce que tu peut faire c'est comment avant de balancer la requete qui va durer; mettre à jour les valeurs necessaire a la creation de sujet ou de message comme la valeur du numero de sujet en cours, tu la met a jour meme si la requete viendra apres, mais au moins si une création de sujet arrive pendant la requete, elle sera bien numéroté
 
Arf non elle sera updatée par le update qui va venir justement lol oubliez moi
Ceci dis tu te vois afficher au mec désolé quelqu'un supprime un topic alors tu ne peut pas en créer pour l'instant  

 
J'ai essayé, et je rencontre exactement le même problème   ..... Sur environ 92 000 sujets, pour peu qu'une personne remonte le premier, c'est foutu. Et un update de 89 999 sujets ahem, c'est plutôt long....

 
table splitée et c'est torché.

cad ?

 
Qu'il suffit de découper la table en plusieurs (plus petites) et d'appliquer le même système sur chacune de ces tables. Il faut par contre savoir combien il y a de topics dans chaque table ce qui n'est a priori pas franchement compliqué.

ça c'est implémenté déjà
Pour info il y a 1029 pages de topics dans prog.

 
comment on enleve l'uptime ?    
 
j'ai envie de tester mes temps là  

Je pense que je vais opter pour une autre solution qui me parait raisonnable et ne gacherait pas trop l'érgonnomie du forum. Cloturer et interdire la suppression d'un topic après un nombre défini de topic supérieur à celui ou l'on veut répondre (genre 1000 ou 2000 maxi (c'est du Access donc forcement...)) par le WebMaster. La suppression serait bien évidemment interdite pour tous les utilisateurs du forum (admin, modo, membre....). Je pense créer une alternative genre le split de sujet à ce moment là. Après ce nombre max dépendra beaucoup de la base de données utilisée  

dans ce cas il suffit (pour ma part) de faire
 
UPDATE forum  
SET verrou = 1  
WHERE id_forum = ".$id_forum_en_cours."
ceci empeche de creer des topic et message dans tout un forum
 
UPDATE sujet  
SET numero = numero - 1  
WHERE id_forum=".$id_forum_en_cours."  
AND id_sujet > ".$id_suppression."
Mise à jour des numero de classement aidant a la pagination
 
UPDATE forum  
SET verrou=0  
WHERE id_forum=".$id_forum_en_cours."
et on reactive le forum  
 
qu'en pensez vous ?
 
Edit -> plutot meme que de mettre a 1 on peut le mettre a 2 et affecter à cet état un marqueur de mise à jour du forum plutot qu'un verrouillage

 
tu as pensé au gars qui floodera ton forum d'une dizaine de milliers de messages ?  

Perso j'ai pas de problème à laisser rigoureusement tous les droits à l'admin, c'est pour ça qu'il est là, il est responsable de tout

 
Je ne limiterai jamais ça . Il pourra flooder autant qu'il veut puisque le sujet sera remonté constamment (et la mise à jour de la pagination aussi !) donc cela ne posera pas de problème. Je pense plus à de vieux topics avec 3 malheureux posts qui vont te sabrer tes perfs pour rien   , ou presque. Je pense à une aute solution, moins strict. Ne pas modifier le numéro de pagination après ce nombre atteint. Je me tate  

 
moi je te parle pour nettoyer .. (virer tous les messages du flood)

 
hum...., moui, je pense que je vais laisser cette option à l'admin finalement   , avec explications je pense (genre "WARNING", "le temps nécessaire pour traiter votre demande peut être long, etc..." )

et euh mon idée elle vous dis rien ... ?
de verrouiller le forum le temps de l'update des sujets ?

 
ca peut etre une solution, bonne pour des forums à faible frequentation mais pour un forum comme celui ci ca serait completement disproportionné je pense  

Le truc plus simple :
MEttre un champ VISIBLE (0 ou 1), quand tu veux deleter un tomic, tu passes ce champ à 0, et il ne s'affiche pas
 
Avantage :
Pas besoin d'updater les autres tomics (HEu, j'ai un doute )

Ha bah si, ça fait quand même des trous

 
si tu veux aller pars la on delete pas un gros topic sur un forum a forte frequentation en pleine journée monsieur on attend la nuit et a ce moment la ma solution fonctionne pour les quelques internautes qui seront bloqué pendant les deux malheureuse minutes ...

disons:
 

 
 
Dans cet exemple, la requete va aller chercher les 25 premiers topics à partir du num_topic 2975 non ?
 
Et lors d'un up d'un topic un peu récent, suffit d'increment& num_topic de 1 par rapport au nombre de message du forum, celà n'aurait aucun effet sur l'affichage des topics et serait assez rapide à faire..
 
Je trouve que mon raisonnement est bon, maintenant peut etre que je me trompe

ouai j'ai enfin uploader ma nouvelle version de mon forum !

Pense ce que tu veux, moi je dis simplement ce que je vois tous les jours
et pap = pages avec publicité, rien a voir avec les vues / jours.

skylight, c'est le meilleur de toute facon

Voila
 
Le système de pagination est terminé. Vraiment génial ce système, et les temps sont enfin corrects.

je ne te le fais pas dire, j'ai divisé le temps de génération par 4

Ok tu m'apprends rien
 
Néanmoins je te crois toujours pas. Rien qu'en débit théorique IDE c'est impossible.