Menu

"tárhely" bejegyzések

Két új, nagy teljesítményű tárhely szerverünk üzemel

A cpanel7-es szervernél már bevált Blade szervereken indítottuk el pár hete a cpanel8 és cpanel9-es tárhely szervereinket, hiszen korábbi várakozásaink beigazolódtak. A két 2.6 Ghz-es Xeon E5 processzorral, SSD-vel, 10k-s merevlemezzel és már bővített 64Gb memóriával szerelt cpanel7 alatt futó vasnak nem nagyon kottyan meg a weboldalak délutáni terhelése sem.

Az új szerverek szintén ezt a konfigurációt kapták. A cpanel8-as szerverre a korábbi cpanel5-ös szerverünk felhasználóit költöztetjük át folyamatosan, míg a cpanel9-re kizárólag az új ügyfelek kerülnek. Már meglévő ügyfeleink számíthatnak rá, hogy a cpanel7 terhelése nem fog nőni, hiszen oda már nem kerülnek új ügyfelek, illetve a az új szerverek is hasonlóan villámgyorsak lesznek.

Természetesen az új szerverek válaszideje is nyomonkövethető Szerver státusz oldalunkon, ahol látszanak az esetleges kiesések, a rendelkezésre állás, és az egyes szerverek működő szolgáltatásai.

Szuper szerveren ketyeg a cpanel7

Szemfülesebb ügyfeleink már napokkal korábban észrevehették szerver státusz oldalunkon, hogy elindult új tárhely szerverünk, a cpanel7. Az új szerver mérföldkő a Tárhelypark történetében, hiszen a két processzoros, összesen 12 magos és 24 szálas Xeon alapú konfiguráció teljesítménye jóval meghaladja eddigi, Intel i7 alapú szervereink számítási kapacitását. Ez természetesen nem jelenti, hogy a teljesítményt csak az új szerveren érezhetitek, igyekszünk a régebbi szerverek terhelését csökkenteni, a jelenlegi terhelést elosztani ahol szükséges.

Mit tud az új szerver?

Supermicro

Itt szeretnék egy kicsit a technikai részletekben elmerülni. A szerver alapja a Supermicro Blade szervere, melyben négy önálló szerver kaphat helyet, egyenként két Xeon processzorral, és 256 Gb memóriával. A cpanel7 jelenleg egy ilyen Blad-et kapott, két 2.6 Ghz-es Xeon E5 processzorral, és 32Gb memóriával. A 24 szálas feldolgozás háromszorosa az eddigi szervereinknek, ahol 8 szál dolgozta fel a beérkező kéréseket. A 32 Gb memória és természetesen a már megszokott SSD Raid garantálja, hogy a weboldalakat a megszokott gyorsasággal jeleníti meg a szerver.

Fejlesztettünk a szerverben levő merevlemezeket is, így az új háttértárak Western Digital VelociRapto 10K háttértárak lettek, melyek sebessége a tesztjeink alapján szintén jócskán meghaladják az eddig használt 7200-as fordulatú lemezekét.

A fejlesztések sorának ezzel még nincsen vége! Lényeges újítás, hogy a szerverhez Gigabites belföldi és külföldi sávszélesség tartozik. Ennek előnyeit az átlagos használatkor nem fogjátok érezni, azonban akkor, amikor egy-egy oldal forgalma hirtelen megnő, jó szolgálatot tesz majd a gigabit, mert a többi oldal nem fogja érzékelni a terhelés növekedést.

Mit tervezünk még?

Sokat várunk az új konfigurációtól, és reméljük, hogy érezni fogjátok a teljesítmény növekedést, ahogyan folyamatosan elosztjuk a jelenlegi szerverek terhelését. Ha beválik az új konfiguráció, nem titkolt tervünk, hogy jelenlegi szervereinket is leváltjuk az új hardver konfigurációra. Ez természetesen egy hosszabb távú cél, és időben értesülni fogtok róla.

Új technológiával indult a cPanel6

Három hete indítottuk el új, cPanel6 tárhely szerverünket, ahol a jól bevált technológiák mellett (pl. SSD Raid) ismét egy újítást hajtottunk végre. Eddig is virtuális gépeket használtunk a webhoszting szolgáltatás mögött, hogy kontrollálni tudjuk a felhasznált erőforrást, de a cPanel6-on ezt odáig fejlesztettük, hogy már nem csak az operációs rendszerben globálisan tudjuk állítani a paramétereket, hanem felhasználó szinten is. Így a nálunk levő oldalak és szervereink még stabilabbak lesznek.

