• hjem
  •  > 
  • Feil i Windows 10
  •  > 
  • Optimalisering av WordPress-bloggen din for å redusere serverbelastningen. Vi identifiserer årsaken til den økte belastningen på hosting

Optimalisering av WordPress-bloggen din for å redusere serverbelastningen. Vi identifiserer årsaken til den økte belastningen på hosting

Hei, kjære lesere av bloggsiden. God ferie!

I løpet av denne tidsperioden (omtrent en halv time) viser administrasjonspanelet en 502-feil, og selv om nettstedet er tilgjengelig for besøkende, åpnes sidene ganske sakte (fra 5 til 15 sekunder). Hvis caching ikke hadde blitt brukt på bloggen, ville de ha utstedt en 502-feil. Det eneste som hjelper er enten å starte serveren på nytt to ganger eller dumt å vente til alt løser seg.

I tillegg til tider høy belastning Søket på siden fungerer ikke og kommentarer sendes ikke, men dette er mindre ting. Generelt er situasjonen, som du forstår, ubehagelig, men ikke kritisk. Det virker tålelig, men det er irriterende - forferdelig.

Generelt krever WordPress et øye og et øye. Ja, motoren er gratis, samtidig profesjonell og rett og slett gal, men alle slags dårlige utskeielser, nei, nei, og til og med slipper gjennom. Her. Denne gangen ble jeg også fanget av «noe nytt». Dette var tre linjer med kode (eller rettere sagt, tre tjenestehyperkoblinger) igjen i overskriften på siden som genereres av WordPress:

Etter litt googling innså jeg at "dette" dukket opp i WordPress 4.4 og var nødvendig for noe (jeg har fortsatt en vag idé om hva - hvis du vet, vennligst forklar). Fordi "dette" dukket opp nylig, det var ikke mulig å Google mange fjerningsoppskrifter, og det som ble funnet fungerte på en eller annen måte skjevt (den første lenken ble slettet, men de to andre var det ikke, og de begynte å føre til samme side, koden hvorav var åpen).

Generelt bestemte jeg meg for å utsette dette foreløpig til situasjonen er avklart og oppskrifter for å "kutte av unødvendige prosesser" dukker opp. Ja, igjen, hvis det er på emnet, så fortell meg det, for disse koblingene irriterer meg virkelig. I alle fall hva de trengs til og om de er ødeleggende for bloggpromotering. Men her har jeg trukket meg tilbake for nå.

I tillegg var det også en veldig merkbar blokk i kildekoden:

Jeg husker at han var der før. Jeg husker at jeg visstnok visste før hvor den kom fra, men nå uansett hvor hardt jeg prøvde, kunne jeg ikke huske eller i det hele tatt få tak i hvor denne "skjønnheten" kom fra i bloggoverskriften (den var også til stede på andre blogger) ). Jeg nølte litt mentalt og stirret på ordet emoji i koden. jeg skrev nylig. Jeg googlet litt og ble overbevist om at ja - denne koden hjelper å vise WordPress-sider disse samme emoji-uttrykksikonene.

Fordi emoji-uttrykksikoner Jeg fikk resultatene i to eller tre artikler på det meste, så jeg bestemte meg for å fjerne denne skam, og det var derfor jeg søkte etter en oppskrift på Internett. Løsningen, som alltid i slike tilfeller, var å legge til filtre fra WordPress-temamappen du bruker. Generelt finner vi sluttpunktet til en funksjon (semikolon) og legger til flere linjer med uforståelig (for meg), men ganske fungerende kode:

Remove_action("wp_head", "print_emoji_detection_script", 7); remove_action("admin_print_scripts", "print_emoji_detection_script"); remove_action("wp_print_styles", "print_emoji_styles"); remove_action("admin_print_styles", "print_emoji_styles"); remove_filter("the_content_feed", "wp_staticize_emoji"); remove_filter("comment_text_rss", "wp_staticize_emoji"); remove_filter("wp_mail", "wp_staticize_emoji_for_email");

Dette er mest fullstendig avstengning Emoji-støtte i WordPress. Hvis du vil, la det stå i administrasjonspanelet. Det er det, etter dette var det en behagelig følelse av renslighet av koden fra alle slags forskjellige ting.

