Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
2452 connectés 

 
 


 Mot :   Pseudo :  
  Aller à la page :
 
 Page :   1  2  3  4  5  ..  86  87  88  ..  486  487  488  489  490  491
Page Suivante
Page Précédente
Bas de page 
Auteur Sujet :

les développeurs de forums, les 3/4 des forums sont down /o\

n°666495
Limit
Posté le 07-03-2004 à 21:17:11  profilanswer
 

Reprise du message précédent :
regarde: ( Uptime:                 26 min 43 sec)
 
 
-/+ buffers/cache:     449872    1620172
 
:D  

mood
Publicité
Posté le 07-03-2004 à 21:17:11  profilanswer
 

n°666496
Limit
Posté le 07-03-2004 à 21:17:28  profilanswer
 

Sly Angel a écrit :


 
Tu l'as bien relancé au moins ? [:ddr555]

oui

n°666497
docmaboul
Posté le 07-03-2004 à 21:18:18  profilanswer
 

joce a écrit :

heu t'as conscience de la taille des bases ?
Si les indexs sont pas un minimum en mémoire, ton disque dur il va deguster sévère :D
Et je peux t'assurer qu'avec 128 Mo sans MySQL, tu fais même pas tenir les process apache/php de ce forum en mémoire :D


 
Eh bien de ce que j'en ai vu, les messages sont plutôt courts ici. Je vais être radin et considérer qu'ils tournent en moyenne aux alentours de 1ko. Avec 14M de messages, ca nous fait grosso merdo 14Go de données. A moins que le texte soit indexé, on peut compter sur quelque chose de raisonnable, à savoir entre 1 et 2 Go d'indexes.
 
Petite disgression. Quand j'ai passé mon cap d'informatique, nos profs nous disaient toujours : "les méthodes et les normes, c'est très bien : apprenez donc à pisser dessus".
 
Du coup, j'ai jamais rien pu comprendre à la modélisation correcte d'une base de données. Par exemple sur ce forum, il y a beaucoup, beaucoup, beaucoup, de messages. He oui, 14 millions, ça fait beaucoup. Mais ce sont beaucoup de vieux messages. Allez hop! Une table pour chaque mois en souvenir de mes vieux profs qui crachaient avec honneur - et bonheur - sur merise. Ca me fera économiser beaucoup, beaucoup, beaucoup de cette ram prise par des indexes dont 90% (au pif-o-mètre) ne sert presque à rien.
 
Après, pour le cas du process Apache, tout le problème de la ram se situe au niveau de la connection à mysql qui est assez gourmande si mes souvenirs sont bons.

n°666499
joce
Architecte / Développeur principal
"BugHunter"
Posté le 07-03-2004 à 21:20:21  profilanswer
 

DocMaboul a écrit :


Du coup, j'ai jamais rien pu comprendre à la modélisation correcte d'une base de données. Par exemple sur ce forum, il y a beaucoup, beaucoup, beaucoup, de messages. He oui, 14 millions, ça fait beaucoup. Mais ce sont beaucoup de vieux messages. Allez hop! Une table pour chaque mois en souvenir de mes vieux profs qui crachaient avec honneur - et bonheur - sur merise. Ca me fera économiser beaucoup, beaucoup, beaucoup de cette ram prise par des indexes dont 90% (au pif-o-mètre) ne sert presque à rien.

MySQL ne mets en RAM que ce qu'il utilise.
Donc t'économisera keud en RAM avec ta méthode, désolé :D
 

n°666500
Limit
Posté le 07-03-2004 à 21:20:37  profilanswer
 

Sly Angel a écrit :


 
Non mais le nombre de process :p
 
Possible d'avoir une idée de la config, de la taille des bases et de la charge moyenne en journée ? :??:

170 process apache actuellement.
config: bi-xeon 2.4Ghz
dd scsi @ 10000 trs
2go de ram.
 
14 millions de messages et 400 000 membres sur les différents forums.

n°666504
Sly Angel
Architecte / Développeur principal
Posté le 07-03-2004 à 21:23:01  profilanswer
 

