Høy CPU-belastning av WordPress - prosessor, server og hosting. Optimalisering av WordPress-bloggen din for å redusere serverbelastningen
Mange WordPress-eiere stiller spørsmål: " Hvorfor skaper nettstedet mitt mye vertsbelastning?" Og hvis halvparten av disse webansvarlige skal klandre seg selv ( et stort nummer av unødvendige plugins, dårlig optimalisering), så kan den andre halvparten virkelig ikke forstå hva som skjer.
Så, korte instruksjoner for andre halvdel, hvordan redusere belastningen på hosting og ytterligere beskytte WordPress-nettstedet ditt mot hacking.
1) Lukk xmlrpc.php
xmlrpc.php er kanskje den mest unødvendige filen på siden, men den brukes ofte til å hacke siden og lage en belastning på den.
Å lagre .htaccess på nettstedet ditt (ved roten) legg til følgende:
I tillegg kan du gå til temafunksjonsfilen funksjoner.php og lim inn følgende kode:
Add_filter("xmlrpc_enabled", "__return_false");
Husk nå å fjerne spor etter denne funksjonen. Gå til filen header.php temaet ditt og slett kodelinjen som inneholder pingback og xmlrpc.php. Vanligvis ser denne linjen slik ut:
2) Lukk eller begrens administrasjonspanelet
Den andre grunnen til den høye belastningen er passordvalg. Hackere prøver å hacke administratoren din ved å lage tonnevis av forespørsler. Vi putter ekstra beskyttelse gjennom det samme .htaccess fil.
2.1) Hvis du er den eneste nettstedadministratoren med en permanent IP-adresse:
Opprett i en mappe wp-admin.htaccess-fil og lim inn i den:
Bestill nekte, tillat nekte fra alle tillat fra xxx.xxx.xxx.xxx
I stedet for X skriver vi IP-adressen din. Som et resultat vil bare du og ingen andre kunne logge på administrasjonsområdet. De vil ikke engang kunne prøve.
2.2) Hvis du ikke er fornøyd med det forrige alternativet, kan du ganske enkelt beskytte administrasjonspanelet ditt ytterligere (uten plugin):
Å lagre .htaccess Lim inn følgende i roten av nettstedet:
Site.ru - endre den til din.
Opprett en fil i roten til nettstedet (på samme sted som .htaccess) .htpasswd
Denne filen vil inneholde en ekstra pålogging og passord. Denne beskyttelsen gjøres på servernivå, så det er ganske pålitelig. Det anbefales å angi et påloggings- og passord som er forskjellig fra påloggings- og passordet på nettstedet.
Åpne filen .htpasswd og sett inn følgende linje:
Pålogging:$apr1$bHEXXPPA$zhrhn9vOOr/sdsdi3
Hvor Login er din pålogging, og deretter passordet ditt i en spesiell kryptert form.
For å generere passordet ditt i dette skjemaet kan du bruke ulike nettjenester, for eksempel: htaccesstools.com.
Som et resultat får du en ferdig linje (kryptert passord) som du må lime inn i .htpasswd
Serveren min, som vil være helten i den påfølgende historien, er en vanlig mellomklasseserver leid fra FirstDedic med en DualCore Xeon E3110 3.00Ghz-prosessor. Tilfeldig tilgangsminne 4 GB ble installert, HDD 500 GB. Serveren hadde nginx 1.01 installert som frontend, og apache 2 som backend, og kjørte skript i CGI-modus.
Historien skjedde med et nettsted som var vert på serveren min, faktisk ikke et nettsted, men en annens personlige blogg. Tidligere opplevde bloggen trafikktopper på opptil 10 000 per dag, men serveren taklet en slik belastning med et smell, absolutt uten optimalisering på standard filer konfigurasjoner.
Og så, en fin "kvinnedag", om morgenen, kommer en SMS fra en nettstedsovervåkingstjeneste om at serveren ikke er tilgjengelig. Naturligvis våkner jeg umiddelbart av slike nyheter og prøver å pinge serveren. Ping var tilstede, men veldig treg. SSH-tilkoblingen kan ikke opprettes fordi alle serverressurser er allokert til en eller flere ukjente prosesser.
Etter å ha koblet til via KVM, sendte jeg serveren for å starte på nytt, og umiddelbart etter oppstart koblet jeg til via SSH. I prosessene så jeg et forferdelig bilde: rundt 1000 løp php-prosesser på vegne av forfatteren av bloggen, i tillegg er belastningsgjennomsnittet mer enn hundre. En veldig skummel indikator som viser hvor lenge en prosess må vente på tur for en del av ressursene.
Naturligvis hadde jeg bare nok tid til å se dette ved å kjøre toppkommandoen. I løpet av et minutt sluttet serveren å svare på forespørsler, og jeg måtte starte den på nytt, og umiddelbart etter omstarten, slå av apache. Nå har jeg garantert en server som ikke bruker opp alle ressursene. Jeg begynte å analysere, jeg kom på et tall åpne forbindelser med netstat-kommandoen og ble forferdet. Det var mer enn 10.000 etablerte forbindelser med nginx. Dette betyr at det i siste øyeblikk var 10 tusen forsøk på å få tilgang til klientens nettsted - en god belastning.
Har prøvd å rote igjennom WordPress-innstillinger, selvfølgelig med klientens samtykke, oppdaget jeg at WP caching plugin var aktivert Super Cache, som jeg slått av fordi når jeg utfører den tyngste belastningen på filsystem Det var han som ga den. Etter å ha slått av plugin-en, begynte nettstedet å sende mange forespørsler til databasen - ingen overraskelse. Derfor var det første jeg gjorde å slå på query caching-systemet i MySQL, siden belastningen ble levert av bare én side, som det var mange overganger til. Etter å ha aktivert query caching, pustet databasen friere, men ikke så mye som vi skulle ønske, til tross for at hovedbelastningen nå ble levert av Wordpress selv.
Slår av alt mulige plugins og omskriving av emnet med minst antall forespørsler, ble ikke belastningen redusert. Jeg måtte gå til ekstreme tiltak- Jeg aktivert tvungen bufring av proxy-forespørsler i nginx. For å gjøre dette skrev jeg følgende linje i http-delen
Proxy_cache_path /path/to/cache levels=1:2 keys_zone=wpblog:10m max_size=10m;
I serverdelen vi trenger skriver vi:
Proxy_cache_valid 200 3m; proxy_cache wpblog; proxy_pass http://127.0.0.1:8080;
Så snart jeg gjorde dette, falt belastningen på serveren dramatisk. Vi opplevde imidlertid mange ulemper knyttet til administrasjon og kommentering. Til tross for ulempen ble problemet løst. Bevisstheten min antydet imidlertid at det ikke alltid ville være tid eller mulighet til å aktivere slik caching manuelt, og å la det være slik det var, var ikke et alternativ for bloggforfatteren. Derfor måtte vi deaktivere caching for autoriserte brukere og brukere som la kommentarer. Sluttresultatet er noe sånt som serverdelen:
Proxy_cache_valid 200 3m; plassering / ( if ($http_cookie ~* "comment_author_|wordpress_(?!test_cookie)|wp-postpass_") (sett $do_not_cache 1; ) proxy_no_cache $do_not_cache; proxy_cache_bypass $do_not_cache; proxy_cache wpblog.1 proxy.0.1 :8080; ) plassering ~* wp\-.*\.php|wp\-admin ( proxy_pass http://127.0.0.1:8080; ) plassering ~* ^.+\.(jpg|jpeg|gif|png| svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar)$ ( root /path/to/static; access_log off; utløper maks; add_header Last-Modified: $date_gmt; ) plassering ~* \/[^\/]+\/(feed|\.xml)\/? ( proxy_pass http://127.0.0.1:8080; )
Etter dette blir ulempene i arbeidet fullt ut kompensert ved uavbrutt drift.
Som et resultat av alt det ovennevnte var serveren utilgjengelig i 2 timer, i løpet av denne tiden sank trafikkflyten betydelig, men etter denne hendelsen var det andre lignende høytidsstigninger i trafikken, som nettstedet klarte å motstå uten å belaste merkbart. serveren. Siden den gang har jeg prøvd å installere denne konfigurasjonen på alle vertsbaserte WordPress-nettsteder.
Google Analytics på klientens side, etter at serveren endelig var oppe, viste 6000 besøkende på nettet. Dette tallet falt raskt fordi relevansen til forespørselen som nettstedet var øverst på søkemotorer, gikk seg vill hvert minutt. Ved slutten av dagen nådde antallet besøkende syv sifre, men eieren av ressursen ser fortsatt på meg som en ulv, fordi tallet kan være mange ganger høyere, så vel som inntekten hans.
Ved å bruke denne konfigurasjonen kan jeg med sikkerhet si at serveren overfører flere lignende nettsteder. Siden prosjektet mitt, etter å ha blitt lagt til Google News, begynte å tiltrekke seg mye trafikk, så vel som fra Yandex-blogger.
I denne artikkelen vil du lære hvordan du kan øke hastigheten på et WordPress-nettsted betydelig ved å bruke Memcached.
Trinn-for-steg instruksjon
Memcached - distribuert minnebufringssystem
Memcached cacher data og objekter direkte inn RAM-minne og reduserer tilgangstiden ekstern ressurs(f.eks. DB-kall eller API-kall). Dette hjelper spesielt dynamiske systemer, for eksempel WordPress eller Joomla!, noe som øker forespørselsbehandlingstiden betydelig.
Viktig: Før vi begynner, vil vi merke oss at Memcached ikke har innebygde sikkerhetstiltak for å jobbe med delt hosting! Denne instruksen Kun egnet for dedikert server (VPS).
Installerer Memcached
Serveren vår bruker Plesk med CentOS 7.x. Denne veiledningen gjelder imidlertid også for andre systemer, men følgende operasjoner krever bruk av verktøy som er spesifikke for ditt system. visse systemer(f.eks. apt-get i stedet for nam). For å installere Memcached bør du først og fremst koble til serveren via SSH og bruke kommandolinje:# nam installer memcached
Etter at installasjonen er fullført, skriv inn følgende kommando:
# tjeneste minnebufret start
Deretter bør du installere PECL-versjonen av Memcached for ønsket PHP-versjoner. WordPress er fullt kompatibel med PHP 7, så la oss aktivere Memcached for siste versjon PHP – 7.1. La oss starte med å installere alt nødvendige pakker for å legge dem til vår egendefinerte PHP-mod i Plesk:
# nam installer lag plesk-php71-devel gcc glibc-devel libmemcached-devel zlib-devel
Sett sammen modulen ved å følge disse instruksjonene. Du trenger ikke spesifisere Memcached-katalogen manuelt, bare trykk Enter når du blir bedt om det:
/opt/plesk/php/7.1/bin/pecl installer memcached
Det neste trinnet er å legge til en linje i den aktuelle konfigurasjonsfilen for å registrere modulen i PHP. Du kan bruke kommandolinjen uten å åpne selve filen i en editor:
# echo "extension=memcached.so" > /opt/plesk/php/7.1/etc/php.d/memcached.ini
Les til slutt PHP-behandlerne på nytt slik at modulen vises i PHP-informasjonen i grafisk meny Plesk.
# plesk bin php_handler -reread
Nå kan du ringe phpinfo()-siden for å sjekke riktig lasting Memmebufret modul:
Eller bruk kommandolinjen:
# /opt/plesk/php/7.1/bin/php -i | grep "memcached support"
Beskytt og kontroller din Memcached
Memcached bruker port 12211 som standard. Av sikkerhetsgrunner kan du omdirigere denne porten til den lokale maskinen.Legg til følgende linje på slutten av filen /etc/sysconfig/memcached og start Memcached-tjenesten på nytt:
OPTIONS="-l 127.0.0.1"
For å overvåke og få statistikk fra Memcached, bruk følgende kommandoer:
ekko "statistikkinnstillinger" | nc localhost 11211
/usr/bin/memcached-tool localhost:11211
Aktiver Memcached i WordPress
Når Memcached er installert på serveren, er den tilgjengelig for aktivering i WordPress. Først av alt må du aktivere Memcached-backend med et spesielt skript som automatisk bestemmer om du skal bruke Memcached som en caching-mekanisme.Last ned skriptet fra https://github.com/bonny/memcachy og overfør alle filene til /wp-content/-katalogen.
Hvis du ikke har endret standard Memcached-port (11211), kan du bruke den direkte. Hvis du endret det, så til wp-config.php-filen som ligger i rotkatalogen til din WordPress installasjoner, bør du legge til følgende kode:
$memcached_servers = array(array("127.0.0.1", 11211));
Nå som backend er aktivert, vil vi installere en caching-plugin for å lagre og betjene de gjengitte sidene via Memcached. Installer Batcache-plugin-modulen (https://WordPress.org/plugins/batcache/) ved å bruke installasjonsinstruksjonene:
- last ned og pakke ut arkivet;
- last opp advancaed-cache.php-filen til /wp-content/-katalogen;
- åpne wp-config.php og legg til følgende linje:
- last opp batcache.php til /wp-content/plugins-katalogen.
define("WP_CACHE", sant);
Viktig: Sørg for at Memcached er aktivert riktig for den valgte PHP-versjonen, ellers vil det å legge til denne linjen føre til en feil!
Det er alt! Nå kan du åpne advanced-cache.php og justere innstillingene som du ønsker. Batcache.php-filen er en liten plugin som regenererer cachen på artikler og sider. Ikke glem å aktivere plugin-modulen i backend på plugin-siden!
Sjekk om Memcached fungerer som den skal i WordPress
La oss nå sørge for at alle handlinger ble fullført etter behov. Det meste på en enkel måte for å bekrefte at den genererte siden blir servert fra hurtigbufferen vil bli lagt til tilleggsfelt overskriften for svaret.For å gjøre dette, må du endre filen advanced-cache.php. Åpne den og finn linjen
var $headers = array();
Erstatt den med:
var $headers = array("memcached" => "aktivert");
Åpne utviklerverktøyene i nettleseren din (F12 for Crhome), velg "Nettverk"-fanen og last inn siden på nytt noen ganger for å være sikker på at siden lastes fra hurtigbufferen og sjekk svarhodene. Hvis du ser memcached-feltet, har du lyktes!
Vær oppmerksom på at hvis du er pålogget administrativt panel nettsted på WordPress, vil ikke bufring bli brukt, og systemet vil alltid betjene den ubufrede versjonen av siden. Hvordan kan jeg sjekke funksjonaliteten til hurtigbufferen i dette tilfellet? Logg ut eller åpne ny fane nettleser i inkognitomodus og bruk utviklerverktøyene i nettleseren.
I stedet for å undersøke overskriftene, kan du sjekke kilde laster siden. Indikerer at siden ble lastet fra cache følgende linjer:
La oss gjennomføre en stresstest sammen med Blitz.io
Vi kan gjennomføre lasttesting ved hjelp av en stresstest som simulerer mange samtidige besøk til en ressurs over en viss tidsperiode. Hvis serveren din ikke er beskyttet mot økt belastning, vil den begynne å svare saktere til den ikke lenger kan behandle forespørsler. Hvis Memcached er aktivert, vil serveren vare lenger og vil ikke generere feil.
La oss kjøre noen belastnings- og ytelsestester ved å bruke Blitz.io.
Merk: for denne stresstesten vi brukte liten server med én CPU og 500 MB minne.
Stresstest uten å bruke Memcached
Resultat UTEN å bruke Memcached:
Resultatet er det samme som Varnish-stresstesten. Som du kan se, måtte vi stoppe stresstesten fordi serveren ikke var i stand til å behandle forespørsler raskere enn 5 sekunder med 50 samtidige tilkoblede brukere. Etter bare 15 sekunder sluttet serveren å svare helt.
WordPress stresstest og Memcached aktivert
Som du kan se, lar Memcached deg opprettholde serverstabilitet selv under høy belastning. Den lille testserveren motsto mer enn 400 samtidige forespørsler i mer enn 50 sekunder uten noen feil. Etter 50 sekunder og nesten 450 samtidige brukere, sluttet serveren endelig å akseptere ytterligere forespørsler. Med en kraftigere konfigurasjon vil disse tallene være betydelig høyere.
Så å bruke Memcached er en god idé for de som ønsker mer belastningstoleranse. Ved å bruke dette systemet kan du til og med sikre nettstedet ditt mot små angrep. For å beskytte serveren mot et ekte DDoS-angrep (Distributed Denial of Service-angrep), bør du bruke CloudFlare tjeneste, Kurator eller lignende filtreringssystemer.
Konklusjon: WordPress fungerer utmerket med Memcached
Memcached kan forbedre ytelsen til et WordPress-nettsted betydelig og redusere CPU-belastningen på serveren din. Den er enkel å installere og fungerer ut av esken.Oversettelse: Anton Largin (Rusonics)
Opprinnelig.
Hvordan redusere belastningen på et WordPress-nettsted på hosting og optimalisere databasen?
Jeg begynte å stille dette spørsmålet etter at Timeweb-hosting-støttetjenesten skrev til meg at nettsidene mine (det er 10 av dem på denne hostingen) legger en overdreven belastning på de sentrale vertsprosessene og databasen. Den økte belastningen skyldtes delvis et DDoS-angrep på en av sidene mine, og i tillegg til at jeg har hostet sider på denne hostingen i lang tid (mer enn 1,5 år), og det er ikke gjort noe arbeid med å rense opp søppel fra eller optimalisere databaser ikke gjennomført. Men en nettside kan til en viss grad sammenlignes med en datamaskin. Hvis du ikke renser den unødvendige filer, sprekker og annet dritt, så vil datamaskinen over tid spise opp og kreve mer ressurser, noe som vil føre til nedgang i driften, hyppig frysing. Derfor må du behandle nettstedene dine med forsiktighet og med jevne mellomrom ta skritt for å optimalisere ytelsen.
Hvordan redusere WordPress-hostingbelastningen og optimalisere databasen (MySQL)?
Jeg utførte små handlinger (som jeg vil diskutere senere), som tillot meg å redusere belastningen betydelig Hosting CPU. Generelt sett klarte vi å redusere belastningen på CPU fra 30-40 til 0,34 - 0,50, og redusere belastningen på databasen fra 90 til 64-70.
Som et resultat av handlingene som ble tatt for å optimalisere databasen (MySQL), ble størrelsen redusert fra 227 MB til 41 MB. Som vi kan se, klarte vi å oppnå betydelige resultater. Hva ble gjort for dette?
Det viser seg at alle handlinger utført i WordPress (det være seg publisering ny artikkel, det være seg å legge til en ny plugin, etc.), ha en viss effekt på databasen, øke den i størrelse. Og jo større størrelsen er, jo mer ulike filer i den, som er i uorganisert rekkefølge - jo større belastning på vertsprosessene. Ved å jobbe med å optimalisere databasen kan du derfor redusere disse belastningene betraktelig.
For å optimalisere databasen må du installere og aktivere plugin - Optimize DB (les om hvordan du installerer plugins). Gå deretter til delen "Verktøy" - finn linjen "Optimaliser DB" og følg den. Nå, for å optimalisere databasen på nettstedet ditt, er alt du trenger å gjøre å klikke på "Optimaliser nå"-knappen.
Som disse enkle trinn optimaliser WordPress-databasen din (så å si, organiser kaoset i den og legg alt på hyllene) For å forhindre at driften av denne plugin-modulen skaper ekstra belastning i fremtiden, trenger du bare å slå den av. For å optimalisere WordPress-databasen din, en gang i uken eller en gang i måneden, gå til plugins-delen, aktiver Optimize DB-pluginen og kjør MySQL-optimalisering(dette er databasen). Og så slå den av igjen.
Men for å redusere belastningen på hosting, begrenset jeg meg ikke til bare å jobbe med Optimize DB-plugin. Betydelig arbeid er gjort for å bekjempe spam. En spesielt stor mengde spam har samlet seg på flere nettsteder (totalt over 6 tusen stykker). Når jeg snakker om spam, mener jeg kommentarer av spam-karakter, hvorav et stort antall også laster hostingen. Jeg slettet mange kommentarer som ventet på bekreftelse (mer presist, for å slette dem fullstendig - jeg sendte dem først til papirkurven, og tømte deretter papirkurven), og tømte også søppelpostmappen. Inn i I det siste"Invisible Captcha"-pluginen hjelper meg mye. Takket være det sendes spam øyeblikkelig til spam-mappen, og derfra kan alle spam-kommentarer slettes umiddelbart ved å tømme denne mappen.
Jeg vil også råde deg til å installere "WP Super Cache"-plugin (hvis den ikke er installert), aktivere den og aktivere caching. Det vil være spesielt nyttig hvis mange besøkende allerede har begynt å besøke sidene dine. I prosessen installerte jeg det på et par flere nettsteder. Takket være caching reduseres også belastningen på hosting.
Slik ble arbeidet utført på 10 steder, noe som tok meg ca. 2 timer. Men jeg oppnådde målet mitt - jeg klarte å redusere belastningen på WordPress-hosting betraktelig.
Det er også verdt å merke seg at jo flere forskjellige temaer aktiveres på et WordPress-nettsted mer belastning. Bruk derfor bare de pluginene du trenger og deaktiver de du ikke bruker.
Hei hei. Ofte står bloggere og webmastere overfor et slikt problem at prosjektene deres før eller siden begynner å avta fryktelig. Belastningen på hosting CPU øker betydelig, og 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, frem til rivingen 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 tok en blogger og informasjonsforretningsmann, som mange kjenner veldig godt, kontakt med meg - Dmitry Zverev, med en forespørsel om å se de alvorlige frysene 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 av alt 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 høy kvalitet nettstedoptimalisering og dens effektive akselerasjon for fullt arbeid. 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 det opp bremser pga skript kalt 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 osv.
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 der en fil som heter 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 som heter 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 trenger du aktiver 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 til selve toppen sett inn følgende kode:
Vi lagrer filen og føler en betydelig hastighetsøkning.
4. Etter det er det veldig 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å vår oppgave beskytte bloggen din mot DDO-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.