Squla en Microsoft Teams hebben capaciteitsproblemen bij toestroom thuiswerkers

Squla, een online omgeving voor huiswerk, heeft maandag moeite met de grote drukte van scholieren die thuis inloggen. Microsoft Teams meldde kort problemen met de afhandeling van berichten te ondervinden.

Veel gebruikers van Squla geven op sociale media aan dat het platform overbelast is en dat ze daarom niet in kunnen loggen. Bij pogingen om de leeromgeving te bereiken, krijgen ze de melding dat het erg druk is en dat ze op een later moment een nieuwe poging moeten doen om in te loggen.

Squla meldt zelf: "Wij zijn druk bezig om iedereen zo snel mogelijk weer toegang tot Squla te geven. Zodra dat het geval is, laten we het jullie weten." Squla is een platform gericht op leerlingen van basisschoolgroep 1 tot en met 8, die er spelenderwijs thuis verschillende schoolvakken kunnen oefenen. Vanaf maandag zijn alle scholen in Nederland dicht, wat tot grote drukte op het platform leidt.

Microsoft Teams heeft last van problemen op een moment dat er waarschijnlijk een toestroom van mensen die thuiswerken gaande is. Met name Europese gebruikers klagen hierover op sociale media. Microsoft meldt de meldingen over problemen met berichten bij Teams te onderzoeken. Begin maart maakte Microsoft Teams gratis voor iedereen om thuiswerken tijdens de uitbraak van het nieuwe coronavirus te stimuleren. Door de adviezen van met name Europese overheden werken veel mensen nu thuis. Niet bekend is of dat tot capaciteitsproblemen bij Teams leidt of dat er een andere oorzaak is.

Update, 12.00: Microsoft meldt de problemen met chatten via Teams verholpen te hebben.

Reacties (172)

[YdieresiS]

Ja, berichten in de chat komen weer niet aan. Vanaf 12:00 tot 15:00 ging het redelijk goed, nu is het weer drama (welke tijdzone is aan het werk gegaan).

Het is wel lastig als je allemaal zo afhankelijk bent van deze techniek en het momenteel niet goed werkt.

[mjtdevries]

welke tijdzone is aan het werk gegaan)

Oosten van de US

Maar je zou verwachten dat het merendeel daarvan op hun eigen infra in de US draait.
Tenzij bedrijven massaal voor Europa hebben gekozen vanwege GDPR.

[Reactie gewijzigd door mjtdevries op 22 juli 2024 13:37]

[La1974]

Amerikaanse bedrijven kiezen toch niet voor de GDPR?

De GDPR is toch alleen geldig voor persoonsgegevens van EU burgers en organisaties?

Een Amerikaans bedrijf dat gegevens van Amerikanen verwerkt en zijn data op een Europees datacentrum zet valt toch gewoon onder de Amerikaanse wetgeving en niet de GDPR? Andersom geldt dit volgens mij ook.

[mjtdevries]

Als je een multinational bent en voor een deel van je landen GDPR regels hebt, dan is het makkelijker om je data in Europa te stallen. Waar ik werk hebben we Teams in Europa staan en de US heeft hun data dus ook in Europa staan.
Vandaar dat er omstreeks 15:00 veel verkeer vanuit de US naar Europese cloud datacenters kan komen.

Maar voor hoeveel bedrijven dat geld weet ik niet.

[Anoniem: 1322]

Helaas kun jij voor Teams data niet bepalen waar deze data staat:
https://products.office.c...eaHeadingTemplate-bkjgypc
Multi-Geo is beschikbaar voor Exchange Online en OneDrive. Microsoft onderzoekt of Multi-Geo ook kan worden gebruikt voor andere Office 365-services.

[mjtdevries]

