Extremt segt att logga in på www.sj.se

Fullskärmsinfångning 2013-03-12 204327

Sedan den senaste uppdateringen av SJs hemsida www.sj.se har dom redan långa inloggningstiderna till Min Sida nu blivit extremt långa.

Idag tar det mer än 1 minut att logga in vilket skall jämföras med tex SEB och ICA Banken som jag använder mig av där inloggningstiden är någon sekund.

Man undrar varför det skall ta sådan ång tid att logga in på www.sj.se och varför det den senaste nu tar så extremt lång tid?

Kanske är det så att jag åker för mycket som gör att det tar så lång tid att logga in – men 1 minut – är det inte lite för mycket trots allt?

7 svar to “Extremt segt att logga in på www.sj.se”

  1. malakit Says:

    Jag är beredd att satsa en krona på att de inte testat med fallet att någon reser så mycket som du, framförallt inte med så många korta resor. Jag föreställer mig att de flesta som köper guldkort gör det i jobbet, och reser lite färre, men längre resor.

    SJ borde kanske införa testfallet ”ÅrskortGuldSJ” i sina prestandatester?

    • By Says:

      Känns konstigt att det skulle ha någon som helst koppling till att inloggningen är rejält slö.

      • malakit Says:

        För att de troligen går genom hela rese-historiken för att kunna presentera något ur den (”Din senaste resa”, ”Antal resta mil i år”, whatever).

        Även om historiken inte används alls just på denna del av siten, så är det inte alls osannolikt att inloggningen använder samma mjukvarukomponenter som andra delar , som faktiskt behöver historiken. Kanske den hämtas tidigt för att finnas snabbt tillgängligt i nästa steg.

        Poängen är att det är precis den typ av dumhet man lätt begår som programutvecklare när man inte har några extremfall att testa mot.

        Därför är jag faktiskt allvarlig när jag säger att de borde ta ÅrskortsGuldSJ’s resehistorik (eller simulera en likartad historik, av sekretesskäl) att testköra mot.

      • arskortguldsj Says:

        Kanske det räcker med att någon annan med inte lika stort ”syndaregister” testar att logga in.

        Går det snabbt för andra så är det min historik som gör att är segt att logga in.

        Kanske det är samma grundorsak till att bara min var fjärde bokning går att genomföra – övriga tappar kontakten med min kundprofil och måste göras om.

      • Apachez Says:

        Förfarandet som malakit beskriver är ju rent amatörmässigt om det är detta som sker vid inloggningen – å andra sidan har jag själv bevittnat sådan idioti i så kallade professionella lösningar.

        Vill man visa senaste resan så behöver man inte ladda varje objekt och låta webservern ta reda på vad som var senaste resan utan detta gör databasservern bäst. Något i stil med:

        SELECT datum, resa FROM tabell WHERE userid = ? ORDER BY datum LIMIT 1;

        Handlar om millisekunder för att få svar.

        Likaså antalet mil för i år, något i stil med:

        SELECT SUM(mil) AS antal_mil FROM tabell WHERE userid = ?;

        Vill man vara lite proaktiv så kan man batcha diverse statistik så att ev. summering inte behöver ske i samband med varje access utan hämtas från en cachetabell.

        Symptomen är vanligt förekommande bland dom som försöker sig på objektorienterad programmering utan att förstå vad dom egentligen sysslar med. Vilket kan leda till tiotusentals databasfrågor när det egentligen bara hade räckt med en databasfråga.

  2. Fredskronk Says:

    Det jag tror vi glömmer här det faktum att vi pratar om ett reseföretag. Sannolikheten att alla resor ligger i ett härligt *nixkluster med någon form av SQL-databas är försvinnande liten. Mest troligt är att all information ligger i ett storfavorit system som troligen är mellan 30-40 är gammalt och som inte alls byggdes för den trafikvolym en webbläsning ger.

    Annat segment som ofta har sina system i dessa gamla monster är banker. Nu tar jag ur minnet så fakta kan vara fel men SEB försökte för några år sedan bygga om sitt stordatorsystem till ett mordernt moln. Efter några år och typ två milliarder i sjön drog någon äntligen i handbromsen!

  3. Apachez Says:

    Då får man väl kopiera över uppgifterna till det där supersexiga *nixklustret som kör MariaDB eller dyl och så är problemet löst… 🙂

    Men med tanke på hur SJ i övrigt fungerar så tror jag inte sådana kostnadseffektiva och kundvänliga lösningar står särskilt högt upp i kurs inom SJ 😦

    Sen är jag skeptisk till att SJ skulle ha kvar gamla stordatorklustrer skrivna i Cobol med tanke på hur mycket biljetthanteringen ändrats senaste 15-20 åren. Om man jämför med banker där grunden fortfarande är oförändrad sedan bankhanteringen började gå på ström.

Kommentera

Fyll i dina uppgifter nedan eller klicka på en ikon för att logga in:

WordPress.com Logo

Du kommenterar med ditt WordPress.com-konto. Logga ut /  Ändra )

Google-foto

Du kommenterar med ditt Google-konto. Logga ut /  Ändra )

Twitter-bild

Du kommenterar med ditt Twitter-konto. Logga ut /  Ändra )

Facebook-foto

Du kommenterar med ditt Facebook-konto. Logga ut /  Ändra )

Ansluter till %s


%d bloggare gillar detta: