Nylig mottok jeg en forespørsel om hjelp til å sette opp en dedikert server for å drive en nettbutikk på 1C-Bitrix. Årsaken til forespørselen er den trege driften av nettstedet.
Vi så på siden - noen sider tar faktisk mer enn et minutt å laste!!! Det første som kom til tankene når du så på nettstedet, var den suboptimale ytelsen til komponenter utviklet av en annen utvikler. Men ikke like mye...

Opprinnelige data: Server på Xeon - 2 GB minne, RAID. OS - FreeBSD. BUSS - Business.

Vel, la oss prøve å rette opp situasjonen på en eller annen måte...
La meg ta en reservasjon med en gang at denne artikkelen ikke er instruksjoner for å jobbe med modulen, bare et ekte tilfelle av bruk av modulen. Kanskje det vil være nyttig for noen.

Etter tilsynet ble følgende hovedproblemer identifisert:
1. Du må installere en PHP-akselerator på serveren
2. På /price/-siden har “nvisions:menu.sections”-komponenten store problemer - en forespørsel genereres til databasen som behandles i nesten ett minutt - dette er hovedårsaken til den lange lastetiden til siden , samt stor belastning på serveren.
3. Databasen fungerer sakte (687 skriveforespørsler per sekund er svært lite), problemet kan være i serverkonfigurasjonen. Du må konvertere tabeller til InnoDB og konfigurere InnoDB
4. Filsystemet er ikke veldig raskt, dette kan skyldes maskinvarefunksjoner på serveren (for eksempel RAID), men i prinsippet skal siden fungere bra med denne hastigheten
5. Det er et problem i nettstedsmalen (det er ikke-eksisterende lenker), den må fjernes - den krever mye ressurser.
6. Det er nødvendig å konfigurere en to-nivå arkitektur på serveren (server statisk innhold via nginx), dette vil redusere belastningen på Apache-serveren betydelig, stabilisere minneforbruket under belastninger, derfor øke hastigheten på arbeidet og øke påliteligheten til prosjektet som helhet.

La oss analysere informasjonen fra 1C-Bitrix ytelsesmodul:

Figuren viser tydelig problemer med databaseserveren, mest sannsynlig er ikke innstillingene optimale, pga dedikert server.
Antall filoperasjoner er også mistenkelig lavt.


Åpenbare problemer med koden eller komponentene på /price/index.php-siden
Mistenkelig lang generasjonstid for /bitrix/urlrewrite.php – se videre:

Ja, dette er kilden til problemene: malen inneholder en lenke til et ikke-eksisterende bilde, dette genererer en 404-feil, og tvinger Apache til å behandle denne feilen og generere en fullverdig side.

Det samme problemet påvirker alle sidene på nettstedet knyttet til den problematiske malen:


Og her er de problematiske komponentene på siden:


Menykomponenten har caching deaktivert.
Sidesammendrag:

Vel, her er en rask analyse. Hvor praktisk ytelsesmodulen forteller deg "hvor problemene er." La oss begynne å feilsøke:

Vi la til et bilde som det var en lenke til, vi la bare til et bilde, og fjernet ikke koblingene, fordi... det var mange lenker, inkludert i tredjepartskomponenter. Også på denne siden har vi deaktivert en problematisk tredjepartskomponent (nsvision:menu.sections), fordi formålet er ikke klart. (etter frakobling har ingenting endret seg eksternt)
Resultat:


Urlrewrite.php kalles nå ikke ved hvert treff



Som du kan se, har arbeidshastigheten økt med 2 ganger (!).

La oss gå videre:
Installerer akselerator. Jeg vil ikke beskrive her hvordan akseleratoren er installert, fordi... denne informasjonen, om nødvendig, kan alltid finnes på Internett.







Resultat etter installasjon av eAccelerator: Nok en dobbelt økning i produktivitet.

La oss gå videre: Optimalisering av databasen(overfør til InnoDB og optimaliser innstillingene)


Som det fremgår av ytelsesmodultesten, har hastigheten på databasen økt betydelig
Generelt forble den generelle ytelsen etter optimalisering av databasen uendret, muligens på grunn av den trege driften av filsystemet.

OPPDATER:
Anbefalinger for ytelsesmoduler.
Etter anbefalingene fra modulen deaktiverer vi parameteren "open_basedir", fordi serveren er kun dedikert til prosjektet vårt, vi mener at sikkerheten som helhet ikke vil bli kompromittert.

Resultat:

Resultatet er, som de sier, TILGJENGELIG

Alt som gjenstår er å omskrive de "skjeve" komponentene og prosjektet vil fly.

Vi har også installert og konfigurert nginx som en proxy-server for Apache. Jeg inkluderer ikke bilder, fordi... tallene har holdt seg tilnærmet uendret. Men etter subjektiv vurdering lastes sidene nå et par ganger raskere.