Je kunt in beperkte mate kiezen.
Je kunt kiezen dat al je Teams data in Europa komt te staan, of dat al je Teams data in de VS komt te staan.
Wat je niet kunt, is bepalen dat een deel van de data alleen in de UK mag staan en een deel alleen in Duitsland en een ander deel "ergens in Europa". Dat is de functionaliteit die multi-geo je biedt en dat ontbreekt in Teams.

Het is erg jammer dat Teams op dat punt zo traag/eigenwijs is.

[WillySis]

Vanaf morgen komen er nog eens flink wat gebruikers bij. Een school gaat dan namelijk starten om via teams online les te geven.
https://www.bndestem.nl/e...r=https://www.google.com/
Een school met bijna 2700 leerlingen (de krant heeft het wat naar beneden afgerond) gaat toch wel een flinke extra belasting geven.

[TWeaKLeGeND]

Druppel op gloeiende plaat neem ik zelf aan, anders mag microsoft zich diep schamen.

[Reactie gewijzigd door TWeaKLeGeND op 22 juli 2024 13:37]

[WillySis]

Het is wel een flinke druppel die binnen tien minuten compleet moet vallen. Zeker als er al problemen zijn zal deze toestroom het niet beter maken.
MicroSoft hoeft zich gelukkig niet te schamen. Vandaag (dinsdag) lijken de problemen een stuk kleiner dan maandag.

[killerdemon]

Skype for business doet ook vaag met meetings

[gooos]

Bij ons op werk bellen we zoveel mogelijk in naar Skype for Business meetings om de servers te ontlasten van de audio load. Dat bied wel wat verlichting, kan je in ieder geval met elkaar in gesprek. De screensharing neemt op zich niet zoveel bandbreedte in dus dat gebeurd nog wel maar proberen we momenteel ook tot een minimum te beperken.

[SkiFan]

Niet vreemd, is de onderliggende techniek van Teams.

[Fraaank]

Als je On-premise draait ligt dat niet aan MS zelf.

[SkiFan]

Neem aan dat het hier om hosted ging. Bovendien kun je Teams alleen maar hosted draaien, is geen on prem variant van.

[bush]

Absoluut niet. Teams is een volledige rewrite en heeft niks te maken met skype for business

[Creesch]

Tenzij je heel specifiek het chat gedeelte bedoelt (daar heb ik geen kennis van) heb je niet helemaal gelijk. Teams maakt namelijk juist erg gebruik van bestaande infrastructuur en technieken. In feite is een team binnen teams een sharepoint omgeving, voeg je een taken bord toe dan maakt het gebruik van microsoft planner, etc.

Wat teams volgens mij meer doet is bestaande losse producten en diensten integreren in één omgeving.

[Kaoh]

Maar @bush meld dat het niets met Skype for business te maken heeft. Jouw antwoord heeft het over de integratie en inzet van de SharePoint Online. De planner etc is puur plugin stijl.
Dus hij heeft best wel helemaal gelijk en jij ook
Video meetings e.d. gaan niet over de Skype for business infra.

[MadEgg]

Hier ook problemen met Squla inderdaad. Kinderen willen graag aan de slag maar het lukt niet. Veel Gateway Errors, timeouts en andere foutmeldingen.

Ze hadden dit afgelopen weekend toch best kunnen voorzien en wat servers bijschalen, in de cloud bijvoorbeeld.

[walteij]

Volgens mij draait Squla al in de cloud (amazon om precies te zijn).
De vraag is dus of de applicatie op VMs draait of in containers.
In het laatste geval is veel eenvoudiger (automatisch) op te schalen dan in het eerste geval.
Het kan natuurlijk ook zo zijn dat er al automatisch opgeschaald is tot de limiet die ingesteld was (waarvan niet werd gedacht dat deze behaald zou worden).

Het lijkt mij dat de frontend redelijk goed is opgeschaald, maar dat de backend wat meer problemen heeft.

[aequitas]

> De vraag is dus of de applicatie op VMs draait of in containers.

