Etusivu / Blogi / Infrastruktuuri
Infrastruktuuri Arvioitu lukuaika: 15 min · 17.09.2026

Mikä on VPS: webhotelli vai pilvipalvelin sivustollesi

Webhotelli, VPS ja pilvipalvelin näyttävät hinnastossa kolmelta tehotasolta, mutta eroavat kolmessa kohdassa: mikä erottaa sivustosi naapureista samalla koneella, mihin tili törmää ja kuka päivittää ohjelmiston.

Webhotellin, VPS:n ja pilvipalvelimen vertailu: monta tiliä yhdellä koneella, erillinen virtuaalikone ja pilvi-instanssi API:lla

Webhotelli, VPS ja pilvipalvelin näyttävät hinnastossa kolmelta tehotasolta, mutta eroavat kolmessa kohdassa: mikä erottaa sivustosi naapureista samalla koneella, mihin tili törmää ja kuka päivittää ohjelmiston.

Keskiviikkoaamuna kymmenen tienoilla sivusto hidastuu — ei kaadu, vain hidastuu: sivu aukeaa viidessä sekunnissa, hallintapaneeli kieltäytyy tallentamasta merkintää, ja puolen tunnin kuluttua kaikki on taas kunnossa, aivan kuin mitään ei olisi tapahtunut. Palveluntarjoajan tuki vastaa lounaan jälkeen, että tili on ylittänyt pakettinsa rajat, ja tarjoaa siirtymistä seuraavalle tasolle, joka maksaa kolme kertaa enemmän ja jonka nimi hinnastossa on ”pilvipalvelin”.

Tässä vaiheessa useimmat ostajat eivät tiedä, mikä on VPS tai mitä kaksi muuta hinnaston riviä ostoksena ovat, eikä se ole moite: webhotelli, VPS ja pilvipalvelin on laitettu hinnastoon allekkain kuin kolme tehotasoa samalle palvelulle, vaikka ne ovat kolme eri teknistä ratkaisua, jotka eroavat kolmessa konkreettisessa kohdassa. Jokaisen näistä kolmesta kohdasta voit tarkistaa sivustosi luvut kädessä, eikä yksikään niistä ole luettavissa paketin nimestä.

Kolme kohtaa, joissa paketit tosiasiassa eroavat

Ensimmäinen on eristys, eli mikä tarkalleen erottaa sivustosi muiden asiakkaiden sivustoista samalla fyysisellä koneella. Webhotellissa se on käyttöjärjestelmän tili yhdessä ydintasolle asetetun resurssikontin kanssa, VPS:ssä erillinen virtuaalikone omalla käyttöjärjestelmällään, pilvipalvelimessa taas sama virtuaalikone, vain tilattuna ja laskutettuna toisin. Käytännön ero näiden kolmen välillä on siinä, missä määrin naapurin kuorma voi vaikuttaa sivustoosi ja kuinka paljon konetta ylipäätään saat muuttaa, kun oletusasetus ei sovi.

Toinen kohta on raja, eli mihin tili törmää ja miltä se näyttää, ja juuri tässä syntyy eniten väärinkäsityksiä, koska ihmiset odottavat ylikuorman tarkoittavan hidasta sivua, vaikka osassa tapauksista se tarkoittaa sivua, joka ei aukea lainkaan ja palauttaa virhekoodin, jota ostaja ei ole elämässään nähnyt kertaakaan. Kolmas kohta on vastuu, eli kuka päivittää käyttöjärjestelmän, kuka HTTP-palvelimen, kuka PHP:n ja kuka itse sivuston, ja juuri tässä VPS:n ostajat laskevat väärin useimmin, koska root-oikeus ei ole lahja, jonka palveluntarjoaja ojentaa tehokkaamman koneen kylkiäisenä — se on velvollisuuslistan siirtyminen häneltä sinulle, ja se tapahtuu hiljaa, samalla minuutilla kun salasana lähetetään.

Kaikki muu, mikä hosting-vertailutaulukossa vie rivejä, on joko samaa kaikissa paketeissa tai ei ole se, mikä pettää: NVMe-levyt ovat nykyään käytännössä kaikkialla, mutta ”rajoittamaton tiedonsiirto” on väite siirretyn datan määrästä, ei resursseista, ja se seisoo yleensä juuri sen taulukon vieressä, jossa resurssit on laskettu viimeiseen megatavuun. 99,9 % taas on luku, jolla on tarkka juridinen merkitys ja poikkeuslista sen alla, ja suurin osa ostajista luulee sen kattavan jotakin aivan muuta kuin se todella kattaa.

