zainstalowałem sobie symfony... zasadniczo zaczynam z nim zabawę
i zrobiłem na razie najprostszy przykład w stylu 'hello world' odpaliłem i wyszło że generowanie trwało ponad 0,1 s
czy to nie aby trochę za dużo jak na uruchomienie samego frameworka...
chciałem się zapytać czy u was też tak chodzi i dla jak dużych serwisów używacie tego frameworka...

ten typ tak ma:)

malutka aplikacja u mnie - 2 zapytania to 400ms i 4,5MB pamieci.
jak chcesz robic szybki serwis na serwerze wspoldzielonym ze 1000 innymi podobnymi to lepiej wybierz inny FW np. Kohana.
jak masz dobra maszyne to symfony powinien sie nadac.
pytasz czy to nie za duzo - moze troche za. ale cos za cos.

"I gdyby przyszło tysiąc atletów,
i każdy zjadłby tysiąc kotletów
i każdy nie wiem jak się wytężał
- to nie udźwigną, taki to ciężar"

sorry, MSPANC

fw ogólnie są po to aby tworzyło się aplikacje szybciej, wygodniej, w jakimś schemacie itd. a wtedy sama prędkość działania schodzi na drugi plan (tym bardziej, że znaczna większość tych aplikacji to nie serwer killery typu NK ). Takie yahoo w ogóle sie tym nie przejmuje bo najwyżej dostawią sobie nowe serwery (info z prezentacji yahoo o budowaniu aplikacji)

The Definitive Guide to symfony :: Chapter 1 - Introducing Symfony :: Is Symfony for Me?

Ja do tej pory byłem zafascynowany Symfony. Jednak od jakiegoś czasu odchodzę od niego. Dlaczego? Właśnie z racji wydajnościowych. Do tego dochodzi Propel, który na początku mnie fascynował. Teraz zaczyna drażnić (dlaczego nie mogę pobrać samych id rekordów?). Miałem okres poznawania ZF ale również zaczął mnie denerwować. W końcu więc wróciłem do korzeni - Kohana. Możliwościami na pewno odstaje od w/w ale za to oferuje znacznie większa prędkość działania.

Swego czasu przeprowadziłem testy "aplikacji" wyświetlającej ogólny design strony, jakiś tekst powitalny, dane pobierane z bazy oraz generowany formularz (za pomocą wbudowanych w frameworki bibliotek) . Testy wykonałem z użyciem ApacheBench z parametrami -n10 -c2. Oto wyniki (pierwsze uruchomienie pominąłem, zliczałem tylko drugie):

Kohana:


Zend Framework:


Symfony (1.1, prod):


Wiem, że próbka mała i wyniki nie są do końca miarodajne no ale... jakieś tam pojęcie jednak dają.

@mike: tak czytałem to, ale nie bardzo rozumiem co mi chcesz przekazać...
tak w skrócie w tłumaczeniu (mój angielski nie zawsze jest taki jak bym sobie życzył, więc aby się upewnić że dobrze rozumiem ):
jeśli robisz małą stronkę, w której jest ograniczony dostęp do bazy, nie ma specjalnych wymagań co do wydajności i dokumentacji. to niewiele dostaniesz od frameworka i mvc

z drugiej strony jeśli będzie złożona z skomplikowaną logiką, do rozszerzania, lekka, czytelna etc
symfony jest dla Ciebie

ok do rozszerzania symfony z pewnością się nada, czytelna prawdopodobnie też jest
ale jeżeli ładowanie konfiguracji w symfony (profilowałem sobie na localu xdebugiem) trwa dłużej niż wygenerowanie strony kohany przez kohanę...
to mam wątpliwości co do jej lekkości...

tzn. nie chce porównywać... tu local tu jakiś inny serw, tu taki fw tu taki, to nie ma za bardzo sensu,
przejrzałem sobie filmik odnośnie "admin generator" w symfony i mimo że to w sumie kolejny język do nauki... to bardzo ładnie wygląda tworzenie panelu admina... i chętnie bym se to wykorzystał...

pytam po prostu bo strona którą będę pisał ma być dość duża, logika pewnie jak w większości stron -> CRUD i mała oprawa wyników, rozszerzać prawdopodobnie będę potrzebował... ruch może być dość duży..., serw to prawdopodobnie będzie dedyk... i po prostu nie chciałbym żeby się okazało że będzie potrzebna np. druga maszyna albo przepisanie na coś bardziej "zwiewnego"