Eljött a szerver túlterhelés vége

Összefoglalom, hogyan működik az új technológia, miről is van szó pontosan? Osztott tárhely szolgáltatáson általában ha az egyik felhasználó hibás programot futtat, túlterhelheti a tárhely szervert, és ezzel elveszi az értékes processzoridőt és memóriát a többi felhasználótól. Ekkor a többi weboldal tulajdonos csak annyit vesz észre, hogy lassabban jelennek meg az oldalai, vagy lassabban töltődnek le a levelei.

A megoldást eddig nekünk az jelentette, hogy a folyamatosan monitorozott szervereken már akkor észleltük a problémát, amikor ez a terhelés elkezdődött, de még nem nőtt kritikussá. Ekkor a hibás programot vagy weboldalt korlátoztuk a szerveren, hogy a többi ügyfelünk észre se vegye a hibát.

Ez akkor működik jól, ha a terhelés nem jelentkezik azonnal, hanem van egy kis felfutása. Abban az esetben azonban ha valaki olyan php vagy perl szkriptet futtat ami hirtelen akar nagyon sok erőforrást (pl. oldal feltörésénél) nem mindig tudunk időben reagálni.

Új cPanel6 szerverünkön ezt próbáltuk megoldani úgy, hogy az egyes felhasználók kaphatnak ugyan nagyon sok erőforrást, de csak értelmes ideig. Ezzel továbbra is fenntartjuk, hogy a weboldalak korlátlanul hozzáférnek a szerverhez, de növeljük a stabilitást is. Ha egy program túl sokáig akar túl sok erőforrást a szervertől, akkor a rendszer automatikusan korlátozza, amivel több szempontból is nyertünk:

  • A túlterheléseket a rendszer automatikusan figyeli, nem kell nekünk kézzel beavatkozni
  • A normálisan futó oldalak nem érzékelnek semmit a problémából
  • Az a felhasználó aki sokáig futtat egy szkriptet érzékelni fogja a problémát és azonnal javíthatja is.

Sokat várunk ettől az újítástól. Mivel még csak most használjuk éles környezetben először, előfordulhatnak hibák, amiket természetesen folyamatosan figyelünk továbbra is, hogy azonnal beavatkozzunk.

Bővítés és egy nem tervezett leállás története

Két hete a cpanel2-es szerver megkapta az új szervereinkben is megtalálható hardver konfigurációt, így az SSD meghajtókat és a nyolc magos processzort is, ami akár 4Ghz-en is képes működni. El kell ismernünk azonban, hogy a dolog nem ennyire szépen indult, hiszen az ominózus napon, Április 3-án délután négy óra körül szerver kiesést jelentett a monitorozó rendszer a már 714 napja töretlenül működő tárhely szerveren.

A leállást gyorsan közzétettük a Tárhelypark Twitter csatornáján, és mivel a szervert nem lehetett elérni távolról, így beautóztam a szerver terembe. A biztonság kedvéért beraktam a kocsiba a már irodánkban álló és feltelepített új tárhely szervert is, amit a következő héten akartuk élesíteni eredetileg. Ez jó ötletnek bizonyult, mert a helyszinen ugyan sikerült a szervert elindítani, instabilnak tűnt, néha nem bootolt be. Alaplaphiba lehetett.

Úgy döntöttem, vállalva a nem tervezett kiesést, üzembe állítom az új szervert úgy, hogy nem kockáztatom a merevlemezek meghibásodását sem, így azokat nem rakom át az új szerverbe. Ennek hátránya, hogy a fájlokat hálózaton át kellett másolni az új gépre, ami több mint tízmillió fájl és majdnem 1 Terrabyte esetében este nyolc órától másnap reggel hétig tartott. (Igen, közvetlen gigabites hálózat volt!)

Szerencsére a vállalt kiesés meghozta az eredményt! A cpanel2 azóta is villámgyorsan üzemel, és ezt remélem minden tárhely tulajdonos észreveszi. Íme egy grafikon a havi szerver terheltségről. Jól látszik, hogy az átállás előtt nem ritkán 10-es érték felett volt a load, és elég hullámos is a grafikon, ami a csere után kisimult, és a csúcsok is jóval kisebbek lettek.