Webhotelli: yksi palvelin, monta tiliä

Webhotelli on käyttäjätili koneella, jolla asuu vielä satoja samanlaisia tilejä, ja Suomessa sama tuote myydään webhotellina, vertailutaulukoissa myös jaettuna hostingina: Zoner kirjoittaa taulukkoonsa ”Jaettu hosting (webhotelli)”. Teknisesti sopimus on sama — sinulle kuuluu tili, ei konetta, sivustoa hallitset cPanelin tai vastaavan paneelin kautta, ja kaikki sen paneelin alla kuuluu jollekulle muulle.

Mikä erottaa sinut naapureista, on tietty ohjelmisto, ei lupaus hinnastossa, ja se kannattaa osata nimeltä. Suurin osa cPanel-palveluntarjoajista toimii CloudLinuxilla, jossa jokaisella tilillä on oma tiedostojärjestelmän kopio: CloudLinuxin CageFS-dokumentaatio kirjoittaa, että käyttäjät eivät voi nähdä eivätkä havaita muita käyttäjiä eivätkä näiden käyttäjätunnuksia palvelimella, eivät voi lukea HTTP-palvelimen asetuksia ja näkevät vain typistetyn prosessilistan. Toinen kerros on LVE — ydintason resurssikontti, joka asettaa kullekin tilille suorittimen, muistin, I/O:n ja prosessien rajat juuri siksi, ettei, kuten dokumentaatio itse muotoilee, yksikään sivusto voisi kaataa koko HTTP-palvelinta.

Kolmas kerros on PHP-asetus open_basedir, ja siitä kannattaa tietää, mitä PHP:n oma käsikirja sanoo, ei palveluntarjoajan markkinointi: se on lisäturvaverkko, joka ei ole millään tavoin kattava ja johon ei voi luottaa silloin, kun tietoturvaa todella tarvitaan. Samassa käsikirjassa varoitetaan, että myös funktioiden sulkemisen disable_functions-asetuksella voi kiertää ja ettei se jaetussa ympäristössä ole riittävä turvatoimi. Mikään tästä ei ole argumentti webhotellia vastaan; se on argumentti sen puolesta, että eristyksen antaa tässä ydin ja tiedostojärjestelmä, ei yksi rivi asetustiedostossa, ja että palveluntarjoaja, joka vastaa eristystä koskevaan kysymykseen sanalla ”turvallisesti”, ei ole vastannut siihen.

Se, mitä webhotellissa ei voi valita, on yhtä tärkeää kuin se, mitä voi: ydin on yhteinen kaikille tileille, joten ydintä et vaihda, PHP-versiolistan määrää palveluntarjoaja ja se jää yleensä yhden tai kaksi versiota jälkeen uusimmasta, mutta HTTP-palvelin on se, joka on asennettu, joten kysymykseen paketista, jota siellä ei ole, vastaus on ”ei”, ei ”asenna”. Jaettu palvelin on myös se paikka, jossa palveluntarjoajan on häiriötilanteessa tarkistettava viereiset tilit, koska hyökkääjä, joka on päässyt yhteen tiliin, yrittää samaa naapureille; mitä tehdä, kun näin on käynyt, olemme kuvanneet artikkelissa hakkeroidusta WordPress-sivustosta. Yksikään näistä rajoista ei ole puute: juuri tämä sopimus tekee tuotteesta halvan, ja ostaja, joka sen ymmärtää, hyötyy siitä.

Mitä tapahtuu, kun tili törmää rajaansa

Webhotellipaketilla on useita eri rajoja, ne täyttyvät toisistaan riippumatta ja ne näkyvät täysin eri tavoin, joten oire on hyödyllinen diagnostiikan väline. CloudLinuxin oletusrajat yhdelle tilille ovat 100 % yhdestä suoritinytimestä, 1 GB fyysistä muistia, 1024 KB/s I/O:ta, sata prosessia ja kaksikymmentä entry processia, ja juuri viimeinen luku yllättää ostajat, koska kaksikymmentä kuulostaa naurettavan pieneltä sivustolle, joka saa kuukaudessa kymmenentuhatta kävijää.

Selitys on siinä, että entry process ei ole kävijä: se on prosessi, joka tulee tiliin ulkopuolelta — uusi HTTP-pyyntö PHP-skriptille, SSH-istunto tai cron-tehtävä — kun taas prosessit, jotka syntyvät jo sisällä, lasketaan aivan toiseen rajaan. Kun entry processes -raja on täynnä, Apache-moduuli ei enää päästä seuraavaa pyyntöä sisään ja palauttaa virheen 508 Resource Limit Reached, ja CloudLinux kuvaa tämän tukisivustollaan ilman pehmennyksiä: sivusto, joka kuluttaa liikaa resursseja, lakkaa toimimasta, mutta muut asiakkaat samalla palvelimella jatkavat normaalisti. Juuri tämä on mekanismin idea — katkaista yksi tili, jotta kone ei pysähdy.