@phpion: wprawdzie nie czytałem o symfony wiele ale z propela nie musisz korzystać..., ale jak patrzę czasem na sekwencje w stylu
$query->select('')->from('')->join('')->where('')->limit('')->i tak dalej to mi nie dobrze... ta sekwencja z reguły wychodzi dłuższa niż gdyby się sql napisało...
propel z tego co pamiętam wygląda trochę inaczej ale zdarza sie że i tak sql trzeba napisać...

tak trochę OT: odnośnie sql ja bym z niego tylko fromy i joiny wyrzucił do jakiegoś configu DB gdzie by były relacje... reszta zapytania by była bardzo znośna ale fromy i joiny imo są męczące...

zasadniczo z tego co pamiętam i co mi się rzuca na myśl to SQL jest językiem wyższej generacji bardziej zrozumiałym dla człowieka więc jego "emulacja" w języku niższego poziomu jest dziwna, spróbujmy to rozpisać od razu na assemblera..


no ale wracając do tematu...
nikt nie odpowiedział mi na jakich stronach udało się wykorzystać symfony... jaki ruch na stronie ten framework przeżył, ew. na jakiej maszynie... tzn. mam na myśli dedyku czy virtualach czy czym...

Wiem o tym doskonale, jednak w takim wypadku, wg mnie, mija się z celem używanie bajerów wbudowanych w Symfony. Dodatkowo nie podoba mi się tworzenie "bezpiecznych" typów dla kolumn w bazie danych. Nie mogę użyć CHAR, nie mogę (korzystając z PostgreSQL) użyć pola BOOLEAN lub też typu tablicowego. Ogólnie mówi się "jeśli coś jest do wszystkiego to jest do niczego". Nie twierdzę, że Symfony to badziew (w żadnym wypadku!) tylko, że czasem może się okazać, że jest inne (lepsze) rozwiązanie.


http://trac.symfony-project.org/wiki/Appli...opedWithSymfony

@phpion

ok, kumam

ok, dzięki za link ale chodziło mi raczej o stronę + odwiedzalnosć + rodzaj serwa

nie mniej przejrzałem polskie:
Pytamy.pl na serwerach wp... im maszyny specjalnie nie robią...
Mp3p.pl - zmienili serwer i przepraszają za niedogodności jakie były... naturalnie może być wina samego skryptu
Mokate, Marzuski, Matpoż, BHP MAX Niedzielscy s.j. - strony firmowe czyli raczej mały ruch
tonieproblem.pl - jeszcze nie ruszyła
Portal Pielęgniarek i Położnych - może być duże ale nie mam pojęcia...

to nie wygląda zbyt zachęcająco...

jak ktoś by rzucił: stronę + odwiedzalnosć + rodzaj serwa byłbym wdzięczny

Zimi taki test jak zrobiłeś na początku jest bez sensu - test typu hello world nie mówi nic o szybkości frameworka - kompletnie nic.

Z symfony jest tak, że na początku daje spory narzut. Ale z czasem gdy rozwijasz aplikację i dodajesz takie rzeczy jak np. ograniczenia dostępu do podstron, prawa użytkowników, filtry, dodatkowe moduły stanowiące tak naprawdę mini aplikacje itd itp. To wtedy symfony już to ma natomiast w php musisz to wszystko dopisać i aplikacja zwalnia.

Mimo wszystko jednak symfony jest raczej "wolnym" frameworkiem (moim zdaniem głównie za przyczyną propela - sam framework odpowiednio dużej aplikacji będzie raczej tak samo szybki jak każdy inny). Z drugiej strony symfony ma bardzo prosty mechanizm cachowania więc newralgiczne części strony można bardzo ładnie cachować przez co wydajność nie stanowi aż tak dużego problemu.

Co do ograniczeń Propela - to nie wiedziałem, że nie można pobrać tylko jedego/kilku pól - dziwi mnie to zwłaszcza, że robię to niemal codziennie ;-) Propel to jest narzędzie do operacji typu CRUD i nic więcej. Nie wymagajmy od niego żeby dało się nim zrobić wszystko i jeszcze żeby był szybki. Jak na ORM do php propel ma bardzo duże możliwości i imho nieźle balansuje pomiędzy szybkością a ilością opcji jaką oferuje. Byłbym nawet skłonny trochę go okroić jeśli dałoby to wzrost wydajności. Każde nietypowe zadanie można zrealizować w propelu półautomatycznie i to mi wystarcza.