Dat maakt vrij weinig uit als je je omgeving goed inricht. VM's kan je bij Amazon net zo hard schalen als je netjes je AMI's op orde hebt en ELB's gebruikt.

Waar je vaak in de problemen gaat lopen zijn de databases. Die kunnen gewoon vele malen lastiger meeschalen dan applicatie nodes omdat je hier tegen CAP theorem aanloopt. Dus het zorgen dat je data beschikbaar en consistent blijft. Containers, vm's en loadbalancers helpen dan ook niet direct, je moet fundamenteel je (data) ontwerp goed op orde hebben.

[MadEgg]

Hangt van je databasetype af. Voor iets als Squla zouden ze prima nosql-databases kunnen gebruiken, die schalen nagenoeg lineair met het aantal machines wat je erop zet. Als direct consistency superbelangrijk is wordt dat iets lastiger.

[aequitas]

Een nosql database lost dit probleem niet gegarandeerd op. Zoals ik al aangaf is het belangrijk dat je goed hebt nagedacht over het ontwerp. Als je hierbij logischerwijs bij een nosql database uitkomt is dat natuurlijk een prima oplossing. Maar een traditionele relationele database is vaak net zo goed. Als je maar niet bijvoorbeeld voor elke leerling die zijn resultaat upload een table lock doet omdat je in dat request ook de eindscore aan het berekenen bent. Dan loopt alles vertraging op en kan je applicaties schalen wat je wil maar helpt dat niks.

[CMG]

