Reprise du message précédent :

Quand tu as besoin de plus de 2 variables PHP dans l'URL, et que tu veux que Google réference ton site avec ces pages, il faut que tu passes par l'URL rewriting.
 
En effet, Google ne référence pas les pages qui ont besoin de plus de 2 arguments PHP dans l'adresse. C'est pourquoi on fait "une transcription" d'adresse normale en adresse PHP.
Ceci est à modifier dans ta configuration apache, et ensuite, tu dois definir tes règles de "transcription", c'est à dire que tu dois indiquer à Apache, quoi rediriger.
 
Exemple : Sujet2-Page1.html, doit etre renvoyé sur sujet.php?sujet=$sujet&page=$page
 
L'exemple que j'ai donné est inutile, car Google referencera quand meme ta page en PHP.
 
C'est aussi utile hors Google, car ca permet aux gens de se souvenir d'adresses plus simples...
 
Sujet1-Page2.html est plus facile a retenir que sujet.php?sujet=$sujet&page=$page
 
 
A+

il te reste moins d'une semaine pour devancer skylight

c'est foutu

Merci je vois l'interet maintenant

Mais non, il suffit de sortir un forum statique

ah mais ça c'est déjà fait, c'est mon proto (bien que toutes les pages ne soient pas encore faites)

Grillé, j'ai même pas eu le plaisir d'annoncer moi même mon nouveau moteur Donc voilà, après de longs mois d'analyse et de développement il est enfin prêt Mais malheureusement, ses performances ne sont pas mises en valeur sur le lien que tu as donné. Sur la page des messages, les "Liens sponsorisés" ne sont pas affichés en JS comme avec une régie traditionnelle, mais par l'include d'un script PHP d'une centaine de lignes qui récupère les campagnes à grand renfort de fsockopen et de fput, ça me prend 60% du temps de génération des pages L'hébergement aussi ne permet pas au moteur de s'exprimer. Je n'ai pas un gros serveur mais deux "petits". Habituellement c'est préférable, mais ca n'a pas que des avantages puisqu'en contrepartie je perds un dixième en temps de génération à cause de la connexion distante au serveur, par rapport à l'utilisation des sockets. Sans même parler du Go de RAM qui est très rapidement saturé aux heures d'affluences (751 connectés cette après midi) et qui m'empêche de configurer MySQL comme je le souhaiterais au niveau de la gestion des index en cache. C'est dommage : en surfant sur le forum installé directement sur le serveur SQL (P4A 2.4 Ghz) les temps de générations sont inférieurs à ceux du forum PPC par exemple (est-ce qu'il peut aussi bien monter en charge par contre c'est pas certain, et faute d'hébergement comparable c'est impossible à vérifier).
 

Merci pour lui, mais le programmeur a parfaitement compris tout cela Simplement, il y a un taff à côté. Il n'est pas payé pour développer un forum, il fait ça sur son temps libre. Et du temps libre il n'en n'en pas beaucoup. J'aurais été le premier ravi d'adopter une séparation stricte pour la mise en page mais ca demande beaucoup plus de temps. La feuille de style du forum est relativement pauvre, mais elle permet déjà pas mal de modifications sympas. Ce qui m'intéresse avant tout c'est la performance, je ne suis pas là pour faire un truc lêché à la IPV avec des frioritures de partout La rapidité d'abord ! Et pour le coup j'ai réussi mon pari : gestion de topics de 370 000 messages sans aucune dégradation de performance, rapidité constante quelque soit la page consultée (de la première à la dernière). Ton moteur sera peut être en XHTML 1.1, mais comment se comportera-t-il avec des sujets de plusieurs centaines de milliers de messages, et avec des sections de plus de 1000 pages de sujets ? Moi c'est ca qui m'intéresse avant tout, je ne suis pas designeur

 
entre 1.0 et 1.1 à part l'attribut name qui a disparu il n'y a pas de grande différence

 
Tiens je savais pas qu'y avait le développeur de ce forum ici... ça tombe bien
 
deux points négatifs de la nouvelle interface :
- les bords 3D un peu partout je trouve que ça allourdit fort l'interface
- après avoir posté/édité je trouve ça lourd de devoir cliquer sur le "cliquez ici" Avant on pouvait choisir dans les Préférences si on voulait revenir au topic ou à la liste après avoir posté.

 
pourtant :  
 
http://forum-auto.com/sqlforum/sec [...] 141319.htm
Cette page a été générée en 0.1525 secondes
C'est pas exceptionnel.

Oulala ça cherche

Cf ce que je disais au dessus :L Espotting ne fournie pas un JS mais un fichier PHP à inclure pour les liens sponsorrisés. Ce script fait un fsockopen() sur leur serveur pour récupérer les données, ca prend un temps fou. Je suis en contact avec eux pour voir si je peux avoir du JS à la place. La leur solution est super clean dans la mesure ou ca permet de personnaliser à 100% l'affichage, mais ca bouffe des ressources
 
antp => je te réponds ce soir

Et la meme chose, mais le fichier en local, ca peut pâs marcher ? Ils mettent a jour directement sur ton serveur (acces protégé)