Muut rajat näkyvät toisin, ja oireesta voi lukea, mikä niistä on täyttynyt, ennen kuin kukaan alkaa arvata: suoritinta ja I/O:ta ei katkaista vaan jarrutetaan, joten sivu hidastuu ja aukeaa lopulta, kun taas muistin ja prosessien rajat antavat yleensä 500:n tai 503:n, eli sivun, joka ei aukea lainkaan. LiteSpeed-palvelimilla entry processes lasketaan toisin kuin Apachella, joten siellä samaa lukua ei saa kääntää samanaikaisten kävijöiden määräksi, ja se on yksi yleisimmistä tavoista, joilla oikea luku päätyy väärään lauseeseen.

On vielä neljäs raja, joka ei liity kuormaan lainkaan ja siksi tulee vastaan odottamatta: inode on tiedostojärjestelmän tietue yhdestä tiedostosta tai kansiosta, joten inodejen määrä tilissä on yksinkertaisesti tiedostojen ja kansioiden määrä, mukaan lukien sähköpostilaatikko, jota kukaan ei ole vuosiin siivonnut. Hostnet julkaisee inode-rajat avoimesti hinnastossaan — MINI-paketissa 400 000, PLUS 600 000, PRO 800 000 — ja samassa taulukossa MINI:n ja PLUS:n vieressä seisoo 100 % yhdestä ytimestä ja 2048 MB muistia, PRO:ssa 200 % ja 3072 MB, lisäksi kaikilla kolmella 10 MB/s I/O ja 150 samanaikaista yhteyttä, kun kuukausittainen tiedonsiirto on ”rajoittamaton”. Tämä yhdistelmä on varsinainen opetus sanasta ”rajoittamaton” hosting-hinnastossa: se koskee siirretyn datan määrää, ja kaikki muut rajat seisovat siinä vieressä, laskettuina viimeiseen lukuun.

Mikä on VPS: oma käyttöjärjestelmä jaetulla raudalla

VPS (virtuaalipalvelin) on virtuaalikone, jossa sinulle kuuluu käyttöjärjestelmä, root-oikeus ja mahdollisuus asentaa se, mitä tarvitaan, ja suomalaisilla markkinoilla se kirjoitetaan sekä lyhenteenä että suomeksi: Zoner avaa lyhenteen sanoista Virtual Private Server ja myy tuotetta virtuaalipalvelimena. Se, mitä tämä nimi ei kerro, on kaksi teknistä kysymystä, jotka ratkaisevat, kuinka paljon ”omasta palvelimesta” todella on sinun.

Ensimmäinen kysymys on, onko virtualisointi laitteisto- vai käyttöjärjestelmätasoista. KVM on Linux-ytimen moduuli, joka käyttää suorittimen virtualisointilaajennuksia ja antaa kullekin vieraalle oman virtualisoidun laitteiston — verkkokortin, levyn, näytönohjaimen — ja ennen kaikkea oman ytimen, joten sillä voi ajaa myös muuttamatonta Windowsia. LXC ja sen sukulaiset kontit ovat toinen mekanismi: ne käyttävät Linux-nimiavaruuksia, cgroups ja oikeuksien rajaamista luodakseen ympäristön, joka on mahdollisimman lähellä erillistä Linux-asennusta, mutta ilman erillistä ydintä. Seuraus on yksinkertainen ja käytännöllinen — kontin ytimen versio, ytimen moduulit ja ytimen haavoittuvuudet jäävät yhteisiksi isäntäkoneen kanssa, joten osa siitä, minkä luulit ostavasi, jäi itse asiassa naapureille.

Toinen kysymys koskee suoritinta, koska sanat ”oma palvelin” eivät tarkoita omaa suoritinta. Hetznerin pilvipalvelimilla on kaksi erillistä tuoteperhettä: jaettujen resurssien paketeissa laskentateho — jaettu vCPU — jaetaan kaikkien instanssien kesken samalla fyysisellä palvelimella perussuorituskyvyllä ja mahdollisuudella ylittää se tilapäisesti, kun taas dedikoitujen resurssien paketeissa yksi vCPU on yksi fyysisen ytimen säie eikä kenenkään muun. DigitalOcean muotoilee tämän vielä selkeämmin: jaetussa paketissa säie voidaan jakaa muiden kanssa, ja jos naapureilla on suuri kuorma, instanssi saa säikeen osia, ei täyttä pääsyä, joten käytännössä täysi pääsy on mahdollista, mutta ei taattua.

