Deuxième semaine de mon moteur open source

Début du crawl et de l’indexation pour valider les correctifs du moteur

La semaine dernière, mon niveau de validation était de 40 % à ne pas confondre avec le taux d’erreur d’écriture sur la phase de récupération des fiches produits, c’est qui était beaucoup trop élevé suite à des erreurs que certains sites effectuent comme l’ajout de texte au lieu d'avoir des integer() sur les prix, mais aussi plusieurs plateformes omettaient de mettre leurs fiches produits dans leur sitemap.

Car ma séquence sur le dispositif de gratuité permettait de récupérer à l’indéfini des url pour les supprimer ensuite donc je passais à un dispositif a 500 url du sitemap pour ensuite en valider 70 ce qui me laisse un taux d’erreur abordable pour passer à la deuxième étape de crawl sur les pages une fonction de boucle indéfinie limitée à la concordance du domaine dans des 500 premières url. Donc il récupère les informations sur les fiches produits avec plus ou moins de vitesse en fonction des boutiques en ligne, certains ajoutent de nombreuses technologies pour accélérer la vitesse d’affichage sur l’écran, qui ralentisse considérablement la vitesse de calcul des serveurs car parfois trop de try:, de while, de for, ou de queryset suivant le language de progrrammation.

Astuce Python

Petite astuce Python un queryset en get() sera beaucoup plus rapide qu’un filter(), mais aussi pour faciliter l’accès entre les tables certains développeurs ajouter la fonction de foreygnkey()many_to_many, etc... ce qui oblige a faire tourner deux tables constamment sur l’ensemble des pages alors que de faire la concordance des variables Model1.prix = Model2.prix dans deux modèles fera ralentir votre donction, car il effectuera 2 appels sur deux tables à un moment donné, mais pas sur l’aspect général. C’est pour cela que j’effectue le traitement à la source pour éviter ensuite à placé des fonctions de typage à ne plus en finir pour corréler la base de données. Pareil sur les phases de séquençage du crawler, je souhaite que mes validations se fassent le plus possible en amont de ma fonction pour ensuite passer à la phase d’écriture, mais de rajouter des écritures dans la phase de validation pourait ralentir ensuite le prochain séquençage, ce qui permet de diviser par 10 le temps de crawl dans certain cas lors d'une invalidation. C’est pour cela qu’un crawler est parfois dur à écrire, car il doit mélanger l'optimisation du séquençage pour diminuer le temps de passage, respecter le timeout, améliorer la validation et la vitesse d’écriture en fonction des ressources machine comme les threads, sans oublier le prétraitement pour améliorer la vitesse de lecture du serp tout ceci dans une base de données réplicables à forte volumétrie, seul l’acceptation par étapes est possible ce qui prend énormément de temps.

Donc, parfois, on est amené à utiliser une multitude de technologies pour le web affin d'accroître la rapidité d’exécution au détriment de la maintenabilité. De mon point de vue je préfère proposer une plateforme automatisée et facilement maintenable évitant de faire appel à d’autre développeur pour résoudre des validations de fonction sur des solutions tiers. Ainsi, c’est clairement moins spectaculaire sur le papier, mais c’est tout aussi robuste dans le temps.

Et pour finir une la 3ème étapes est de pouvoir récupérer l'url des images pour les redimensionner, car je ne peux ajouter des fichiers avec 200 000 octets donc j’effectue un traitement de l’image sur du Rgba, rgb pour passer d’une conversion beaucoup moins volumétrique grâce aux fonctions en python pour un résultat en moyenne de 20000 octets sachant que je pourrait passer à 3000 octets bientôt. Vous comprendrez que je n’ai pas un datacenter pour stocker.

Maintenant, mon taux de validation est passé à 70 %, c’est pour cela que je sors le projet, j’améliorais au fur et à mesure du temps avec un travail quotidien sur le moteur de recherche.