DocMaboul a écrit :


 
Eh bien de ce que j'en ai vu, les messages sont plutôt courts ici. Je vais être radin et considérer qu'ils tournent en moyenne aux alentours de 1ko. Avec 14M de messages, ca nous fait grosso merdo 14Go de données. A moins que le texte soit indexé, on peut compter sur quelque chose de raisonnable, à savoir entre 1 et 2 Go d'indexes.
 
Petite disgression. Quand j'ai passé mon cap d'informatique, nos profs nous disaient toujours : "les méthodes et les normes, c'est très bien : apprenez donc à pisser dessus".
 
Du coup, j'ai jamais rien pu comprendre à la modélisation correcte d'une base de données. Par exemple sur ce forum, il y a beaucoup, beaucoup, beaucoup, de messages. He oui, 14 millions, ça fait beaucoup. Mais ce sont beaucoup de vieux messages. Allez hop! Une table pour chaque mois en souvenir de mes vieux profs qui crachaient avec honneur - et bonheur - sur merise. Ca me fera économiser beaucoup, beaucoup, beaucoup de cette ram prise par des indexes dont 90% (au pif-o-mètre) ne sert presque à rien.
 
Après, pour le cas du process Apache, tout le problème de la ram se situe au niveau de la connection à mysql qui est assez gourmande si mes souvenirs sont bons.


 
-> Et quand quelqu'un poste dans un topic qui a 2 mois ? Tu déplaces de table ? Et si plusieurs le font au même moment ?
 
-> Pour Apache le fait est qu'il prend de la RAM, mais ça c'est inévitable, de toute manière avec 600 process, si ça bouffe 1 Mo du process...

n°666505
joce
Architecte / Développeur principal
"BugHunter"
Posté le 07-03-2004 à 21:23:12  profilanswer
 

Limit a écrit :

170 process apache actuellement.
config: bi-xeon 2.4Ghz
dd scsi @ 10000 trs
2go de ram.
 
14 millions de messages et 400 000 membres sur les différents forums.


charge moyenne ?
Pour info à l'heure actuelle sur HFR y a 405 process apache, donc je sais pas c'est quoi le timeout de ton compteur mais doit y avoir une couille dans le potage :o

n°666507
kfman
Credo quia absurdum
Posté le 07-03-2004 à 21:24:08  profilanswer
 

joce a écrit :

compare le code source :D


 
Vas-y, fais donc voir :D

n°666508
docmaboul
Posté le 07-03-2004 à 21:24:16  profilanswer
 

KrisCool a écrit :


 
Mais ne prendre en compte que la performance est assez vide de sens. Le coût du développement est à prendre en compte, et à mon avis entre le développement d'une application web de grande taille en C (langage conçu à l'origine pour faire du Web donc spécialement équipé pour en terme de bibliothèques, et de structure, bien entendu) et le développement dans un langage tel que l'ASP ou le PHP (conçus pour le développement web), y'a pas photo.
 
Et ça aussi ça compte dans les choix technologiques. Pourquoi les boîtes font pas encore du développement en C/C++ au lieu de se mettre à Java ? C'est vrai quoi, Java c'est du bytecode, faut une machine virtuelle, tout ça... pfiouu les perfs gnagna...  
Parce qu'elles y gagnent en temps de développement et en réusabilité des composants développés. Sans parler du SDK qui évite de réinventer 50 fois la roue.
 
Alors c'est bien beau de dire que les langages interprétés sont lents, mais clairement pour moi en terme de temps de développement y'a pas photo.


 
Vous avez raison mais lorsqu'on fait un forum qui va potentiellement servir à des milliers de personnes par jour, la question du langage mérite d'être posée.

n°666509
joce
Architecte / Développeur principal
"BugHunter"
Posté le 07-03-2004 à 21:24:40  profilanswer
 

kfman a écrit :


 
Vas-y, fais donc voir :D
 

le code source HTML :p

mood
Publicité
Posté le 07-03-2004 à 21:24:40  profilanswer
 

n°666511
Limit
Posté le 07-03-2004 à 21:25:10  profilanswer
 

joce a écrit :


charge moyenne ?
Pour info à l'heure actuelle sur HFR y a 405 process apache, donc je sais pas c'est quoi le timeout de ton compteur mais doit y avoir une couille dans le potage :o

j'utilise pas le keep-alive donc si tu utilises ca doit jouer énormement.
 