Ogólnie Symfony oferuje bardzo wiele opcji, których nie znajdziesz w innych projektach. Wydajność jest moim zdaniem "akceptowalna" - na pewno małe frameworki są szybsze. Z drugiej strony im większa i bardziej skomplikowana aplikacja tym ta różnica się zaciera.
Ja odkąd zacząłem pracę z symfony to nie wyobrażam sobie pracy z innym frameworkiem. Przy dzisiejszych cenach wolę dokupić lepszy pakiet/serwer niż pracować na projektem 3x dłużej.
Jeśli priorytetem jest wydajność to symfony może nie być najlepszym woborem (tak na prawdę żaden frameworki nie będzie wydajniejszy od kodu dobrze napisanego od zera), ale nie demonizujmy dobrze napisana aplikacja w symfony to nie jest wolna krowa - po prostu trzeba umieć użyć cachowania i czasami w paru miejscach zrezygnować z propela.

@athabus: imho bezsensu to by było jakbym sobie zrobił echo 'hello world'; i powiedział że wykonuję się o 4 rzędy szybciej...
nie nazwałbym tego testem ale sprawdzaniem narzutu jaki symfony daję... i przy profilowaniu wyszło że połowa czasu to było ładowanie konfiguracji...a druga połowa rozpakowanie żądania, więc czy zrobię cache-a czy nie to raczej nieunikniony narzut... (?)


chcesz mi powiedzieć że dla każdej aplikacji nawet kalibru hello world odpalane są "ograniczenia dostępu do podstron, prawa użytkowników, filtry, dodatkowe moduły stanowiące tak naprawdę mini aplikacje", nie wiem jak to działa ale zdaję się że sensowne by było że to zadziała jak tego użyjesz...
a jeśli zadziała jak tego użyjesz to zwolni tak samo niezależnie czy Ty to napisałeś czy ktoś inny kto wbudował to we framework
ten fragment Twojego posta jest dla mnie nielogiczny/niezrozumiały

inaczej... chcę robić projekt duży, ktoś tam chce trochę kasy władować w ten projekt i nie chciałbym żeby się okazało że na serwerze który jest planowany gdy wejdzie na www np. 100 osób online, strona padnie i się żywcem pogrzebię

zasadniczo nie wiem czy na stronie będzie 10 osób online czy 1000... ale biorąc pod uwagę fakt że trochę chcą w projekt władować raczej się nastawiam na dużo...

Chodzi mi raczej o to, że robiąc hello world ładujesz całą konfigurację - ale z twojej odpowiedzi wnioskuję, że twój test miał na celu właśnie sprawdzenie tego ile się będzie ładować konfiguracja więc w tym sensie to miało sens ;-) Myślałem, że będziesz kolejną osobą która zrobi test wydajności frameworka pisząc w każdym prostą aplikację -takich testów jest już sporo w sieci.

Co do użycia dodatkowych modułów - nie zagłębiałem się jak to dokładnie działa. Ale w symfony np. ustawienie zabezpieczenia hasłem dla akcji/modułu to słownie 1 linia w plikach konfiguracyjnych. Z tąd niezależnie od tego czy go używasz czy nie moduł musi być sprawdzany czy jest bezpieczny czy nie.

Co do filtrów itp - tak nawet dla prostej aplikacji jest uruchamiane wiele filtrów, dekoratorów widoku itp. W każdej aplikacji korzysta się z tych rzeczy. Trudno byłoby stworzyć w symfony aplikację, która np. nie dekoruje widoku szablonem głównym itd (można to wyłączyć, ale domyślnie jest to opcja włączona). W symfony book jest cały rozdział poświęcony "tuningowaniu" aplikacji - domyślnie w symfony wiele rzeczy, z których się często korzysta są włączone - np. ładowane są często stowsowane helpery do tworzenia urli itp. Można to wyłączyć, ale w praktyce każdy widok wyświetla jakiś url, więc po co? Wiadomo w hello world się tego nie użyje, ale już każda nawet mała stronka korzysta z takich udogodnień.