et puis 50% de 152ms, ca donne 71ms ...

DaFloodMachine n'est pas encore assez rapide pour générer une base de cette taille dans des temps acceptables (genre HFR)

Question caches PHP, j'ai pu voir en vrai ce que ça donne depuis que je taffe chez Skyrock .... on dirait pas, mais les blogs coté serveur, c'est hallucinant

tu taffe a skyrock ?    
t'es dans leurs locaux ou c'est a distance ?

J'aimerais bien, mais va expliquer à une régie que leur fuc**** script prend 0.06 secondes de temps machine et que c'est scandaleux
 

Ce qui est correct, je ne revendique d'ailleurs pas de temps bien meilleurs (d'autant plus que je gère une table unique de 6 millions de messages), simplement la stabilité de ces temps sur des sujets particulièrement gros Que tu prennes un topic de 10 messages ou un de 100 000 messages pour moi c'est pareil

Je suis dans leur locaux
Enfin je taffe pour Skyrock .. c'est un bien grand mot.
Je taffe pour Telefun, société qui erige tous les services web de Skyrock (skyrock, skyblog, tasante.com, yazata, skymobile...), donc oui, j'ai accès à tous les serveurs de skyrock, et c'est monstrueux.
 
D'ailleurs ya un serveur en reiserFS qui merdouille comme il faut là.

 
La configuration du serveur c'est quoi ?
Tu as fait un monitoring coté MySQL ?

t'es a paris donc ?

Yep (cf profil ou config, j'aurais jamais de connexion internet comme ca )

 
Ca a de multiples avantages. Ca évite toute la partie de communication avec mysql. Ca évite les allocations mémoire qu'on peut avoir faire. Ca permet aussi d'éviter des requêtes d'update. Par exemple pour les hits, on peut très bien faire un système qui ne les update (en base) que tous les n hits. Un autre avantage que je pensais pouvoir avoir est la transformation du bbcode et des smileys déjà faite en cache mais j'ai un petit problème: la transformation du bbcode est dépendante du template utilisé (mais si on n'utilise qu'un seul template, par contre, ça marche très bien). Bref, ça permet d'économiser énormément de cpu pour (assez) peu de mémoire.

En même temps celui là doit pas être loin d'être strict

Tu peux pas comparer un P4 2.4 GHz et un bi athlon MP 1800+ ou 2000+

en a qui cheatent ici

 
D'un autre côté, c'est techniquement exact

pour le BBCode effectivement c'est pas bête

Non, effectivement, c'est très difficile. C'est pour ca que je me garde bien de faire des estimations sur la capacité de mon moteur à monter en charge aussi bien que celui de PPC (même si avec suffisament de RAM je dois aussi pouvoir tenir 1000 à 2000 users sans difficultés), qui est vraiment impressionnant à ce niveau.
 
Ceci dit, P4 2.4 (FSB 400) et MP 1800+ ca n'a pas d'influence sur le temps de génération. J'ai des résultats quasi identiques sur un Céléron 800

ca dépend énormement des traitements fait en PHP derrière je dirais

Et puis surtout si tu as un mono-processeur d'un coté contre un bi-processeur de l'autre ...

ca joue pas sur les temps de génération, apache n'est pas multithreadé.

Non mais avoir un processeur pour MySQL c'est quand même mieux plutot que tout tourne sur le même ...

Hello.
Je voulais savoir comment vous gériez les multi-pseudo.  
J'avais eu pour idée de faire une table "multis" avec comme champs: "id_user1", "id_user2" où j'indiquerais les id des 2 utilisateurs lorsqu'il y a détection de multipseudo.
 
Mais imaginons l'exemple suivant:
 
multipseudo entre les user 10 et 22 detected => entrée dans la table
multipseudo entre les user 22 et 56 detected => entrée dans la table
 
Il faut bien sur pouvoir détecter que 10,22 et 56 sont la même personne. Pour tout récupérer, j'utilise actuellement une fonction récursive, mais c'est un peu lourd.
 
Ais-je mal pensé le système? (je pense que oui )

tu pourrais faire: détection 22 - 56 => tu mets 10 - 56
 
tes entrées se feraient toujours par rapport au premier pseudo enregistré.
 
non ?
 

en fait, avant de l'ajouter en DB, tu pourrais tester pour voir s'il existe déjà, et utiliser 10 comme id principal.

 
ben tu fait une jointure sur la meme table en creant un alias.
puis tu fait les champ id1 id2
puis tu fou un distinct pour pas avoir deux fois le meme resultat.

Moa j'ai créer un champs unique qui limite donc les doublons...

héhé, je crois pas
 
si tu as deux champ, id1 id2
 
id1:fabien id2:scull
id2:scull  id1:scull
 
ce qui veut dire:
 
fabien=scull
scull=fabien
 
tu trouve pas que ca fait doublon ?
 

meme si ton post est pas tres clair, je pense que ca peut se regler avec un unique sur plusieurs champs.
unique(id1, id2) et voila.

MySQL est multithread par contre