Het soort DB heeft niks te maken met performance. Als ze het slim aanpakken, doen ze een vorm van sharding toepassen waardoor je gebruikers over databases kunt verdelen (e.g. userId %100 => kun je al je users over 100 databases verdelen; %1000 en dan kun je het over 1000 db's verdelen); enige wat je moet doen is zorgen dat de software daarmee om kan gaan (als je dat niet gemaakt hebt, kan dat maanden werk zijn). Overigens kun je gewoon al die databases op de zelfde server draaien en afhankelijk van load die db's migreren naar eigen servers; dan moet je zorgen dat bij het opzetten van de verbinding 'gevraagd' wordt op welke server database X draait en ben je klaar, maar, dat moet wel helemaal in je architectuur ingebouwd worden.

[MadEgg]

Je kunt prima schalen met fully ACID SQL databases maar het kost wel veel meer denkwerk en ontwerp dan NOSQL-databases.

Als je op Google Cloud Platform bijvoorbeeld Datastore of Firestore tegenover Cloud SQL zet dan hoef je bij die eerste twee eigenlijk bijna geen rekening te houden met schaalbaarheid, terwijl je bij Cloud SQL goed moet opletten of je geen deadlocks of bottlenecks introduceert. Met sharding los je maar een deel van het probleem op. Als je data relationeel of transactioneel van aard is kan SQL alsnog de juiste oplossing zijn maar dat is in heel veel gevallen ook niet aan de orde.

[aequitas]

> Je kunt prima schalen met fully ACID SQL databases maar het kost wel veel meer denkwerk en ontwerp dan NOSQL-databases.

Wat ik vaak ervaar is dat dingen die simpele oplossingen voor een complex probleem lijken vaak een paar aspecten van dat probleem vergeten op te lossen. Of dat ze die complexiteit verbergen. De complexiteit van het probleem is er namelijk nog steeds, alleen door de focus te versmallen zie je hem niet. De complexiteit komt dan vaak op een andere plek weer net zo hard terug met nieuwe problemen. Bijvoorbeeld in je applicatie of aan de kant van de gebruiker. Het is dus niet zo dat je een simpele oplossing kiest. Maar meer dat je bewust moet kiezen welke problemen je wel of niet mee te maken wil hebben. Zorg er alleen wel goed voor dat je altijd een goed beeld hebt van het gehele probleem, en je niet blind staart op simpel lijkende oplossingen.

[MadEgg]

Het moet zeker een bewuste keuze zijn. Het punt is dat ACID flink wat implicaties heeft die voor lang niet alle applicaties nodig zijn maar opschalen wel in de weg kunnen zitten. Als je die features simpelweg niet nodig hebt hoef je het ook niet aan de kant van de gebruiker op te lossen.

[Cergorach]

Dat maakt vrij weinig uit als je je omgeving goed inricht. VM's kan je bij Amazon net zo hard schalen als je netjes je AMI's op orde hebt en ELB's gebruikt.

Erm... Iedereen doet alsof al die cloudaanbieders limitless servers klaar hebben staan, dat is natuurlijk ook weer niet waar. Normaal is dat natuurlijk geen issue, maar in situaties als deze moet iedereen wel aan de online apps.

[aequitas]

Normaal kan dat ook best een issue zijn hoor. Ik heb al diverse malen meegemaakt dat de 'smaak' VM waarmee wij provisionde momenteel niet leverbaar was in een bepaalde availability zone. Dan moet je dus een andere capaciteit gebruiken of een ander type VM (c4 ipv c3 bv). En hoe goed de cloud providers je ook abstractie beloven, op hardware niveau zit er toch verschil in (type CPU architectuur en zo). Als je een OS/applicatie combi hebt die daar net een bug mee heeft merk je dat wel. De cloud is heel leuk als het werkt. Maar zorg dat je zelf flexibel kunt zijn in je oplossingen.

[Tokkes]

Amazon ondersteund sinds een aantal maanden 'serverless' RDS die meeschaalt zoals Lambda dat doet.

[MadEgg]

Ja, maar de problemen houden al uren aan inmiddels. Als de vraag de ingestelde capaciteitslimiet overstijgt hebben ze inmiddels genoeg gelegenheid gehad om die op te hogen. Naast dat het voor de thuiswerkende ouders vervelend is (zeurende kinderen ) lopen ze ook veel omzet mis of kweken ze in ieder geval geen tevreden klanten.

[Christoxz]

lopen ze ook veel omzet mis of kweken ze in ieder geval geen tevreden klanten.

Dus is de huidige situatie iets wat ze zelf liever ook hadden voorkomen.

Zulke scenarios is altijd lastig voor te bereiden, wellicht waren ze bezig met upgrade plannen, en ineens besluiten ze in het weekend een spoedoverleg te doen over de scholen.
Ook voor hun is dit een verassing geweest.

En ja, ze hadden eerder voorbereid kunnen zijn, zo ook Italie & Nederland.
We moeten keuzens maken, en maken niet altijd de juiste keuzens.

[MadEgg]

Sure. Maar zoals @walteij aangeeft lijken ze al in de cloud te draaien. Ik werk veel met de cloud als cloud / data engineer en als er iets eenvoudig en soepel opschaalt is het dat wel. En een piek van Nederlandse proporties is daarvoor geen enkele uitdaging. Ze hoeven niet over te stappen, het is alleen wat meer servers bijschalen. Natuurlijk weet ik de ins en outs van hun omgeving niet, maar het zou niet moeilijk moeten zijn gezien de aard van de dienst. Dus als dat niet schaalt is de opzet van hun systemen niet zo handig gedaan.

[Leemeijer]

Heeft misschien ook wel te maken met de vraag, wie gaat dat betalen

[MadEgg]

Nou ja, onder andere ik dus. Ik heb net €20 naar ze overgemaakt en ben ongetwijfeld niet de enige. De school heeft nog geen alternatief lesmateriaal verstrekt en je moet toch wat.

[Bongoarnhem]

Wij hebben een zoon met Squla en een zoon op een andere school waar ze werken met Ambrasoft. Ambrasoft doet het prima. Ook gaf die school wat goeie sites per mail door:

Rekenen.nl
Avi-lezen.nl
Redactiesommen.nl
Spellingoefenen.nl
Leestrainer.nl

Ik hoop dat jullie daar wat aan hebben.

[Reactie gewijzigd door Bongoarnhem op 22 juli 2024 13:37]

[supertheiz]

Toch wel bizar dat als ik dit soort domeinnamen ziet, ik tegenwoordig argwaan krijg.
Op zich is het wel logisch dat je voor avi lezen naar Avi-lezen.nl kan gaan natuurlijk, maar ik krijg op de een of andere manier visies van geknutselde sites met jaren 90 techniek enzo. Ik ga straks de site bezoeken en mijn eigen ongelijk bevestigen.

-Edit-
Site bezocht. Ik had geen ongelijk.

[Reactie gewijzigd door supertheiz op 22 juli 2024 13:37]

[Bongoarnhem]

Helaas is niks gratis....gelukkig doet Pi-hole veel filterwerk.

[Reactie gewijzigd door Bongoarnhem op 22 juli 2024 13:37]

[GekkePrutser]

Hun klanten betalen er toch al voor. Dat soort dingen moet je gewoon meenemen in je kostenplaatje.

[Leemeijer]

Ik denk dat zelden voorkomende zaken, zoals het op slot gaan van het hele land, niet meegenomen worden in wat voor planning dan ook

[Christoxz]

Heb zelf op die manier geen ervaring met cloud, maar kan het zeker begrijpen.

Maar als het zo makkelijk is, waarom zou het dan nog niet zijn gebeurd?
In deze situatie wilt Squla natuurlijk nooit in terecht komen en zo snel mogelijk uit.
Niet goed voor de klanten ervaring, niet goed voor de (toekomst)omzet etc)