På de sidene der jeg brukte emoji, måtte jeg korrigere teksten litt. Jeg åpnet nettopp disse artiklene for redigering i administrasjonspanelet og helt i begynnelsen (kl HTML-editor, og ikke i en visuell) la til denne koden, som ble fjernet fra overskriften på alle sider:

window._wpemojiSettings = ("baseUrl":"http:\/\/s.w.org\/images\/core\/emoji\/72x72\/","ext":"..min.js?ver=4.4") ); !function(a,b,c)(function d(a)(var c=b.createElement("canvas"),d=c.getContext&&c.getContext("2d");retur d&&d.fillText?(d.textBaseline ="top",d.font="600 32px Arial","flag"===a?(d.fillText(String.fromCharCode(55356,56806,55356,56826),0,0),c.toDataURL( ).length>3e3):("simple"===a?d.fillText(String.fromCharCode(55357,56835),0,0):d.fillText(String.fromCharCode(55356,57135),0,0 ),0!==d.getImageData(16,16,1,1).data)):!1)funksjon e(a)(var c=b.createElement("script");c.src=a, c.type="text/javascript",b.getElementsByTagName("head").appendChild(c))var f,g;c.supports=(simple:d("simple"),flag:d("flag" ),unicode8:d("unicode8")),c.DOMReady=!1,c.readyCallback=function() (c.DOMReady=!0),c.supports.simple&&c.supports.flag&&c.supports.unicode8|| (g=function())(c.readyCallback()),b.addEventListener?(b.addEventListener("DOMContentLoaded",g,!1),a.addEventListener("load",g,!1)):( a .attachEvent("onload",g),b.attachEvent("onreadystatechange",function())("complete"===b.readyState&&c.readyCallback()))),f=c.source||() ,f .concatemoji?e(f.concatemoji):f.wpemoji&&f.twemoji&&(e(f.twemoji),e(f.wpemoji))))(vindu,dokument,vindu._wpemojiSettings); img.wp-smiley, img.emoji ( display: innebygd !viktig; kantlinje: ingen !viktig; boksskygge: ingen !viktig; høyde: 1em !viktig; bredde: 1em !viktig; margin: 0 .07em !viktig; vertikal-justering: -0.1em !viktig; bakgrunn: ingen !viktig; polstring: 0 !viktig;)

Det er det, jeg fikk tilfredsstillelse fra i det minste en delvis løsning på problemet med renslighet kildekode og fortsatte å gjøre rutinen (skrive artikler og annet tull).

Hvordan erkjennelsen kom

Dagen etter snek imidlertid tvilen seg inn - det hadde ikke vært noen feil på lenge. Det virker som om jeg har jobbet med nettstedet lenge, men 502 vises ikke i administrasjonspanelet. Det var umulig å tro på et mirakel, for jeg hadde allerede begynt å feire seieren ti ganger, og neste heng brakte meg tilbake til jorden.

Men etter å ha ventet litt til, husket jeg at når jeg lette etter en løsning for å fjerne emoji-støtte, husket jeg at denne koden dukket opp i WordPress fra og med versjon 4.2, og den kom ut akkurat på våren, da jeg begynte å få problemer. Det er ganske sannsynlig at det er akkurat det WordPress oppdatering til neste versjon og ble årsaken til utseendet til en feil med tidvis høy belastning.

I alle fall, når det gjelder timing og det faktum at problemet ikke vises etter fjerning av emoji-støttekoden, var det mulig å gjøre visse konklusjoner. Jeg laget dem og skrev dette innlegget. Hvis problemet dukker opp igjen, vil P.S. vises like nedenfor. med beklagelse over bortkastet tid (av deg på lesing, og av meg på å skrive).

Avgjørelsen viste seg å være skikkelig kjip, ifølge i det minste ser fra mitt ekstremt lave mentale klokketårn. Hvor er logikken? Jeg vet ikke, men det er fortsatt hyggelig at, om enn ved et uhell, ble den tekniske hendelsen som plaget meg i ganske lang tid mer eller mindre vellykket løst. For dette, la meg ta min permisjon. Takk for oppmerksomheten og nok en gang god jul.

Lykke til! Vi sees snart på sidene til bloggsiden

Du kan se flere videoer ved å gå til ");">

Du kan være interessert