Malen tar fortsatt ganske lang tid å generere (genereringstiden er nesten den samme som systemkjernen) - tilsynelatende var koden ikke optimalt skrevet av den forrige utvikleren. Det er ingen tid, ikke noe budsjett, ikke noe ønske om å analysere andres kode. Det er enklere, raskere og billigere å skrive koden fra bunnen av.

Generelt: Ytelsesmodulen er et veldig nyttig og praktisk verktøy for å feilsøke driften av et prosjekt og en server. For det, takket være utviklerne.

P.S. Personlig har jeg liten erfaring med å jobbe med Linux. Jeg ble nært kjent med FreeBSD for første gang. Jeg ble overrasket over at etter å ha installert noe programvare, er konfigurasjonsfilene helt tomme (for eksempel MySQL). Jeg var fornøyd med hvor enkelt det var å installere programvaren fra "portene".

", retning "Dataoverføringssystemer".

Før vi går inn på de tekniske vanskelighetene med WAN-optimalisering, la oss finne ut hva det er og hva det er ment for.

Nylig har migreringen av IT-strukturer til en desentralisert datamodell blitt tydelig, der selskaper distribuerer sine prosesseringssentre rundt om i verden. Som et resultat har volumet av data og antall IT-ressurser som er lagret utenfor bedriftens datasentre (DC) økt, og avdelingsledere leter nå etter måter å konsolidere IT-infrastrukturen sin på. Bedrifter har innsett fordelene som konsolidering gir når det gjelder å redusere infrastrukturkompleksiteten, redusere kostnader, forbedre ressursutnyttelsen og beskytte data.

Sentralisering av ressurser og data viser fordelene beskrevet ovenfor, men det er ulike fallgruver som organisasjoner som planlegger å optimalisere IT-infrastrukturen bør huske på. Et av problemene de vil møte er tregere applikasjonsytelse. Populariteten til den distribuerte databehandlingsmodellen var i stor grad drevet av behovet for å holde IT-ressurser så nært som mulig til distribuerte nettverksbrukere for å sikre maksimal ytelse. Konsolidering av servere på en sentral plassering reverserer ressursallokeringsmønsteret og forringer derfor ytelsen til mange applikasjoner.

For å løse problemet utvider organisasjoner kapasiteten til WAN-koblinger i et forsøk på å redusere responstiden. Så oppdager de at utvidelse av kanalene praktisk talt ikke har noen (eller minimal) innvirkning på applikasjonshastigheten, siden problemet ligger i den store forsinkelsen i dataoverføringen over kanalen og bruken av protokoller som er ineffektive for arbeid med WAN. I tillegg er det kanskje ikke kostnadseffektivt å utvide båndbredden utenfor Moskva totalt sett. Og det er nettopp til slike oppgaver at WAN-kanaloptimaliseringsutstyr brukes.

Globalt kan slike WAN-optimaliseringsløsninger redusere kostnadene for organisasjoner på flere måter:

redusere kostnadene for kommunikasjonskanalens båndbredde. Faktisk vil organisasjoner klare seg uten å kjøpe ekstra båndbredde, noe som er en nøkkelbetingelse for mange bedrifter når de starter prosjekter for å implementere WAN-optimalisatorer;

konsolidere infrastruktur i et datasenter. Bedrifter vil kunne fjerne en betydelig del av IT-infrastrukturen (fil- og e-postservere, programvaredistribusjonsservere, SharePoint-portaler, båndstasjoner, etc.) fra eksterne kontorer uten tap av ytelse og administrasjon;

forenkle den eksterne kontorinfrastrukturen. Noen produsenter tilbyr en programvareplattform i enhetene sine som lar brukere være vert for noen av tjenestene som gjenstår etter konsolidering av datasenter (for eksempel utskriftsserver, DHCP-server, filtjenester) direkte på optimaliseringsenheten. Dette gjør det mulig å redusere driftskostnadene ytterligere.

Hva er WAN-optimalisering? Løsningen for å optimalisere funksjonen til nettverksapplikasjoner bruker klient-server-arkitektur og sesjonsprinsippet for nettverksapplikasjoner. Hovedoppgaven er å optimalisere applikasjonsøktene. I hovedsak er dette et sett med enheter for å forbedre ytelsen til applikasjoner installert i sentrum og på hvert regionale (lokale) kontor i selskapet. De passerer all trafikk gjennom seg selv, "avskjærer" og optimaliserer applikasjonsarbeidsøktene.

Det finnes en rekke produsenter som tilbyr løsninger innen optimering av trafikkoverføring over lange WAN-kanaler. De mest kjente av dem på det russiske markedet inkluderer Riverbed (med sitt SteelHead-produkt), Cisco (WAAS-produkt), Juniper (WXC-produkt) og BlueCoat (ProxySG-produkt).