Jelenleg a szerver átlagos terheltsége 2-es alatt van, ami egy 8 szálas processzornál több mint jó. Gyakorlatilag negyed terhelés. Az SSD miatt a szerver IO teljesítménye is szemmel láthatóan megugrott.

Elindult új szerverünk a cPanel5

Három hete helyeztük ki a szerverterembe új tárhely szerverünket a cpanel5-öt. Azóta több új és pár régi ügyfelünk is helyet kapott rajta. Természetesen mint már minden új szerverünkben ebben is SSD meghajtók biztosítják a hiperűr sebességet a weboldalaknak.

A hardver teljesítményen túl, a szerveren a legfrisebb PHP és MySQL verzió került telepítésre, így a tárhelyeken biztosan futtathatók a legújabb CMS rendszerek, például a Joomla 3 is.

A szerver állapota már nyomon követhető Szerver Státusz oldalunkon is.

Módosul a php.ini a cpanel4-en

Cpanel4 szerverünkön szükségessé vált a php.ini konfigurációs fájl módosítása, így január 12-én szombaton 10:00 és 11:00 óra között a következőket módosítjuk a tárhely szerveren:

  1. A központi php.ini-ben a magic_quotes_gpc opciót Off-ra állítjuk
  2. Megszüntetjük az egyedi php.ini használatát, így minden tárhelyen a központi beállítás fog működni.

A beállítás szerver leállással nem jár, azonban ha oldalad jelenleg egyedi php.ini-vel működik, akkor ellenőrizned kell, hogy a szerver alapértelmezett beállításai megfelelőek-e.

A szerver alapértelmezett php.ini beállításait Szerver Státusz oldalunkon megtalálod. Amint a beállítás megtörtént, Twitter oldalunkon ezt megírjuk.

Jó tudni!

A beállítás csak a cpanel4-es tárhelyeket érinti, a többi szerveren nem változnak a beállítások

Miért szükséges a magic_quotes_gpc beállítása?

A magic_quotes_gpc a php szkriptekben automatikusan módosítja a bejövő adatokat. Használata az új 5.3-as php-ben nem ajánlott, és az 5.4-es php-ben már nem is szerepel ez a funkció. Az újabb CMS rendszerek, mint például a Joomla 3 megkívánják, hogy ez a beállítás Off legyen.

Miért nem engedélyezett a saját php.ini?

A szerveren összesen nagyjából 20 tárhely használ saját php.ini-t. Ezeket átnéztük, és a bennük szereplő fontosabb beállítások megegyeznek a szerver alap beállításaival. A saját php.ini beállítás potenciális biztonsági rés a szerveren, amit szeretnénk megszüntetni, ezért nem engedjük tovább a használatát. (Ez a beállítás megegyezik többi szerverünk beállításával.)

Hekker támadás Joomla és WordPress oldalak ellen

Ma hajnalban sajnos számos nálunk üzemeltetett Joomla és WordPress oldalt feltört egy (vagy több) hekker. Szerencsére túl nagy módosításokat nem végeztek az oldalakon, azonban az aktuális template fájl-t megváltoztatták valamint az adatbázisban felülírták a felhasználók jelszavait.

Az oldalak visszaállításán jelenleg dolgozunk. Egy szkript átnézi a szervereket a feltört oldalak után, és miután megvan az összes, a mentésből visszaállítjuk a tegnapi állapotot. Az adatbázis rendberakása ennél bonyolultabb feladat, így egyelőre kérésre az admin jelszavakat tudjuk egy alapértelmezett jelszóra állítani. Ha ilyet szeretnél, írj nekünk levélben vagy chat-en!

Hogyan törték fel az oldalt?

A feltörés pontos menetét még nem térképeztük fel teljesen, de annyi biztosan látszik, hogy nem szerver feltörés történt. A hekkerek először feltörtek egyetlen Joomla tárhelyet annak hibás témáján keresztül, majd erről a tárhelyről jelentkeztek be HTTP kapcsolattal oda, ahova tudtak.

Friss: Részletes leírást publikáltam az Adminisztrátori Blogon.

Hogyan védheted meg oldalad a jövőben?

Minden esetben amit eddig átnéztünk a hekker (program) bejelentkezett az adminisztrátori felületre az admin felhasználóval és jelszóval, tehát ismerte azt. Ott a Téma szerkesztőt (template editor) használva írta át az aktuális témát.