Kortom het is blijkbaar toch wel wat meer moeite dan alleen even de capaciteit verhogen.
Zoals @PageFault al suggereert, hoeven dit niet altijd technische beperkingen te zijn, maar speelt er genoeg om heen.

Anyway, hopen dat het snel is opgelost voor deze 'bizare' tijden.

[Reactie gewijzigd door Christoxz op 22 juli 2024 13:37]

[PageFault]

Bij Google/Amazon etc moet je betalen voor dataoverdracht, rekencapaciteit etc. Als er ineens een enorme toename is, dan zou het niet handig zijn wanneer een aanbieder ineens 100x zoveel moet betalen (en daar wellicht niet aan kan voldoen).

[GewoonWatSpulle]

als er iets eenvoudig en soepel opschaalt is het dat wel.

Dit is dus absoluut geen garantie van je applicatie in de cloud hebben, als je architectuur niet inherent schaalbaar is qua opzet komen je bottlenecks op dagen als deze ineens aan het licht, en dan even snel een applicatie wijziging doen is vaak geen wijs besluit, liever dan een 2e keer goed over de bottleneck(s) nadenken voor je weer iets live zet.

[MadEgg]

Dan heb je dus gefaald. Zeker als je al op AWS draait - waarom zou je op een cloudplatform draaien als je niet op de schaalbaarheid van je applicatie let? Draai het dan gewoon on-premise of op een VPS.

[CEx]

Omdat AWS soms voordeliger is dan on prem of VPS. Contractueel sowieso flexibeler.

[GewoonWatSpulle]

First time kinda guy, ghe ghe

[PageFault]

Of ze hebben contractueel niet alles op orde om tijdens die schaling ineens veel meer te moeten betalen.

[Kaoh]

In de cloud werken is nog niet hetzelfde als de cloud zo te gebruiken dat je ook maximaal flexibel bent en kan opschalen. De architectuur van de software moet er wel op aangepast zijn om maximaal nut uit de cloud concepten te halen. Klassieke software op een web role of VM plaatsen maakt je wel in de cloud maar niet maximaal schaalbaar.

[Arjan90]

Laten we met zijn allen vooral niet vergeten dat het bijzondere tijden zijn in plaats van ons oordeel gelijk klaar te hebben. Ook bedrijven doen hun uiterste best om alles het hoofd te bieden.

