Trop de passage, serveur SQL sur les genoux, 10 secondes pour le chargement de nos pages "dynamiques" rien ne va plus....
 
J'ai prodigué à mes boss le passage à des pages HTML me doutant bien qu'il doit y avoir un moyen de faire un brassage nocturne pour créer à la volée nos petits html à la place de nos ASP.
 
héhé malin! (non?)
Mais on manque de compétences à ce niveau et je n'ai pas l'ombre d'une idée sur la méthodologie à mettre en place, ce qui limite la portée de ma proposition.
 
Des idées sur la mise en place du merdier (logiciel qui le fait ou quoi...)

Je ne saisi pas bien. Pourquoi tes pages sont dynamiques ? A quoi servent-elles ?

ben on a plusieurs sortes de "services"
Là je pense à une partie qui nous sert à afficher des articles rédactionnels.
Actuellement on a une page du genre:
 
"affiche_article.asp?article=31"
 
qui afficherait le contenu de l'article 31 enregistré dans la base, en récupérant plusieurs champs: titre, date de rédaction et j'en passe. La mise en page est différente suivant quelques variables contenues dans la table. L'affichage d'une/plusieurs photos etc...

1/ c'est aussi simple de générer un fichier HTML statique que de coder une page ASP toute bête : tu envoies juste la sortie dans un fichier plutôt que dans l'objet Response. Reste ensuite un peu de travail pour automatiser le lancement de toutes les pages.
2/ ensuite euh... t'as pas imaginé plus pourri comme solution ?
 
-> Audit du code + optimisation/réécriture d'une partie
-> Boost des performances du serveur avec du matériel récent (cluster ?)
-> Petite analyse de la base pour avoir des index corrects et une volumétrie décente
-> En passant, utiliser un SGBD plus adapté peut-être ?
 
Bref, avant de passer à des solutions hideuses, il serait peut-être temps de faire travailler des gens compétents des yeux nouveaux sur le site et ne pas perde de temps à développer une solution impossible à maintenir par la suite.
 
 
Et je suis l'exemple vivant de ce que j'avance.
 
J'ai développé à mes débuts un site pour un client.
Le truc était d'une lenteur abominable, passait son temps à planter. Mettait à genoux un serveur dédié pour la base, et un server dédié pour l'ASP.
J'ai fait de la TMA dessus pendant plusieurs années.
 
Au fur et à mesure que je progressais et qu'on me demandait de nouvelles fonctionnalités, j'ai voulu commencer à améliorer la chose. Je suis retombé sur des pages qu'un goret n'aurait pas pu écrire lui-même.
 
Puis un jour le client en a eu marre de perdre de l'argent à maintenir cette bouse. Ils m'ont fait développer d'autres choses pendant 18 mois environ. Arrivé à une grosse baisse d'activité, je les ai bassiné jusqu'à avoir le feu vert pour réécrire le truc (de A à Z).
 
J'ai réussi à leur imposer l'utiliser d'un serveur Unix dédié pour la base de données (au lieu d'un NT4 agonisant). J'ai refais le modèle des données en utilisant correctement des index les plus optimisés possibles (avec l'aide de 3 DBA qui ont passé des nuits au paramétrage d'Oracle).
Puis je suis parti sur un site dont les specs étaient infiniment plus longues, avec des procédures incomparablement plus complexes, des fonctionnalités à plus savoir qu'en faire.
 
Malgré une architecture que je regrette aujourd'hui (on apprend constament), j'ai mis en place le site en un petit mois, et pour des perfs incomparables : les pages mettent 2 ms à tout casser pour se charger, quand bien même j'ai des traîtements particulièrement complexes. (genre 12 tables de plusieurs centaines de milliers de lignes chacunes pour récupérer un malheureux prix d'un produit).
 
