Wikipédia:Fonctionnement technique de Wikipédia

Un article de Wikipédia, l'encyclopédie libre.

A en juger par l'abondance des réactions il y a un vrai problème pour l'avenir jeffdelonge 27 aoû 2003 à 12:20 (CEST)

Je sais si ca ete dit, Brion a désactivité certaines fonctions des 'gros' wikipédias (dont le notre) pour essayer d'améliorer les performances. Shaihulud 20 aoû 2003 à 17:00 (CEST)

Au fait, c'est prevu pour durer ? parce que concernant les pages orphelines, c'est (un peu) genant... Traroth 21 aoû 2003 à 13:07 (CEST)

Est-ce qu'il est prevu de réactiver cette page un jour ? Impossible d'integrer les articles orphelins si on ne les connait, et si on attend trop longtemps, on va se retrouver avec des tonnes d'articles orphelins... Traroth 26 aoû 2003 à 14:50 (CEST)

Oui.. Quoi que d'un autre côté si celà améliore la rapidité de wikipedia.. qui, à propos est des plus détessables les derniers jours.. jpréfèrerais presque ça. Mais cette page ne saurait-elle pas être mise à jour tous les deux jours? c'est mieux que rien. Et quelqu'un pourrait expliquer cette frustrante lenteur à certaines périodes de la journée. Je dois parfois attendre 30 min ou plus (sérieux!) pour voir une page apparaître. Conection adsl qui fonctionne très bien, donc ce n'est pas ça. Guillaume Bokiau 26 aoû 2003 à 22:42 (CEST)

c est qlq chose qui me stresse. Le débit n est pas bon en effet. Et le coup de pub ne va rien améliorer. Je ne pense pas que les articles orphelins soient reconnectes avant que plus d ameliorations soient apportés au soft. Il est meme possible que d autres fonctions soient desactivees autour du 08 sept. Eventuellement, wikipedia pourrait meme être en read only. Vous souvenez vous le dernier coup de pub des allemands ?Ant

Amelioration du soft ? Je ne sais pas si ça va suffire... Les possibilités d'optimisation ne sont pas illimitées. Il faudrait recourir à des mesures plus radicales, comme la separation de serveurs, avec installation des serveurs à proximité geographique des contributeurs. Mais ça, ça coute (très) cher... Traroth 27 aoû 2003 à 09:15 (CEST)

Il y a deja deux serveurs differents. Mais les séparations ne sont pas non plus infinies si l on veut garder la notion d internationalisation. Si chaque wiki est sur un serveur différent, il n y a plus de lien interwiki par exemple. Et...la notion de proximité géographique est complexe. Pourquoi le serveur serait il plus en France, qu'en Belgique, qu'au Canada ? Mais, au final, le fait est que nous avons besoin de ressources financieres pour assumer les aspects techniques. D ou la Donation doit il est discute plus bas. Que penses tu de la mise en place d un systeme de donation ? Quel systeme de don verrait tu le mieux ? Et ou le mettre en place pour qu il soit visible de l utilisateur sans être pesant ? Ant

Il me semble que l'inteconnexion Amerique-Europe se trouve en France : un serveur en France pourrait donc servir tous les wikipedia de langues européenne : non seulement français mais aussi italien, allemand, portugais, néerlandais, basque, corses, bretons, etc. Treanna 27 aoû 2003 à 10:29 (CEST)

Il n'y a pas qu'une interconnexion entre l'amérique et l'europe ! Chaque opérateur ou presque a ses propres cables et les interco arrivent aussi bien en irlande, qu'en espagne, à gibraltar ou effectivement en france :)

Sans aller jusque là, on peut admettre que pour des langues comme l'anglais, l'espagnol ou le français, la question peut être complexe, mais pour l'italien, l'allemand, le hollandais ou le danois, n'importe quelle localisation europeenne serait mieux que la situation actuelle, et permettrait de delester les serveurs americains. Traroth 27 aoû 2003 à 10:46 (CEST)

On pourrait déjà mettre en place un mirroir, à partir du logiciel de Wikipedia et d'une sauvegarde récente de la base de données.