[Kevinp]

Je hebt daar zeker gelijk in. Maar dus de eerste keer dat je echt de cloud nodig hebt (wel heel extreem) gaat het mis. Ondanks dat ze het al een tijdje konden zien aankomen.

En servers bijschakelen houd natuurlijk een keer op wanneer er fysiek gewoon geen extra zijn.

Misschien in de toekomst toch een meer hybride oplossing kiezen?

[Anoniem: 310408]

Misschien in de toekomst toch een meer hybride oplossing kiezen?

Dingen opschalen als ze op je eigen servers staan is vele, vele malen moeilijker dan iets wat al op cloud servers staat. Het gaat hier niet om een paar gigabyte meer geheugen maar over vele malen meer gebruikers dan je ooit gehad hebt. Als je dat zonder problemen kan doen heb je al die tijd teveel betaald.

[K-aroq]

Nou nou, wat gaat het mis. Wij hadden vorige week vrijdag een wat mindere kwaliteit, maar dat is in het weekend allemaal prima opgelost. Ik denk dat de meeste van ons problemen niet sneller oplossen onder extreme omstandigheden.

[FilipSP]

Van al dat technische heb ik absoluut geen kaas gegeten, maar dat "konden ze al een tijdje zien aankomen" is natuurlijk wat hier een beetje aan schort. Ze zijn in amper een week tijd van een leuke gadget naar (wellicht) de backbone van ons nationale onderwijsstelsel gegaan.

[MadEgg]

Akkoord. Misschien moet ik ze maar even contacteren of ze nog extra ICT-handjes nodig hebben om de boel weer vlot te trekken

[eborn]

Dat iets in de cloud draait betekent uiteraard niet dat een applicatie oneindig op te schalen is. Het hangt er geheel vanaf of en waar je eventuele bottlenecks hebt. Als je iets in de cloud draait zodat je makkelijk HA kunt opzetten, maar maximaal maar 2 instanties van je applicatie kunt draaien, heb je er weinig aan dat je er in theorie ook 20 kunt opstarten.

[Tokkes]

Nouja, op VM's is het ook makkelijk opschalen dmv een ASG, en natuurlijk vraag je Amazon best ook even om je Load Balancer te pre-warmen voorafgaand flink grotere verkeersinstromen.

Cloud is wel fijn en schaalt inderdaad reuzemakkelijk mee maar je moet het wel goed doen dan.

[wica]

Dus is het meer een vraag van kosten. Ik neem aan dat een bedrijf als Squla niet echt meer omzet hierdoor behaald.

[thePiett]

Bijschalen in de cloud! Jij werkt zeker in de marketing? Zo eenvoudig als het klinkt is het vaak niet. Vooral niet met oudere applicaties.

[MadEgg]

Dit is geen legacy. Het draait zelfs al op AWS.

[thePiett]

mySuperCoolPHPBoard 0.1 uit 2001 krijg je ook vast draaiend op AWS. AWS is niet een een of ander stuk magic waar alles maar vanzelf schaalt.

[MadEgg]

Klopt. Maar Squla is een vrij recente dienst vanuit het huidige tijdperk van everything-as-a-service. Vroeger draaide dit soort software als applicatie op PC's in het klaslokaal of bij mensen thuis. Er is snoeihard op ingezet,o.a. door dit soort bedrijven, om iedereen ervan te overtuigen dat alles via de browser the way to go is. Dan moet je je software ook zo opzetten dat je gebruik maakt van mogelijkheden die er zijn om je bijvoorbeeld in staat te stellen om snel op te schalen.

[K-aroq]

Op applicatieniveau werkt dat prima, mits er natuurlijk voldoende cloud capaciteit is. Maar er zitten veel meer onderdelen in de keten die minder makkelijk schalen.

[mjtdevries]

Ook dat valt tegen.
CPU en memory kun je makkelijk opschalen in de cloud. IOs een stuk minder makkelijk.