Kuinka monta naapuria yhdellä koneella on, ei julkaise yksikään suurista palveluntarjoajista, eikä suhde, jonka löydät blogeista, ole kenenkään julkaisema mittaus, joten sitä ei kannata siteerata eikä uskoa. Ainoa dokumentoitu suure, johon voi vedota, on se, lupaako paketti jaettuja vai erillisiä resursseja, ja tämä ero on yleensä kirjoitettu aivan avoimesti — kahdella eri tuotenimellä, kahdella eri teknisellä kuvauksella ja hintaerolla, joka on moninkertainen.

Pilvipalvelin on sama VPS ostettuna toisin

Pilvipalvelin on teknisesti virtuaalikone hypervisorilla, eli täsmälleen sama asia kuin VPS. Zoner kuvaa pilvipalvelinta virtuaaliseksi palvelinympäristöksi, ja Hetznerin dokumentaatio aloittaa samalla lauseella — pilvipalvelimet ovat virtuaalikoneita, jotka toimivat fyysisillä palvelimilla. Jos odotat kahdelta tarjoukselta kahta eri rautaa, odotukselle ei ole perustetta.

Ero ei ole raudassa vaan ostamisen tavassa, ja sen kuvaa tarkimmin Yhdysvaltain standardilaitoksen NISTin määritelmä, jota ala yhä siteeraa: pilvellä on viisi piirrettä — itsepalvelu tarvittaessa, verkkoyhteys, resurssien yhdistäminen useille vuokraajille, nopea joustavuus ja mitattu kulutus. Käytännössä se tarkoittaa API:ta, jolla koneen voi luoda ja purkaa ohjelmallisesti, tuntiveloitusta kuukausikaton kanssa ja lisäpalveluita, jotka voi kytkeä erikseen: snapshotteja (tilannevedoksia), erillistä lohkotallennusta, siirrettävää IP-osoitetta ja kuormantasaajaa.

Jokaisella näistä lisäpalveluista on rajat, jotka kannattaa tietää ennen ostoa, ei kuukausi sen jälkeen. Hetznerin paketin vaihto ei voi pienentää levyn kokoa silloinkaan, kun siitä on käytössä vain osa; levyn kasvattamisen jälkeen osio on laajennettava itse rescue-tilassa, ja itse paketin vaihto on merkitty saatavuustakuun poikkeukseksi. Snapshot taas ei ole varmuuskopio, vaikka molempia sanoja markkinoilla käytetään synonyymeinä: Hetznerin snapshotteihin eivät sisälly liitetyt taltiot, eikä eheyttä taata, jos palvelin on käynnissä, joten se on hyvä asia ennen päivitystä ja huono asia ainoana datakopiona. Siirrettävä IPv4-osoite maksaa erikseen, samoin kuin instanssin oma ensisijainen IPv4-osoite.

Viiden sivun yrityssivusto ei yleensä käytä yhtäkään näistä lisäpalveluista, ja se on rehellisin lause tässä osiossa: jos sivusto ei koskaan vaihda tehoa, ei koskaan siirry toiselle koneelle eikä koskaan kytkeydy API:hin, pilvipalvelin ja saman kokoinen VPS ovat yksi ja sama kone kahdella eri laskulla. Tämä ei ole argumentti pilveä vastaan, koska siellä, missä joustavuutta käytetään, se maksaa vähemmän kuin jatkuvasti pidetty varateho. Se on argumentti sen puolesta, että valinta on niiden mahdollisuuksien välillä, joita todella käytät, ei sellaisten sanojen välillä, jotka kuulostavat nykyaikaisilta.

Kuka päivittää mitä

Suurin käytännön ero kolmen paketin välillä ei ole nopeus vaan velvollisuuksien jako, ja selkeimmin sen ovat muotoilleet pilvipalvelujen tarjoajat itse. AWS:n jaetun vastuun malli jakaa kaiken kahteen osaan: pilven tietoturva on AWS:n vastuulla — laitteisto, ohjelmisto, verkko ja tilat, joissa palvelut toimivat — mutta tietoturva pilvessä on asiakkaan vastuulla. Tietoturvapaikkausten kohdalla se on kirjoitettu erikseen ja sana sanalta: AWS vastaa infrastruktuurin paikkauksista ja vioista, mutta asiakas vastaa vieraskoneensa käyttöjärjestelmän ja omien sovellustensa paikkauksista.