Pour le timeout il est 5min.

n°666512
Sly Angel
Architecte / Développeur principal
Posté le 07-03-2004 à 21:25:26  profilanswer
 

Limit a écrit :

170 process apache actuellement.
config: bi-xeon 2.4Ghz
dd scsi @ 10000 trs
2go de ram.
 
14 millions de messages et 400 000 membres sur les différents forums.


 
2500 connectés avec 170 httpd ça fait une sacrée différence
 
Tu as viré le KeepAlive ? :??:

n°666513
drasche
Posté le 07-03-2004 à 21:25:31  profilanswer
 

kfman a écrit :

Bon en même temps:
 
L'inspiration de PPC:
http://www.izware.com/ubb/Forum2/HTML/000604.html
 
[:ddr555]


Citation :

Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
 
Please contact the server administrator, webmaster@izware.com and inform them of the time the error occurred, and anything you might have done that may have caused the error.
 
More information about this error may be available in the server error log.
 
Apache/1.3.12 Server at www.izware.com Port 80


ça fait un peu pitié et en plus ça sent le vieux (Apache 1.3.12) [:ddr555]


---------------
Whichever format the fan may want to listen is fine with us – vinyl, wax cylinders, shellac, 8-track, iPod, cloud storage, cranial implants – just as long as it’s loud and rockin' (Billy Gibbons, ZZ Top)
n°666515
kfman
Credo quia absurdum
Posté le 07-03-2004 à 21:25:47  profilanswer
 

joce a écrit :

le code source HTML :p


 
C'est ce que je me suis dit après coup...
 
[:dehors]
 

n°666516
Limit
Posté le 07-03-2004 à 21:25:48  profilanswer
 

Sly Angel a écrit :


 
Tu as viré le KeepAlive ? :??:

oui, je sais pk mais ca marche mieux sans.

n°666518
Sly Angel
Architecte / Développeur principal
Posté le 07-03-2004 à 21:26:41  profilanswer
 

Limit a écrit :

j'utilise pas le keep-alive donc si tu utilises ca doit jouer énormement.
 
Pour le timeout il est 5min.


 
oki :jap:

n°666519
kfman
Credo quia absurdum
Posté le 07-03-2004 à 21:26:48  profilanswer
 

N'empêche ça me rappelle le forum HFR en 2000 :sweat:

n°666520
Sly Angel
Architecte / Développeur principal
Posté le 07-03-2004 à 21:28:12  profilanswer
 

Limit a écrit :

oui, je sais pk mais ca marche mieux sans.


 
Plus lent pour les utilisateurs, après niveau charge je crois que ça fait plus, mais moins de RAM par contre. Faudra que je regarde ce que ça donne pour ici tiens en vitesse

n°666521
docmaboul
Posté le 07-03-2004 à 21:28:45  profilanswer
 

joce a écrit :

MySQL ne mets en RAM que ce qu'il utilise.
Donc t'économisera keud en RAM avec ta méthode, désolé :D


 
Je ne connais pas parfaitement les optimisations de mysql mais je n'en suis pas si sûr. S'il est capable de ne garder en mémoire que les parties d'indexes les plus utilisées, tu as parfaitement raison.

n°666522
joce
Architecte / Développeur principal
"BugHunter"
Posté le 07-03-2004 à 21:30:17  profilanswer
 

DocMaboul a écrit :


 
Je ne connais pas parfaitement les optimisations de mysql mais je n'en suis pas si sûr. S'il est capable de ne garder en mémoire que les parties d'indexes les plus utilisées, tu as parfaitement raison.

moi j'en suis sur parce que je connais bien MySQL :D
Si MySQL a besoin d'un index un jour, il le met en mémoire, il va pas s'amuser à charger tout l'index d'une table d'un coup (sinon je te dis pas le bordel que ca serait au redemarrage de mysql sur ce serveur :D)

n°666526
docmaboul
Posté le 07-03-2004 à 21:32:44  profilanswer
 

Sly Angel a écrit :


Le problème c'est pas le débit, ce sont les I/O et accès ;)


 
Qu'entendez-vous par débit?

n°666527
docmaboul
Posté le 07-03-2004 à 21:33:53  profilanswer
 

joce a écrit :