borte venstre meny i WordPress-administratoren etter å ha oppdatert Hvor kan du laste ned WordPress - bare fra den offisielle nettsiden wordpress.org
Installere WordPress i detaljer og bilder, logge inn på WP-administrasjonsområdet og endre passordet Tom side når du ser på store innlegg (artikler) i WordPress
Redusere minneforbruk i WordPress når du lager sider - WPLANG Lite-plugin for å erstatte lokaliseringsfilen
Hvordan logge inn WordPress admin, samt endre administratorinnlogging og passord gitt til deg når du installerer motoren

Hei hei. Ofte står bloggere og webmastere overfor et slikt problem at prosjektene deres før eller siden begynner å avta fryktelig. Øker belastningen betydelig Hosting CPU, A tradisjonelle metoder Hjelper ikke med løsningen i det hele tatt. Og i dag vil jeg gjerne fortelle deg om hva du skal gjøre hvis WordPress-siden din er treg og hvordan du reduserer belastningen på serveren i dette tilfellet.

I de fleste tilfeller begynner betydelige fryser og bremser på nettstedet helt uventet, og derfor begynner panikken naturlig. I en tilstand av frykt begynner bloggere å "velge" nettstedet sitt og prøver å redde det fra dette ubehagelige problemet. Men oftere enn ikke ender en slik "redning" i fiasko, og fører til og med til riving av stedet, uten mulighet for restaurering.

Dette er faktisk svært beklagelig, spesielt hvis bloggen er mer enn ett år gammel og har samlet mye interessant og nyttige artikler, og tallene på besøksdisken blir mer og mer tiltalende for hver dag. Vil du ikke komme i en så forferdelig situasjon? Da er du veldig heldig, jeg vil gjerne beskytte deg mot dårlige ting akkurat nå, og lære deg hva du skal gjøre hvis WordPress fryser.

For bare et par dager siden kontaktet en blogger og informasjonsforretningsmann, som mange kjenner veldig godt - Dmitry Zverev, meg med en forespørsel om å se på den alvorlige stammingen på bloggen hans. Naturligvis, jeg er enig, dette er jobben min, spesielt hvorfor ikke hjelpe en god person? 🙂

Så Dmitry sendte meg alle dataene fra nettstedet og hosting, og jeg begynte å analysere det. Forestill deg, gjennomsnittshastighet Nettstedets lastetid var så mye som 13 sekunder.

Tøft, ikke sant? Hva kan jeg si, i tillegg til en slik "hastighet", var tilgjengeligheten til nettstedet dårlig, noen ganger åpnet nettstedet annenhver gang. Med et ord, den krasjet katastrofalt og nektet å fungere fullt ut. Og det mest interessante var at når du logger inn på admin-panelet var det enda flere problemer!

Dette vekket interessen min enda mer fordi jeg aldri hadde vært borti noe lignende før! «Vel, la oss prøve, jo vanskeligere det er, jo mer interessant er det,» tenkte jeg og begynte å jobbe.

Først av alt begynte jeg å analysere de aktiverte og se hvilke av dem som laster nettstedet mest. Jeg utførte analysen ved hjelp av en plugin kalt P3. Hvis noen er interessert i å lære mer om ham, abonner på bloggoppdateringer. Jeg vil definitivt skrive om dette i en av de følgende artiklene.

Dermed oppdaget jeg 2 plugins som lastet bloggen mer enn andre, disse er LeadPages og NextGEN Gallery. Men etter å ha deaktivert dem og tømt bufferen, endret absolutt ingenting. Og så begynte moroa. Jeg begynte å grave dypere og dypere for å finne den sanne årsaken til denne skammen :)

Etter litt eksperimentering og testing kom jeg til den konklusjonen at hostingen kan være årsaken til problemet. Jeg skrev til Jino support, men jeg fikk aldri noe klart svar eller hjelp. Derfor kunne jeg bare stole på meg selv og min mangeårige erfaring.

Og så, etter to dager, og mange forsøk, inkludert helt ubrukelige, ble hastigheten som følger:

Og i tillegg til dette stoppet konstante funksjonsfeil og hosters sluttet å klage på økte CPU-belastning. Hurra! Det jeg strebet etter, jeg fikk det - misjonen fullført.

Men hva gjorde jeg egentlig og hvordan klarte jeg å vinne? La oss gå i rekkefølge.

Reduserer serverbelastning