Prosessen med å optimalisere utstyret de tilbyr er basert på omtrent de samme mekanismene, som inkluderer datakomprimering, caching, optimalisering av TCP-protokollen og optimalisering av driftslogikken til selve forretningsapplikasjonene.

Alle asom vurderes bruker øktsegmentering, og deler den mellom klienten og serveren i tre segmenter: mellom optimaliseringsenheten og arbeidsstasjonen, mellom enheter over WAN-nettverket og mellom optimaliseringsenheten og datasenteret (serveren). I det første og tredje segmentet kjører økten over LAN, og mangler i TCP-protokollen påvirker ikke programforsinkelsen. Det andre segmentet er optimalisert ved å justere TCP-hastigheten. Som et resultat er de nødvendige minimumskravene sikret: når det gjelder forsinkelse ved overføring av trafikk over WAN og i applikasjonens responstid. La oss se på mekanismene som, i en eller annen form, ligger til grunn for beslutningene til hver optimaliseringsprodusent.

Komprimeringsmekanismer er i stand til å fremskynde dataoverføringen ved å øke informasjonsinnholdet i informasjonsoverføringen per tidsenhet. Oftest presenteres data som overføres over nettverket i et ikke-optimalt format og er urimelig stort i volum. Nå, med aktiv bruk i applikasjonsutvikling, for eksempel XML eller andre språk for å presentere informasjon i tekstform, er det ingen grunn til å bekymre seg for datarepresentasjon. Dette øker hastigheten og enkel utvikling, men fører samtidig til at vesentlig ustrukturerte data overføres over nettverket, og introduserer store mengder redundans i trafikken.

Trafikkkomprimering eliminerer denne ulempen. Apbruker en tapsfri datakomprimeringsalgoritme (som Lempel-Ziv) og enme. Kombinasjonen av disse to algoritmene gjør at vi kan oppnå den høyeste graden av tapsfri informasjonskomprimering, og dermed sikre rask overføring av informasjon selv over relativt lavhastighetskanaler.

Komprimeringsfunksjonalitet, i en eller annen form, finnes i nesten alle moderne rutere, og faktisk var det her moderne optimizere begynte sin reise. Svært ofte tror nettverksadministratorer at dette er den beryktede optimaliseringen, og overbeviser lederne deres om at det ikke er nødvendig å kjøpe spesielle enheter. Og det er her de tar feil, som vi skal se senere.

Buffermekanismer også bidra til å redusere mengden overført trafikk. I et distribuert nettverk oppstår det ofte situasjoner når alle ansatte i en bedrift trenger å overføre de samme dataene. For eksempel ved oppdatering av programvareprodukter eller antivirusprogramvaredatabaser, overføring av forespørsler fra bedriftsledelsen, multimediefiler og opplæringsprogrammer, offentlige dokumentbiblioteker. Ved å bruke optimaliseringsenheter kan denne informasjonen bufres, dvs. overføres én gang over WAN, og deretter leveres til hver bruker lokalt (fra harddisken til nærmeste optimaliseringsenhet), i stedet for fra en ekstern global ressurs.

En viktig forskjell fra konvensjonelle hurtigbufferenheter er det faktum at optimerere deler informasjon i deler/blokker og lagrer dem på harddisken. Dette er interessant fra et synspunkt at hvis vi endrer noe av informasjonen i den nylig overførte filen (for eksempel setter inn et lysbilde eller et bilde i et dokument), så er det endringen som vil bli overført, og ikke hele filen . Mekanismene for dynamisk oppdeling av overført informasjon i blokker og sporing av endringer er proprietære og er ikke gjenstand for offentliggjøring. Hvis vi snakker om funksjonene til arbeidet, bruker produsentene 2 tilnærminger. Et særtrekk ved den første av dem er dens forening, dvs. når du overfører én fil til forskjellige grener, vil bare én kopi av filen bli lagret i den sentrale optimaliseringsenheten for alle eksterne optimaliseringsenheter. I det andre tilfellet deles harddiskplassen dynamisk i forhold til antall eksterne kontorer (fjernoptimalisatorer), og hvis én fil overføres til alle filialer, vil en lignende kopi gjenspeiles i hvert harddisksegment "ansvarlig" for sin gren.