[mr_evil08]

Zo snel gaat dat nou ook weer niet, het persbericht kwam pas rond 17:30, en toen was het eerst "chaos" van wat gaan we doen, om alles op te starten/processen gaat ook wel even tijd overheen.

Voor ons engineers is het inderdaad even op een knopje drukken maar er zit een heel process achter wat je dus voor gemak even vergeet.

Reken maar dat die bedrijven nu ook overbelast worden om alle verzoeken aan te kunnen voldoen.

[Reactie gewijzigd door mr_evil08 op 22 juli 2024 13:37]

[DefaultError]

De mensen die nu geen capaciteit problemen hebben zijn de kinderen/ouders die geen computer hebben. Wat is de meest haalbare instap, en is dit al eens in kaart gebracht?

[Kaoh]

Daar maak ik me ook zorgen over, ik heb twee home offices, 1 flex waar soms mijn zoon huiswerk maakt en soms ik werk en de primaire waar de thuiswerkende ouder mag werken... maar nu moet iedereen thuis werken tegelijkertijd, dus werkplekken tekort. En wij hebben dit al redelijk luxe voor elkaar. Ik zie op de NOS mensen op vensterbanken werken als home office. Schattig vandaag, maar over 3 weken zijn die mensen kapot.

[DefaultError]

Gisteren heb ik via school een huiswerk pakket meegekregen voor de komende tijd. Ik was wel verbaasd te horen, via de overkoepelende organisatie, dat 30% van de kinderen geen toegang tot internet hebben en geen gebruik kunnen maken van digitale techniek. Vandaar een huiswerkpakket opgehaald bij de school. Bedankt voor het samenstellen juf!

[Bender]

De cloud is uiteindelijk ook fysieke hardware, dat is er niet onbeperkt.

[MadEgg]

Klopt. Maar dit gaat om Nederland. Daar is zat capaciteit voor.

[mjtdevries]

Gelukkig heeft corona zich alleen beperkt tot Nederland ja.

[Vinnie2k]

Van de overheid zijn er ook al heel de ochtend problemen met het bereik van websites, oa uitvoeringarbeidsvoorwaardenwetgeving.nl heeft het moeilijk.

[Room42]

Nu helemaal omdat iedereen die site gaat checken, natuurlijk. Vroeger heette dat het slash-dot-effect.

[LocalJoost]

*slash-GoT

[jnggroot]

Hier waren er ook problemen met teams. Maar wie heeft dat domein verzonnen? Klere!

[Frankster]

Dacht dat je een grapje maakte met zo een belachelijke URL, maar hij bestaat echt

[Vinnie2k]

Dat dacht ik eerst ook toen ik de URL zag.. maar inderdaad gevalletje creabeametsitenamen.nu

[Maulwurfje]

Is de servercapaciteit of bandbreedte een probleem? Ik zat gisteren een beetje te fantaseren over wat er mogelijk kan gebeuren als iedereen massaal thuiswerkt. Zullen Netflix, YouTube etc. straks op 1080p max streamen. Zodat er capaciteit overblijft die elders ingezet kan worden. Ik snap wel dat een streaming server van Netflix niet hetzelfde is als de server waarop Teams staat, maar wel interessant om over na te denken.

[woutertje]

O.a. Netflix maar ook Youtube hebben lokale caches bij de grote providers. Voor Netflix staat daar bijv. gewoon de gehele catalogus op. Dat lost qua bandbreedte dus niet zoveel op omdat er, zeker in het geval van Netflix, praktisch geen "internet" bij komt kijken.

[i-chat]

het zou me het plaatje wel zijn dat ziggo straks, tusen 08 en 18 uur netflix tot 720p laat limiteren zodat er genoeg bandbreedte overblijft voor thuiswerk al dan niet in samenspraak met netflix youtube ea.

[Kaoh]