Ogólnie w konfiguracji symfony ustawia się bardzo wiele rzeczy, które powodują moim zdaniem wstępne zwolnienie aplikacji, ale potem nie musisz tego kodować ręcznie więc ilość wykonanego kodu pozostaje bez zmian. Pamiętaj, że wiele z tych rzeczy możesz wyłączyć, jeśli twoja aplikacja jest specyficzna.

Ogólnie co próbuję powiedzieć to: symfony przy większych aplikacjach ma już wiele rzeczy wbudowanych napisanych i uruchomionych, inne frameworki bazują trochę na zasadzie, że włączają wszystko oprócz swojego rdzenia na wyraźne komendy programisty. W obu przypadkach wychodzi jednak na to samo, bo 90% tego co jest włączone defaultowo w symfony włączysz ręcznie w innych frameworkach przy prawie każdej aplikacji. Stąd ostateczne porównanie prędkości aplikacji napisanej w symfony i w innym frameworku nie wygląda tak źle jak na początku (choć symfony jest imho raczej wolnym frameworkiem).
Z drugiej strony wiele rzeczy w symfony możesz wyłączyć i w ten sposób przyspieszyć całą aplikację.

BTW przy obciążeniu rzędu 1000 osób online to raczej i tak będziesz musiał sporo pozmieniać we frameworku - przy takich obciążeniach zaczyna się raczej robić swoje własne (sub)frameworki dedykowane dla danej aplikacji.

Za jakiś czas będę miał średnio-mały serwis (planowane kilka tysięcy... miesięcznie) na home.pl, wówczas napiszę, jak to się sprawuje. Co do wydajności przy projektowaniu. Przeciętny request w adminie, to 10-15 zapytań, w tym 2 obciążające. Czas: 200-900 ms bez cache i 200-800 z cache. Różnica niewielka, zwłaszcza, że tylko niektóre elementy można cechować. W części publicznej uśredniony czas to 130 ms bez cache i 10 zapytań. Łatwość tworzenia przewyższa braki wydajnościowe. Niezrozumiała powolność propela to mit. Zobaczcie, ile trwają zapytania - tyle samo, co normalnie, a potem zobaczcie, że to czas zabierany przez Propel na utworzenie obiektów wraz z powiązaniami jest problemem. Nie zawsze trzeba pozyskiwać obiekty, a na pewno nie po to, aby dostać ID rekordu Trzeba się też nauczyć korzystania np. z metody doSelectJoinAll() i nagle wydajność wzrasta, to zamiast np 5 zapytań do powiązanych tabel, wykonuje się jedno.

Pozdrawiam.

gwoli ścisłości: kilka tys. miesięcznie to ledwo kilkadziesiąt dziennie - to ani średni, ani mały, tylko miniaturka, jakiś promilek, tyci tyci. Nie, nie chcę tutaj żadnego flejma robić ale akurat nazwanie tej ilości "średnio-małą" jest nieporozumieniem Przy takiej ilości to mozna by po 3 instancje Symfony odpalać i serwer by się nie zorientował nawet

Robiłem jeden mały (średnio mały? ) serwis, który ma ~10k UU na dobę. Kohana 2.1, lighttpd, dedyk 4letni AMD, 1 GB ramu, stare wolne dyski. Load średni 0,2 CPU 15%. Minimalizacja kosztów. (Jaki tu jest jeszcze zapas mocy!!! prędzej dyski wysiądą )

Jak ktoś (jak Yahoo) nie musi się w ogóle przejmować tymi sprawami to może spokojnie wybierać sobie dowolne narzędzia. A nie da się ukryć, że łatwiej wpuścić Symfony w zespół niż wszystkie pozostałe FW.

Cysiaczek jest dokładnie tak jak piszesz. A co do propela to na prawdę jest on wolny - ale tak jak piszesz nie obciąża bazy danych a sam parser php. W newralgicznych punktach często lepiej obejść się bez propela bo przy skomplikowanych joinach potrafi nieźle zamulić ;-)