Tydeligvis fungerer hurtigbuffermekanismen sammen med kompresjonsmekanismen. Det er takket være disse to mekanismene at optimeringsprodusenter viser vakre grafer der optimeringsnivået kan nå 150-200X. Vi var i stand til å skaffe de samme dataene når vi sendte den samme store datafilen flere ganger, fordi etter den første overføringen ble den lagret i enhetsbufferen, og da ble bare kilobyte med lenker som peker til filens plassering på harddisken overført. Et logisk spørsmål dukker umiddelbart opp her: hva er kapasiteten til harddisken og er det mulig å koble ekstern lagring til optimizere? Noen produsenter nevnte en gang muligheten for fremveksten av denne typen utstyr (men det vil allerede være beregnet utelukkende for installasjon i datasenteret).

TCP-optimaliseringsmekanismer arbeid på transportnivå. Dette er den viktigste "slagmarken" for optimaliseringsprodusenter før de begynte å "klatre" til høyere nivåer (applikasjon). TCP-transportprotokollen ble utviklet i 1980, og har i dag ikke gjennomgått store endringer, mens dataoverføringsteknologiene har endret seg betydelig. Når pakker går tapt, reduserer standard TCP-protokollen hastigheten kraftig - nesten halvparten, og økningen fra dette nivået skjer deretter lineært og i små trinn. Derfor fører selv et relativt lite nivå av pakketap (2-3 % av tapene anses som normalt) til hyppige og kraftige tap i nettverkshastighet.

Den optimaliserte TCP-protokollen, når et tap oppstår, reduserer hastigheten ikke med 2 ganger, men med bare noen få prosent, og med et enkelt pakketap reduseres hastigheten veldig litt. Det viser seg at løsningen for å optimalisere funksjonen til nettverksapplikasjoner først og fremst øker hastigheten på informasjonsoverføringen. Maksimal utnyttelse av hele båndbredden til dataoverføringskanaler sikres av den forbedrede operasjonsprosedyren til TCP-protokollen.

Optimaliseringsmekanismer for applikasjonsnivå tilby akselerasjon av forretningsapplikasjoner selv via WAN-kanaler. Det er implementeringen av noen protokoller i populære produkter som dessverre er langt fra perfekt. Spesielt CIFS (Common Internet File System)-protokollen, som brukes aktivt i Microsoft-nettverk, skaper et for stort volum av tjenestemeldinger (leveringsbekreftelse, enhetsberedskap, etc.). I et lokalt nettverk introduserer ikke disse overskridelsene en betydelig forsinkelse i responstiden, men i et distribuert nettverk blir de betydelige. Optimaliseringsenheter er i stand til å behandle de fleste uviktige meldinger lokalt, uten overføring over WAN, redusere mengden trafikk og redusere responstiden til en rekke nettverksapplikasjonsfunksjoner, som nettverksutskrift, tilgang til filtjenester, etc. I dag er det faktisk nettopp på dette området at produsentene konkurrerer. De mest optimaliserte protokollene inkluderer CIFS, NFS, MAPI, Video, HTTP, SSL og Windows-utskrift. Dette "herresettet" finnes i porteføljen til nesten alle produsenter, men de er optimalisert på forskjellige måter.

Av alt det ovennevnte følger det at trafikk fra kilden til mottakeren går gjennom minst to optimaliseringsenheter, og på hver av dem behandles den frem til applikasjonen.

Det er ikke vanskelig å gjette at alle optimerere fungerer med TCP-baserte applikasjoner, noe som betyr at resten av trafikken går gjennom uten optimalisering. Det samme kan sies om kryptert trafikk (unntaket er kanskje SSL - mange optimerere kan "bryte" økten, optimere trafikken og kryptere den tilbake).

Bedrifter med en distribuert struktur som ønsker å redusere kostnader for teleoperatørene kan være interessert i en slik løsning. Dette kan manifestere seg både ved bruk av per-megabyte-tariffer (effekten er åpenbar) og ved ubegrensede (bytte til lavere hastighetsplaner). I dag er dette kanskje det mest interessante formålet med å bruke slike enheter. Andre bonuser, ikke så åpenbare og gjennomsiktige, kan være: konsolidering av servere, reduksjon i antall IT-personell på eksterne kontorer, økt produktivitet på grunn av økt applikasjonshastighet.

I kampen om interessen for optimizere tilbyr produsenter også muligheter til å optimere arbeidet til mobile ansatte ved å installere spesialisert programvare på bærbare datamaskiner og muligheten til å installere virtuelle servere basert på én optimizer på et eksternt kontor. Programvare for bærbare datamaskiner ligner i kode på programvare på selve optimererne, dvs. Den bærbare datamaskinen blir som en optimizer.

I tillegg til bedrifter med distribuert struktur, kan denne løsningen også være av interesse for operatører som kan gi bedrifter optimaliseringstjenester (for eksempel utleie). Slike tjenester blir populære i Europa.

Den vanligste optimaliseringsløsningen er selvfølgelig Cisco WAAS. God leverandørmarkedsføring, en god løsning og utviklingsstrategi gjør jobben sin. Med bruken av en serie med rimelige og pålitelige WAVE, har Ciscos posisjon blitt enda sterkere.