La lecture s'opèrerait sur le mirroir et l'édition sur le serveur principal. La synchronisation du mirroir profiterait des conflits d'édition. L'avantage de cette solution est qu'elle permet d'éviter toute modification sur le serveur principal.

La question qui se pose maintenant est l'hébergement du mirroir. Plusieurs solutions : des hébergeurs ou les wikipediens eux-mêmes. La charge se répartirait entre les mirroirs par un site indiquant leur charge, les mirroirs en ligne, etc.

Utilisateur:Athymik

Ca modifierait considerableemnt le mode de fonctionnement. La question de la mise à jour des miroirs se pose inevitablement, surtout dans un contexte Wiki, où les mises à jour sont frequentes. Mais je pense que l'hebergement dans le milieu universitaire est envisageable pour un projet comme Wikipedia, surtout s'il acquiert uncertaine reputation, non ? Traroth 27 aoû 2003 à 11:24 (CEST)

Absolument pas. Les articles sont sauvegardés sur Wikipedia. Les mirroirs se synchronisement lors des conflits de modifications, qui deviendraient plus fréquents. Cela éviterait à Wikipedia de supporter la charge due à la lecture et à une grande partie des éditions.

Soit j'ai mal compris, soit ça ne tient pas debout. Cas de figure : Quelqu'un edite un article. Il obtient la version du miroir, l fait ses modifs et sauvegarde sur le serveur central. Quelqu'un d'autre arrive, voit la version du miroir (non modifiée, donc), et refait une modif, et sauvegarde, ce qui ecrase la version de la premiere personne. On pert donc les modifs de la premiere personne. Comment ton systeme de conflits de modifs permet-il de resoudre ce probleme ? Traroth 27 aoû 2003 à 11:45 (CEST)

il faudrait savoir ce qui génère à certaines heures une baisse des performances: trop de requètes en écriture au même moment, trop de requètes en lecture? aujourd'hui est ce que la lecture se fait sur un système de cache ou en requete directe sur la base?

d'autre part l'accès sur le wiki anglais me semble souvent beaucoup plus rapide vrai ou faux ou décalage horaire ? jeffdelonge 27 aoû 2003 à 12:08 (CEST)

Wikipedia contient un système de timestamp. Je reprends ton exemple: Quelqu'un édite un article. Il obtient la version du mirroir, fait ses modifs et sauvegarde (la sauvegarde est faite sur le serveur central de façon transparente ainsi que sur le mirroir). Quelqu'un d'autre arrive, le mirroir est à jour puisque la dernière modif a été faite sur le mirroir. Mais non, quelqu'un, sur le serveur central, a édité l'article : le mirroir n'est donc plus à jour. Notre quelqu'un fait ses modifs, sauvegarde et paf! le serveur central n'a pas accepté la modif puisque le timestamp correspond à celui d'une ancienne version. Ce système de timestamp existe depuis les débuts de Wikipedia.

Etant donné qu'on recherche de meilleures performances grace à un eventuel positionnement geographique, c'est le pragmatisme qui doit predominer. Positionner les serveurs dans la zone geographique où on trouve le plus d'internautes francophones, par exemple, pour fr: (et non là où il y a le plus de Wikipediens, car ça, ça peut changer vite). Pour le systeme de donation, c'est une bonne idée, mais je suis trop désabusé pour imaginer qu'on puisse en tirer beaucoup de resultat. En fait, ça pose la question de la viabilité à long terme du projet. On cherche à avoir le plus de participants possibles, mais il faut bien admettre qu'on serait bien embeté si BEAUCOUP de gens venaient. Les fondations comme la fondation Apache ont de bonnes rentrées d'argent car leur activité presente maintenant un grand interet economique pour d'enormes societés (Apache est soutenu par IBM, Sun ou Borland, par exemple). Tel n'est pas le cas de Wikipedia pour l'instant. Ca ne serait pas la premiere initiative victime de son succès. Je ne pretends pas avoir de solution, mais je pense que la prise de conscience du probleme est un premier pas dans la bonne direction. Peut-etre que la recherche de soutiens publics (ministeres de la culture de differents pays, universités) ou internationaux (UNESCO) peut offrir un debut de solution... Ce qui est sûr, c'est qu'en l'absence d'amelioration de l'architecture physique, le probleme de preformance (et bientot de disponibilité, tout simplement) ne va pas aller en s'arrangeant. On commence par supprimer des fonctionnalités "non-essentielles", et ensuite quoi ? Traroth 27 aoû 2003 à 10:21 (CEST)