Co do cache to w czasie testów na localhost nie widać dużych różnic, ale na serwerach współdzielonych 90% problemów z wydajnością leży po stronie bazy danych - tam po cachowaniu wydajność wzrasta znacznie. Kiedyś miałem przypadek, że przepisałem aplikacje na propela (bez symfony użyłem tylko propela jako ORM) - stara aplikacja wykonywała ~20 zapytań, nowa ~5. Na localhost nowa aplikacja była 2x wolniejsza od starej - ale po wgraniu na serwer nowa była ponad 3x szybsza - po prostu propel generował duży nakład pracy dla parsera co spowalniało go na localhost - na hostingu natomiast problemem była baza danych więc zmniejszenie liczby zapytań dała dużego bosta. Po tamtym doświadczeniu wiem, że prędkość działania aplikacji to rzecz względna ;-) Cachowanie jest opłacalne w środowisku produkcyjnym chociaż czasami nie widać znaczących różnic podczas testów.

Cysiaczek, moim zdaniem zamiast robić doSelectJoinAll (który pobiera wszystkie tabele powiązane, nawet te których nie potrzebujemy) lepiej jest skorzystać z sfPropelFinderPlugin.


Moim zdaniem jak na możliwości sf to bardzo szybko działa. Domyślam się, że bez specjalnych zabiegów (akceleratory, pluginy).

Sf jest wolne ale w tej dyskusji padło pare argumentów, które jednak przekonują do niego. Reszta jest w książce.

@normanos chyba trochę opacznie rozumiesz yahoo. Wydaje mi się, że dla nich ma znaczenie optymalizacja. Każdy błąd w optymalizacji w ich przypadku może wymagać wielotysięcznych nakładów w infrastrukturę. Ja raczej odczytuję ich wypowiedzi w kontekście "wydajność to nie wszystko - lepiej dołożyć trochę sprzętu aby zaoszczędzić na budowie i rozbudowie aplikacji". Bo prawda jest taka, że dzisiaj już nawet dedyka możesz mieć za śmieszne pieniądze.

Co do obciążenia 1000os/miesiąc to faktycznie bardzo mało (choć pewnie 95% stron tego nie osiąga). Z kolei 10.000/dobę to już całkiem sporo jak na polskie realia i zużycie sprzętu faktycznie bardzo małe - choć wiadomo wszystko zależy od typu aplikacji, średniej ilości oglądanych stron, jej złożenia itd bo np. 50 osób online na gołym phpbb a phpbb by przemo to jest spora różnica.

Ale na pewno zgodzę się, że jeśli chodzi o wydajność to kohana jest lepszym wyborem niż symfony.

no dobra to z trochę innej beczki... chyba podjąłem już decyzję...

co do jednego myślę wątpliwości nie ma... 90% całych zasobów serwa to i tak bedzie baza danych... prawie na pewno...

poprosiłem osobę której pisałem dużą stronę (w uznanej w topicu nomenklaturze średnio-małą ) o "zeznania" odnośnie serwa

jaka konfiguracja serwa jest nie wiem
strona była robiona jakiś czas temu... za siedmioma górami za siedmioma lasami :P w trzeba przyznać niezbyt piękny sposób... pisana w całości przeze mnie... bez OOP bez DRY bez MVC, metoda copy-paste domyślam sie że możecie sobie wyobrazić...

jest na niej troche danych i trochę ruchu... zintegrowana z forum phpbb które pokazuję w tym momencie około 90 użytkowników online

około 3k uu dziennie, widziałem że niektóre żądania trwały długo za długo... jak próbowałem je powtórzyć wychodziły w znacznie krótszym czasie wiec to olałem... zastanowię się jeszcze o powody ale to nieważne...

strona chodziła też przy większym ruchu max online wg phpbb to ponad 250, ok 8k UU dziennie niegdyś... i strona chodziła... problemów nie było...

pobrałem więc "próbki" średnia arytmetyczna czasu na żądanie to ok. 0,8 s bez tych niezindentyfikowanych bardzo długich... z nimi ok. 1,2 s (swoją drogą dziwne to było dosłownie kilka wejść ale generowanie trwało nawet 2 min O.o, a jak wszedłem w to samo miejsce czas 0,2 albo 0,4 s no ale nieważne)

problemów z serwem nie ma... ale dedyk... więc czy symfony dorzuci mi 0,1 s czy 0,2 to jakoś mnie to już nie przeraża...
ale jak zacznie szarżować będzie problem... jednym słowem pobawię się w symfony... i zobaczę co ono na to

EDIT: aha i dziękuję wszystkim za opinie... chętnie również poczytam kolejne