Webhotellissa tämä kerros kuuluu palveluntarjoajalle, ja se on tämän tuotteen suurin arvo, jota harva ajattelee: ytimen, HTTP-palvelimen ja PHP:n päivittävät he, etkä tiedä siitä mitään, ennen kuin jokin hajoaa. Hallitsemattomassa VPS:ssä tai pilvipalvelimessa kaikki tämä siirtyi sinulle root-salasanan mukana, ja Hetzner sanoo sen ehdoissaan myös toiselta puolelta: ohjelmisto, asetukset ja järjestelmän määritykset, jotka asiakas ottaa käyttöön, eivät ole saatavuushäiriö, joten niistä ei vastaa palveluntarjoaja eivätkä ne kuulu mihinkään hyvitykseen.

Itse sivusto jää vastuullesi kaikissa kolmessa tapauksessa, ja se on se kohta, jossa tarjoukset pitää lukea tarkkaan, koska sana ”hallittu” tarkoittaa alalla yleensä käyttöjärjestelmää ja palvelinohjelmistoa, ei WordPress-ydintä, lisäosia ja teemaa. Myös oman infrastruktuurimme vuokrauksen ylläpitoon kuuluvat käyttöjärjestelmän ja palvelinohjelmiston päivitykset, tietoturva-asetukset, varmuuskopiot testatulla palautuksella, valvonta ja reagointi SLA:n mukaan — eikä siellä lue, että päivitämme lisäosasi, koska se on eri rivi hinnastossa ja eri sopimus, ja sanomme sen suoraan, ettei kukaan löydä tätä rajaa häiriön päivänä.

Käytännön testi ennen tilausta on yksi kysymys, esitetty suoraan ja kolmessa osassa: kuka päivittää käyttöjärjestelmän, kuka HTTP-palvelimen ja PHP:n, ja kuka sivuston koodin. Jos vastaus johonkin kolmesta on ”sinä itse”, se on työtä, johon tarvitaan joko ihminen, jolla on aikaa, tai sopimus jonkun muun kanssa, eikä kumpikaan ole ilmainen. Vastaamatta jätetty tämä kysymys ei katoa — se palaa kahdeksantoista kuukauden kuluttua järjestelmänä, johon kukaan ei ole laittanut yhtään paikkausta, ja silloin se ei enää ole paketin valinnan kysymys.

Mitä 99,9 % tarkoittaa ja mitä se ei kata

Saatavuusprosentti hinnastossa näyttää lupaukselta, mutta on itse asiassa kaava, jolla on poikkeuslista. Hetznerin pilvipalvelinten palvelutasosopimus lupaa 99,9 % kuukaudessa yhdelle instanssille, ja Hetzner itse laskee selityksessään, mitä tämä luku tarkoittaa käytännössä: kolmenkymmenen päivän kuukaudessa 43 minuuttia käyttökatkoa on yhä sopimuksen rajoissa, eli se ei ole rike eikä siitä ole luvassa mitään hyvitystä.

Itse hyvitys on yhtä konkreettinen ja paljon pienempi kuin ihmiset odottavat: se lasketaan kynnysarvon ylittävistä minuuteista, muunnettuina tunneiksi ja kerrottuina instanssin tuntihinnalla, ja maksetaan hyvityksenä tulevaan kulutukseen, ei rahana. Hetznerin omassa esimerkissä 185 minuutin katko antaa 142 minuuttia kynnyksen yli eli 2,37 tuntia ja 0,87 euron hyvityksen, mikä on vähemmän kuin tunnin työ sen laskemiseen. Menetetty liikevaihto, menetetyt tilaukset ja pudonneet sijoitukset hakutuloksissa eivät kuulu siihen mihinkään, eikä yksikään hosting-sopimus, jonka olemme lukeneet, kata niitä.

Poikkeuslista on yhtä tärkeä kuin luku, koska juuri se määrää, kuinka usein tätä lukua ylipäätään sovelletaan: sopimuksen ulkopuolelle jäävät ennalta ilmoitettu huolto, asiakkaan oma ohjelmisto ja asetukset, asiakkaan pyytämä paketin vaihto, live-migraatiot isäntäkoneen vakauden vuoksi ja verkko palveluntarjoajan runkoverkon takana. Kaikki tämä on kirjoitettu rehellisesti ja avoimesti, ja siitä seuraa yksinkertainen johtopäätös: prosentti koskee konetta, ei sivustoasi, joten sivusto, joka kaatui epäonnistuneen päivityksen jälkeen, on tämän sopimuksen ulkopuolella kokonaan.