Junipers WXC-løsning skiller seg ut ved at all trafikk pakkes inn i en UDP-tunnel, d.v.s. optimering skjer over all trafikk. Denne tilnærmingen har absolutt sine fordeler. Jeg vil inkludere en ganske høy "sykehusgjennomsnittlig" optimaliseringsverdi over all trafikk (basert på testing med én stor kunde).

Riverbed kom til Russland for ikke så lenge siden, men utvikler aktivt partnernettverket sitt. Den har betydelige fordeler i forhold til konkurrerende løsninger (for eksempel en kompetent hurtigbuffermekanisme, applikasjonsoptimalisering), men den høye prisen for løsningen hindrer fortsatt veksten av dens popularitet.

Oppsummerer alt det ovennevnte, vil jeg merke at WAN-optimalisering er en interessant løsning, ganske gjennomsiktig for virksomheten, men dessverre har den ennå ikke fått mye etterspørsel i russiske selskaper. Basert på implementeringene var det mulig å redusere trafikken med gjennomsnittlig 2-3,5 ganger og øke hastigheten på applikasjonssvarene betydelig. For eksempel sparte en av våre kunder, på satellittlinjer, omtrent 20 timer med svar i løpet av en måned med testing. For selskapet vårt tillot implementeringen av denne løsningen oss å oppnå doble besparelser når vi betaler for nettverkstrafikk, samt øke hastigheten på bedriftsapplikasjoner med gjennomsnittlig 1,7 ganger. Samtidig var avkastningen på investeringen i prosjektet kun 3 måneder.

Uansett, hvis du er interessert, er det best å først teste løsningen i omtrent en måned.Bare basert på resultatene av slik testing vil det være mulig å si hvor effektiv implementeringen av optimizere er i forhold til et spesifikt nettverk. Det er best å involvere erfarne systemintegratorer for å utvikle en løsning, gjennomføre testing og installasjon.

Effektiv SEO kan hindres av bare én irriterende feil i den tekniske optimaliseringen av nettstedet, men dette vil føre til at søkemotorrobotene ikke vil være i stand til å indeksere ressursen riktig, forstå strukturen til nettstedet, og brukerne vil ikke finner informasjonen de trenger. Alt dette vil igjen føre til lav rangering av nettstedet.

Teknisk nettstedoptimalisering er et sett med tiltak som er rettet mot å justere de tekniske aspektene ved ressursen for å forbedre dens interaksjon med søkemotorroboter. Teknisk optimalisering gir den raskeste og mest komplette indekseringen av nettstedssider.

5 viktigste tekniske optimaliseringsparametere

1. Robots.txt-fil

Det er viktig å merke seg at robots.txt-filen må finnes i rotkatalogen til hver ressurs. Dette er den første filen som PS-roboter får tilgang til når de besøker nettstedet, og hvor instruksjoner for dem er lagret.

Denne filen spesifiserer nettstedets indekseringsparametere: hvilke sider som skal inkluderes i søkedatabasen og hvilke som skal ekskluderes. I tillegg kan den spesifisere direktiver både for alle søkemotorroboter samtidig, og for robotene til hver søkemotor separat. Du kan lære mer om å kompilere denne filen og sette den opp på hjelpenettstedet for Yandex webmaster.