A ja Propela zarzuciłem, od kiedy odkryłem dla siebie Doctrine. Nie wiem jak tam z wydajnością - ale każdy ORM jest tutaj gorszy od czystego SQL-a. Tyle że Doctrine ma cache-owanie zapytań, hehe. Za to DQL (coś a'la sfPropelFinder) mnie na łopatki rozwalił. I proszę mi tu nie pisać o "never-ending line", bo entera chyba każdy umie używać.

~qqrq Doctrine ma jeszcze lata świetlne do Propela jeśli chodzi o niektóre możliwości. A poza tym jest wolniejszy.

@normanos - no średnio-mała kurcze - jakieś 10k odwiedzin, ale już odsłon przynajmniej 100k
Wiem, że serwer się nawet nie spoci hehehe, ale na shared hosting to jest i tak dużo (transfery).

POozdrawiam.

trochę obok tematu ale nie będę robił nowego dla akcentu humorystycznego ;P

grafy chyba nie wymagają komentarza (odwołania - co, gdzie). graf zenda normalnie mnie rozłożył była by z tego dobra gra planszowa

Symfony:
http://phpimpact.files.wordpress.com/2008/08/symfony.gif

ZF:
http://phpimpact.files.wordpress.com/2008/...blog-db-hor.gif

Ale śmietnik.

jeszcze trzebaby dorzucić parę zasad
np. po liniach przerywanych można chodzić tylko gdy ma się nieparzystą liczbę oczek a po ciągłych gdy parzystą
albo po liniach prostych można chodzić tylko na trzeźwo, a po falujących tylko po kolejce
a na 'skrzyżowaniach' trzeba uważać czy ktoś inny nie robi ruchu
pole końcowe to to z Exception :P po kilku kraksach albo kolejkach będzie Exception :P więc się nadaję

idę po pionki, kto gra?:P

PS. ten post podchodziłby pod 'pomógł' w temacie 'wybór frameworka'

Edit: zapomniałem dopisać że chyba trzeba się przerzucić na ZF jak widać musi dawać dużą radość tworzenia

Graf całkiem ciekawy, ale nie nie ma co demonizować ;-).
ZF jest dobry jak się wie co się chce zrobić. Nie wiem jak teraz, ale korzystałem z jakiś tam bet (chyba 0.2 i 0.7) i całkiem przyjemny ten framework tyle tylko, że więcej czasu zajęło mi złożenie tego do kupy niż pisanie samej aplikacji - co gorsza był to pierwszy framework jakiego używałem i popełniłem kilka "kluczowych" błędów co odbijało się potem na jakości kodu. Teraz korzystam z niektórych części ZF bo są nieźle udokumentowane i dość jasno napisane. Raczej jednaj nie wrócę do niego jako frameworka, bo nie potrzebuję aż takiej elastyczności - wolę uzyskać większą szybkość pisania.

Jako ciekawostka - w tym frameworku stworzyłem sobie kilkanaście rozwiązań typu helpery, dodatkowe metody kontrolerów itp. - potem ucząc się symfony większość z tych rozwiązań była w podobnej formie już zaimplementowana w tym frameworku - aż dziwne, że nie znając podobnych rozwiązań stworzyłem je "od zera" w podobny sposób jak były zaimplementowane w innych frameworkach...

Jakie? Nie wiem o czymś ważnym?

Relacje między obiektami i ich wykorzystanie jest w Doctrine bezużyteczne.

Przykładzik?

Po odpowiednim zdefiniowaniu encji w schema.yml masz na przykład coś takiego:

[PHP] pobierz, plaintext 
<?php
 
/* @var $category Category */
$category->Articles; // "ładne" pobranie artykułów z kategorii
 
?>
[PHP] pobierz, plaintext 

Taki system operowania na relacjach jest całkowicie bezużyteczny ponieważ w 99% przypadków kończy się na klepaniu własnoręcznie zapytań za pomocą Doctrine_Query. Docrine nie pozwala na wstrzykiwanie dodatkowych kryteriów do takich zapytań co czyni ten system kompletnie nieprzydatnym do czegokolwiek.

no fakt - kompletnie. zastanow sie co mowisz - po to wlasnie jest dql zeby miec dane i zaleznosci miedzy nimi takie jak sie chce.

jak ktoś ma 100k odwiedzin to chyba nie potrzebuje sie dzielić maszyną na hostingu