Le fait d'avoir des serveurs separés n'empeche en rien l'inteconnectivité des Wikipédias. Ceci dit, si j'ai bien compris c'est surtout le serveur qui souffre des milliers de requettes qu'il a a gerer. On aurai donc surtout besoin d'un GROS GROS serveur. Aoineko 27 aoû 2003 à 09:47 (CEST)

Bonjour Ant. Je ne vois pas en quoi la séparation des serveurs poserait problème pour les liens interwiki. Tu peux fournir plus d'explications s'il te plait. En revanche pour les optimisations, pourquoi ne pas changer de BDD. On utilise MySQL en ce moment il me semble. Ce n'est pas la seule BDD libre, certaines sont peut-être plus performantes dans notre cas. Comme il y a beaucoup plus de lectures que d'éditions, il faudrait trouver une BDD très rapide en lecture. Bon, sinon je ne suis pas du tout un spécialiste des BDD. Sinon il me semble que nous sommes statistiquement plus nombreux en Europe, donc un serveur en Euope serait logique. Cependant que ne pense pas que cela ait une grande incidence. Le temps de réponse en lui-même est relativement rapide :

PING fr.wikipedia.org (130.94.122.197) 56(84) bytes of data.

64 bytes from Pliny.wikipedia.org (130.94.122.197): icmp_seq=1 ttl=47 time=179 ms

64 bytes from Pliny.wikipedia.org (130.94.122.197): icmp_seq=2 ttl=47 time=176 ms

64 bytes from Pliny.wikipedia.org (130.94.122.197): icmp_seq=3 ttl=47 time=176 ms

64 bytes from Pliny.wikipedia.org (130.94.122.197): icmp_seq=4 ttl=47 time=174 ms

64 bytes from Pliny.wikipedia.org (130.94.122.197): icmp_seq=5 ttl=47 time=173 ms

64 bytes from Pliny.wikipedia.org (130.94.122.197): icmp_seq=6 ttl=47 time=173 ms

64 bytes from Pliny.wikipedia.org (130.94.122.197): icmp_seq=7 ttl=47 time=173 ms

64 bytes from Pliny.wikipedia.org (130.94.122.197): icmp_seq=8 ttl=47 time=173 ms

64 bytes from Pliny.wikipedia.org (130.94.122.197): icmp_seq=9 ttl=47 time=173 ms

64 bytes from Pliny.wikipedia.org (130.94.122.197): icmp_seq=10 ttl=47 time=172 ms

--- fr.wikipedia.org ping statistics ---

10 packets transmitted, 10 received, 0% packet loss, time 9017ms

rtt min/avg/max/mdev = 172.993/174.583/179.169/1.922 ms

Med 27 aoû 2003 à 10:00 (CEST)

Si je ne m'abuse MySQL est justement performant en lecture et c'est une des raisons pour laquel elle est utilisé pour le web. Par contre elle a un peut de peine en écriture. Après, outre la possibilité de changer de bd, il y a celle de passé à la version 4 de MySQL si ce n'est pas déjà le cas. Mais je ne suis pas exepert dans le domaine :)

La localisation des serveur peut-être uns solution, mais en fait se qu'il faut c'est surtout une augmentation des ressources matériel et donc du nombre de serveur. Leur localisation peut à mon avis surtout aider à la recherche de financement car une assosication, une entreprise, une université ou autres préférera savoir que ce qu'elle finance serra localiser localement. En soit même si la distance compte, actuellement le problème doit venir soit d'un engorgement de la bande passante aloué aux machines actuel ou à une sucharge des serveur eux-même.

Garko 27 aoû 2003 à 11:21 (CEST)

je m'y connais tellement peu que je vous laisse deviser. A moment donné, j'avais envisagé, en faisant le projet écorégion, de m'addresser à National Geographic and Co question pépettes... Anthere

