Postnuke & Serwer

[Erem 0]

Witam,

Postnuke jest "żarłocznym" systemem bardzo obciżającym serwer (jak większość nuków). Hostingi przynajmniej niektóre się przed nim bronią. Stąd moje pytanie, czy jest możliwość wydzielenia zasobów serwera (zużycie pamięci, procesora) tak aby nie spowalniał pracy pozostałych serwisów na serwerze?

Druga moja wątpliwość, czy hostingi "z górnej półki" (te droższe) na swoich serwerach mają mniej kont, czy po prostu mają lepszą konfigurację serwerów?

Wyczytałem gdzieś, że postnuka można trzymać na serwerze do ok 300 unikalnych wizyt dziennie. Co o tym sądzicie?

[dziku 0]

Witam,

Postnuke jest "żarłocznym" systemem bardzo obciżającym serwer (jak większość nuków). Hostingi przynajmniej niektóre się przed nim bronią. Stąd moje pytanie, czy jest możliwość wydzielenia zasobów serwera (zużycie pamięci, procesora) tak aby nie spowalniał pracy pozostałych serwisów na serwerze?

Mozna ograniczyc ilosc odwolan strony do bazy mysql co poskutkuje albo wyłożeniem sie postnuka albo spowolnieniem jego pracy. O ograniczaniu zyzycia procesora na serverach typu shared nie slyszalem, natomiast mozna z poziomu php ograniczyc ilosc pamieci dla plikow. Z tym ze wtedy ograniczasz wszytskim a nie tylko tej osobie. Jesli sie myle to prosze mnie skorygowac

 

Druga moja wątpliwość, czy hostingi "z górnej półki" (te droższe) na swoich serwerach mają mniej kont, czy po prostu mają lepszą konfigurację serwerów?

 

Lepszy support, serwery w Europie. I z reguły tak jak zauważyłeś są to serwery z wyższych półek.. Wysokobudżetowa firma nie kupuje Celeronów.. Co innego firmy z małym budżetem.. One startują z reguły z resellerów bądź zaczynają od Celeronów by kiedys w przyszłości przenieść dane na mocniejsze maszyny typu P4 , Xeon, AMD Opteron, z dysków IDE/SATA na SCSI...

 

 

Wyczytałem gdzieś, że postnuka można trzymać na serwerze do ok 300 unikalnych wizyt dziennie. Co o tym sądzicie?

Zalezy na jakim... Jesli masz swoj jeden dedykowany tylko pod swoja strone to mozesz miec 5 x wiecej odwiedzin i nic sie nie stanie, ale jeśli hostujesz sie na czyimś serwerze, musisz uważać żeby twoje sktypty nie były zbyt proceso lub pamieciożerne...

[patryk 451]

Mozna ograniczyc ilosc odwolan strony do bazy mysql co poskutkuje albo wyłożeniem sie postnuka albo spowolnieniem jego pracy. O ograniczaniu zyzycia procesora na serverach typu shared nie slyszalem  

 

Apache - RLimitProc (liczba procesow), RLimitMem - w przypadku przekroczenia przydzielonej ilosci zasobow wywali odpowiedni komunikat .

[Erem 0]

Dziękuję za odpowiedz

Podsumowując:

Technicznie da się zamknąć postnuka w "klatce", ale skutki mogą być opłakane :? (w skrajnym przypadku),

Jak stawiać już serwis na PN to na mocnym serwerze (czytaj: droższym),

a najlepiej na dedyku (w skrajnym przypadku :cry: ),

I to co nie zostało powiedziane taniej (nie znaczy lepiej) przejść na inny skrypt CMS (pisanie własnego odpada), może mambo? :idea:

[Ranma_man 0]

Ja bym wybrał drupala: http://drupal.org , nie ma stopki inforumujacej o skrypcie, ma bardzo duzo dodatkowych modulow pare roznych silnikow szablonow, przepustnice, ktora zarzadza odpowiednio modulami w przypadku obciazenia serwera itd. itp. Główną wadą jest to, że ma mało gotowych typow tresci zrobionych i trzeba za pomocą specjalnych modułów dodawać / tworzyc samemu (np. system katalogu linków, wybieramy z listę pole do wpisywania linka, pole do wpisywania tekstu itd.), bawić się w kategoryzacje itp., ale jak się włoży w konfigurację tego wszystkiego trochę czasu to wyniki są bardzo dobre.

[Erem 0]

Może trochę odbiegam od tematu. Z uwagi na to, że na forum jest dużo przedstawicieli firm hostingowych chciałbym dowiedzieć się (może nie tylko ja ) ), które CMS-y (jeżeli przyjmiemy, że nie ma innego wyjścia :? ), chcieliby widzieć hostingodawcy na swoich serwerach? To samo dotyczy skryptów forum.