Du kan sjekke filen i Yandex.Webmaster-tjenesten, menyelementet "Analyse av robots.txt" (https://webmaster.yandex.ru/robots.xml).

2. Sitemap - site map

Et nettstedskart er en av ressurssidene, hvor informasjonen ligner på innholdet i en vanlig bok. Denne siden brukes som et navigasjonselement. Områdekartet inneholder en fullstendig liste over seksjoner og/eller alle sider som er lagt ut på ressursen.

Et HTML-nettkart er nødvendig av brukere for å raskt og enkelt finne informasjon, og XML er nødvendig av søkemotorer for å forbedre nettstedindeksering.

Ved hjelp av et nettstedskart ser søkeroboter hele strukturen og indekserer nye sider raskere.

Sjekker nettstedskartet(https://webmaster.yandex.ru/sitemaptest.xml)

Et eksempel på et korrekt områdekart i .html-format:

3. Omdirigeringer (viderekoblinger)

En omdirigering brukes til å omdirigere besøkende fra en side til en annen. Det er mange eksempler på hvorfor omdirigeringer er nødvendig:

1. Endring av domenenavnet til nettstedet.
2. Kryssfiner speil. Mange nettsteder har ikke en 301-viderekobling konfigurert fra et domene som inneholder www i adressen til et domene uten www, eller omvendt.

Omdirigeringer må legges inn i .htaccess-filen. Siden søkemotorer kan betrakte site.ru og www.site.ru som forskjellige nettsteder, kan duplikater vises i resultatene. Dette vil skape vanskeligheter med rangering i søkeresultater osv.

Hovedomdirigeringsstatuskoder:

• 300 - Flere valg (flere alternativer å velge mellom);
• 301 - Flyttet permanent (flyttet for alltid);
• 302 - Midlertidig viderekobling;
• 303 - Se Annet (den forespurte ressursen kan finnes på en annen adresse);
• 304 - Ikke endret (innholdet er ikke endret - dette kan være bilder, stilark osv.);
• 305 - Bruk proxy (tilgang må skje via en proxy);
• 306 - Ubrukt (ikke i bruk).

Nyttig tjeneste for å bestemme sidesvar: http://www.bertal.ru/

4. Tilpasse URL-sidevisninger

Det er viktig å sjekke nettstedet for å sikre at adressene til alle sidene er konsistente. For eksempel, på hele nettstedet, må sidene ha en avsluttende skråstrek: http://site.ru/katalog/ og http://site.ru/products/ . Hvis noen sider ser ut som http://site.ru/katalog, og noen ser ut som http://site.ru/products/, er dette feil.

Det vil være praktisk å sjekke adressene til interne ressurssider for feil etter å ha opprettet et nettstedskart.

5. Nettstedsfeil

Når en side på et nettsted lastes, sendes en forespørsel til serveren, som svarer med en HTTP-statuskode og laster (eller ikke laster) siden.

Grunnleggende statuskoder:

• 200 - siden er fin;
• 404 - ikke-eksisterende side;
• 503 - serveren er midlertidig utilgjengelig.

"404-feil" er en av de viktigste tekniske parameterne for optimalisering, som må forbedres.

Hvis siden eksisterer, og serveren informerer om en 404-feil når den ber om den, vil siden ikke bli indeksert av søkemotorer. Ellers kan et stort antall sider med samme tekst havne i indeksen, noe som har en ekstremt negativ effekt på rangeringen.

Du kan sjekke statuskoder ved å bruke http://www.bertal.ru/ eller Yandex.Webmaster.

Vi har kun vurdert hovedparametrene for den tekniske forbedringen av nettstedet, som du må ta hensyn til først. Hvis du finner slike feil på nettstedet ditt eller har problemer med å eliminere dem, kontakt kun et profesjonelt SEO-selskap.

Det er flere metoder du kan bruke for å øke serverytelsen, men det beste er optimalisering.

Operativsystemoptimalisering (FreeBSD)

• Overgang til 7.x er nyttig for flerkjernesystemer ettersom den nye ULE 3.0 Scheduler og jemalloc kan brukes. Hvis du bruker et eldre 6.x-system og det ikke kan takle belastningen, er det på tide å bytte til 7.x.
• Overgang til 7.2 vil tillate deg å øke KVA, optimalisere som standard sysctl og bruke supersider. En ny FreeBSD 8.0 er allerede under utarbeidelse, noe som vil bidra til å øke produktiviteten betydelig.
• Overgang til amd64 gjør det mulig å øke KVA- og Shared Mem-volumene til mer enn 2Gb. Det er nødvendig å legge forholdene til rette for utvikling av serveren, fordi databaser stadig øker og krever større størrelser.
• Nettverksundersystem avlasting i FreeBSD vil hjelpe med å optimalisere serveren. Denne prosessen kan gjøres i to trinn: innstilling av ifconfig-parametere og sysctl.conf/loader.conf-innstillinger. På forberedelsesstadiet bør du sjekke egenskapene til nettverkskortet. Drivere fra Yandex vil bidra til å øke hastigheten ved å bruke flere tråder; de brukes ofte til flerkjerneprosesser. For et tredjerangs nettverkskort er polling den beste løsningen. Den siste oppdaterte versjonen av FreeBSD 7 tuning vil bidra til å løse problemet.
• FreeBSD og et stort antall filer fungerer utmerket takket være caching av filnavn i katalogen. Å søke i hash-tabellen vil hjelpe deg raskt å finne den nødvendige filen. Selv om den maksimale minnemengden er omtrent 2MB, kan du øke den så lenge vfs.ufs.dirhash_mem tillater det.
• Myke oppdateringer, gjournalOgmontere alternativer– Dette er nye terabyteskruer som har utmerket ytelse. Hvis strømmen går, vil deres fsck ta veldig lang tid, så du kan bruke softupdates eller logge via gjournal.

Frontend-optimalisering (nginx)

Denne typen kan klassifiseres som for tidlig optimalisering, selv om den vil bidra til å øke den totale responstiden til nettstedet. Blant standardoptimaliseringene er det verdt å være oppmerksom på reset_timedout_connection; Send fil; tcp_nopush og tcp_nodelay.

• Godta filtre er en teknologi som gjør det mulig å overføre informasjon fra kjernen til prosessen i tilfelle nye data kommer inn eller mottar en gyldig http-forespørsel. Disse filtrene vil hjelpe til med å avlaste serveren når det er et stort antall tilkoblinger.
• Buffer nginx er preget av fleksibilitet, og er produsert fra fastcgi eller proxy-backends. Alle kan bruke caching smart i prosjektet sitt.
• AIO er veldig nyttig for noen spesifikke serverbelastninger, fordi det sparer responstid samtidig som det reduserer antall arbeidere. Nye versjoner av nginx gjør det mulig å bruke aio sammen med sendfile.

Backend-optimalisering

• APC er et rammeverk som lar deg redusere belastningen ved å bufre kompilert kode i OP. APC-låsing er verdt å oppdatere, da det kan bremse og mange begynner å bruke eAccelerator i stedet for APC. Det er verdt å erstatte låsing med spinlock eller pthread mutex. APC-hintverdien bør økes hvis det er et stort antall .php-filer eller hvis de ofte bufres i APC-brukerbufferen. APC-fragmentering er et tegn på at du bruker APC upassende. Han kan ikke uavhengig slette poster av TTL eller LRU.
• PHP 5.3 vil bidra til å øke produktivitetsgevinsten, så det er verdt å oppgradere PHP-versjonen din, selv om listen over utdaterte funksjoner kan skremme mange.

Databaseoptimalisering

Det er mange ideer for å forbedre ytelsen til MySQL på Internett, fordi hvert nettprosjekt før eller siden møter begrensninger i mengden minne, disk eller prosessor. Derfor vil ikke enkle løsninger hjelpe til med å takle problemet; det er verdt å bruke mer tid på profiler (dtrace, systemtap og oprofile), i tillegg til å bruke et stort antall ekstra programvare. Det er nødvendig ikke bare å være perfekt i stand til å bruke indekser, sortere og gruppere dem, men også å vite hvordan alt dette fungerer inne i MySQL. Du må også kjenne til fordelene og ulempene med forskjellige lagringsmotorer, forstå Query cache og FORKLAR.

Det er flere måter å optimalisere MySQL på, selv uten å endre kodene, fordi halvparten av serverinnstillingen kan gjøres i en halvautomatisk modus ved å bruke tuningprimer, mysqltuner og mysqlsla-verktøyene.

• Overgang til 5.1 gir mange fordeler, blant dem er det verdt å fremheve optimaliseringsoptimalisering, partisjonering, InnoDB-plugin og radbasert replikering. For å få fart på siden tester noen ekstremsportentusiaster allerede versjon 5.4.
• Bytter til InnoDB gir mange fordeler. Den er ACID-kompatibel, så enhver operasjon utføres med bare én transaksjon. Den har låsing på radnivå, som gjør det mulig å lese og skrive mange tråder samtidig isolert fra hverandre.
• Innebygd MySQL-cache – Query Cache er ganske vanskelig å forstå, så mange brukere bruker det irrasjonelt eller slår det av. For ham betyr mer ikke bedre, så det er ikke verdt å maksimere dette delsystemet. Query Cache er parallellisert; som et resultat, hvis mer enn åtte prosesser brukes, vil det bare bremse hele prosessen og ikke bidra til å redusere lastetiden for nettstedet. Innholdet i dette undersystemet, som er relatert til en spesifikk tabell, blir ugyldig når det gjøres endringer i den tabellen. Dette betyr at Query Cache kun gir positive resultater ved bruk av godt utformede tabeller.
• Indekser kan være skadelige både for SELECT (hvis det ikke er noen) og for INSERT/UPDATE (hvis det er ekstra). En indeks som ikke lenger er i bruk tar fortsatt opp minne og bremser dermed dataendringer. For å håndtere dette problemet, bør du bruke en enkel SQL-spørring.

PostgreSQL

Postgres-systemet er ganske allsidig, fordi det tilhører Enterprise-klassen og Skype fungerer utmerket på det, men samtidig kan det til og med installeres på en mobiltelefon. Blant de 200 tilgjengelige parameterne er 45 av dem grunnleggende og er ansvarlige for tuning.

Du kan finne mye nyttig informasjon om tuning av Postgres på Internett. Men noen artikler er allerede utdaterte, så du bør starte fra publiseringsdatoen og være oppmerksom på informasjonen der vacuum_mem-nøkkelen brukes, eller i nye versjoner av maintenance_mem. Avanserte programmerere vil kunne finne mange avhandlinger av høy kvalitet; nedenfor vil vi bare liste opp de grunnleggende tingene som vil hjelpe den gjennomsnittlige brukeren med å forbedre prosjektet sitt.

• Indekser PostgreSQL er alltid på førsteplass, mens de i MySQL alltid inntar de siste posisjonene, og dette kan forklares med at PostgreSQL-indekser har enorme muligheter. Programmereren må ha god forståelse for slike indekser, og vite når og hvilken som skal brukes, som GiST, GIN, hash og B-tree, samt partial, multicolumn og på uttrykk.
• pgBouncer og alternativene må først installeres på databaseserveren. Uten en tilkoblingspooler oppretter hver forespørsel en egen prosess som bruker RAM. Det virker som ingenting dårlig, men når du oppretter mer enn 200 tilkoblinger, har selv en veldig kraftig server problemer med å behandle informasjon. pgBouncer hjelper til med å løse dette problemet.
• pgFouine er et uunnværlig program, siden det trygt kan kalles en analog av mysqlsla i php. Sammen med Playr kan den utføre spørringsoptimalisering under vanskelige forhold på oppsetningsservere.

Laster ned databasen

For å optimere driften av databasen og øke ytelsen, bør du bruke den så lite som mulig.

• SphinxQL kan brukes som en MySQL-server. For å gjøre dette trenger du bare å lage sphinx.conf, samt oppføringer for indeksering i cron og bytte til en annen database. Med disse handlingene er det ikke nødvendig å endre koden engang. Å bytte til SphinxQL vil bidra til å forbedre søkehastigheten og -kvaliteten, og glemme MyISAM og FTS.
• Ikke-RDBMS-lagring lar deg ikke bruke en relasjonsdatabase. Du kan velge Hive eller Oracle. Nøkkelverdidatabasen bruker på grunn av sin hastighet valg fra relasjonsdatabaser for videre hurtigbufring. Eiere av store PHP-prosjekter kan bruke den utmerkede opcode-bufferfunksjonen til å lagre alle tilpassede data. Med dens hjelp kan du pålitelig lagre selv endringer av global betydning, fordi de tar liten plass og praktisk talt ikke opptar minne, og samplingshastigheten kan også øke betydelig. Hvis for et stort prosjekt en blokk med globale endringer skrives til bare én maskin, øker trafikken og den begynner å avta kraftig. For å løse dette problemet, må du lagre globale variabler i en opcode-cacher eller klone variabler på tvers av alle servere og legge til unntak til konsistens-hash-algoritmen.
• Kodinger referer til effektive metoder for å losse en database. Det er verdt å merke seg at UTF-8 er et utmerket valg, men på russisk tar det mye plass, så for en enspråklig kontingent bør du først tenke på den rasjonelle bruken av kodingen.
• Asynkroni vil bidra til å redusere responstiden til en applikasjon eller nettside, samt redusere belastningen på selve serveren betydelig. Batchforespørsler gjøres mye raskere enn de vanlige enkeltforespørslene. For store prosjekter kan du bruke RabbitMQ, ApacheMQ eller ZeroMQ meldinger, og for små prosjekter kan du bruke bare cron.

Ytterligere applikasjoner for optimalisering

• SSHGuard eller dets alternativ er standard praksis for ssh. Anti-brute force bidrar til å skape pålitelig serverbeskyttelse mot botangrep.
• Xtrabackup fra Percona er et utmerket MySQL-sikkerhetskopieringsverktøy som har mange innstillinger. Men den ideelle løsningen er fortsatt å kalle kloner i ZFS, fordi de opprettes veldig raskt, og for å gjenopprette databasen er det nok å endre banene til filene i muskelkonfigurasjonen. Kloner lar deg gjenopprette systemet fra bunnen av.
• Overfør e-post til en annen vert vil spare trafikk og IOPs hvis serveren din bare bombarderes med spam.
• Integrasjon med tredjepartsprogramvare vil hjelpe med å optimalisere mysql-serveren. Du kan for eksempel bruke smtp/imap-tilkoblingen til å utveksle meldinger, som ikke tar opp mye minne. For å opprette en chat er det nok å bruke grunnlaget for en jabber-server med en javascript-klient. Disse systemene, som er basert på adaptere til hylleprodukter, er svært skalerbare.
• Overvåking er en svært viktig komponent, fordi det er umulig å optimalisere noe uten detaljert analyse. Det er nødvendig å overvåke ytelsesmålinger, gratis ressurser og forsinkelser; Zabbix, Cacti, Nagios og andre verktøy vil hjelpe med dette. Web Performance Test lar deg beregne lastehastigheten til et nettsted eller et prosjekt, så det er veldig nyttig for overvåking. Når du setter opp en ytelsesserver, husk at bare en grundig analyse vil bidra til å eliminere alle problemer og utføre optimalisering.

Hvis du ikke forsto halvparten av det som ble skrevet, spiller det ingen rolle.