Lisäksi 99,9 % ei ole alan vakio, vaikka sitä usein käytetään kuin olisi. Amazon EC2:n sopimus yhdelle instanssille lupaa 99,5 %, mutta 99,99 % vain jos instanssit on sijoitettu vähintään kahdelle saatavuusalueelle, eli nämä ovat kaksi eri sopimusta kahdella eri luvulla, ja lause ”alalla on 99,9 %” litistää ne yhdeksi. Webhotellissa tällaista asiakirjaa ei yleensä ole lainkaan — on vain luku verkkosivuilla ilman määritelmää, ilman mittausmenetelmää ja ilman seurauksia, ja se on väite, ei velvoite.

Miten mittaat sivustosi ennen valintaa

Luku, joka ratkaisee, ei ole kävijöiden määrä kuukaudessa, vaikka juuri sen ostaja osaa ulkoa ja juuri sitä myyjä kysyy ensimmäisenä. Sen ratkaisee samanaikaisten PHP-pyyntöjen määrä sillä hetkellä, kun kuorma on suurin, ja se on aivan toinen suure, joka korreloi heikosti kuukausittaisen käynnin kanssa.

Kaksi sivustoa, joilla on sama käyntimäärä, voivat olla eri puolilla samaa rajaa, ja ero on siinä, kuinka kauan kukin sivu pitää prosessia. Staattista, välimuistissa olevaa yrityssivustoa palvelee enimmäkseen HTTP-palvelin ilman PHP:tä, joten se ei juuri kuluta entry processes -rajaa eikä kymmenellä tuhannella kävijällä kuukaudessa ole sille merkitystä. Verkkokauppa, jossa jokainen ostoskori, jokainen kirjautuminen ja jokainen paluu maksuportista pitää PHP-prosessia kaksi sekuntia, voi saavuttaa saman rajan jo kahdellakymmenellä samanaikaisella ostajalla, ja juuri siksi kampanjan ensimmäisenä tuntina kaatuvat ne kaupat, jotka ovat kampanjan maksaneet.

Tämän luvun rinnalla kannattaa lukea vielä kolme, ja kaikki kolme saa ilman kehittäjän apua. Ensimmäinen on tietokannan koko ja sen hitain kysely, koska juuri se on yleensä hitauden varsinainen syy, ei koneen teho. Toinen on tiedostojen määrä tilissä, koska inode-rajan saavuttavat odottamatta ja ilman varoitusta sivustot, joilla on suuri mediakirjasto ja vanha sähköpostilaatikko. Kolmas on se, mitä sivusto tekee selaimen ulkopuolella — cron-tehtävät, postin lähetys, integraatiot kirjanpitojärjestelmään — koska nämäkin prosessit tulevat tiliin ulkopuolelta ja kuuluvat samaan rajaan, jonka juuri mittasit ostajille.

Kaikki neljä lukua on luettavissa yhdessä iltapäivässä webhotellin hallintapaneelin tilastoista ja palvelimen lokeista, ja se on ainoa paikka, jossa on sivustosi todellinen kuorma, ei aavistus siitä. Paketin nimi ei näitä lukuja tunne, myyjä, joka ei ole niitä nähnyt, ei myöskään, ja keskustelu, joka alkaa niistä, päättyy yleensä halvempaan vastaukseen kuin keskustelu, joka alkaa pakettilistasta.

Milloin siirto auttaa ja milloin se ei ratkaise mitään

Siirto suurempaan pakettiin on oikea vastaus selvästi harvemmin kuin sitä tarjotaan, ja ensimmäinen tapaus, jossa se ei auta, on myös yleisin. Jos sivusto on hidas siksi, että yksi kysely lukee koko tuotetaulun jokaisella sivun avauksella, tehokkaampi kone suorittaa sen nopeammin, ongelma jää, ja olet ostanut aikaa, et ratkaisua. Sama koskee neljääkymmentä lisäosaa, käsittelemättömiä kuvia täydessä koossa ja teemaa, joka jokaisessa pyynnössä rakentaa valikon nollasta.

Siirto on oikea vastaus silloin, kun raja on saavutettu korrektilla koodilla: jos sivusto on välimuistissa, kyselyt kunnossa ja tili silti törmää entry processes -määrään, se on paketin raja, ei vika koodissa, eikä optimoitavaa enää ole. Samoin siirto on ainoa vastaus silloin, kun tarvitaan jotakin, mitä jaettuun tiliin ei voi asentaa — toinen PHP-versio, jononkäsittelijä, Redis, oma cron minuutin välein — tai kun alan, tarjouspyynnön tai asiakkaan vaatimus määrää, missä maassa data fyysisesti sijaitsee.