1. Først og fremst anbefaler jeg at du leser en av mine første artikler om å øke lastehastigheten til nettstedet ved å bruke. I denne artikkelen lærer du hvordan du utfører nettstedoptimalisering av høy kvalitet og effektivt øker hastigheten for fullverdig drift. Også i denne artikkelen demonstrerer jeg beste tjenester for å sjekke hastigheten.

Men noen ganger er disse tipsene ikke nok, for eksempel som i tilfellet med Dmitry. Etter å ha fullført alle fremskyndelsestrinnene fra den artikkelen, begynte siden å åpne enda verre, og hosterne begynte bokstavelig talt å blokkere tilgangen til den på grunn av betydelig overbelastning. Derfor var det nødvendig å utføre noen andre handlinger.

2. Ofte dukker bremsene opp på grunn av et script som heter WP-Cron. Dette skriptet innebygd i WordPress er ansvarlig for å planlegge oppgaver. For eksempel å legge ut artikler etter tid, automatisk rengjøring kurver, skapelse sikkerhetskopi ved hjelp av en plugin, etc.

Alt virker greit, tingen er kul og alt det der, men faktum er at Cron skaper veldig tung last på .Og noen ganger tåler hosting ikke en slik belastning og blokkerer tilgang til nettstedet. I dette tilfellet må du deaktivere dette manuset og belastningen vil bli betydelig redusert.

Men du bør forstå at handlingene du utfører i automatisk modus slutte å virke, må du gjøre dem manuelt. Men det er absolutt ingenting komplisert med dette.

Så det er flere måter å deaktivere WP-Cron. Faktum er at noen av dem (som tilfellet var i mitt tilfelle) kanskje ikke fungerer, men andre kan.

1 vei. Gå til roten til nettstedet ditt via Ftp, for eksempel gjennom FileZilla, og åpne en fil der kalt wp-config.php og legg til en ny linje:

Define('DISABLE_WP_CRON', sant);

Det anbefales å legge det til etter linjen:

Define('WPLANG', 'ru_RU');

Lagre så filen og gled deg, skriptet skal være deaktivert.

Men hvis dette ikke skjer, må du bruke følgende alternativer.

Metode 2. Igjen, i roten av nettstedet må du åpne en fil kalt wp-cron.php, finn linjen:

Ignore_user_abort(true);

og kommentere det ut (deaktiver det) med to skråstreker. Utgangen skal se slik ut:

//ignore_user_abort(true);

Vi lagrer filen og cron er deaktivert.

3. Deretter må du aktivere zlib-komprimering, som lar deg øke hastigheten på nettstedet betydelig på grunn av prosessering og komprimering php-kode. Først av alt, må du skrive til hosteren og finne ut om du har zlib-funksjonen aktivert eller ikke. Hvis den er tilkoblet, flott, men hvis ikke, slå den på. Gå deretter til header.php-filen og sett inn følgende kode helt øverst:

Vi lagrer filen og føler en betydelig hastighetsøkning.

4. Deretter er det svært viktig å optimalisere databasen ved hjelp av plugin. Gå til administrasjonspanelet, åpne "Plugins"-fanen - "Add plugin" og skriv inn "WP-Optimize" i søket, trykk Enter og installer den første plugin.

Nå er databasen vår optimalisert, og dette er nok et pluss i retning av å få fart på siden.

5. Nå er vår oppgave å beskytte bloggen mot Ddos-angrep, fordi... Det er nettopp slike angrep som ofte blir årsaken til "brainbreaking" av et nettsted. For å gjøre dette anbefaler jeg for det første å installere en plugin kalt iThemes Security, jeg vil snakke om å sette den opp i neste artikkel, og for det andre er det viktig å bruke blokkering av mistenkelige besøkende ved å bruke .htaccess.

Jeg vil ikke forklare nå hvordan jeg ser etter slike mistenkelige og ondsinnede, fordi dette er temaet i en egen artikkel, men jeg vil dele med deg en liste over IP-adresser som jeg var i stand til å samle over en tid. Det er de som må blokkeres.

God dag, kjære lesere av bloggsiden. I dag vil jeg snakke om hvordan du kan redusere belastningen på vertsserveren opprettet av . Med andre ord vil vi optimalisere denne motoren for å redusere belastningen på vertsserveren.