Javaslatok:

  • Gyakran, havonta legalább egyszer változtasd meg jelszavadat!
  • Rendszeresen frissítsd az oldal motorját (Joomla, WordPress) és a modulokat
  • Helyezz el .htaccess fájlt az admin könyvtárban, hogy csak egy adott IP címről lehessen hozzáférni
  • A konfigurációs fájlok jogosultságát (wp-config.php és configuration.php) állítsd ‘600’-ra, hogy bárki ne tudja őket olvasni

.htaccess

Ebben a fájlban lehetőséged van korlátozni a hozzáférést egy könyvtárhoz például IP cím alapján. Az Ip cím egyedileg azonosítja az Internethez hozzáférő gépet, így a te gépedet is. Ip címed itt tudhatod meg például: http://myip.dk/

Tételezzük fel, hogy Ip címed: 111.111.111.111

Ebben az esetben a .htaccess fájlt az admin könyvtárban így módosítsad:

Ha IP címed gyakran változik, mert mondjuk 3g mobil hálózatot használsz, akkor is észre fogod venni, hogy csak az utolsó egy vagy kettő számjegy módosul. Ekkor a htaccess fájlban tartományt is megadhatsz.

Ha az utolsó kettő változik (jobb oldali két szám):

Ha csak az utolsó változik (jobb oldali szám):

Több IP cím megadása:

Konfigurációs fájl jogosultság

Nem elképzelhetetlen, de annak ellenére, hogy ügyfeleink egymás tárhelyeit nem látják illetéktelenek mégis olvasni tudják a fájlokat a tárhelyen egy szkripttel. Ekkor azonban a szkript nem a tárhely tulajdonosának jogosultságaival fut. Abban az esetben ha a konfigurációs fájl jogosultsága például ‘666’ az azt jelenti mindenki számára olvasható, így az illetéktelen behatoló is hozzáfér az adatbázis jelszavakhoz.

Az FTP programmal módosítsd a konfigurációs fájlt! A helyes beállítás: 600

WordPress konfigurációs fájl: wp-config.php
Joomla konfiguráció: configuration.php

SSD-vel üzemel új tárhely szerverünk a cPanel4

Az elmúlt hetekben sokat dolgoztunk új szerverünkön tanulva a meglevők gyengéiből, és tegnap elindult a cPanel4. Sok módosítás mellett természetesen megmaradt az igen jól teljesítő Intel i7 proci 4 maggal 8 szállal, de már 3.4GHz órajellel és a 16GB DDR3-as memória. A szerverbe 4TB merevlemezt pakoltunk RAID10 tükrözéssel.

Lényeges változtatás, hogy az alaplapon levő 6Gb-es SATA3-as portokra brutálisan gyors Corsair Force GT SSD meghajtókat kötöttünk természetesen RAID-ben, hogy még gyorsabbak legyenek. Ez a RAID kötet szolgálja ki a MySQL adatbázist és azokat a fájlokat melyekre gyakran van szüksége a szervernek.

Force GT SSD

Mi az az SSD és mire jó?

Az SSD (Solid State Drive) leegyszerűsítve egy memória mozgó alkatrészek nélkül ami úgy működik mint egy merevlemez. Berakható normál alaplapok vagy notebook-ok SATA portjára, így tulajdonképpen kiváltja a hagyományos merevlemezeket. Lényeges különbség, hogy a mozgó alkatrész elhagyásával igen gyors lesz az adatok elérése, olvasása és írása, közel annyira gyors, mintha a gép memóriájába írnánk. Ez a sebességkülönbség természetesen olyan alkalmazásoknál vehető észre igazán, melyek gyakran nyúlnak a merevlemezhez, például a MySQL adatbázis kezelő.

De mennyivel is gyorsabb pontosan? Számos tesztet végeztünk és végzünk folyamatosan, hogy a tárhely szolgáltatás a lehető leggyorsabb legyen, így a weboldalak is gyorsan jelenjenek meg. A tesztekből ide csak egy példát emelnék ki, a 100kb-os fájlok véletlenszerű létrehozását:

  • RAID merevlemez: 2324 db / másodperc
  • RAID SSD: 26328 db / másodperc

Jellemzően a sebesség növekedés több mint tízszeres. Ez természetesen nem jelenti, hogy a weboldalak is tízszer gyorsabban fognak betöltődni, de arra számíthatunk, hogy egy-egy pillanatnyi túlterhelés például adatbetöltéseknél nem fogja észrevehetően lassítani a szervert, mert annak rengeteg tartaléka marad.

Csak az új ügyfelek élvezik a sebességnövekedést?

Természetesen nem. Régebbi tárhely szervereinken is optimalizálunk úgy, hogy a kritikus oldalakat áttesszük az új szerverre, így régebbi ügyfeleink is jelentős sebességnövekedést tapasztalhatnak a közeljövőben.

Spam szűrés bekapcsolva

Összes cPanel szerverünkön átállítottuk a SPAM szűrő működését, így az minden megrendelőnknek kötelezően be van kapcsolva. Kikapcsolni ezentúl úgy lehet, hogy a SpamAssassin pontozási rendszerét a felületen úgy állítja be aki ilyet szeretne, hogy a spam jelölés ponthatára olyan mgas legyen, hogy a szűrő ne érzékeljen levélszemétként egyetlen levelet sem. Ez a megoldás természetesen nem javasolt, hiszen a szűrő igen jó hatékonysággal működik és alap beállítások használatakor igen kevés esetben jelöl szemétként nem spam leveleket.

A beállításra azért volt szükség, mert megrendelőink általában elfelejtették bekapcsolni ezt a funkciót, és úgy tűnhetett, hogy a tárhely szolgáltatáshoz tartozó spam szűrő nem jól működik.

Mennyibe kerül az olcsó tárhely?

Vagy inkább a kérdés, tárhely szolgáltatóként mit tudunk olcsón adni és mi az amit már mi sem viselünk el webhosting címén, mert olyan magas költségekkel jár. Több éves pályafutásunk alatt szerencsére nem sokszor futottunk bele abba, hogy amúgy olcsónak mondható tárhely csomagjainkon olyan szolgáltatást futtasson valamelyik ügyfelünk, ami már nemhogy nem éri meg nekünk, de egyenesen veszteséget generál. Ebben a bejegyzésben azt próbálom áttekinteni, mik voltak a fő problémák, és mik vezetnek oda, hogy egy szolgáltatás nem üzemeltethető osztott tárhely környezetben, illetve mi a megoldás.

A problémák megismeréséhez és elkerüléséhez érdemes megnézni mi a webhosting vagy más néven osztott tárhely szolgáltatás lényege: egy nagy szerveren megpróbálunk sok ügyfelet elhelyezni, akik a szerver processzorán, memóriáján, merevlemezén, hálózati kapcsolatán és nem utolsó sorban adminisztrátorain osztoznak. A Tárhelypark fizeti a ezeket az erőforrásokat, melyeket a megrendelők között szépen elosztunk, lehetőleg úgy, hogy mindenkinek megérje. Az ügyfélnek azért éri meg, mert nem kell saját szervert üzemeltetnie, a szolgáltató pedig, ha sok megrendelője van szintén jól jár az üzlettel.

Ez eddig mesebeli, de mi okozhat problémát? Elsődlegesen az, hogy a kitalált rendszer és a szerver felosztása átlagos weboldalakra van optimalizálva. Ezekre 99%-ban jellemző:

  • Kis méretű oldalak, és képek 10-50 kb átlag méretben
  • Aránylag hamar megjelenő oldalak, amik nem generálnak nagy CPU és memória terhelést
  • Belátható és nem extrém módon növekvő látogató szám

Amint egy weboldal valamelyik kritériumnak nem felel meg, a tárhely csomagokban meghatározott áron veszteséget termel a szolgáltatónak legfőképp azzal, hogy nem tudunk mellette más oldalt üzemeltetni, tehát egy sokkal nagyobb szerver “szelet” kell neki, aminek az ára viszont nem mérhető össze a webhosting árakkal.

Megpróbáltam összeszedni azokat a tipikus problémákat amik eddig előfordultak, hogy a végén megválaszoljam a “mennyibe kerül?” kérdést.

Látogató szám probléma

