En als jij in 2022 nota bene een server nog ST opzet, dan ben je dus een voorbeeld van zo'n software ontwikkelaar die achtergebleven is. Een server moet al heel lang meerdere gebruikers in parallel ondersteunen. Dan is het zo goed als gratis om twee acties van één gebruker in parallel ook te ondersteunen.
Sorry maar je uitleg riekt van een probleem met begrijpend lezen. Ik heb een hekel aan mensen dat proberen te argumenten terwijl ze volop het probleem negeren. Voor iemand dat zogezegd in MT programmeerde, toon je enorm weinig kennis van de problemen.
De server draait niet in ST! Je weet toch dat je HTTP server in MT draait maar de request per user in de praktijk een ST is right?
Een specifieke
taak welke in ST draaide, werd tegen hoge kosten ( dev uren = hoge kosten ) omgezet naar MT voor meer performance te geven aan de eind gebruiker.
Het "simpel" omzetten van ST naar MT, opende heel wat problemen. Daarom zijn veel ontwikkelaar eerder ST focust dan MT.
En 32 cores op 100%? Gefeliciteerd. Het is een server; het doel daarvan is om werk te verrichten. Dat je CPU's geen cycles versplillen is een positief iets. 32 cores op 50% zou betekenen dat alles dubbel zo lang duurt. Een kunstmatige limiet op 4 cores betekent dat alles onnodig 8 keer zo lang duurt.
32 Core op 100% voor 1 gebruiker is idiooooooot. Want dat betekend dat al je andere gebruikers op datzelfde moment hinder ervaren.
Je moet limieten inbouwen in sommige MT of 99% van je gebruikers gaan klagen "waarom is de at random, de website traag???? Slechte gebruikers ervaring, we gaan naar concurrent!".
Snap je hoe dom je uitspraak overkomt. Je wilt nooit je server op 100% draaien want dan heb je geen rek als meerdere gebruikers taken uitvoeren. We hebben de boel op 4 CPU cores gezet omdat dit de beste balans was vs 1GB upload van de eind gebruiker. Aka wat de server goed kan processen zonder de rest van de gebruikers te beïnvloeden en tegelijk nog altijd "rek" heeft, als meerdere mensen ( MT op MT ) uploads op hetzelfde moment doen.
SQL databases zijn ook standaard server technologie; ook die kunnen al decennia tegen meerdere gebruikers.
SQL databases zijn standaard technologie bla bla .. Het gaat hem niet om meerdere gebruikers maar het feit dat je MT code ervoor kan zorgen dat je duplicate entrees krijgt. Gebruiker X upload "The Punisher". Serie bestaat niet in de databank. Je checkt, nowp. Je zegt Insert die serie. Mooi, weinig kans op een probleem. De kans dat 2 gebruikers op hetzelfde moment, dezelfde serie uploaden is zo klein, dat het nutteloos is om locks voor in te bouwen.
Maar in MT kan je voorhebben dat je in parallel:
* Upload 1: Serie (Ep01) "The punisher" bestaat?
* Upload 2: Serie (Ep02) "The punisher" bestaat?
* Upload 2: Response: Nee
* Upload 2: Maak serie "The punisher" aan.
* Upload 1: Response: Nee
* Upload 1: Maak serie "The punisher" aan.
Dat is niet de databank fout maar het probleem dat je meer kans hebt op duplicatie data te processing met MT. De kans om hetzelfde voor te hebben met ST is zo kleine, dat het de moeite niet waard is.
Het gevolg is dat je kan zagen dat mensen niet genoeg MT gebruiken in hun code, maar waar ik effen aanhaalde hoeveel meer werk en bugs/issues MT code kan veroorzaken voor de ontwikkelaars. Laat staan dat je dan lock/unlocks moet beginnen toe te passen enz.
Ik ga men woorden niet meer vuil aan maken, want je wilt argumenteren voor te argumenteren blijkbaar. MT heeft nut maar het verhoogt de kosten exponentieel en moet ingezet worden waar het nuttig is, en niet zonder limieten. En het kan bug veroorzaken waar je niet aan dacht. Ergo, mensen hebben meer schrik van MT programmeren en waarom er best nog veel apps zijn waar ST performance meer helpt dan MT.
En ja phone argument is ook halfbakken want de meeste phones deze dagen zijn een mix van Fast Core, Medium Core en Slow cores. Waar je task balancing moet uitvoeren tussen ST/MT voor de beste ervaring. MT is niet de oplossing voor alle problemen, net zoals ST niet de oplossing is voor alle problemen. Maar MT is duidelijk duurder als oplossing. En dat hebben we nog altijd niet opgelost in software. Zelf in talen zoals Go, dat uitsteken concurreny ingebouwd heeft, ontsnap je niet aan de issues van MT en de hogere kosten dat dit met zich meebrengt vanuit developer PoV.