Men du vet hva prosjektet ditt heter, og det er slett ikke nødvendig å få tilgang til databasen når du åpner noen av sidene. Derfor, etter at du endelig har bestemt deg for valg av mal, kan du trygt erstatte kodedelene i filene som implementerer spørringer til databasen med spesifikke navn, stier osv. ().

Dermed vil vi redusere antall anrop til WP-databasen ved lasting av noen av bloggsidene, og dette er ikke mindre. La oss nå gå fra teori til detaljer og se hva som virkelig kan korrigeres.

Først må du få tilgang til temafilene dine via FTP. De ligger i mappen:

/wp-content/themes/ditt_tema_navn

La oss starte med den som allerede er nevnt ovenfor - HEADER. Jeg tror at du allerede er kjent med Filezilla og FTP-tilgang til verten er ikke nytt for deg. Hvis ikke, er det en søkeboks øverst, og det vil være nok å skrive inn ordet "filezilla" eller "notisblokk" der for å få mest mulig full informasjon for disse to ekstremt nyttige programmene.

HEADER implementerer ganske mange databaseanrop, som enkelt kan erstattes med statiske data eller slettes helt. Helt øverst vil du sannsynligvis se følgende kodebit:

spørringer på sekunder.

Som et resultat, etter å ha lastet inn siden, helt nederst (i bunntekstområdet), vil du se hvor mange anrop til databasen som ble gjort:

Lykke til! Vi sees snart på sidene til bloggsiden

Du kan se flere videoer ved å gå til ");">

Du kan være interessert

Den venstre menyen forsvant i WordPress admin etter oppdatering
Vi lager knapper for å legge til sosiale nettverk og bokmerker for en WordPress-blogg (uten plugins og skript)
Redusere minneforbruk i WordPress når du lager sider - WPLANG Lite-plugin for å erstatte lokaliseringsfilen Uttrykksikoner i WordPress - hvilke uttrykksikonkoder som skal settes inn, samt Qip Smiles-plugin (vakre uttrykksikoner for kommentarer) Slik legger du automatisk til Alt-attributtet til Img-taggene til bloggen din på WordPress (der de ikke finnes)
Hyper Cache - aktiver en caching-plugin i WordPress for å optimalisere en WP-blogg og redusere belastningen på vertsserveren

En periode på omtrent 30 dager har gått, det er ikke flere problemer med driften av nettstedet og det er ingen høy belastning på serveren, prosessoren blir ikke lenger observert. Nå skal jeg fortelle deg hvordan jeg klarte å takle den periodiske høye belastningen av WordPress på prosessoren og serveren.

Det hele startet helt spontant og hver dag ble serverens respons lengre og lengre. Så, på et tidspunkt, dukket det opp et tilsvarende kritisk varsel i Yandex nettredaktørpanel. Der en lang respons fra serveren ble indikert på nesten 40 - 50 sider på nettstedet. Alt er i orden.

Innhold i artikkelen: Høy belastning opprettet av et WordPress-nettsted på server-CPU - de viktigste symptomene på dette problemet

På siden min oppsto problemet helt spontant og i ulike tidsperioder. 100 % belastning på serverens CPU ble drevet av overganger mellom nettstedssider. Rundt den andre siden var det et kraftig hopp i ytelsen til serverprosessoren. Jeg vil merke meg at for øyeblikket har RAM praktisk talt ingen svingninger. Og antallet prosesser er helt ubetydelig og bør ikke legge en slik skadelig belastning på serverprosessoren.

De viktigste karakteristiske tegnene på arbeidsbelastning som mange nettredaktører opplever er:

  • Øke CPU-belastningsgrensen på vertsserveren.
  • WordPress begynte å skape uakseptabel CPU-belastning.
  • Toppverdier, alvorlig CPU-overbelastning på hosting.
  • Lang serverrespons, variabel verdi varierer fra 5 til 30 sekunder.
  • Overdreven belastning oppstår spontant, i forskjellige tidsperioder.
  • Nettstedet bremser ned, sidene lastes nesten ikke inn, eller denne prosessen tar veldig lang tid.
  • Nettstedet krasjer på toppnivåer.
  • WP lager en lang serverrespons, siden er ikke stabil. Under høye CPU-svingninger fungerer RAM-minnet i sin normale stabile modus.
  • Antall prosesser som påvirkes og utføres i løpet av overspenningsperioder er minimalt.
  • Streaming batch-tilgang og tilkoblinger involvert på nginx eller apache er minimale.
  • Denne anomalien oppstår flere ganger om dagen, med forskjellige intervaller. Det slutter like raskt som det begynte.