(podaje kilka przykładów)

CMS:

1. Php-fusion

2. Drupal

3. Mambo

4. Postnuke

5. Php-Nuke

6. Typo

 

Forum:

1. IPB

2. vBulletin

3. PunBB

4. PhpBB2

5. PhpBB by Przemo

6. SMF

 

Myślę, że to w jakiś sposób zainspiruje użytkowników i da im do myślenia :wink:

[patryk 451]

5. PhpBB by Przemo

 

To jedyny przyklad tego czego definitywnie nie lubie widziec, a musze czesto .

[Ranma_man 0]

Z CMS'ami to ciężko jest. Jeśli zaś chodzi o skrypty for, to sprawa prosta, albo IPB albo vB, kwestia gustu, ale ja bym wybrał IPB ze względu na bezpieczeństwo. vB po prostu zalicza więcej kompromitujących wpadek, jak np. to. Z darmówek wybrałbym bezdyskusyjnie SMF.

[RebelPanther 0]

CMS typu Nuke czy PN są napisane na zasadzie opracowania ich szkieletu, a resztę tworzy cała społeczność nuke'owa, więc siłą rzeczy kod jest często jak wesoła twórczość.

 

Moje rady - jeśli już używasz Nuke lub PN - poświęć kilka dni i poczyść kody z niepotrzebnych odwołań. Np. montujesz blok pokazujący zalogowanych użytkowników - ale interesuje Cię tylko by byli wykazani, a nie wyświetlanie ostatnio zarejestrowanych, podsumowań ile zapisało się w tym miesiącu itp. Więc usuń z kodu tego bloku te fragmentu, w których blok komunikuje się z bazą w celu pobrania danych do obliczeń i zestawień, które Cię nie interesują - oczywiście bacząc, by nie wywalić całego kodu w przestrzeń kosmiczną.

 

Jest to ciężka robota, żmudna, ale dla chcącego....

 

Druga rzecz: jak najmniej bajerów na stronie głównej - czyli jakichś "Ostatnio dodane pliki", "Ostatnio dodane linki", "Najnowsze ogłoszenia", itp, itp.... Każdy taki blok generuje dużo odwołań do bazy - przez co możesz mieć mało osób obecnych na stronie, a przeciążenie wystąpi i tak. Wystarczającym obciążeniem strony głównej jest system newsowy - nie ma co przesadzać z nadmiarem, zawsze można użytkowników kierować poprzez link w menu.

 

Trzecia rzecz: postaw na.... html. Samemu zrób szablon templatesa i np. zamiast menu z gotowego bloku zrób własną wstawkę kodu. To, co się na stronie nie zmienia (np. menu) lepiej mieć opracowane jako statyczne - znów się kłania ograniczenie odwołań. Jeśli masz galerię i chcesz w bloku losowy obrazek - skorzystaj z prostego skryptu php pobierającego losowo grafikę ze wskazanego katalogu - ominiesz tym samym bazę.

 

Mogłabym tak jeszcze godzinami pisac, ale podejrzewam, że już się rozglądasz za brzytwą

[Erem 0]

RebelPanther wymieniłaś większość "grzechów głównych" portali opartych o PN (w tym mojego ). "Obcinanie" bloków zmniejszy zużycie zasobów serwera, ale co pozostanie za postnuka? . Cały "power", który ma PN tkwi w jego blokach i elastyczności (no może prawie cały).

No i tu dochodzimy do wniosku, "coś kosztem czegoś".

Więc pora już zacząć się rozglądać za nowym hostingiem. Zbliżają się święta i niektóre firmy (hostingodawcy) robią "porządki", a szkoda bo Postnuke dobrym cms-em jest :wink:

[Kacper Warda 0]

Może jestem trochę nieżyciowy, ale jeśli potrzebuję jakiegoś systemu for, czy czegoś w tym rodzaju, i jeśli znam się na rzeczy, najlepszym (moim zdaniem) pomysłem jest zrobienie go samemu, co jest tylko kwestią czasu, sprawia niemałą frajdę i dodatkowo pozwala zaimplementować tylko i wyłącznie taką funkcjonalność, jaką chcę. Ni mniej, ni więcej.

[Erem 0]

Problem zaczyna się już na samym początku, czy zajmować się stroną techniczną serwisu, czy merytoryczną ?

Nawet przy wykorzystaniu gotowych skryptów pogodzenie w/w czynności czasami rodzi problemy :? .

Napisanie samemu (pomijając umiejętności do tego potrzebne :? ) potrzebnych skryptów jest dobrym rozwiązaniem dla serwisów o dużej oglądalności.