Bref, avant de se lancer dans des trucs "à chier", repenser le site et améliorer ce qui doit l'être est un impératif.
Et ne pas hésiter à investir un peu pour avoir un serveur digne de ce nom quand il est requis.

 
Tu n'as pas tout à fait tord sur la qualité de notre base....    
Bon la boite n'a pas trop les moyens d'employer un tel superMan (même si je soutiens qu'il faut savoir se donner les moyens de ses ambitions...) te remeciant de barrer le passage où tu me traites d'incompétant. Je te remercie aussi de m'aider à faire avancer ma réflexion (sincèrement) sur les solutions à apporter, oui car la solution est juste à l'étude pour le moment et c'est bien pour me faire une idée sur cette hypothèse et mesurer les moyens qu'il faudrait y mettre que je suis ici.
 
Enfin: je connais très peu de sites rédactionnels qui ont des pages autres que .htm sur leur contenu, pourtant je doute qu'ils se paluchent tout à la main. L'intelligence des fois plutôt que d'avoir un bête regard nouveau est de commencer par regarder comment font les autres pour que ca marche....

on en reparle ce soir, je quite le taf (merde, raté mon bus )

Je lirai demain, je quitte le taf bientôt...
Par soucis d'avoir une vraie vie je me suis refusé à prendre le net à la maison, j'ai même pas branché mon PC (sinon je sors jamais le nez...)
 
Mince pour ton bus : /

heu j'ai lu ton rajout...
Chez nous c'est en gros la situation que tu y décris sur l'état de ta boite à tes débuts.
Oui il faudrait revoir en gros toute la structure... Tu n'as pas tord.

Pour un site avec des articles il faut faire une admin.

Alors, je vais en remettre une petite couche.
 
Evidement, cela s'applique à mon expérience, sur un projet précis. Il va donc de soit que les contrôles que je préconisent ne s'appliquent pas forcément.
 
Déjà, dans un premier temps, au niveau de l'ASP :
- Utilisation de la clause "Option Explicit" en haut de toutes les pages
- Ouverture d'une unique connection par page, et fermeture de cette dernière dans toutes les pages (les connections qui restent ouvertes, c'est très courant en ASP, et ça coûte très cher en terme de mémoire, puis en terme de vitesse pure -quand ça se met à swaper c'est fini )
- Création du MINIMUM d'objets ADODB.RecordSet et ADODB.Command : dès qu'il ne sont plus utilisés, les fermer proprement, puis les réutiliser au lieu de créer de nouvelles variables inutiles.
- Ne jamais utiliser "rs.Open" et encore moins "cnx.Execute" ! TOUJOURS passer par un objet ADODB.Command pour écrire dans la base ou lire des informations. Ca change les performances du tout au tout, et c'est en plus se blinder contre d'éventuelles tentatives de "SQL Injection".
- Oublier définitivement les variables de session. Leur préférer l'utilisation de Cookies de session (cookies avec une date d'expriration antérieure à leur création). Ne pas hésiter à gaspiller des requêtes pour rechercher des données qu'on aurait pu mettre en session. Le gain par l'abandon de ces dernières sera de toute façon suppérieur (bien penser à les désactiver dans IIS). L'utilité de se passer des variables de session, c'est surtout :
1/ Economiser une quantité non négligeable de mémoire sur le serveur
2/ Economiser en vitesse pure (c'est pas terrible d'avoir un objet de connection avec tout le cache ce cela implique en mémoire, surtout que ça force le SGBD à contrôler d'éventuels locks)
3/ Ca améliore la lisibilité du code et sa maintenance (les sessions qui tombent du ciel et expirent en plein milieu d'un process complexe, c'est vraiment la tannée à débuger)
- Oublier aussi les variables d'application, pour la même raison. Même la chaîne de connection ne doit pas s'y trouver : préférer un fichier d'include avec ce genre d'informations en constante.
- Oublier les passages d'objets entre fonctions. Ou les minimuser au maximum. Genre les fonction GetRs("select toto from truc" ) qui retournent un recordset sont à banir !
- Ne pas hésiter à multiplier les fonctions quite à les rendre très courtes et avec des niveaux d'imbrication plus élevé. Même si cela représente une légère perte de performances, cela évite généralement des usines à gaz et la duplication de code dans des includes titanesques (et ça par contre c'est mortel de faire un include de 8 Mo, j'ai testé pour vous)
- Utiliser au maximum des procédures stockées et des vues pour accéder à la base : le gain de performance lors de leur exécution est énorme, surtout en utilisation intensive, mais surtout, ça permet de gérer les droits d'accès à la base de façon plus précise : dans une application idéale, l'utilisateur qui sert au site doit avoir un DENY sur tous les objets de la base, mise à part aux procédures stockées où il aura la permission EXEC uniquement. (ça change rien aux perfs, mais niveau sécurité, ça permet de s'affranchir d'un grand nombre de mécanismes qui serait utilisés sur le serveur, et surtout, c'est plus propre, donc tant qu'on y est, autant le faire).
 
Pour ce qui est de la base de données :
- Déjà, c'est simple : refaire l'analyse point par point, à la fois pour les tables volumineuses, mais aussi pour les tables intensément utilisées. Genre t'as 200 users inscrits... Si tu vérifies le mot de passe à chaque page, t'as plus intérêt à optimiser cette table que celle de l'historique des commandes qui ne sera consulté que par deux gars dans la journée.
- Limiter au maximum les données redondantes, et ne pas hésiter à multiplier les jointures (c'est faux, une jointure NE CONSOMME RIEN en terme de performances ou mémoire... bien moins qu'un index non unique qui porte sur des milliers de doublons inutiles)
- Ne pas hésiter à stocker quelques valeurs calculées. Genre pour un site marchant, ne pas hésiter à stocker dans l'entête du basket son total : il ne change pas à chaque page, donc c'est idiot de devoir rechercher tous les produits qu'il contient afin de retrouver le montant total.
- Toujours en ce qui concerne la dénormalisation, ne pas hésiter non plus à plancher sur des vues "de la mort qui tue" afin de simplifier énormément des requêtes (genre t'as une gestion de composés/composants avec des prix unitaires calculés, ne pas hésité à faire ces traîtements dans une vue).
- En ce qui concerne l'installation du SGBD, suivre scrupuleusement les recommandations de l'éditeur. A savoir, pour la plupart :
1/ Un disque physique pour l'OS uniquement
2/ Un disque physique pour la SWAP uniquement
3/ Un disque physique pour l'applicatif du SGBD uniquement (à la limite, tu peux le mettre sur le premier)
4/ Un disque physique pour la base de données (données)
5/ Un disque physique pour les index (quand c'est possible, avec SQL Server par exemple, c'est pas évident puisque les PK sont obligatoirement stockées dans le même fichier que la table)
6/ Un disque physique pour les log de trasactions
=> Eh oui : 6 disques dur, pas moins ! Le RAID, vous en mettrez si vous avez encore des disques en rab. (ne pas oublier une solution de backup horraire incrémentale si les données et les logs ne sont pas sur un RAID redondant)
- Repenser tous les index. La présence de vues et procédures stockées à la place de requêtes perdues dans le code est un atout non négligeable pour cette étape !
 
Voilà, je n'entre pas plus dans le détail, mais rien qu'avec ça, y'a de quoi améliorer considérablement les performances, surtout si nombre de ces points n'ont pas été suivis au départ.
 
Et je redis encore et toujours : si le serveur d'application (IIS) peut tourner sur un serveur low cost d'entrée de gamme (une machine perso actuelle est infiniment plus puissante que nécessaire pour un serveur qui se tape des milliers de hits par seconde), le serveur pour le SGBD, lui, doit être bichonné ! Au moins deux canaux SCSI, au grand minimum, 2 Go de mémoire (c'est pas pour ce que ça coûte...) et si possible une architecture bi-processeur (une vraie, pas du HT) pour avoir une montée en charge plus linéaire.

Ok... j'ai pas lu les solutions proposées, mais j'aurais tendance à dire: load balancing. Pour le(s) serveur(s) web et/ou pour la BDD.
En gros, plus de serveurs, et de préférence transparent au niveau IP/DNS.
Solution alternative Linux+PHP.... Malheureusement trop économique pour le commun des mortels.

Quequette pour les disques ou on parle d'une solution pro pro et là s'il est pas capble de deviner ce qui tourne pas rond (y'a pas que unix dans la vie hein Parer au pire pour faire du mieux est pas une excuse pour coder comme un goret....) c'est qu'il faut changer de métier parce que là tu aborde l'ultime

pas vraiment d'accord : load balancing/cluster, c'est +30% de perfs dans le meilleurs des cas si jamais on utilise des procédures concurrentes dans la base (mises à jour par exemple, ce qui impose que toutes les version du loadbalancing soient synchronisées en permamance)
 
Ensuite, pour Linux+PHP, je suis obstinément contre dans ce cas :
1/ A nouveau, à compter que le site est écrit "de la même façon", c'est un gain qui se situe entre 10% et 20% dans le meilleurs des cas (et je dois être particulièrement généreux là)
2/ Ca demande non seulement à tout réécrire (ce que n'impose pas complètement mes recommandations) mais surtout à reformer toute l'équipe
3/ A cause de cette "reconversion" de l'équipe, on peut affirmer que des erreurs monumentales seront faites (variables globales, etc.) faute de maîtriser le langage. On peut donc être sûr qu'il y aura autant d'erreurs de réalisation dans cette version que dans la version ASP, ce qui confirme le point 1
 
A noter que c'est comme ça que malgré mes recommandations ma société à été exclue d'un appel d'offre alors qu'on était en shortlist : un client avec 100% de son parc en NT et SQL Server. On doit lui faire un site. Deux solutions retenues : ASP ou PHP. Le client est conquis par notre maquette et notre savoir faire. En tant qu'architecte d'application, je met la pression sur le commercial et le DP pour ne pas parler de la version PHP, mais insister sur la version ASP qui est la seule à avoir une chance vu l'environnement du client. Ils ont fait le contraire... La réunion n'a même pas eu le temps de se terminer : reconduits direct à la porte. En gros, t'as un système en place, avec des compétences pour le maintenir, hors cas de force majeure, il est impensable de se lancer dans une autre techno (qui n'apporte vraiment pas grand chose qui plus est -économie de 700 € ?-) qu'on ne maîtrise pas.

Ah, tiens, j'oubliais. Dans mon cas, ce qui nous a fait gagner énormément de perfs aussi, c'est l'abandon de l'usineà gaz Site Server 3.0 + Commerce Server 2.0 (d'autant que c'était pas adapté, puisqu'on vendait à l'époque des IRM à 2 000 000 $ en Lire italienne et que CS ne supporte que des INT 16 bits pour le montant) au profit d'une solution 100% écrite à la main en ASP.
Comme les gens qui font du PHP, j'ai eu un mal de chien à les convaincre qu'un truc fait à la main pour pas un rond serait mieux qu'une solution pourrie à 40 000 €... Mais je suis très persuasif, "si tu veux pas que je fasse ce que je veux, je fais rien, à toi de voir"

Ok MagicBuzz
C'est long, je me suis encore perdu. En gros c'est un merci pour ne pas avoir répondu à ma question de base (lol) mais pour m'avoir aider à avancer dans une autre question que je n'ai pas posée ici mais sur laquelle je planche en ce moment, ammélioration des perfs générales du site.
Pour ma question de base j'ai trouvé comme un grand une solution alternative.
 
Pour les détails c'est plus bas....
 
 
Merci pour le temps que tu as visiblement passé à écrire ces précieux conseils.
Bon on n'est pas du tout nickel (qui l'est?) mais quand même pour une grande partie de tes remarques on est déjà propre.
 
Je ne savais pas par exemple qu'il fallait privilégier la ré-utilisation des variables recordSet fermées précédemments. Perso j'ai tendance à multiplier les noms pour éviter de ré-utiliser des RS ouverts dans un des vieux include qui trainent et qui sont fermés plus tard (bouh...usine à gaz...pas ma faute à moi...) et surtout pour la lisibilité du code (RSlisteFacture ca m'aide plus pour le débug que RS1 à gogo).
Très bête je ne savais pas non plus pour les variables de session... Bon on en utilise très peu actuellement de toute facon et notre serveur Web lui tourne pas mal... Mais bon pour les futurs développements... A penser!
 
Bref pas mal de choses utiles pour amméliorer les perfs de notre server de BDD. Avant ton audit j'étais déjà en train de remettre mon nez dans les index.
Les view j'avais tenté l'année dernière pour des gros extract mais je n'avais pas constaté d'ammélioration... A revoir sans doutes, si tout le monde dit que c'est bien c'est que ca doit êre vrai!
 
Mais bon, je ne peux pas tout révolutionner aujourd'hui. Tes conseils sont en voie d'impression et vont être affichés dans mon bureau. Même si je suis sensibilisé à la plupart de ces problèmes il est bien de garder constament tout ca en vue.
 
Bon pour le HTML la problématique reste d'actualité pour certaines typologies de nos services mais j'ai trouvé une proposition pour ceci. Pas de HTML à la volée. Au lieu de transférer nos articles de la base d'édition à la base de consultation (c'était pas mal pour ménager nos index cluster et pas charger en brouillons...) ben la procédure partira créer un truc figé. On a aussi une problématique de référencement google derrière que je n'ai pas développé ici pour laquelle "afficher_article.asp?num_article=31" est pas la solution la plus performante...

Rien à voir... Notre hébergeur me demande si je fais fréquemment la mise à jour de mes index... Heu une fois en place j'ai toujours cru que ca se faisait tout seul, au fur et à mesure des insertions ou effaçages (ce qui explique pour moi le fait qu'indexer une base grève parfois les performances d'édition de base).
 
Dois-je faire une manip sur SQLServer pour faire cette mise à jour?
J'ai pas trouvé l'option sur le logiciel, ce qui me conforte plutôt dans l'idée que j'ai rien à y faire...

Re
 
Pour la réutilisation d'une variable provenant d'un include, tu as raison : surtout ne le fait pas. Moi je parle au sein d'une même page (includes non compris)
 
Il ne faut d'ailleurs jamais utiliser une variable provenant d'un include, ou le moins possible. privilégier les fonctions dans ce cas, car le jour où tu vires un include pour x raisons ça commence à déconner (et pas toujours de façon visible) sans raison évidente.
 
Sinon, pour le problème de référencement, tant que tu passes par des liens HTML dans ton code, normalement ça ne devrait pas poser de problème pour l'indexation.
 
Le coup de la génération de pages statiques, je vois en effet ta problématique. Perso, je n'aime pas cette solution car elle pose problème lorsque tu dois modifier un article ou le supprimer. Idem pour ce qui est de leur indexation depuis les menus.
 
Sinon, en gros, lors de la publication, appelle une page qui est une copie de ta page d'affichage actuelle.
Modifie-la de façon à ce que :
1/ Elle ne contienne plus un seul tag HTML directement dans la page (voir exemple plus bas)
2/ Elle ne fasse plus de Response.Write() mais une affectation dans une chaine de caractères
3/ Enregistre cette chaîne au final sur le disque
=> après t'as plus qu'à te débrouiller pour publier la page en question et l'indexer proprement dans tes menus sur le site de prod.
 
Mais bon, perso je n'aime pas du tout...
 
Exemple :
 

 
Devient :
 

 
En fait,c'est un peu pareil que quand tu envoies un mail au format HTML

de base, ça marche comme tu pense.
sauf que vu que j'imagine qu'il y a plus de lectures de d'écritures dans la base, contrairement à ce que tu penses, les index apportent un gain immense de performances avec une perte vraiment négligeable
 
sinon, recherche dans la doc, je ne me souviens plus trop de la syntaxe.
 
c'est un truc style "update statistics on index_name"

Oui oui
surtout sur ces bases que l'on a voulu purement pour consultation l'indexage fera gagner beaucoup.
Notre hébergeur parle même d'un gain pouvant aller jusqu'à 80% entre un système sans index et un autre bien indexé (bon tout dépend des besoins évidement). Je ne pense pas arriver à ce résultat avec les seuls indexs mais ouais j'ai aucun doute sur les index... C'est plutôt sur les views où je suis pas très à l'aise.
 
pour les index...
Exemple: toujours sur nos articles que j'essaie d'amméliorer.
En condensé de ce qui est intérressant pour le tri des données, on a 4 colonnes.
 
-article (numéro de l'article)
-page (numéro de la page)
-tri_nivo1 (variable de tri hiérarchie 1)
-tri_nivo2 (variable de tri hiérarchie 2)
 
Actuellement l'index est en cluster sur article/page. C'est à dire que ma base est triée physiquement par article puis par page....
A la base c'est beaucoup mieux pour afficher l'article une fois qu'on l'a choisi. Mais je trouve ca très faiblard au niveau affichage de mon index (enfinlà l'index c'est la page où le lecteur peut voir tous les articles d'une rubrique).
Ma proposition là dessus, me détromper si c'est pas le best...
Me contenter d'une clé primaire sur article/page qui indexe tout seul la chose et que je comprend pas pourquoi la personne qui à fait la base n'a pas mis de clé.
Puis un index composé sur tri_vivo1/tri_nivo2 (cluster? ou non cluster?) cela devrait amméliorer pas mal, ai-je bon?
 
Je m'excuse de cette question très innocente, mais la BDD c'est pas mon dada... J'ai pas été formé aux indexs... J'ai le sentiment que c'est mieux ainsi, à confirmer...

Je confirme. Ca peut d'ailleurs être largement plus dans le cas de requêtes complexes !
 
Pour les vues, le gain est remarquable surtout quand la requête est complexe. En effet, le temps d'analyse et de calcul du plan d'exécution est non négligeable dans ce cas alors que la récupération pure des infos peu être très rapide.
 
Pour un select * sur une clé d'une table unique, évidement cela ne pose pas de problème.
 
Pour ton index, explique plus : "un exemple, un exemple, un exemple !"
 
En tout cas l'index que tu proposes me semble très mal choisi

 
ah... zut... c'est bien que je le sache maintenant avant de plonger les mains dedans.
 
En plus clair la table concerne quelque chose comme 30% de notre trafic (en terme de pages vues) et elle n'est pas du tout optimisée.
Elle est utilisée de deux manières:
1-affichage d'un article choisi
2-affichage d'une sélection/de listes par famille et rubrique
 
Pour le 2 en plus clair un article sur ce qu'on peut demander lors d'un licenciement (oui j'aime les exemples corrosifs   ) sera rangé dans la famille "droit" et la rubrique "emploi". Lorsque je navigue à ce niveau là je dois lister tous les articles de "droit/emploi".
Evidemment "droit" et "emploi" sont des numéros ralliant à d'autres tables référençant les familles et les rubriques par des numéros. Si mon numéro de rubrique (7) correspond à "emploi" dans "droit", ce même numéro de rubrique me renverra à "poissons" dans la famille "cuisiner". Donc mon indexage pour cette problématique ne peut pas se contenter de pointer vers les rubriques mais bien le combo famille/rubrique.
 
C'est en différenciant ces deux problématiques que j'ai pensé à indexer la base en deux parties (ce qui a priori ne pose pas trop de problème technique).
 
Maintenant que j'ai (j'espère) développé la chose, je suis vraiment parti pour faire un truc tout pourri? c'est bon? Ya mieux?  

Autant pour moi ca se passe pas comme ca notre archivage.... hum
 
Ya une table intermédiaire qui relie l'article avec sa catégorie...
Bon ben pas de jointure, pas d'index... on fait la vidange quand même ou on attend que les soupapes nous lachent aussi?
 
Bon je fais (en plus d'un pétage de cable nerveux) la définition des clés, des jointures pis normalement j'ai des index qui se crééront automatiquement qui vont pas trop mal du coup. (Encore qu'il y a sans doutes mieux mais de l'aveu de mon patron le système d'archivage change dans pas longtemps pour mettre un troisième niveau)
 
Bref si tu veux répondre à la problématique d'avant je t'en serai gré pour ma culture perso, que je sache pourquoi c'est pourri encore qu'on est carrément pas dans le bon topic dans HTML.
Merci pour ton aide, ce fut fort instructif
 
C'est motivant ces petites boites, on est jamais à cours de boulot, wouh ouh!

Là, pour le moment, je nage
 
Si j'ai bien compris, tu as une table article (avec mettons juste un ID plus le texte, c'est ça ?)
Une ou deux tables pour gérer les rubriques et les sous-rubriques ?
Puis une table qui fait le lien rubrique/sous-rubrique/article, c'est bien ça ?
 
Quelle est l'utilité de cette table de jointure ? Vous faites du multi-référencement ? (article présent dans plusieurs rubriques à la fois)
Si ce n'est pas le cas, c'es alourdir les traîtement pour pas grand chose (bon, c'est pas non plus très grave).
 
Pour ce qui est des index générés lorsqu'on indique les clés étrangères, ça ne suffit pas du tout. Ils sont utiles, certes, mais ne suffisent pas.
http://forum.hardware.fr/hardwaref [...] 6416-1.htm
 
Je vais compléter un peu cet article afin de mieux traîter le problème des index, mais déjà avec les infos qu'il contient sur le sujet, ça devrait te mettre sur le piste (lis le fichier PDF, 3° post)
 
Sinon, écris-nous ton modèle des données entier en ce qui concerne la gestion des articles, ainsi que :
1/ ce que vous voulez faire avec
2/ ce que vous faites en réalité (liste des requêtes)
 
Parceque sans ces deux informations, à la base y'a pas trop moyen de faire de plan sur la comète.