On myös kolmas tapaus, josta myyjät puhuvat harvoin, koska se pienentää laskua: joskus oikea liike on alaspäin. Sivusto, joka kolme vuotta sitten siirrettiin VPS:lle yhden mainoskampanjan takia ja on sen jälkeen saanut kaksisataa kävijää päivässä, maksaa koneesta, jota ei käytä, ja maksaa siitä kahdesti — rahalla laskussa ja ihmisen ajalla, koska VPS:n käyttöjärjestelmä on jonkun päivitettävä silloinkin, kun sinne ei kukaan tule.

Ennen mitä tahansa siirtoa kannattaa ratkaista vielä yksi kysymys, joka ei liity tehoon lainkaan: kenen nimiin verkkotunnus on rekisteröity ja kenen nimiin webhotellitili on. Tästä kirjoitimme erikseen artikkelissa virheistä verkkosivujen tilaamisessa, ja tämä on niitä kysymyksiä, joita migraatiopäivänä ei enää korjata nopeasti, koska vastaus riippuu ihmisestä, jonka kanssa et ehkä enää puhu.

Mitä ostat, kun paketin nimi on hallittu

Hintaero hallitsemattoman ja hallitun koneen välillä on suuri, eikä se ole kate samasta tavarasta, joten molemmat luvut on rehellistä panna vierekkäin. Hetznerin hinnastossa, joka tuli voimaan 15. kesäkuuta 2026, CX23-pilvipalvelin kahdella vCPU:lla, neljällä gigatavulla muistia ja 40 GB levyllä maksaa 5,49 € kuukaudessa ilman ALV:a, ja ensisijainen IPv4-osoite tulee siihen päälle 0,50 € kuukaudessa. Hallittu hostingimme alkaa 45 €/kk, ja ero näiden kahden luvun välillä on juuri se, mistä tämä osio kertoo.

Ero on työtä, ja sen voi luetella yksi kerrallaan: käyttöjärjestelmän ja palvelinohjelmiston päivitykset, tietoturva-asetukset, valvonta Zabbixilla ympäri vuorokauden ja reagointi SLA:n mukaan, varmuuskopiot joka päivä 30 päivän säilytyksellä ja säännöllisesti testatulla palautuksella, mutta erityisen kriittiselle infrastruktuurille — jopa 365 päivää ja kahdessa eri Euroopan unionin maassa. Ympäristön valmistelu ja siirto kestää 3–10 päivää, migraation teemme rinnakkain ja DNS:n vaihdamme suunnitellussa ikkunassa, ja sen jälkeen sinulla on yksi vastuullinen yhteyshenkilö, ei tukipyyntöä toisella aikavyöhykkeellä.

Rehellisesti on sanottava myös toinen puoli, koska ilman sitä tämä osio olisi hinnasto, jonka ympärille on kirjoitettu artikkeli. Jos sivustosi on staattinen, käynti vähäinen eikä kukaan koskaan kysy PHP-versiota, jota palveluntarjoajalla ei ole, webhotelli muutamalla eurolla kuukaudessa on oikea vastaus, ja hallittu ympäristö olisi maksu mielenrauhasta, joka sinulla jo on. Sanomme sen myös niille, jotka soittavat tämän kysymyksen kanssa, koska myydä ympäristöä, jota ei käytetä, on lyhyen tähtäimen kauppa — vuoden päästä se palaa kysymyksenä siitä, mistä oikeastaan maksettiin, eikä siihen ole hyvää vastausta.

Jos et ole varma, kummalla puolen tätä rajaa sivustosi on, nuo neljä lukua voidaan lukea yhdessä: kirjoita meille, niin kerromme, mitä nykyisen tilisi tilastot näyttävät ja mikä raja on sinua lähinnä — myös silloin, kun vastaus on, ettei siirtoon ole mitään tarvetta ja raha kannattaa sijoittaa sivuston nopeuteen.

ES
Edijs Stikuts
Omistaja · Webmasters
Luonnos laadittu tekoälyn avulla; faktat tarkistanut ja sisällön hyväksynyt Edijs Stikuts.
Ota yhteyttä →
FAQ

Usein kysytyt kysymykset.

Mistä tiedän, riittääkö sivustolleni webhotelli?