W moim przypadku (może w większości innych) wybór ogranicza się do:

1. Optymalizacji skryptu, tak jak to radzi RebelPanther (rozglądam się za brzytwą :-D ),

2. Zmiany skryptu (CMS-a) na inny,

3. Zmiany hostingu na inny - droższy ( nie koniecznie lepszy :-( ).

 

Wracając do tematu "nadrzędnego" - technicznego, które skrypty (cms-y, fora) uważacie za "optymalne" technicznie (zużycie zasobów), funkcjonalnie (możliwości prezentacji treści)?

[beloved 0]

A zobaczcie tu benchmarki:

http://www.cms.rk.edu.pl/Benchmark_C...yptow___8.html

 

i tu:

benchmark pamięci

 

Używam Mambo z 30tys. odwiedzin / mies i juz się martwię...

[Erem 0]

Oglądałem ,

Mam zamiar powtórzyć testy Rikiego przy włączonym cachowaniu dla Postnuka (Xanthia) i Joomli.

Trochę mnie zaskoczyło duże zużycie pamięci przy mambo/joomla. Widocznie "uniwersalny szkielet" wymaga odpowiednich zasobów.

 

Używam Mambo z 30tys. odwiedzin / mies i juz się martwię...

 

To chyba jeszcze za wcześnie

[beloved 0]

To chyba jeszcze za wcześnie

Nie za wcześnie. Mam jeszcze dwa inne serwisy i kilkadziesiąt mniejszych i admin serwera twierdzi, że już mu zżarłem 40% zasobów, głównie przez te 3 serwisy. W tym Mambo jakieś 10%. Namawia mnie na przejście na dedyka.

[Piotr Mikołajski 0]

A zobaczcie tu benchmarki:

Ja bym się nimi aż tak mocno nie sugerował - przy części skryptów nie ma praktycznie żadnych informacji o wersji czy skinach, co IMHO podważa wiarygodność całego zestawienia. Różnice w bebechach między np. Mambo 4.5.109 i 4.5.3h będą znaczne, podobnie jak między Joomla 1.0.1 i 1.0.8.

 

Poza tym liczenie czasu ładowania się pierwszej strony jest generalnie średnim pomysłem. Defaultowy skin może być zbudowany na tabelkach w tabelkach i wsadzonych w kolejne tabelki, co raczej generowania strony nie przyspiesza. Może też być wyposażony w piękny nagłowek ważący 80kB, który również lekkości nie daje. Przerobienie pierwszej stronie na układ beztabelkowy plus lekka grafika zmienią czas ładowania się strony głównej dość mocno i cały test bierze w łeb

 

Znacznie lepszym testem byłby test obciążenia bazy danych (iloścy zapytań) i coś w tym stylu zrobiono:

http://www.cms.rk.edu.pl/Liczba_zapytan_do...Sach___111.html

Niestety, najświeższy nie jest, o czym świadczy np. skrypt Mambo w wersji 4.5.1 Beta 4 - wypuszczonej 12 sierpnia 2004. Mambo 4.5.1 Stable wypuszczono 23 września 2004. Wychodzi zatem, że ów test ma blisko dwa lata, czyli jest bezużyteczny

 

Gdybyście rzeczywiście chcieli powtórzyć takie testy, to prosiłbym o dokładne opisanie:

- wersji skryptu;

- rodzaju instalacji;

- konfiguracji sprzętu;

- procedury testowej;

- wersję z cache i bez cache;

 

Oprócz tego dobrze byłoby dorzucić parę mniej znanych skryptów, jak np. FUDforum, K4BB czy WTCBB. Pierwszy jest tworzony przez dewelopera PHP, drugi jest opakowany w AJAX, trzeci jest pewnego rodzaju klonem vBulletin. Zawsze to jakaś alternatywa dla phpBB

[Ranma_man 0]

Jeżeli dobrze zauważyłem, to ten test można wyrzucić do kosza z prostej przyczyny. Skrypty nie były testowane przy solidnym zapełnieniu baz danych. Co mi po testach czystych skryptów i na dodatek strony głównej, skoro może się okazać, że ten najszybszy po jakimś czasie zacznie ostro mulić? Przecież może się okazać, że skrypt, który teraz jest wolny, w miarę rosnącego obciążenia zacznie wyprzedzać inne.

 

Test powinien oprzeć się na pomiarze w różnych stadiach rozwoju witryny, że tak powiem, aby potem z uzyskanych danych dało się wyrysować wykres, który w przybliżeniu wskazałby ładną krzywą zależności pomiędzy objętością a zużyciem zasobów serwera.