Це відео не доступне.
Перепрошуємо.
Améliorez FORTEMENT les performances de vos Applications Web grâce à ces 3 astuces.
Вставка
- Опубліковано 14 тра 2024
- J’ai accidentellement créé une application web TRES rapide
💪 Soutenir la chaine via tipeee :
fr.tipeee.com/...
🚀 Plus de 40 formations pour 25 €/mois SANS engagement de durée 🚀
codeconcept.te...
Je trouve que c'est facile d'avoir des performances de ouf avec une DB vide en local et un seul utilisateur.
Je serai curieux de voir la même app avec des millions de lignes en DB et des utilisateurs qui utilisent l'appli en même temps.
Pas d'accord avec les ORMs, je les ai toujours utilisé avec les projets sur-lesquels j'ai bossé et pas de problème de perf lié a son utilisation. Le problème c'est que bcp de devs sont feignants et ne prennent pas la peine de regarder les requêtes exécutés par l'ORM et ils n'hésitent pas a appeler l'ORM toutes les 4 lignes ce qui forcément fini par tuer le DB.
Donc encore une fois je trouve qu'on tire sur les outils alors que le problème est entre la chaise et le clavier
Les ORM en ecriture OK, par contre en lecture, faire des requêtes native sera bien plus performants (et aussi beauocup plus souples et faciles à optimiser), d'autant plus que les requêtes en lecture sont beaucoup plus frequentes et complexes en générale dans les applications.
@Raiden0602 Avoir une opinion est totalement différent de se forger une opinion en créant une application et en mesurant ses performances.
Mon application est effectivement encore en phase de tests. Ceci dit, je n’ai jamais vu le signe "micro" s’afficher sur d’autres applications web - elles aussi en local. J’étais toujours entre 5 et 20 ms de traitement de requêtes + accès à la base de données pourtant elle aussi locale. Quand on compare ce qui est comparable, passer de 5 ms à 700 microseconds dans les mêmes conditions, j'ai quand même tendance à appeler ça une amélioration de performances 😀
Quant à tester des ORM sur des tables contenant des centaines de milliers de lignes, j’ai eu le retour d’expérience direct d’un architecte quand nous, les devs, poussions à l’adoption d’un ORM. Pour être franc, on n’aimait pas SQL : on aurait préféré rester de bout en bout en C#. Ledit architecte, pas borné, a décidé de se forger une opinion et donc de faire des tests sur notre base (dont quelques tables contenaient des centaines de milliers de rows). Ses tests ont été sans équivoque. L’ORM dégradait les performances. On a donc laissé tomber l'idée sans regret.
A moins que tu aies une application à présenter où l’ajout d’un ORM, qui fait des requêtes sur une base de données dont les tables contiennent plusieurs centaines de milliers de lignes, ne dégrade pas les performances en lecture (car c’était en lecture que le problème était le plus prononcé), je resterai convaincu que l’ORM est une abstraction pas seulement inutile, mais contre-productive. Si en revanche tu me présentes une application qui a de meilleures performances avec un ORM que sans ORM, je changerai d’opinion sans le moindre problème. Car finalement, une opinion ne vaut que si elle est soutenue par des faits. Quand une opinion est une extension de son égo elle devient ... une simple croyance. On s'est tous laissé aller à ce travers un jour, moi y compris.
@MrMojoRisinBzh Effectivement. Un DBA, qui venait une fois par semaine nous aider à améliorer nos requêtes, nous a fait une démo de profiler qui permettait de visualiser les requêtes faites par l'ORM Entity Framework (là aussi, pour nous dissuader de céder à la facilité). Même nous, qui n'étions pas DBA, avons tout de suite remarqué que les requêtes bien étaient plus complexes que nécessaires et donc plus lentes, dès qu'il y a avait des jointures. Bon, c'était il y a 15 ans, peut-être que les ORMs ont progressé depuis.
Le but premier d'un ORM est d'être "time to market". Sur des applications de type CRUD le surcoût leger en terme de perfs est largement en sa faveur. Dans le cas d'une application de gestion avec un modèle relationel complexe, c'est une autre histoire. Mais même dans ce dernier cas tu peux repasser en requête native sur des uses cases ou users stories spécifiques nécessitant les meilleures perf. Tu peux faire 90% de ton appli avec l'ORM pour gagner sur le temps de dev pour tenir les délais et cibler l'effort sur le reste. Et rien ne t'empêche de réécrire plus tard la partie ORM en SQL natif. D'expérience ça ne fait jamais...
Mais ce qui à donné une mauvaise image aux ORM ce sont les dev inexpérimentés qui n'y comprenaient absolument rien et à peine plus dans leur langage de programmation et encore moins en génie logiciel.
J'ajouterais pour finir, que le choix du stack technique du développement d'une application est conditionné par le niveau géneral de l 'équipe de dev, des délais, du SLA (niveau de service) à respecter et surtout du budget. Donc en fonction du contexte, les choix techniques pourront être totalement différents car le but est d'être efficient, de tenir les délais et le budget (maintenance incluse 🤭).
De mon point de vue, le nerf de la guerre des projets d'entreprise envoyé en prod avec de vrais utilisateurs, c'est la réduction de la complexité. Chaque outil ajoute une couche d'abstraction et rajoute de la complexité sur certains aspects, et/ou en supprime aussi sur d'autres. L'abstraction n'est pas forcément mauvaise, mais souvent les développeurs les utilisent dans tous les sens parce que "on a toujours fait comme ca" sans trop réfléchir, ou pour gonfler leur CV... Faire ce genre d'exercice permet de remettre un peu en question cette fuite en avant et d'utiliser l'abstraction quand c'est vraiment bénéfique.
Trouver le bon dosage de complexité : vaste programme 😀
Il est possible que la prochaine chose à se complexifier pourrait être SQLite, remplacé par une base tradi. Je verrai bien après les tests de charge. En entreprise, j'avais eu accès à Load Runner, mais là, pour un projet perso, je vais devoir trouver un outil équivalent. Je suis preneur de toute suggestion 😄
J'ai aussi eu cette réflexion, et finalement ça peut se résoudre avec juste une posture: Toujours minimiser le nombre et la taille des dépendances (Faut trouver le juste milieu) mais à terme, c'est ce qui permet d'enlever ces couches de complexité.
@@codeconcept Bah juste un script qui compte le nombre de requêtes par seconde devrait suffir non ?
Jmeter ça fait le job.
J'ai un slogan pour ton projet : Composter, c'est bien, congeler, c'est mieux !!!
Merci pour le slogan 😀Vu le rejet de l'écologie à notre époque, je préfère cibler le porte-monnaie. Après, Le résultat sera le même en termes de diminution de gaspillage 🌱
Je suis tellement en accord avec ton approche.
Avec le recul, c'est quand même un poil galère. Mais les perfs sont là 😀
Est-ce qu'en hébergement distant la différence de performance entre les applications en micro et en millisecondes est toujours aussi marquée ?
Je viens de déployer et ça se tient 😀
Bon, ajouter par dessus NGINX a dû ralentir un peu la chose. Je suis plus souvent autour de 2ms quand il y a des requêtes vers la DB. Ce qui est quand même bien mieux que les 10 à 20 ms d'ordinaire juste après une install 😉
Super vidéo comme d’habitude, quand tu reviens au source ton application deviens plus rapide mdr, on veut bien un petit tuto de sqlite
Merci ! C'est bien noté pour le tuto SQLite 😉
À la place de sqlite j'utilise liteDB c'est un peu le même délire, mais en noSQL avec des "relations" possible et possibilité de faire du SQL.
Je trouve bien parfois de revenir aux technos vanilla pour des apps de ce genre
L'abstraction n'est pas une mauvaise chose, mais les dev l'utilise dans tous les sens car "on a toujours appris ou fait comme ça", pour une simple requête l'ORM en exécute 10.
c'est un projet à porter sur ledit frigo ?
Non, c'est simplement un pense bête qui calcule les dates limites de congélation, pour éviter de jeter de la nourriture conservée trop longtemps (j'ai découvert des tupperware là depuis 2 ou 3 ans😄)
Super merci 👍 Je connaissais SQLite de nom mais je n'avais jamais fait attention aux performances. Je pensais être le seul à faire des fronts JS sans framework pour mes projets perso. Te voir en parler sans complexe me rassure. J'adore l'approche minimaliste quand on peut se le permettre. PS: tes tomates sont vachement longues 🍅
Merci JP 😀
Attention, je le fais dans le cadre de projets perso 😀 En entreprise, ne serait-ce que pour se couvrir, un Chef de Projet ou un DSI privilégieront presque toujours des solutions traditionnelles, pour ne pas être attaqués par des rivaux qui lorgnent leur fauteuil. Si bien que côté DB, MS-SQL, Oracle ou PostgreSQL restent le trio de choix. Idem pour les frameworks Front : le tiercé gagnant reste Angular, React et Vue (avec parfois Svelte).
Je vais peut-être m'en mordre les doigts d'avoir choisi SQLite d'après certains commentaires (SQLite ne serait pas adapté au multi-user, même avec le Write Ahead Logging). Les tests le diront 😄
Ceci dit, sur des petites apps, si je peux éviter d'envoyer 1 Mo de JavaScript lors de la première utilisation à des utilisateurs qui utilisent l'appli sur leur téléphone en 3G, je peux tenter des choses plus exotiques. Même si, en dehors de Go, c'est plutôt Astro ou Qwik que j'aurais pris pour leur capacité à ne presque pas envoyer de JS par défaut. Mais je reste convaincu que continuer à faire du JavaScript "pur" en plus d'utiliser un framework est un plus.
Je compte plus les problèmes avec les les outils tout fait de bdd par exemple oracle jdev, JPA, ORM sur Android. En fait ce que j’ai remarqué c’est que plus le projet grandi les outils et plus c’est une tannée de l’utiliser soit à cause des bugs ou soit des requêtes sont mal géré. Après on peut pas faire une généralité non plus.
Très instructif le sql est un peu intimidant mais Sqlite a l'air génial.
L'avantage c'est que progresser dans l'un, c'est progresser aussi dans l'autre 😎
CatchChallenger, seulement les frameworks minimum, principe KISS, UI comme on le fesais avant w/h + draw x/y, les temps de réponse sont plutot
Est-ce qu'on peut utiliser SQLlite avec des ORM comme sequelize par exemple ?
Oui c'est possible. Avec Prisma c'est sûr. Avec d'autres aussi je suppose.
La dernière fois, je regarde une vidéo d'une personne qui annonçait mettre en place tout un environnement JS. La liste était tellement énorme que je partage cette vidéo à un ami. Nos réponses étaient : ridicule !
C'est ce que je trouve un poil délirant dans le monde de JavaScript : on ne fait que générer des fichiers HTML / JS / CSS, mais pour ça, on empile de plus en plus d'outils ... qui nécessitent d'autres outils pour corriger la lourdeur des premiers outils 😄
Il y a tellement de nouvelles APIs natives aujourd'hui, par rapport à il y a 15 ans, que j'en viens à me demander pourquoi, pour des app simples, on ne les utilise pas davantage.
Ensuite, sur de grosses applications, c'est une autre histoire.
Je veux bien le tuto sqlite
Pour me former par exemple à go et à Rust, j’ai utilisé que du bas niveau pas d’ORM, rien du tout et ça permet vraiment d’être plus proche de ce que veut nous faire apprendre le langage
Mon objectif est également pédagogique, donc j'ai utilisé au maximum la standard library, très riche (bonne surprise)😀
J'aime bien le principe
En terme de prod, concernant Sqlite, qu'en est-il de sa secu intrinsèque, de la charge multi-users ainsi que du nombre maximal de recodset par table ? Merci pour cette superbe appli démo👍
Merci Rachid 😀
Je vais surveiller de près SQLite dns le cadre d'une appli web, car c'est l'avertissement qui revient régulièrement en commentaire.
Bon, s'il faut que je passe à PostgreSQL ou MySQL, je le ferai 😉
Sqlite n'est pas fait pour des gros volumes de données ou du multi-user, mais pour de la base de donnée embarquée et légère, donc forcément, y'a moins de fonctionnalités que SQL Server ou MySQL.
Et puis en théorie, y'a pas de limite du nombre d'entrées, tant que t'as de la RAM et de l'espace disque...
Faut être pragmatique : le cout d'un serveur plus puissant est-il moins cher que le cout de développement ?
Tout à fait : et ce même pragmatisme implique de prendre en compte ...le contexte, celui d'une application gratuite faite par développeur solo 😀
J'irais même jusqu'à ajouter que compenser les mauvaises performances d'une application par l'utilisation de gros serveurs tient trop souvent de la fuite en avant. Car à mesure de la montée en charge, le budget hébergement croîtrait de trop. Ce serait un peu comme accepter qu'une voiture consomme 20 litres au 100 et "compenser" en prévoyant un gros budget carburant. Il vaut bien mieux régler le problème technique avant.
Dans le contexte d'une application développée par une équipe, avec gros marketing budget à la clé, là je suis d'accord, on peut (et même doit) se payer les hébergements les plus haut de gamme avec toutes les redondances qui vont bien 😉
Est-ce que ce programme fonctionne aussi avec la Pizza 4 fromages ? 🤡
Pas encore testé, mais à moins que ça lève une CholesterolException, y a pas de raison, ça devrait aller 😁
@@codeconcept 😆😆😆 Return Cholesterol
En vrais je pense bien que le développeur est la pour réinventer la roue. Et tous faire depuis zero c'est son objectif. Mais il faut bien avouer que les développeurs peuvent pas faire ça. C'est la différence entre un trucs perso et un truc de groupe. Tu auras des gens qui font du freestyle avec un ballon et ce seras des trucs de fou. Mais tu les mets dans une équipe ça donnerait rien. C'est pas la même chose du tout.
Après l'utilisation sqlite c'est très bien je pense avoir lu que sqlite se veut pas une basse de données mais plutôt se veut un système de persistance. On n'arrive pas encor lourd de nos habitudes mais le système de fichiers est dépassé. C'est plus opportun.
Sqlite est une alternative. Enfin j'ai compris comme ça.
Le principe de "réinventer la roue" ne me choque pas. Après tout, on ne peut pas mettre de roues de charrette sur une voiture. Donc même en dehors du dev, on passe du temps à réinventer de nouvelles roues plus adaptées 😀 Mais là où ça devient fou, c'est que l'on charge parfois trop la mule en compliquant des choses simples au point que les performances et la maintenance en prennent un coup.
Sur de gros projets, les frameworks restent en effet incontournables. Et sur une app plus grosse en Go, je prendrai un framework (comme Chi, Gin ou Fiber), car je me suis quand même bien pris la tête à tout faire à la main. Mais c'était pour pratiquer et bien comprendre ce qui se passe son le capot histoire de ne pas avoir l'impression que c'est magique 😀
Concernant SQLite, il a tellement de projets sur lesquels il y a seulement quelques dizaines d'utilisateurs, que ce soit dans le cadre d'intranet ou d'applications très niche qui n'auront au plus qu'entre 100 et 1000 abonnés. Dans ce cas de figure, SQLite est très adapté. Et sur un smartphone, c'est aussi un bon choix
Ps: Je crois que j'ai ma réponse, pile après avoir posté la question en commentaire j'arrive sur la partie de la vidéo où tu en parle 😅
Parfait 😄
Je suis curieux pour siplike.
J'ai deux idées
c'est un problème qu'un dév et poussé adoit full stack, ce qui amène la création de framework et par Essence nous enlève de connaître avec précision des language
Dans un seconde temps il peut aider le dev l'or de la conception comme java avec Spring boot
Pour moi cela vas dépendre de notre besoin et surtout de connaître la philosophie dernière le language ou framework ou librairie
Attention, tu es en local. Aussi, Sqlite n'est pas une bonne solution. C'est une base de données monoutilisateur. C'est-à-dire que pour ton cas et que pour chaque compte, tu es obligé de créer une base par utilisateur. Sinon, tu risques de verrouiller ou mettre en file d'attente la requête suivante. Cela dit, je confirme que Sqlite est une bonne DB (mais attention, bien qu'elle se soit améliorée, elle ne prend pas tout en charge (tout le langage SQL ex : truncate, tu oublies. Il faut faire une autre manip pour arriver à ce que truncate fait))
@MrNiuxe J'avoue avoir surtout utilisé SQLite dans le cadre d'applications mobiles hybrides, donc effectivement en local sur un device. J'espère, ceci dit, qu'utiliser le fichier WAL va me permettre d'avoir de bonnes perfs en multiusers également.
100% en phase avec le principe
Merci Alex 😀
Maintenant, c'est le passage du principe à la réalité qui va peut-être me faire regretter certaines options. Comme SQLite sur une appli web, d'après plusieurs commentaires argumentés et bienveillants (donc à prendre en compte). Ca va être le point que je vais surveiller de près 😅
@@codeconceptJe veux bien te croire. Après, il n'y a pas être dans le dogmatisme (c'est souvent le cas chez les devs). Chacun son style. Moi je fais parti des minimalistes et je travaille bien mieux comme ca, mais je peux comprendre que certains raffolent des surcouches de surcouches
Oui je partage tout à fait l'idée qu'il y a trop d'abstractions !
Je ne comprend pas vraiment l'intérêt des ORM.
À priori, l'utilité c'est que l'application ne soit pas couplé au système de BDD.
Cela permettait de changer de SGBD sans avoir à modifier le code de notre application.
Ces abstractions rendent selon moi le code plus compliqué, car il faut toujours apprendre de nouvelles choses, plutôt que d'apprendre une fois pour toute une stack.
Aussi, j'ai l'impression que le coût d'un déploiement en prod devient de plus en plus élevé.
Tu déploies un VPS, un Cloud, ... ?
J'ai eu la chance de voir à plusieurs reprises architecte ou DBA nous faire des démos de profilers qui montraient les requêtes SQL générées par un ORM. Dès qu'il y avait des jointures, l'ORM prenait des détours assez ... surprenants.
Je n'ai pas encore décidé pour l'hébergement : si tu as des suggestions, je suis preneur 😀
@@codeconcept
Si, la taille totale de ta db, image etc. ne depasse pas 100mo, ce qui pour un projet minimaliste serait logique, je pense qu'il y a pas mal hébergeur gratuit.
Je peux t'en conseiller un;)
sqlite fonctionne pas bien en multi-users
C'est là que ça va devenir intéressant. Le WAL mode (Write-Ahead Log) a l'air d'être là pour ça :
www.sqlite.org/wal.html
Bon après, je peux faire une file d'attente et faire de l'optimistic uptate (je mets à jour la vue immédiatement) puis au moment où l'écriture se fait réellement en base, s'il y a eu un problème, je rollback.
Dans le pire des cas, je passerai sur un SQL tradi. J'attends de voir les tests avec mes utilisateurs pilotes 😀
9:52 ce serait intéressant de voir la différence de performance avec drizzle ou prisma
Pour Go, il y a GORM et Go-Jet. Je vais faire le test et voir ce que ça donne niveau perfs 😉
Prisma est une catastrophe honnêtement
@@galactic_dust42 et drizzle ?
Pas d'ORM au profit du SQL, c'est oui.
SQLight c'est non : c'est très bien pour de l'embarqué, mais ce n'est pas terrible si plusieurs utilisateurs doivent écrire sur la base en même temps. Quid des transactions ?
Enfin, utiliser LIKE pour de la recherche, là encore, ce n'est pas terrible...
Pas d'accord avec ta vidéo.
Ok pour un projet perso mais jamais pour un projet "entreprise". Ton projet n'est pas scalable, c'est un vrai problème et cela peut devenir un enfer pour des équipes si un jour ton projet prend de l'ampleur. Pas d'accord avec toi sur les ORM, ils sont optimisés pour et ce peu importe ta requête. On parle quand même de lib faites par des ingénieurs Google, facebook etc...
Les frameworks c'est pas une question de CV, il y a vraiment un intérêt à l'utilisation, à l'architecture et une fluidité en équipe.
Mais ok si ton projet reste dans un garage et pour ton plaisir. Pour moi une véritable astuce de performance est par exemple de s'attaquer au cache.
Ce sont des critiques pour échanger mais sinon j'aime ton travail.
@vfb6265 Pas de problème 😉 . 100% d'accord pour la création de caches. C'est fréquemment ce qu'on a dû ajouter en poste quand une application commençait à être à genoux soit à heure fixe (quand tout le monde arrivait en début de journée par exemple), soit suite à un événement particulier qui entraînait bien plus de connexions que d'ordinaire.
Pour ce qui est des ORMs, là en revanche, je n'ai pas été convaincu. Sur au moins deux missions, on a fait machine arrière là-dessus (moins bonnes perfs que sans l'ORM). Mais si tu as des contre-exemples, je suis preneur 😀
Mon prochain projet Go utilisera probablement un framework pour comparer. Sur de grosses app, pas de framework, ce serait en effet trop de boulot. Et ça reviendrait à créer ... un framework maison, ce qui est rarement mieux que les frameworks connus.
@@codeconcept concernant le choix d'utiliser un ORM ou pas, c'est; AMHA, à mettre au même niveau que le choix du reste de ta stack, avec les même considérantions. si tu veux privilégier les perfs, tu prendras peut etre pas un ORM, tout comme tu ne choisira peut etre pas tel ou tel langage front/back.
avec ou sans ORM c'est avantage et des inconvenient des 2 cotés.
pour prendre l'exemple de c# (que je connais bien), tu peux dire "je veux des perfs" et prendre Dapper, mais (je trouve), la maintenance des query et du schema de BdD devient une tannée (AMHA) (et on va pas parler des updates...) ou dire "je privilégie la maintenance/evolution" et utiliser Entity Framework en Code First (et qui, bien utilisé, sur la majorité des select, sera pas si loin en perf que Dapper)
au final, c'est comme dans tout le reste des projets: c'est quoi tes besoins et objectifs et faire les choix appropriés.
autre ex: Sqlite, pkoi pas, mais si tu dois avec une partie reporting dans ton applis, est-ce que tu vas toujours choisir Sqlite et écrire tout un code pour faire le reporting ou, par exemple, passer sous SQLServer avec SSRS qui est déjà là expres pour ça? (tu choisi cout d'infra ou cout de dev?)
@zethoun Pour une grosse appli, je privilégie en effet sans hésiter la maintenabilité aux performances pures. Car une appli qui tombe et qu'on n'arrive pas à débugguer rapidement à cause de sa complexité ou du manque de lisibilité du code, c'est beaucoup plus gênant que quelques millisecondes grattées pour se faire plaisir sur un benchmark.
Je viens du monde de .NET/C# 😀 A l'époque, c'était surtout Entity Framework qui était utilisé. Pour tout ce qui était reporting, toute l'infra étant purement Microsoft, on utilisait logiquement MS-SQL et si je souviens bien, le trio SSAS, SSIS, SSRS. En tous cas les experts décisionnels auraient moyennement apprécié qu'on essaie des outils exotiques 😄
Pour me former par exemple à go et à Rust, j’ai utilisé que du bas niveau pas d’ORM, rien du tout et ça permet vraiment d’être plus proche de ce que veut nous faire apprendre le langage