Napjainkban igen népszerűek a közösségi oldalak és a hozzájuk kapcsolódó weboldalak. Tipikusan ilyen problémás oldalak a tizenévesek által előszeretettel látogatott “képes vicc blog”-ok, melyekre tulajdonosuk feltölt egy képet, a látogatók megosztják Facebook oldalukon. Ide sorolhatók még a mozifilmek letöltési linkjeit, vagy torrent linkeket megosztó oldalak vagy fórumok is. Belátható, hogy pillanatok alatt akár több százezer felhasználó érkezhet az oldalra (ha egy webshop napi 1000 látogatóval büszkélkedik, az már elég jónak mondható), ami erre nincs felkészítve, és ráadásul még a tulajdonosnak sem éri meg üzemeltetni az Index.hu szerint. A szerveren a probléma leggyakrabban CPU terhelés formájában jelentkezik, amire előre fel lehetett volna készüli akár az oldalon, akár a szerveren egy gyorsítótár bekapcsolásával, de utólag ez látogató vesztéshez, oldal korlátozáshoz és elégedetlen ügyfélhez vezet.

Megoldás: mielőtt weboldaladhoz szolgáltatást választasz gondolt át, mennyi látogatód lesz! Ha nem átlagos az oldalad, és rögtön napi több ezer vagy tízezer látogatóra számítasz, szólj, mi segítünk!

Erőforrásigényes hibás programok

Manapság különösebb programozói tudás nélkül is lehet valakinek komoly weboldala adminisztrátori felülettel, és rengeteg kiegészítővel, például webáruházzal. Elég csak a WordPress, Joomla, Druplal rendszerekre gondolni, amik ráadásul igen egyszerűen telepíthetők a cPanel felületről. Sajnos azonban ezekkel az egyik nagy probléma a rengeteg konfigurációs beállítás amivel könnyen problémássá tehető az oldal megjelenítése, illetve, hogy pont népszerűségük miatt a számos kiegészítő modulból igen sok hibásan lefejlesztett. Működnek ugyan, de nincsenek letesztelve “éles” környezetben, esetleg sok látogatóval. Tipikusan ilyen a WordPress-ben előszeretettel használt egyedi címkefelhők, összes kategória megjelenítők, a thimthumb képméretező, vagy például a Joomlában egyes webshop modulok. Ezek rosszul megírt, nem optimálisan futó programok, melyek már alacsony látogatószámnál is igen nagy CPU terhelést generálnak.

Megoldás: minden esetben gondold át, hogy a választott rendszer a legjobb-e a feladatra, illetve mindig legyen alternatívád egy modul kiváltására vagy ha értesz hozzá átprogramozására!

Nagy méretű fájlok problémája

Egy átlagos weboldal HTML programból, kis képekből és maximum monitoron megjeleníthető méretű nagyobb képekből áll össze. Ezek átlagos mérete nem éri el az 50kb-ot, így egy teljes oldal általában 300-400kb méretű. Ennél nagyobb fájlok vagy oldalak kiszolgálása nem optimális, és a legtöbb esetben nem is szükséges, hiszen minek egy weboldalra 5 megapixel méretű fénykép, ha monitor csak ennek tizedét képes megjeleníteni? Egy osztott tárhelyen ugyan lehetséges galéria üzemeltetése, de nem szükséges mindenkinek rögtön a teljes méretű képet mutatni. Szintén probléma a filmek megosztása ami ugyan lehetséges, de egy gyors számítással kideríthető, hogy hacsak 10-en néznek egy HD filmet egyszerre (50Mbit / s), az máris akkora sávszélességet fogyaszt, mint 5000 másik oldal. (Erre való a streaming szerver vagy média szerver).

Megoldás: mielőtt megosztasz valamit oldaladon, gondolt át mi történik, ha azt akár több százan megnézik! Ha feltöltesz egy 100 Mb-os fájlt és azt 100-an letöltik az 10 Gb forgalmat jelent, ami több mint 2 DVD. Biztosan ezt akartad?

De mennyibe kerül?

A végső kérdés, miért kell erről beszélni egyáltalán, mennyibe kerül az olcsó tárhely? Szerintem a tárhely csomag árán túl a megrendelők által az oldalra fordított időbe, ami semmi esetre sem szabad, hogy nulla legyen. Bármennyire is úgy tűnik, ingyen lehet weboldalad, amiből aztán megélsz, ez nem igaz! Hosszú hónapok vagy akár évek munkája egy olyan oldalt létrehozni, ami egy olcsó tárhelyen nagy látogatószámmal stabilan üzemelni képes és pénzt termel.

Ha az oldal nem optimális, sok erőforrást eszik, akkor nem lesz olcsó a tárhely, az árat a felhasznált erőforrások szabják meg. Ha egy weboldal elhasznál egy egész szervert… inkább gondolt át, válassz optimális megoldást, az neked is, nekünk is jobb lesz!