D'apres ce que j'ai pu comprendre, on a actuellement deux serveurs, un serveur uniquement web qui est dédié au wiki anglais (un PIII quelque chose) et un serveur de base de données qui en plus supporte le serveur web pour tous les autres wikis(un Bi-Athlon de mémoire). C'est peut-etre pour cela que le wiki anglais est plus rapide, il a son propre serveur web dédié (mais partage le meme serveur de base de données). Par ailleur il existe depuis peu un systeme de donation par paypal si je me souviens bien. Cet argent devrait être dedié a l'achat d'un troisième serveur. Shaihulud 27 aoû 2003 à 12:17 (CEST)

Le detail des serveurs:

Jimmy Wales wrote:

> Jason could you post for everyone all the current specs on both
> machines, as best as we know them, as well as what each machine is
> doing?  This would probably help us to plan for a reconfiguration in
> the event of a new server (or two) purchase.

Pliny - Running MySQL, Apache 1.3.27 and kernel 2.4.20  and the non-English Wikis

Tyan S2462 motherboard 
2 Gig RAM (4 512Meg modules of ECC Reg. 266 MHz PC2100 DDR RAM in 4 slots) 
2 Processor AMD Athlon MP 1800+/266FSB 
Adaptec AIC-7899P SCSI U160 controller 
1 IBM 36 GB SCSI Ultra 160 / 10 K RPM 
1 IBM 36 GB SCSI Ultra 320 / 10 K RPM (running as U160, of course) 
Dual onboard 3Com 10/100 (3C982) adapters 

Larousse - Running Apache 1.3.27 and kernel 2.4.20 and the English Wiki

TYAN S2518UGN motherboard
2Gig RAM (4 512Meg modules of ECC Reg. 133 MHz PC133 SDRAM in 4 slots) 
Pentium III 866MHz processor w/256K cache 
Adaptec AIC-7899 SCSI U160 controller 
1 Quantum Atlas 18 GB SCSI U160 Drive, currently unused and known to
 be troublesome (It's awaiting some tsting which I have put off due to
 the high load on the system) 
1 IBM 36 GB SCSI U160 Drive 
Dual onboard Intel 10/100 (eepro) adapters 

Et où peut-on trouver les sources complets et à jour du logiciel ? Traroth 27 aoû 2003 à 12:46 (CEST)

Sur sourceforge normalement. Tu trouverra des infos sur http://download.wikipedia.org Shaihulud 27 aoû 2003 à 12:48 (CEST)

Il faudrait plutôt discuter tout ceci sur les listes WIKITECH-L et WIKIPEDIA-L. De discuter le soft wikipedia & l'hebergement & les serveurs ici, c'est un peu comme le conseil municipal de Lille qui discute de changer la constitution francaise -- Tarquin 28 aoû 2003 à 15:04 (CEST) (et on pourrait le nettoyer un peu le bistro?)

Savoir si fr: sera encore en mesure de fonctionner demain (je dramatise un peu, là), je crois que c'est important, et que ça concerne la communauté fr:. Traroth 28 aoû 2003 à 15:14 (CEST)

[modifier] Quelques remarques sur les problèmes en discussion:

• Attention! PayPal a une mauvaise réputation (aucune garantie et pas de recours si vous avez un problème)
• Le système de dons ne raporterait pas grand-chose si j'en crois les expériences similaires qui ont été faites dans le monde du logiciel libre.
• Le soutien d'Université me semble une très bonne idée. En quoi une quelconque université pourrait être intéressée par notre projet? Tout simplement pour se faire de la pub? Pourquoi pas? Universités américaines? Quant à l'UNESCO, je doute qu'ils me laissent continuer de parler de clonage reproductif humain..., ce qui rend la solution foireuse!!! Sinon, des entreprises pourraient nous subventioner (avec leur logo gratos), des entreprises en croissance et qui supportent les logiciels libres)
• Pour la base MySQL, c'est la plus rapide, en lecture et en écriture. Elle arrive à égalité (un chouuuuilla moins) avec Oracle 9i www.eweek.com.
• Un système RAID 5 est-il installé, envisagé? Meilleures performances car accès en parallèle sur plusieurs disques.
• Définition des goulots d'étranglement (réseau, BD, disques, table, accès particulier?). Ou la machine passe-t-elle le plus de temps? A formatter les pages, faire les diff, récupérer l'historique, lock tables, etc. Taux d'occupation du processeur? Mémoire?
• Utilisation de la fonction: OPTIMIZE <table1>, <table2>, ...
• Clause DISTINCT dans les requêtes quand c'est possible
• Supprimer les clauses: Where annee LIKE '200_' et remplacer par Where annee BETWEEN ... Raison: utilisation de l'index dans le 2ème cas, pas dans le premier.
• Certains LOCK sont-ils bloquants pour les autres utilisateurs?
• Installation de version 4
• Utilisation des tables InnoDB (vers. 4 only?...)