moi j'en suis sur parce que je connais bien MySQL :D
Si MySQL a besoin d'un index un jour, il le met en mémoire, il va pas s'amuser à charger tout l'index d'une table d'un coup (sinon je te dis pas le bordel que ca serait au redemarrage de mysql sur ce serveur :D)


 
Oui mais est-ce qu'il fait des statistiques sur l'utilisation de ces tronçons d'indexes?

n°666529
Sly Angel
Architecte / Développeur principal
Posté le 07-03-2004 à 21:35:18  profilanswer
 

DocMaboul a écrit :


 
Qu'entendez-vous par débit?


 
Bah la vitesse de transfert ça change pas grand chose quand les requêtes sont sur des données légères, je préfère un SCSI qui a un temps d'accès à une donnée rapide plutôt qu'un IDE qui tape du 60 Mo/s mais s'écroule dès qu'on le fait bouger aux 4 coins du disque parce qu'il y a bcp de requêtes :/ ( même si la vitesse de transfert aide aussi )


Message édité par Sly Angel le 07-03-2004 à 21:37:24
n°666533
Limit
Posté le 07-03-2004 à 21:38:15  profilanswer
 

n'empeche que j'ai bien
 
Uptime:                 47 min 56 sec
key_buffer_size:                1363144704  
-/+ buffers/cache:     478696    1591348
 
c'est limite chiant :o

n°666537
docmaboul
Posté le 07-03-2004 à 21:40:13  profilanswer
 

Sly Angel a écrit :


 
Bah la vitesse de transfert ça change pas grand chose quand les requêtes sont sur des données légères, je préfère un SCSI qui a un temps d'accès à une donnée rapide plutôt qu'un IDE qui tape du 60 Mo/s mais s'écroule dès qu'on le fait bouger aux 4 coins du disque parce qu'il y a bcp de requêtes :/ ( même si la vitesse de transfère aide aussi )


 
Je suis entièrement d'accord avec vous mais je ne sais pas trop si mon vieux disque scsi est toujours plus rapide qu'un ide d'aujourd'hui.

n°666539
joce
Architecte / Développeur principal
"BugHunter"
Posté le 07-03-2004 à 21:42:53  profilanswer
 

Limit a écrit :

n'empeche que j'ai bien
 
Uptime:                 47 min 56 sec
key_buffer_size:                1363144704  
-/+ buffers/cache:     478696    1591348
 
c'est limite chiant :o
 

pourquoi :o
vois pas pkoi il s'amuserait à mettre en mémoire des indexs qu'ils utilisent pas :D

n°666540
Limit
Posté le 07-03-2004 à 21:44:17  profilanswer
 

joce a écrit :

pourquoi :o
vois pas pkoi il s'amuserait à mettre en mémoire des indexs qu'ils utilisent pas :D
 

toutes les tables que j'ai sont indexés, et il pioche dans toutes les tables, donc il utilise tous les index :??:

n°666559
Sly Angel
Architecte / Développeur principal
Posté le 07-03-2004 à 21:55:03  profilanswer
 

Limit a écrit :

toutes les tables que j'ai sont indexés, et il pioche dans toutes les tables, donc il utilise tous les index :??:


 
Il prend surement que des petits bouts d'index :??:

n°666562
Limit
Posté le 07-03-2004 à 21:57:21  profilanswer
 

oui certainement, mais la taille utilisée en ram est quand même très faible par rapport à la taille réelle des index sur le disque.

n°666564
joce
Architecte / Développeur principal
"BugHunter"
Posté le 07-03-2004 à 22:00:01  profilanswer
 

Limit a écrit :

oui certainement, mais la taille utilisée en ram est quand même très faible par rapport à la taille réelle des index sur le disque.
 

moi je dis heureusement que le moteur de recherche passe pas entièrement en RAM :D

n°666566
joce
Architecte / Développeur principal
"BugHunter"
Posté le 07-03-2004 à 22:01:27  profilanswer
 

Limit > je comprends mieux pourquoi ton forum est pas chargé, t'as pas implementé la recherche dans le contenu des topics :D


Message édité par joce le 07-03-2004 à 22:03:14
n°666567
Limit
Posté le 07-03-2004 à 22:01:36  profilanswer
 

