Reprise du message précédent :
http://forum.les-potes.com/forum2. [...] 30&sujet=1
 
   
aussi ds le genre bizarre, t'as foutu une variable $numero ds l'url qui determine un code d'erreur :-/

Comment fait-on ça?

 
Euh au début avec une table au format HEAP/MEMORY mais plus maintenant pasque j'ai vu que avec ma methode ça ameliorait pas des masses
 
Par contre si t'as une technique spéciale toi pour faire un cache qui marche et dont on voit vraiment la différence, jsuis prenneur
 
 
 
Pour la catégorie 30, j'avais pas pensé à faire un message d'erreur, merci
Et puis en quoi c'est bizarre de faire les erreurs dans un fichier différent avec un numéro d'erreur dans l'url

Voila, ça fait 1 an que mon site possede un forum Le-Node Basé sur Sky-O-Matic et il n'y a pas a dire, c'est un excelent forum, bon il y a pas mal de bugs mais pour les 3 posts par jours ça suffit lol.

Bonjour,
 
Comme j'ai l'impression que ce topic est tres centré PHP, je me permet d'indiquer qq autres possibilité à ceux qui se posent encore la question du choix du language:
sous Ruby, il y a bien evidemment Ruby on Rails (j'imagine que vous connaissez), et sous Perl il y a Catalyst (vu comme le successeur de Mypole). Tous deux sont de tres bons MVC qui pourraient tout à fait se preter à la réalisation d'un beau forum. Il est dommage qu'en France on continu à associer Perl à CGI, et à ignorer Ruby. Rares sont les hebergeurs qui proposent mod_perl et mod_ruby...
 
En outre je me permet de vous glisser un lien vers une presentation pdf tout à fait interessante sur l'evolution technique de livejournal.com (le premier site de blog à avoir vu le jour, qui gere aujourdhui des pics de plus de 3000req/s sur 8 millions de blogs).
 
http://www.danga.com/words/2005_oscon/oscon-2005.pdf
 
les technos principales sont Apache/Perl/Mysql et un load balancer entierement ecrit en Perl (Perlbal)

php4ever
 
 

Ce sont des frameworks, pas des langages, on pourrait parfaitement faire des forums en CGI/Perl, CGI/Ruby ou CGI/Python sans utiliser de frameworks

evidemment, mais un language c'est une syntaxe et des librairies! les deux sont indissociables. Pour savoir si un language est adapté à une application il faut egalement voir les libairies dont il dispose.
Ensuite, quand tu parle de CGI c'est encore tout à fait autre chose. moi je comparais CGI à mod_perl (ou FastCGI à la limite). CGI est un vraie limace, quelque soit le language que l'on met derriere, et c'est justement mod_php qui a fait le succes de PHP à une epoque ou le CGI etait légion

UN FRAMEWORK N'EST PAS UNE LIBRAIRIE
 
Ca n'a strictement rien à voir, un framework simplifie mais limite alors qu'une librairie étend.

   
 
T'es ptet pas au courant, mais un certain nombre d'hebergeurs pros ont une implémentation native de PHP sous CGI pour des raisons de stabilité et de sécurité, et il faut le demander pour avoir php en mod_php

PHP en CGI, quelle joie...
mod_php est si buggé que ca pour devoir en arriver la?
J'espere au moins qu'ils font du fastcgi.
 
si tu veux qu'on discute il va falloir que tu range tes smilies (tu pourra les resortir quand je serais parti).
 
pour ce qui est du framework ou de la librairie, je ne sais pas qui t'as mis ca dans la tete. Pour moi un framework C'EST une librairie. librairie, toolkit, framwork, composant, stack, etc... etc... tout ca c'est la meme chose, il n'y a que des commerciaux et les vendeurs de boukins pour te faire croire le contraire...
Alors tu peux l'ecrire en rouge si tu veux, tu peux mettre des images et meme de la musique, ca ne changera pas la réalité de la chose

mod_php (comme tous les mod_) tourne avec les droits d'apache, donc des droits étendus + failles potentielles Apache, alors que les scripts CGI tournent avec les droits d'un compte local donné.
Donc en cas de problème de sécurité, le serveur risque moins de se faire tomber (il y a quelques autres problèmes en moins)

oui  

La réalité de la chose, c'est que t'as strictement rien compris à l'approche framework par rapport à l'approche library...
 
Avec une approche framework, t'as une structure de base, un cadre initial, et tu adaptes ton application au cadre, avec les contraintes et les limitations de celui-ci, mais aussi les avantages (code pré-généré, structures de flux claires et précises, code générique déjà écrit pour la majorité des tâches).
Avec une approche library, tu n'as pas de cadre, pas de structure, c'est à toi de concevoir l'intégralité du flux de l'application et les libs utilisées ne font qu'augmenter les fonctionalités de l'application, la seule limitation de celle ci étant le concepteur.
 
L'approche framework et l'approche library sont très différentes et certaines personnes ont une forte orientation dans un sens ou l'autre alors que d'autres ont moins de problèmes à mêler les deux.

CGI n'est pas une limace
Ca dépend justement du langage derrière, et le forum en C/CGI de Maboul est de loin le plus rapide qui soit par ici

 
On attend toujours le forum CGI/ASM de harko d'ailleurs

héhé, l'approche bidule et l'approche machin...
pour moi si ya une API c'est une lib, point barre.
 
 
Drasche, je ne parle pas de fastcgi ou autres systeme persistants, mais bien du bon vieux CGI qui consiste à executer un prog à chaque requete. Pour les languages interprétés comme Perl c'est un surcout enorme (lancement de l'interpreteur + chargement et parsing du code et de toutes les librairies + compilation + execution). Pour un language compilé comme le C c'est effectivement beaucoup moins lourd (d'ailleurs speedycgi, une solution "genre fastcgi" en perl utilise un executable C à chaque requete qui va faire le lien avec le process Perl resident), mais il y a tout de meme un surcout. avec Fastcgi ou mod_* l'interpreteur (ou plutot les interpreteurs) est persistant et est réutilisé à chaque requete. Donc ca coute juste la latence de la communication avec le process persistant sur un socket unix par exemple dans le cas de fastcgi. c'est tout de meme plus leger que de lancer un executable.
 
