Mekkora helyet foglalnak a weboldalak?

Fórumok

Figyelvén bizonyos tendenciákat, elgondolkodtam, hogy mennyi helyet foglalnak a szerveren a weboldalak. Kóddal, adatbázissal, fájlokkal összesen. biztonsági mentést nem számolva.

Oldalanként a kérdések :

  • Mi az oldal profilja ? (céges, közösségi, blogszolgáltatás, személyes, stb.)
  • Mennyi a napi látogatószám ?
  • Mennyire interaktív az oldal ? (10-es skálán. wikipedia:10, facebook:9, hup:6 lap.hu:1)
  • esetleg url-t is szívesen vennék, de megértem ha nem.
  • Mennyi ideje van kint az oldal ?
  • Mennyi helyet foglal most ?
  • Mennyi az átlagos bővülés ? (elmúlt 12 hónap, havi átlag)
  • Hogyan alakul a bővülés üteme ?
  • Szerinted mennyire fontos ez a méret kérdés? Ha fejlesztesz, optimalizálsz rá ? Ha adminisztrálsz, örülnél ha a fejlesztők foglalkoznának evvel ?
  • Milyen tendenciát vársz az elkövetkező 3-5 évben méret ügyben ?

Előre köszönöm mindenkinek aki válaszol :D

Hozzászólások

1. céges weboldal, hwsw kisker
2. 100-200
3. 5
4. integral95.hu

5. domain 2003-ban regisztrálva, de ez az aktuális oldal 2010.03.01-től megy
6. 330 MB - ebből termékfotó: 156 MB
7. havi 3-5 MB az új termékfotók
8. Hogyan alakul a bővülés üteme ???? - konstans

9. A méret nálam nem fontos, dedikált szerver van itt beállítva. Van benne 80 GB HDD, még sok is. :)
10. konstans, nem fog nőni :)

screenshotok itt

Amúgy a felsővezetés pattogására a megoldás - ami nekem egyszer bevált - hogy egy harmadik oszlopot kirakni jobbra, mondjuk 200px széleset, amiben a leggyakrabban vásárolt, legújabb, legkékebb... akármi termékek szerepelnek.
Vagy liquid layout. de az melósabb talán.

### ()__))____________)~~~ ################
#"Ha én veletek, ki ellenetek?"#1000H/UbuFb

nem hittem volna hogy valahai is ilyet fogok mondani, de nem a méret a lényeg ;D

(nem akartam uppogni de ha már kétszer is neked kellett talán nem vagyok ezzel a véleményemmel egyedül:) )

például igen :)

tömöríteni fontos, pl megfelelő képtömörítés választása, js "obfuscating", zárótagek lehagyása akár (lsd gugli)... és ... meg még ... :)

tehát ahogy lentebb írták az adatforgalom fontos, de ezek többnyire utólagos finomítások, nem pedig hogy az összmérettel előre kellene foglalkozni (kell persze de ez szinte bármelyik projektnél hasraütésre jól belőhető aztán legfeljebb még egy nullát írsz utána ha bizonytalan :)

Tárhelyben nem spórolás, de requestben spórolás, ami ekkora méretben számít. A Google-re alapból jellemző ez a fajta mentalitás, nekem ez tetszik. Abban igazad van hogy a kérdésre vonatkozóan nem takarékos, de amúgy az. Inkább csak érdekes megfigyelésképp említettem meg, véletlenül vettem észre.

Csak a poen kedveert, korabbi, mar inaktiv oldalrol par info:

1) World of Warcraft Guild oldal (news, progress, killshots, videok & forum)
2) A rekord latogatottsag 2000 kulonbozo latogato / nap volt, ez tartott kb egy hetig. Atlagban inkabb olyan 300 latogato / nap volt. A request/sec ennel lenyegesen magasabb volt, tisztelt guild memberek szerettek az F5-ot spamelni.
3) Forum miatt ugy 6 korul lehetett.
4) Url mar nincs, leven inaktiv az oldal mar kb 1.5 eve.