gelukkig is daar de netneutraliteit wet voor gestoken
Ze mogen wel segmenteren en diensten voorrang geven maar niets blokkeren en afknijpen. Ook de diensverlener zelf mag niet getarget worden.
Dus of alle video of geen.

[THA_ErAsEr]

Een cache dat bij de provider staat, moet toch nog altijd over het internet naar de eindgebruiker?

[woutertje]

Het is maar net wat je het internet noemt natuurlijk. Je blijft binnen het netwerk van je eigen provider, dus in die zin bedoel ik dat er geen sprake is van internet. Maar ik had hem al tussen quotes gezet omdat je erover kunt discussiëren.

Het lijkt mij waarschijnlijker dat er capaciteitsproblemen optreden upstream van de provider (dus van de provider naar 'het internet"). Alhoewel een blik op de AMS-IX statistieken een indicatie geven dat het allemaal zo'n vaart niet loopt.

[gooos]

Ik zat ook al aan hetzelfde te denken, zou dit kunnen leiden tot een aanpassing van de netneutraliteit in geval van grote zeer ingrijpende maatschappelijke gebeurtenissen?

In dat geval lijkt het me een logische keuze als services zoals Youtube / Netflix / Spotify / online gaming / etc als eerste geknepen gaan worden om thuis werken en thuis les volgen mogelijk te maken / houden.

[RobbyTown]

Dan zou je capaciteit problemen zijn aangezien de traffic minder is.

https://stats.ams-ix.net/index.html

Bijzonder dat er juist dan minder traffic is. Door iedereen thuis is zou de traffic juist meer worden had ik gedacht.

[Reactie gewijzigd door RobbyTown op 22 juli 2024 13:37]

[JordiGeelhoed]

Er is meer traffic als je naar die grafieken kijkt, kijk maar naar de week-grafiek.

[smiba]

Vandaag niet hoor? Waarbij het normaal over de 7Tb/s is het nu krap 6.5Tb/s

EDIT: Tja het is iets minder maar eigenlijk valt het verschil idd best wel mee.

[Reactie gewijzigd door smiba op 22 juli 2024 13:37]

[kokx]

Jawel? Kijk even goed. Normaalgezien is er op maandag altijd een trage start, en word pas later in de middag meer dan 7Tb/s gebruikt. Vergeleken met een week zitten we op dezelfde tijd nu wel iets hoger.

[ciato]

Ik ondervind wederom problemen met de chat binnen Teams.

[Quacka]

Jep veel berichten worden niet verstuurd.
Edit:
Het is overigens begrijpelijk, maar wel lastig.

[Reactie gewijzigd door Quacka op 22 juli 2024 13:37]

[SkiFan]

Webex was net ook in gesprek. Nog nooit meegemaakt.

[heval]

We probeerden vanochtend ook skype/teams meeting te houden. Het was kansloos. Ene persoon na ander werd eruit gegooid. Dus we zijn maar gestopt en proberen einde van de dag nog eens.

[FreshMaker]

We probeerden vanochtend ook skype/teams meeting te houden. Het was kansloos. Ene persoon na ander werd eruit gegooid. Dus we zijn maar gestopt en proberen einde van de dag nog eens.

Want tijdszones zijn ook afgeschaft

[bush]

hier geen problemen met teams

[walteij]

Ik weet het, N=1 in mijn geval (of misschien 2).
Maar bij mij werkt teams (zowel voor mijn werkgever als voor de opdrachtgever) probleemloos.
Kan chatten, desktop sharen, documenten in de verschillende teams openen (vanuit zowel de office webapps als een desktop applicatie).

[GORby]

Bij mij heeft Teams vanmorgen wat moelijk gedaan, met berichten die niet doorkwamen en zo. Rond de middag liep alles weer vlot, maar nu begint het weer op te spelen. Constant berichten die niet verzonden kunnen worden.

[Kaoh]

Zelfde bij mij, maar de meetings gingen juist wel goed.