Samanaikaisten PHP-pyyntöjen määrästä, ei kuukausittaisesta kävijämäärästä. Jos sivusto on staattinen tai välimuistissa ja sivut palvelee HTTP-palvelin ilman PHP:tä, webhotellipaketti kestää paljon enemmän kuin hinnan perusteella näyttää. Jos sen sijaan jokainen sivu pitää PHP-prosessia yhden tai kaksi sekuntia — ostoskori, kirjautuminen, paluu maksuportista — Apachella CloudLinuxin oletuksena olevat kaksikymmentä entry processia täyttyvät jo kahdellakymmenellä samanaikaisella ostajalla; LiteSpeedillä ne lasketaan toisin, eikä samaa lukua saa siellä kääntää näin. Lue webhotellin hallintapaneelin tilastoista, kuinka monta pyyntöä sivusto palvelee huipputunnissa ja kuinka kauan kukin niistä kestää; se on ainoa luku, joka tähän kysymykseen todella vastaa.

Mitä virhe 508 tarkoittaa ja miksi se näkyy vain joskus?

508 Resource Limit Reached tarkoittaa, että tili on saavuttanut entry processes -rajan, eli niiden samanaikaisten pyyntöjen määrän, jotka tulevat tiliin ulkopuolelta. Apache-moduuli ei enää päästä seuraavaa pyyntöä sisään, joten sivu ei aukea lainkaan, ei hidastu, ja juuri siksi se näkyy vain kuorman huipussa. Tässä tämä raja eroaa muista: suorittimen ja I/O:n rajat jarruttavat sivua, mutta muistin ja prosessien rajat antavat yleensä 500:n tai 503:n. Virhekoodista voi siis lukea, mikä raja on täyttynyt, ennen kuin kukaan alkaa arvata.

Mikä on VPS:n ja pilvipalvelimen ero?

Ostamisen tavassa, ei raudassa, koska molemmissa kyse on virtuaalikoneesta hypervisorilla. Pilvipalvelin tulee API:n, tuntiveloituksen ja kuukausikaton sekä erikseen kytkettävien lisäpalveluiden kanssa: snapshotteja, erillistä lohkotallennusta, siirrettävää IP-osoitetta ja kuormantasaajaa. Viiden sivun yrityssivusto ei yleensä käytä yhtäkään niistä, ja silloin pilvipalvelin ja saman kokoinen VPS ovat yksi ja sama kone kahdella eri laskulla. Valinta on siis niiden mahdollisuuksien välillä, joita todella käytät, ei kahden nimen välillä.

Tarkoittaako VPS, että prosessori on vain minun?

Ei aina, ja vastaus on kirjoitettu paketin teknisiin tietoihin. Hetznerin pilvipalvelimilla on kaksi erillistä linjaa: jaettujen resurssien paketeissa laskentateho jaetaan kaikkien instanssien kesken samalla fyysisellä palvelimella, mutta dedikoitujen resurssien paketeissa yksi vCPU on yksi fyysisen ytimen säie. DigitalOcean muotoilee saman — jaetussa paketissa säie voidaan jakaa muiden kanssa, joten täysi pääsy on mahdollista, mutta ei taattua. Kuinka monta naapuria yhdellä koneella on, ei julkaise kukaan, joten ainoa tarkistettava suure jää se, lupaako paketti jaettuja vai erillisiä resursseja.

Mitä päivityksille tapahtuu, jos ostan VPS:n?

Ne siirtyvät sinulle root-salasanan mukana. Webhotellissa ytimen, HTTP-palvelimen ja PHP:n päivittää palveluntarjoaja, mutta hallitsemattomassa VPS:ssä tai pilvipalvelimessa kaiken tämän tekee asiakas. AWS kirjoittaa jaetun vastuun mallissaan suoraan: palveluntarjoaja vastaa infrastruktuurin paikkauksista, mutta asiakas vastaa vieraskoneensa käyttöjärjestelmän ja omien sovellustensa paikkauksista. Hallittu paketti ostaa tämän työn takaisin, mutta silloinkin se kattaa yleensä käyttöjärjestelmän ja palvelinohjelmiston, ei WordPress-ydintä, lisäosia ja teemaa, joten kysy ennen tilausta kaikista kolmesta kerroksesta erikseen.

LIITTYVÄ PALVELU
Hallittu hosting ja palvelininfrastruktuuri

Palvelimet, hosting ja ylläpito EU:ssa — Frankfurtissa, Helsingissä tai Riiassa, valvonta 24/7. Täysi hallinta: päivitykset, tietoturva ja suorituskyky, automaattiset varmuuskopiot testatulla palautuksella, SSL-sertifikaatit, CDN ja DDoS-suojaus. Siirrämme sinut nykyiseltä palveluntarjoajalta ilman käyttökatkoa ja skaalaamme kuormituksen mukaan.

Lue lisää →