mboost-dp1
Derfor kiksede Polsag: Krævede 100.000 SQL-kald i sekundet
http://www.version2.dk/artikel/derfor-kiksede-pols...
Jeg vil starte med at sige, at jeg ikke er programmør eller IT-designer/arkitekt eller lign.
Jeg synes, at det lyder som meget at Polsag krævede 7.8 mio. HTTP-request i timen og 100.000 SQL-kald i sekundet. Til de 7.8 mio.HTTP-request krævede det så 44 processorer, mens de 100.000 SQL-kald vil kræve yderligere 60-128 processorer. Dette er med kun 13 udvalgte handlinger. Desuden fyldte forsiden vist 5.5 mb.
Polsag er åbenbart bygget over en Oracle-database med Scanjours Capita ESDH-system, der skulle tilpasses til at ligne det gamle Polsas. (se kommentarerne)
Globeteam har lavet en rapport over de tekniske mangler, og kan findes her: http://www.scribd.com/document_downloads/121767705...
Jeg spørger så, er dette normalt for et IT-projekt, eller det kun offentlige IT-projekter?
Jeg vil starte med at sige, at jeg ikke er programmør eller IT-designer/arkitekt eller lign.
Jeg synes, at det lyder som meget at Polsag krævede 7.8 mio. HTTP-request i timen og 100.000 SQL-kald i sekundet. Til de 7.8 mio.HTTP-request krævede det så 44 processorer, mens de 100.000 SQL-kald vil kræve yderligere 60-128 processorer. Dette er med kun 13 udvalgte handlinger. Desuden fyldte forsiden vist 5.5 mb.
Polsag er åbenbart bygget over en Oracle-database med Scanjours Capita ESDH-system, der skulle tilpasses til at ligne det gamle Polsas. (se kommentarerne)
Globeteam har lavet en rapport over de tekniske mangler, og kan findes her: http://www.scribd.com/document_downloads/121767705...
Jeg spørger så, er dette normalt for et IT-projekt, eller det kun offentlige IT-projekter?
thimon (1) skrev:Jeg spørger så, er dette normalt for et IT-projekt, eller det kun offentlige IT-projekter?
Hvis det var normalt for IT projekter, så ville IT projektor normalt fejle :op
En normal del af at designe et IT system er at analysere hvilke opgaver der skal udføres og hvilken belastning det vil have på systemet.
Uden at have viden om hvordan Polsag har fungeret, så lyder det som et meget dårligt design, når der udføres så mange requests for en relativt simpel opgave.
Det skal dog siges at antallet af requests kan høre sammen med urealiserbare krav, såsom at systemet skal integrere med andre eksisterende systemer, som ikke egner sig til at blive integreret med.
Offtopic: Hvem er det som har fundet på at scanne et tekstdokument ind i en PDF fil, i stedet for at gemme tekstdokumentet som PDF?
Mort (4) skrev:
Offtopic: Hvem er det som har fundet på at scanne et tekstdokument ind i en PDF fil, i stedet for at gemme tekstdokumentet som PDF?
Enten version2 eller det offentlige, men med de overvældende beviser for deres himmelråbende inkompetence vil jeg gætte på det offentlige
For en der har erfaring med Scanjours ESDH-system kommer det ikke som nogen overraskelse.
Hver gang man skal lave et opslag (som jo er hele pointen med et ESDH-system), laver den ikke bare et SQL-kald for at indlæse de nødvendige data, den laver utallige SQL-kald til metadata tabeller for at forstå dens egen datastruktur.
Det ligner lidt at de har brugt et databasesystem til at lave deres eget databasesystem.
Hver gang man skal lave et opslag (som jo er hele pointen med et ESDH-system), laver den ikke bare et SQL-kald for at indlæse de nødvendige data, den laver utallige SQL-kald til metadata tabeller for at forstå dens egen datastruktur.
Det ligner lidt at de har brugt et databasesystem til at lave deres eget databasesystem.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Software
Gå til bund