Testa nya forumet på Happyride

Testa nya forumet på Happyride
MagerValp sa:
Jo, det är mobilen. Kraschar fliken på iOS också när det är en sida med 50 youtubeklipp. Funkar när senaste sidan bara innehåller 10-20 filmer, men sedan ballar det ur.
Klicka för att se resterande...

Hmm, men tidvis, bla tidigare i dag, funkar de trådarna utan problem. (kan ta en stund för allt att ladda, men ballar inte ur...)

Sony xperia 1V 12 GB Ram. Android 13.

Ska testa att tömma Chrome cachen
 
Testa nya forumet på Happyride
Några exempel på fel i samband med att happy hakar upp sig.
1000002777.jpg
1000002776.jpg
 
Testa nya forumet på Happyride
Jag har också upplevt att sidan låser sig, laddat extremt segt, på min IFån. Den här gången har det hållit på några veckor av och till, uppskattar jag.
 
Testa nya forumet på Happyride
Fjärdebrunn sa:
Framförallt imobilen (iOS) sidan laddar trögt, eller inte alls. Notifieringarna är speciellt svåra. Är de särskilt tunga/krångliga?
Klicka för att se resterande...

Notifieringarna har ofta problem med att ladda. Men det måste vara någon request som behandlas trögt. Omladdningen av hela sidan går i så fall ofta snabbt och då blir också notifieringarna uppdaterad.
 
Testa nya forumet på Happyride
Just nu, strax innan kl 13, så har det segat ordentligt för mig (stått och tuggat 10-15 sek för att posta inlägg eller ladda sida). Andra sajter inga problem.
 
Testa nya forumet på Happyride
Lite lustigt.

Tycker typ halva internet gått otroligt dålig senaste veckan, oavsett vartifrån jag surfar, men Happy har gått som en klocka. En liten störning igår bara, en "svara" knapp som stod still i kanske 5 sek innan man kom vidare.
 
Testa nya forumet på Happyride
Säg åt Databasen! Fortfarande väldigt segt om än tidvis lite bättre. Det hänger sig ofta om jag skall svara på ett inlägg och därför missade jag #3000 i Den Viktigaste Tråden! - som därför skall pågå i minst 1000 inlägg till. Det är alltså Databasens fel!
 
Testa nya forumet på Happyride
Pfaff sa:
Säg åt Databasen! Fortfarande väldigt segt om än tidvis lite bättre. Det hänger sig ofta om jag skall svara på ett inlägg och därför missade jag #3000 i Den Viktigaste Tråden! - som därför skall pågå i minst 1000 inlägg till. Det är alltså Databasens fel!
Klicka för att se resterande...
Vad är väl 1000 inlägg (till)?
 
Testa nya forumet på Happyride
Fortfarande segt, men bara vissa request.
Vet inte alls hur servern är uppsatt eller vilken FW som används, men kan inte låta bli att spekulera, en yrkesskada.

Har testat några gånger att när den står och tuggar klicka på "Sök", borde vara en request utan någon db-läsning, åtminstone ingen tung sådan. Den står också och tuggar. Så har det inte varit tidigare när det stått och tuggat vad jag kan minnas, då har ett nytt klick gått snabbt.

En enkel gissning är att någon request tar lång tid p.g.a. någon tung läsning, och alla processer är upptagna så ytterligare request köas. Men då kan det inte vara många processer av webservern som körs. Det känns spontant som en dålig gissning.

Något har uppenbarligen hänt. Bytt host? Uppgraderat forummjukvaran? Någon ny funktion som tar mycket kraft?
Hosten har mycket trafik, och Happy drabbas av det? Men återigen, detta kom plötsligt på något sätt.

Jag har en del erfarenhet av webapplikationer, och att det plötsligt blir segt med vissa request som i sig inte är tyngre än de som går snabbt har jag nog aldrig varit med om. Utom vid deadlock, eller nära deadlock enkelt uttryckt. Men då går andra request som inte gör samma läsning snabbt ändå.

Det närmsta jag kan komma är när jag jobbade med en applikation som använde Oracle. Det var på 90-talet och Oracle hade då (vet inte hur det är nu) någon funktion att alla anrop typ kompilerades och las i ett minne, det tog lång tid. Liknande anrop som kunde använda samma kompilerade kod gick snabbt.
Det var en bugg i programspråket vi använde som gjorde att vissa anrop rensade detta minne, och anropen fick kompileras om. Det gjorde att några standardanrop tog över 5 sekunder istf någon tiondel.

Vet inte om det finns någon motsvarighet till det idag. Men att problemet finns hos hosten eller Happyservern är klart. Och något måste ha förändrats när det här problemet dök upp.
 
Testa nya forumet på Happyride
me.I.am sa:
Det närmsta jag kan komma är när jag jobbade med en applikation som använde Oracle. Det var på 90-talet och Oracle hade då (vet inte hur det är nu) någon funktion att alla anrop typ kompilerades och las i ett minne, det tog lång tid. Liknande anrop som kunde använda samma kompilerade kod gick snabbt.
Det var en bugg i programspråket vi använde som gjorde att vissa anrop rensade detta minne, och anropen fick kompileras om. Det gjorde att några standardanrop tog över 5 sekunder istf någon tiondel.

Vet inte om det finns någon motsvarighet till det idag. Men att problemet finns hos hosten eller Happyservern är klart. Och något måste ha förändrats när det här problemet dök upp.
Klicka för att se resterande...
Oracle DB (vissa versioner i alla fall) kunde ibland byta execution plan för queries utan någon uppenbar anledning. Det kunde leda till att en query som borde ta <100 ms kunde ta sekunder eller minuter. Det var dock på varje anrop och inte sporadiskt. Har inte varit med om det på ett tag nu.

Iofs fick man mer sporadiskt resutlat med lastbalanserad DB om bara en nod fick fel execution plan.

Jag upplever mest problem när jag ska expandera Notiser-listan. Oftast är den omedelbar men ibland tar den åtskilliga sekunder.
 
Testa nya forumet på Happyride
DarkMatter sa:
Oracle DB (vissa versioner i alla fall) kunde ibland byta execution plan för queries utan någon uppenbar anledning. Det kunde leda till att en query som borde ta <100 ms kunde ta sekunder eller minuter. Det var dock på varje anrop och inte sporadiskt. Har inte varit med om det på ett tag nu.

Iofs fick man mer sporadiskt resutlat med lastbalanserad DB om bara en nod fick fel execution plan.

Jag upplever mest problem när jag ska expandera Notiser-listan. Oftast är den omedelbar men ibland tar den åtskilliga sekunder.
Klicka för att se resterande...

Det låter ju mer som det har varit tidigare, innan problemet som är nu. Då hjälpte det att klicka igen eftersom man hamnade i en annan process (eller vad man nu kallar det). Lite mysko om du inte har samma problem som flera andra upplever, eller du kanske inte hänger här lika mycket :)

Något är uppenbart fel, om inte hosten plötsligt fått problem, eller det är bytt till någon annan host, så känns det som att det måste vara något med db.

Eller om man av någon anledning dragit ner på processer. Men mönstret stämmer inte med det heller. Om det bara skulle bero på hög belastning skulle det inte vara dom här plötsliga sega requesten, då skulle svarstiderna gå lite mer upp och ner.

För något år sedan hade vi lite problem med plötsliga långa tider för vissa requests. Det visade sig vara sökningar på datumfält, de krånglade av någon anledning för att tabellerna hade 'COLLATE=utf8_swedish_ci' (MySQL), och om db-connection öppnades med 'collation: "utf8_swedish_ci"' så blev det fel, men först efter ett tag, och bara för just datum-fält, helsnurrigt. Var inte helt lätt att hitta det felet.

Min gissning hamnar nog på något strul med db ändå. Något index som rymt kanske.
 
Testa nya forumet på Happyride
me.I.am sa:
Det låter ju mer som det har varit tidigare, innan problemet som är nu. Då hjälpte det att klicka igen eftersom man hamnade i en annan process (eller vad man nu kallar det). Lite mysko om du inte har samma problem som flera andra upplever, eller du kanske inte hänger här lika mycket :)

Något är uppenbart fel, om inte hosten plötsligt fått problem, eller det är bytt till någon annan host, så känns det som att det måste vara något med db.

Eller om man av någon anledning dragit ner på processer. Men mönstret stämmer inte med det heller. Om det bara skulle bero på hög belastning skulle det inte vara dom här plötsliga sega requesten, då skulle svarstiderna gå lite mer upp och ner.

För något år sedan hade vi lite problem med plötsliga långa tider för vissa requests. Det visade sig vara sökningar på datumfält, de krånglade av någon anledning för att tabellerna hade 'COLLATE=utf8_swedish_ci' (MySQL), och om db-connection öppnades med 'collation: "utf8_swedish_ci"' så blev det fel, men först efter ett tag, och bara för just datum-fält, helsnurrigt. Var inte helt lätt att hitta det felet.

Min gissning hamnar nog på något strul med db ändå. Något index som rymt kanske.
Klicka för att se resterande...
Märkte att jag också ser problem med att ladda bilder ibland. Man ser bara filnamnet en stund innan bilden plötsligt uppenbarar sig.
 
Testa nya forumet på Happyride
MtbIte sa:
@JohanA Verkar ju inte få tummen ur att fixa problemet.

@me.I.am du får fixa det så får du fakturera dom för arbetet ?
Klicka för att se resterande...

Jag gör mig bäst från sidlinjen :) Allt verkar väldigt enkelt då, hade det varit så enkelt hade det nog redan varit löst.

Kan helt enkelt inte låta bli att spekulera, det är såna problem som gör jobbet roligt. Men hade det varit jag som jobbade med det hade jag nog mest stört mig på inlägg som mina...
 
Testa nya forumet på Happyride
Är inte insatt i hur det är uppsatt förut men tidigare när vi hade liknande problem så var det VM-hosten vi delade med andra som tidvis hade för hög belastning.
 
Testa nya forumet på Happyride
jomper sa:
Är inte insatt i hur det är uppsatt förut men tidigare när vi hade liknande problem så var det VM-hosten vi delade med andra som tidvis hade för hög belastning.
Klicka för att se resterande...

Är det något som ändrats där? Annat avtal? Bytt host?
Jag upplever det som att detta kom plötsligt, från i princip inga problem till att det är ganska vanligt med problem, flera requests om dan som tuggar i ett antal sekunder.
 

Senaste inläggen

Köp & Sälj

Ny annons

Artiklar

Tillbaka
Topp