[Wisk:AVG en STD] Standaard afwijking groter dan gemiddelde

[MacNetron]

Bij het analyseren van een performance probleem in mijn applicatie heb ik tijden (in seconden) gelogd van diverse verwerkingen.

Een van de taken logt over 1000x werk: AVG=2.39 ; STDDEV=1.12
Met de kennis van normaal verdelingen (95% binnen 2 stand.afwijkingen) weet ik dus vanaf hoeveel seconden ik die 2.5% kan loggen die dus erg lang duurt. (2.29 + 2*1.12)

Een andere taak logt (over 1000x werk): AVG=0.27 ; STDDEV=0.47
Ai, de standaard afwijking is hier groter dan het gemiddelde. Hier spelen dus erg interessante dingen af.
Maar hoe bepaal ik nu vanaf welke tijd ik extra wil gaan loggen om te kijken waarom die taak zo lang bezig is? Ik wil immers ook weer niet te veel loggen...

[Twieka]

Dit is niet een normaal verdeling, immers kun je hier niet twee standaard deviaties onder het gemiddelde zitten. Dat zou betekenen dat je programma er negatieve tijd over doet om af te ronden. Ik verwacht eerder dat er een aantal uitschieters naar boven zitten, maar dit is je reinste speculatie. Je kan bv. een histogram plotten om wat meer inzicht te krijgen hoe de tijden verdeeld zijn.

[MacNetron]

Ik was al bang voor je opmerking dat dit geen normaal verdeling is.
Kansrekening was nooit mijn favoriete vak

Er zitten inderdaad uitschieters naar boven in, en die wil ik juist analyseren om te zien waarom.
Mijn idee was het gewoon benaderen als een normaal verdeling zodat ik met die 68% en 95% regels de uitschieters naar boven eruit kan vissen.

Als ik zoek naar omzetten van de data naar normaal verdeling, dan kom ik de term Box-Cox tegen.
Echter, ik vind ook de opmerking dat de data vervuild kan zijn.
Dat is hier ook wel een beetje waar. De taak met STD>AVG verwerkt meerdere varianten.
Ik denk dat ik deze eerst moet opsplitsen naar aparte tijd-logs, want ik zit dus nu eigenlijk appels met peren te vergelijken
Als dat gedaan, verwacht ik stiekem dat het STD>AVG -fenomeen ook verdwenen is.

[ Voor 9% gewijzigd door MacNetron op 16-10-2017 08:32 ]

[fiftyhillswest]

Eigenlijk wat je dus wilt is het vinden van uitschieters in data. Waarom gebruik je dan geen algoritme om outliers te vinden zoals RANSAC. Als je het echt statistisch wilt benaderen zou je kunnen kijken naar de Mann-Whitney U-test. Deze werkt onhafhankelijk van je verdeling en bepaalt grof gezegd of twee samples uit dezelfde verdeling komen.

[MSteverink]

Je kunt natuurlijk de statisticus gaan uithangen, maar ik vraag me af of dat in dit geval nodig is. Je vraag is namelijk ...Maar hoe bepaal ik nu vanaf welke tijd ik extra wil gaan loggen... Met andere woorden, je wilt een grens bepalen.
Er zijn eenvoudiger methoden.

1. Gebruikers ervaren een wachttijd van 5 seconden als lang. Dan is 5 seconden dus je definitie voor die grens.
2. Of, als je het een beetje statistisch wilt doen: op basis van de huidige metingen weet je dat 95% van de processen binnen zoveel tijd is afgerond. dan is die 95% grens je grens.

Het interesseert je eindgebruikers weinig of dit onderzoekje aan de statistische normen voldoet. Of wil je erover gaan publiceren?

[MacNetron]

Ik vraag me af of de RANSAC niet een beetje zijn doel voorbij schiet?
Ik wil met een soort van least-effort een voorspelling doen van wat ik als "dit duurt echt te lang, ga analyseren" kan classificeren.

Op piek momenten lees ik in een uur 16000+ messages van een queue. Dat zijn er 4.4 per seconde, ofwel idealiter mag mijn verwerker er 0.225 seconden over doen.

Door die paar te selecteren die significant lang duren en te versnellen, daar zal de hele set van profiteren.
Maar ik log enkel de tijden, bij 1000 bereken ik AVG en STDDEV, log ik en gooi de boel weer weg. Anders zit de database zo vol.
Die statistieken wil ik bij de volgende 1000 gebruiken om een klein aantal super trage te kunnen "voorspellen" (lees: bericht ook loggen ter analyse/debugging)

[MSalters]

Het is goed voorstelbaar dat de verdeling zo ongebruikelijk is omdat je twee verdelingen optelt: 1 voor de normale situatie waarin een bericht goed verzonden wordt, en een andere verdeling in het geval dat er een probleem is.

Overigens kun je onafhankelijk van de verdeling stellen dat maximaal N^-2 van je berichten meer dan N*STDDEV vertraagd is. Dus voor je tweede case weet je dan maximaal 1% van de berichten meer dan (0.27+10*0.47) seconde vertraagd zijn.

[MSteverink]

MacNetron schreef op maandag 16 oktober 2017 @ 13:09:
Door die paar te selecteren die significant lang duren en te versnellen, daar zal de hele set van profiteren.