• Contraintes sur les clés étrangères
• Fiabilité (consistance garantie)
• Verrous au niveau des enregistrements (et non des tables!!!)
• Gestion des transactions

• Regrouper les index primaires sur plusieurs colonnes en un index sur 1 colonne résumé des 2 précédentes.
• Une réorganisation/optimisation des index de la base de donnée en fonction des accès problématiques
• D'après ce que j'ai compris, les doubles enregistrements identiques sont autorisés, cela signifie que la base n'est pas normalisée, donc pas optimalisée sur le plan relationnel. C'est là, AMHA où il faut certainement trouver les meilleures solutions d'optimisation qui rendront la base hyper rapide, "toutes choses étant égales par ailleurs", comme le dirait lui-même Eslios.
• Personnellement, j'ai du mal à croire que le goulot d'étranglement se doit d'être la base (si elle est conçue correctement) plutôt que le réseau...
• Si réplication, ne la faire que du serveur central vers les mirroirs. Les mirroirs servent à la lecture. Le serveur pour les mises à jour.
• Et pour les fans de Windows, acheter un licence de SQL Server 2000! Virez cette saloperie gratuite de Linux pour pauv'zouaves et reprogrammer le tout en Visual (plus que) Basic. Remplacer les while par des GOTO. Rebooter toutes les 10 mn (et comme ça, ça ne plante JAMAIS! Faites l'expérience, vous verrez!!!)...
• Et si je peux me permettre une dernière remarque idiote? Serait-il possible d'avoir un message du type: "Attention, un autre utilisateur édite cet enregistrement?". Ca nous ferait gagner du temps si toutefois nous agissons avec courtoisie.
• Et pendant que je suis dans les demandes ridicules..., serait-il possible de gérer les sessions? Je me loggue, et puis tout à coup, je ne suis plus loggé et on voit mon affreuse adresse I(nsuportable)P(apotages). Et je suis toujours le dernier à m'en rendre compte. C'est pas très solide comme identification. Passer à PHP 4.x qui connaît le concept de 'sessions'?

Je vois qu'on a affaire a un spécialiste des BDD. :-) Je pense que ce serait pas mal si tu pouvais faire un dump de la base et faire quelques expérimentations chez toi histoire de voir ce qui est efficace à peu de frais. Pour contacter les développeurs et faire partager tes améliorations peut-être que la liste wikitech serait adaptée. Bonne chance. Med

---

[modifier] est ce un bug ?

en expérimentant la liaison possible entre les sites sous SPIP version 1.6 et Wikipédia. la syntaxe est toute simple [?toto] dans SPIP renvoie directement sur la page toto de Wikipédia je suis tombé sur un fonctionnement bizarre http://fr.wikipedia.org/wiki/États-Unis dans la barre d'URL de mon navigateur renvoie vers une page États-Unis correctement orthographiée mais vide alors que la recherche sur même orthographe fonctionne sans pb. Ce ne doit pas provenir du navigateur car à partir du site sous SPIP on obtient la même erreur

il faut éditer cette section sinon c'est incompréhensible

jeffdelonge 19 oct 2003 à 10:55 (CEST)

En fait wikipedia interprète correctement http://fr.wikipedia.org/wiki/%C9tats-Unis mais pas http://fr.wikipedia.org/wiki/États-Unis

problème résolu en utilisant le code Unicode (Table de caractères de Gnome dans la Mandrake 9.1) y'a donc bien un petit bug avec le html qui n'est pas toujours bien converti dans l'url de page ;-) jeffdelonge