Dette er nøyaktig hva som skjedde med siden min i en måned. Et godt eksempel kan være følgende bilder:

Som du kan se, er antallet prosesser som er involvert minimalt. RAM holdes på en stabil verdi, tatt i betraktning den åpne nettleseren og et stort antall sider. Men alle CPU-kjernene jobber under kritisk belastning, og i utgangspunktet er det umulig å forstå årsaken i det hele tatt.

Hvilke metoder har jeg prøvd for å bekjempe den kritiske belastningen på CPU?

Det vanligste er at jeg gjorde meg skyldig i WP-plugins og mangel på minne. Selv om for å være ærlig, bruker motoren bare 16 MB minne av de tillatte 512 MB som jeg tildelte. Hva jeg faktisk prøvde:

  • Gjorde en fullstendig Debian-oppdatering, og renset deretter hele systemet.
  • Slettet 99 % av lagrede databaserevisjoner på VestaCp.
  • Jeg så gjennom konfigurasjonsfilene i VestaCp tjue ganger for feil.
  • Jeg fant et stort antall systemlogger i Exim-postserveren (helt slettet).
  • Jeg sjekket nettstedet for virus (det er ingen).
  • Jeg gjorde et spor til nettstedet, sjekket hastigheten på Internett-tilkoblingen.
  • På nettstedet deaktiverte jeg lagring av postrevisjoner; jeg gjorde ikke noe annet på nettstedet. Siden er optimalisert for 98 % av grunnen til å sjekke den.

Etter alle trinnene som ble tatt, ble ikke problemet løst. I løpet av måneden fortsatte stigninger og topp kritiske belastninger av WP på serverprosessoren.

Hva var egentlig problemet med WP-overbelastning på CPU, og hvordan løste jeg det?

Problemet var en WP Cron-feil. For omtrent fire måneder siden installerte jeg en plugin som hindrer motoren, temaene og plugins i å oppdatere. Den første samtalen, slik jeg forstår det, var feil i nettstedets serverlogger adressert til wp-cron.php. Feilen var i allokeringen av minne for prosessen, eller rettere sagt utilstrekkelig minne. Da jeg husket denne situasjonen, merket jeg den umiddelbart.

Hva hjalp meg:

  • Jeg installerte WP Crontrol-plugin - wp cron oppgaveplanlegger. Jeg anbefaler deg å installere det umiddelbart, en veldig god løsning.
  • Etter installasjonen så jeg en toppbelastning på omtrent 900 identiske hendelser, som, slik jeg forstår det, relaterer seg til bilder.

Den enkleste løsningen er å tilbakestille alle wp cron-hendelser til sin opprinnelige tilstand, dette gjøres i functions.php. Bare sett den inn helt i begynnelsen av filen under spørringer på sekunder.

Alternativet ovenfor vil vise informasjon om antall databaseanrop og sidelastetid. Vær oppmerksom på at informasjonen kun vil være synlig for deg. Det vil si at den bare vises når du er autorisert på siden. Det vil se omtrent slik ut:

Naturligvis kan du leke med stilene, oversette "søk i" og "sekunder", men dette er valgfritt. Personlig er jeg fornøyd med alt uansett.

WordPress maloptimalisering

Å optimalisere en mal eller et tema kommer ned til å redusere antall anrop til databasen. Siden maler er laget for å være universelle, prøver utviklere å automatisere alt. Alt dette gjøres for brukernes bekvemmelighet. Men hvis du allerede har funnet ut temaet du vil bruke, kan du allerede begynne å optimalisere det. Hele poenget er å erstatte standard PHP-kode med kall til databasen med statiske. Vi vil gjøre dette i to filer – sidetopp og bunntekst. La oss starte med den første.

Header.php-optimalisering

1. Finn koden

og endre det til navnet på bloggen din. jeg har dette

Nettsted - opprettelse og promotering av nettsteder, blogger, tjene penger på nettstedet.

2. Koden som er ansvarlig for å vise beskrivelsen, erstattes med en statisk.

3. Linjen som er ansvarlig for å skrive ut kodingen.