Ytelsesoptimalisering

• Økte ytelsen i geografiske datapipelines 50 ganger ved å forbedre SQL‑programmeringen og datamodelleringen i PostgreSQL, MS SQL og Google Cloud BigQuery.
• Forbedret ytelsen i en geografisk kartapplikasjon 10 ganger gjennom et strategisk databaseskifte fra MSSQL til PostgreSQL, inkludert omleggingen av dataene, og optimaliserte samtidig behandlingen og datasikkerheten.
• Løste 1 000 problemer i geografiske data og tidsseriedata med GDAL, ArcGIS, PostGIS, Mapbox, QGIS, SQL (PL/pgSQL, Transact‑SQL) og Bash, og sikret behandling av stordata med høy kvalitet.
• Utformet, opprettet og administrerte 100 databaser for datavarehus i PostgreSQL, MS SQL og Google BigQuery, hovedsakelig med GIS- og tidsseriedata, og optimaliserte ytelse og skalerbarhet.
• Styrte fullstack‑utviklingen av GIS‑kart med ansvar for PostgreSQL, Mapbox, ReactJS og NodeJS, og leverte en integrert løsning.
• Fornyet interne prosesser og sparte 8 000 timer ved å forbedre programvarearkitekturen, systemene og effektiviteten i planleggingen.
• Administrerte 40 nettsteder på Ubuntu Linux‑servere for webhotell med Apache og Nginx, og sikret høy tilgjengelighet og ytelse.
• Designet en JSON‑passthrough‑arkitektur der PostgreSQL‑funksjoner returnerer komplett JSON som Go‑API‑et videresender uendret, noe som fjernet mellomliggende unmarshalling og frikoblet frontend fra skjemaendringer.
• Modellerte det maritime domenet i 348 normaliserte tabeller fordelt på 34 PostgreSQL‑skjemaer — fagfolk, selskaper, skip, stillinger, omtaler og resten — med SMALLINT‑oppslag og UUID v7‑nøkler.
• Bygde Next.js 16‑frontenden med bevisste strategier for SSR, SSG og CSR, og en gjenbrukbar fabrikk for forhåndshentede serversider som fjerner N+1‑kaskaden av hentinger fra hver autentisert side som flyttes over på den.
• Leverte full støtte for Progressive Web App — kan installeres og fungerer uten nettforbindelse — med caching under kjøring i Workbox via next‑pwa.
• Flyttet tregt arbeid ut av forespørselsbanen og over i en River‑jobbkø — 15 worker‑moduler, 8 planlagte oppgaver og 20 pg_cron‑jobber — slik at en forespørsel returnerer mens arbeidet bak den fortsetter.
• Bygde misbruksvern som stenger ved feil — 22 Redis‑baserte hastighetsbegrensere, Cloudflare Turnstile, idempotente forespørsler og en origin‑lås — slik at plattformen avviser boter og flom i stedet for å stole på dem som kaller den.
• Bygde lojalitets- og omdømmesystemet — 67 funksjoner over en hovedbok på 31 tabeller, med ligaer, merker og en innløsningsbutikk — med radlås på saldoen for å lukke vinduet for dobbeltforbruk.
• Driftet hele selskapet på én vert med én kjerne og 512 MB — en git‑forge, en webserver for sju domener, Tor, to servere for alternative protokoller, sikkerhetskopier og utestenging av inntrengere — ved å behandle 464 MB brukbart minne som den bindende arkitekturbegrensningen.
• Bygde et flerspråklig statisk nettsted i Hugo med 108 malfiler, blant dem 53 partials, som publiserer hver side i fire representasjoner fra ett innholdstre på tre språk, og på nytt under sju fokuserte underdomener bygd fra det samme treet.
• Kuttet nettstedets nettleserdrevne kvalitetsport fra 1 636 sekunder til 615 ved å kjøre kontrollene med de lengste først gjennom en worker‑pool begrenset til fire baner, etter å ha målt at alfabetisk rekkefølge kostet 320 sekunder mot 224.
• Kuttet stilarkpakken fra 87 KB til 31 KB ved å ta ut en base64‑kodet skrift, og fjernet 756 KB fordelt på 22 filer som ble publisert ved hver produksjonssetting og som ingenting refererte til.
• Bygde inn en QR‑enkoder — Reed‑Solomon over GF(256), fast moduloppsett, åtte maskemønstre — på 522 linjer i stedet for å ta inn en tredje kjøretidsavhengighet, og verifiserte den ved å lese den ferdige matrisen tilbake med en uavhengig skrevet dekoder.
• Stoppet en applikasjon som fylte minnet med 41 MB i sekundet — registrert 111 GB komprimerte sider på en maskin med 36 GB — ved å begrense hver hendelsesstrøm, abonnere etter hendelsestype og sette et frekvensbudsjett på loggingen, som tok 610 996 logglinjer ned til 1 411.
• Tok i bruk fullstendig streng samtidighet i Swift 6 uten actors, og koblet en blokkerende C‑hendelsesløkke til main actor gjennom én produsent, én konsument og én rekkefølge — etter å ha slått fast at én task per hendelse mister rekkefølgen grensesnittet er avhengig av.

Dette arbeidet er en del av det vi tilbyr som Backend- og API‑utvikling, Frontend‑utvikling, Plattform- og løsningsarkitektur, Databasedesign og datamodellering, GIS- og geodataløsninger, Utvikling av nettsteder og CMS, Pålitelighet og overvåking og Teknisk ledelse og rådgivning.

Holder du på med noe som krever dette? Ta kontakt.