Par contre effectivement ensuite il y a la vitesse d'execution du code lui meme. Si c'est une requete qui demande un traitement complexe alors le surcout du CGI devient moindre vis à vis du temps total de la requete. Et si l'executable est en C evidemment il a des chances d'allers encore bien plus vite...
 
Mais bon la plupart du temps dans ce genre d'appli c'est plutot la base de donnée qui rame, et la encore le fait d'avoir un interpreteur resident est un avantage enorme: on peu garder une connexion persistante avec la base de donnée.
Dans le cas d'un CGI (pure souche encore une fois, je ne parle pas de fastcgi) on est obligé de réinitier la connexion à chaque lancement, c'est à dire à chaque requete... (mais bon, mysql est rapide à la connexion donc ca peut encore aller)

à mon avis, tu peux encore attendre
dernièrement il parlait d'un forum en C#/SQL Server
 
pospos: oui, vu comme ça, je suis d'accord, mais bon, personne de sérieux de va se contenter du simple CGI exécutable à la PHP

en tous cas je vous conseil à nouveau la lecture de ce lien, tres instructif :
 
http://www.danga.com/words/2005_oscon/oscon-2005.pdf

 
Heu, c'est pas de chance parce que mon forum est justement codé sous forme de module En le codant avec un cgi, il serait beaucoup plus lent à cause des accès disques nécessaires (pour charger/mapper l'exécutable et pour charger/mapper les libs qui génèrent les pages).

 
D'un coté, sans l'api Win32 on irait pas loin dans windows
 
Je preferes la librairie, un bon vieux conio.h, rien de mieux  

 
J'ai bien aimé le coup des 30Go en cache. Je me demande comment je pourrais en faire autant (utiliser plusieurs serveurs pour le cache) sachant que je n'y mets pas des enregistrements bd mais des structures de données qui pointent directement entre elles. Je pourrais faire une couche proxy mais restera le problème de faire du "memory balancing" afin que les données se regroupent automatiquement au mieux selon leur utilisation sur les serveurs.

 
struts et Zope sont donc des libs
 
intéressant
 
et puis Google Maps aussi, après tout il y a bien une API Google Maps
 
ben on est pas dans la merde avec des idées pareilles

 
avec des serveurs NFS peut etre ? bon ça commence a etre compliqué pour un simple forum

 
Mais si l'interpréteur plante, tous les sites plantent aussi, non ?

Ce n'est pas la NFS qui gere la synchro des fichiers entre plusieurs ordi ?
 

 
Ben, ma problématique est de pondre une archi distribuée stockant en mémoire des informations structurées extraites d'une base de données sans avoir un bousin qui rame et sans avoir non plus à réécrire tout mon code (bref, rien à voir avec les fichiers )

Ha ok, donc c'est au niveau du serveur SQL que tu veux Je ne penses pas que Mysql sache faire ça non ? a part le faire a la mano, genre une table sur un serveur, une autre sur un autre.

chaced> Arrête toi là  

Tient au passage, pour ceux qui ont fait leur forum avec du mysqli et malheureusement le serveur ou est hébérgé le forum ne le gere pas, voici une petite lib qui permet de passer quand meme, ce n'est pas top, mais en attendant, ça dépanne
 
http://old.coggeshall.org/show_sou [...] mysqli.php

dans le cas de mod_perl ou fastcgi il y a plusieurs intepreteur (forké à partir d'un seul, donc avec copy on write) qui tournent. Si un des intepreteur plante un autre est forké pour el remplacer

 
Bon ok je sors    
 
 

 
oui, pour moi l'api google est une librairie, accessible en SOAP.

 
leur system de cache est open source: memcached.
 
http://www.danga.com/memcached/
 
c'est une petite appli serveur qu'on lance sur les machines ou l'on a de l'espace RAM disponible, et qui devient un serveur de cache.
Ensuite il y a une applie cliente (existe en Pelr, Python, C, etc...) qui se charge de communiquer avec les differents serveurs de cache installés. On peu meme ilmplementer tres facilement un client dans un autre language, car le protocole est tres simple.

ah zut

dis moi Doc, ça te dirait pas d'ouvrir un topic dans lequel tu causerais de toutes tes techniques en matière d'optim ? je suis sur que ça intéresserait pas mal de monde, à commencer par moi

 
Pas bete ça, car avec les gestionnaires de cache, on s'y perd, genre mm d'apache, TurkMMCache de php... maintenant une api Memcached !

 
Je veux bien mais je ne vois pas trop ce que je vais pouvoir y dire à part des banalités comme quoi il faut d'abord travailler sur l'archi et les algos avant d'optimiser le code en lui-même. Ah si, il faut lire le code de ce qu'on utilise (le code de gcc, le code du runtime C, le code de mysql, le code de apache, le code de php, ...) et ne jamais hésiter à réinventer la roue (parce c'est en essayant de faire rouler des cubes qu'on comprend de manière intime et définitive qu'il vaut mieux les tailler jusqu'à aboutir à une structure arrondie pour limiter les pertes dûes aux frottements). Qu'est-ce qui vous intéresserait en particulier?

Je suppose que les systèmes de caches, de copy on write bit et tout ça devraient intéresser pas mal de monde ;o

DocMaboul, tu a lu le code d'Apache? et ca ne t'as pas donné envie d'utiliser autre chose?

 
Qu'est-ce que vous lui reprochez au juste?

 
C'est sur que le code d'IIS, il ne risque pas de le lire  

Bah je sais pas moi, je me demandais ce qui pouvait les intéresser