oui bien sur, mais là je pense qu'il pourrait mieux utiliser la ram inutilisée mis à sa disposition.

n°666568
Limit
Posté le 07-03-2004 à 22:02:08  profilanswer
 

joce a écrit :

Limit > je comprends mieux pourquoi ton forum est pas chargé, t'as pas implenté la recherche dans le contenu des topics :D

oui :D  
 
Mais c'est en cours, j'y réfléchis bien avant.

n°666569
Sly Angel
Architecte / Développeur principal
Posté le 07-03-2004 à 22:03:09  profilanswer
 

joce a écrit :

moi je dis heureusement que le moteur de recherche passe pas entièrement en RAM :D


 
Moi je dis seulement que la recherche elle est que sur le sujet :o
 
Bon sinon moi je dis qu'il faudrait quand même redesigner les forums, autant PPC que AceBoard :o ( même si je ferais pas mieux perso :D )

n°666571
Sly Angel
Architecte / Développeur principal
Posté le 07-03-2004 à 22:03:41  profilanswer
 

zut encore grillai :cry:

n°666572
joce
Architecte / Développeur principal
"BugHunter"
Posté le 07-03-2004 à 22:03:48  profilanswer
 

Limit a écrit :

oui bien sur, mais là je pense qu'il pourrait mieux utiliser la ram inutilisée mis à sa disposition.

implemente la recherche dans le contenu, tu seras comblé :D

n°666573
docmaboul
Posté le 07-03-2004 à 22:04:19  profilanswer
 

gizmo a écrit :


Non.
 
Les infos sont extraits d'un DB (ou de toute autre source) dans un certain ordre, mais rien n'indique que cet ordre sera le même sur le template (c'est justement son but). Donc, tant qu'on n'a pas toutes les infos, et donc terminé le script, on ne peut rien envoyé au client.


 
Oui.
 
C'est donc bien l'implémentation de la la génération du template qui pose problème. J'entends par là qu'avec un parser réalisant une extraction des données au fil de l'eau, on peut envoyer le début avant d'avoir généré la fin.
 
Après, nous n'avons peut-être pas la même conception d'un template?

n°666575
joce
Architecte / Développeur principal
"BugHunter"
Posté le 07-03-2004 à 22:06:21  profilanswer
 

Limit a écrit :

oui :D  
 
Mais c'est en cours, j'y réfléchis bien avant.

je l'ai désactivée sur HFR juste histoire de voir :D

n°666577
Limit
Posté le 07-03-2004 à 22:08:31  profilanswer
 

joce a écrit :

je l'ai désactivée sur HFR juste histoire de voir :D

la lecture ou la mise à jour?

n°666578
fabien
Vive la super 5 !
Posté le 07-03-2004 à 22:08:33  profilanswer
 

joce a écrit :

je l'ai désactivée sur HFR juste histoire de voir :D

ho putain,ca va vite la  :ouch:


---------------
✈ Découvre le HFRcoin ✈ - smilies ♥
n°666580
joce
Architecte / Développeur principal
"BugHunter"
Posté le 07-03-2004 à 22:10:47  profilanswer
 

Limit a écrit :

la lecture ou la mise à jour?

lecture
la mise à jour est toujours là

mood
Publicité
Posté le   profilanswer
 

 Page :   1  2  3  4  5  ..  86  87  88  ..  486  487  488  489  490  491
Page Suivante
Page Précédente
Haut de page 

Aller à :
Ajouter une réponse
 

Sujets relatifs
question avec les forums phpbb2[php] trouver la premier place ou inserer un enregistrement (résolu)
Forums phpBBQui connait l'algo du Passticket et sa mise en place en VB ?
[Merise] Mise en place d'un MCDFocus mal placé....
[Blabla/Prog] Les développeurs foromeurs sont-ils des feignasses?Mise en place d'un formulaire CGI
forums création de site internetJava - Mise en place d'une api (Servlet)
Plus de sujets relatifs à : les développeurs de forums, les 3/4 des forums sont down /o\

Forum MesDiscussions.Net, Version 2010.2
(c) 2000-2011 Doctissimo
Page générée en 0.116 secondes

Copyright © 1997-2025 Groupe LDLC (Signaler un contenu illicite / Données personnelles)