Dat is nog maar de vraag.
Als er een situatie is die 100 seconden duurt, en die weet je te optimaliseren tot 1 seconde, dan heb je 99 seconden gewonnen. Maar die situatie doet zich misschien maar één keer voor.
Als er een situatie is die 2 seconden duurt, en je weet die te optimaliseren tot één seconde, dan heb je 1 seconde gewonnen. Maar die situatie doet zich heel vaak voor.

Het kan(!) de moeite waard zijn om je niet te concentreren op die heel zeldzame langdurige uitschieters, maar juist op situaties die heel vaak voorkomen. Daar is de meeste winst te halen.

[MacNetron]

Ik vrees dat ik toch wat gedetailleerder op de situatie moet in gaan om te verduidelijken waarom ik de uitschieters wil versnellen:

De verwachting dat het versnellen van de uitschieters alle berichten versneld is gebaseerd op het feit dat de structuur van de messages voor de verschillende types gelijk is.

Elite:Dangerous Data Network ZeroMQ json-berichten.
Groot Journal, event "FSDJump" bericht:

code:

{"header": {"softwareVersion": "2.4.4.0", "gatewayTimestamp": "2017-10-18T12:37:01.925383Z", "softwareName": "E:D Market Connector [Windows]", "uploaderID": "a27690728d2543b6ab29e3ef3a615ff0"}, "$schemaRef": "https://eddn.edcd.io/schemas/journal/1", "message": {"StarSystem": "LHS 3899", "SystemFaction": "LHS 3899 Crimson Bridge Ind", "timestamp": "2017-10-18T12:37:00Z", "SystemSecurity": "$SYSTEM_SECURITY_low;", "SystemAllegiance": "Federation", "SystemEconomy": "$economy_Military;", "StarPos": [-32.25, -40.094, 5.281], "Factions": [{"Allegiance": "PilotsFederation", "FactionState": "None", "Influence": 0.0, "Name": "Pilots Federation Local Branch", "Government": "Democracy"}, {"Name": "ZZ Piscium Bridge Commodities", "Government": "Corporate", "Influence": 0.009901, "Allegiance": "Federation", "PendingStates": [{"Trend": 1, "State": "Boom"}], "FactionState": "War"}, {"Name": "LHS 3899 Jet Syndicate", "Government": "Anarchy", "RecoveringStates": [{"Trend": -1, "State": "Boom"}], "Influence": 0.139604, "Allegiance": "Independent", "PendingStates": [{"Trend": 0, "State": "Famine"}, {"Trend": 0, "State": "War"}], "FactionState": "None"}, {"Name": "Abi Progressive Party", "Government": "Democracy", "Influence": 0.139604, "Allegiance": "Federation", "PendingStates": [{"Trend": 0, "State": "War"}], "FactionState": "Boom"}, {"Name": "LHS 3899 Crimson Bridge Ind", "Government": "Corporate", "Influence": 0.486139, "Allegiance": "Federation", "PendingStates": [{"Trend": 1, "State": "Boom"}], "FactionState": "None"}, {"Name": "Revolutionary Party of Iota Piscium", "Government": "Democracy", "Influence": 0.113861, "Allegiance": "Federation", "PendingStates": [{"Trend": 1, "State": "Boom"}], "FactionState": "None"}, {"Allegiance": "Independent", "FactionState": "None", "Influence": 0.064356, "Name": "Lords of LHS 3899", "Government": "Feudal"}, {"Name": "Union of LHS 3899 League", "Government": "Confederacy", "Influence": 0.046535, "Allegiance": "Federation", "PendingStates": [{"Trend": 0, "State": "Outbreak"}], "FactionState": "War"}], "event": "FSDJump", "SystemGovernment": "$government_Corporate;", "Population": 23634}}

Klein Journal, event "FSDJump" bericht:

code:

{"header": {"softwareVersion": "2.4.4.0", "gatewayTimestamp": "2017-10-18T12:36:49.689759Z", "softwareName": "E:D Market Connector [Windows]", "uploaderID": "a3964cfc3e3b402a8296406a008f1fea"}, "$schemaRef": "https://eddn.edcd.io/schemas/journal/1", "message": {"StarSystem": "Pleiades Sector MN-T c3-15", "timestamp": "2017-10-18T12:36:42Z", "SystemSecurity": "$GAlAXY_MAP_INFO_state_anarchy;", "SystemAllegiance": "", "SystemEconomy": "$economy_None;", "StarPos": [-79.531, -144.625, -288.656], "event": "FSDJump", "SystemGovernment": "$government_None;", "Population": 0}}

Ik wil van oa. dit type weten wat de uitschieters zijn. Is het echt puur de grootte? Maakt het aanwezig zijn van factions nog uit? Zit er verschil in doorlooptijd van mijn INSERT en UPDATE code?
Heb ik een bug/denkfout in algemene code of in afhandeling van extremiteit?

Zo haalde de Journal verwerking voor elk event altijd het system op uit de database. Maar van event "Scan" sla ik niks op, alleen in het randgeval dat een bekend iemand de uploader is. Aangepast en versnelling voor alle Scans.

Daarnaast, monitoring gaf aan dat op piek-momenten (vrijdag avond, iedereen zit te gamen) komen er soms meer dan 35 berichten per seconde binnen. Ik kan me dus eigenlijk niet veroorloven dat er messages tussen zitten waarvan de verwerking meer dan 7 seconden duurt