5) Cirka 1.5 evig volt aktiv a dolog, bar inkabb 2-hoz kozelitett.
6) A vegen 20Gb volt
7) Az adatbazis kb 2Mb / honap bovulest mutatott, a videok random: volt-e, milyen minoseg, milyen hosszu, stb.
8) Most mar sehogy. De amig meg mukodott az oldal, addig szepen novogetett.

9) Meret kerdes nagyon nem fontos. Legfeljebb akkor, ha az ember a havi forgalom limitet feszegeti, vagy kifogy a tarkapacitasbol. Nem optimalizalok meretre, a JS/CSS/html minificationon kivul (azt is csak azert, hogy a letoltes gyorsabban menjen, tarolas szempontjabol teljesen lenyegtelen). Fejlesztoknek ezzel nem kell szorakozniuk.
10) Ha mukodne az oldal tovabb, a havi 2mb-s adatbazis novekedest varnam, meg eves atlagban kethavonta 1gb video.

Szumma: a meret a forgalom szempontjabol fontos (oldal betoltesi sebessege, illetve havi limiten belul maradas). Tarolas szempontjabol picit sem: a tarhely olcso.

Kivetel termeszetesen akad, de nagy tobbsegben szerintem ez a helyzet.

* személyes
* ~60 egyedi
* 1
* http://sandor.czettner.hu/

* 1 éve
* 20MB :)
* 160kB/hónap :)
* Blogokhoz feltöltött képek függvénye

* Agyonoptimalizálva egyedi kód esetén, ha valami CMS, akkor annak a rendszerét használom
* Ugyanezt

Különböző framework-ök tanulására csináltam, kezdetben Zend Framewfork, utána kis ideig Symphony, CodeIgniter, Kohana. Meguntam és Drupalos lett.

--
http://sandor.czettner.hu

igyekeztem lényegesen eltérő profilú oldalakat felhozni:

1.)
- céges weboldal
- ~1000 visits/day (webalizer szerint)
- 1
- titok :)

- 2000 április óta
- portálmotor: kevesebb, mint 1 MB, SQL: pár MB, statikus tartalom: kevesebb, mint 100 MB.
- évente +10%

- elborult optimalizáló vagyok. oprendszert írok 2kB-ban :)

2.)
- oktatási intézmény weboldala
- ~300 visits/day (webalizer szerint)
- 5
- http://poli.hu

- 1997 eleje óta
- portálmotor: pár MB, SQL: kevesebb, mint 100 MB, statikus tartalom: bazi sok kép is videó, majd' 30 GB
- évente +30-40%

- Wordpress. Van még kérdés? (lassú, de legalább nem gyors)

3.)
- médiacég tartalomszolgáltató portálja
- ~20.000 visits/day (webalizer szerint)
- 7
- titok :)

- 2004 eleje óta
- portálmotor: pár MB, SQL: kevesebb, mint 1 GB, statikus tartalom: videók nélkül ~100 GB.
- évente +50% felett

- optimalizálás? napi 15 ezer egyedi IP, többmillió oldalletöltéssel, egy P4 2.6GHz 512MB RAM MySQL backend, és P4 3GHz, 1GB RAM apache2 frontenddel jó eredmény? :) (ez 2006 tájékán volt)

Köszönöm a részletes választ.

Szép eredmény szerintem. Ez valamejest megnyugtat, hogy avval a kis vassal ami nekem van (dual p3, 2,1Giga ram) is elég sokáig lehet húzni, jó kód és beállítások esetén.

### ()__))____________)~~~ ################
#"Ha én veletek, ki ellenetek?"#1000H/UbuFb

Off: Egy wikipedia, ami alapvetoen egy online lexikon 10-s interaktivitasu, de egy faszbuk, ami azt akarja, hogy mindent rajta keresztul csinalj csak 9? Wikipedianak meg akkora interaktivitasa sincs, mint a hupnak...

----------------
Lvl86 Troll