mariann 0 Zgłoś post Napisano Kwiecień 12, 2005 Witam. Nie znam sie na hostingu, a spotkal mnie nie lada problem. Potrzebuje serwera na witryne gdzie przewidywalny ruch to 50-60tys odslon dziennie i okolo 30tys userow. Czy wytarczy mi zwykly serwer wirtualny, czy powiniem myslec o rozwiazaniu z serwerem dedykowanym, a jezeli tak to czy musi byc on fizyczny czy moze byc wirtualny? Co jeszcze powinienem wziasc pod uwage? Udostępnij ten post Link to postu Udostępnij na innych stronach
Gość Fobi Zgłoś post Napisano Kwiecień 12, 2005 Witamy na forum, Duzo zalezy od samej strony, co na niej bedzie. Jak jest napisana. Czy jest to jakies forum/cms/crm ? Wszystko zalezy co to dokladnie jest i z jakich technologii korzysta. Odpowiadajac na szybko to zwykly hosting nie starczy. Pozdrawiam, Bartek Udostępnij ten post Link to postu Udostępnij na innych stronach
mariann 0 Zgłoś post Napisano Kwiecień 12, 2005 Dziekuje za odzew. Chodzi system CMS ktory bedzie dosc duzym serwisem typu "allegro". Serwis napisany jest przy pomocy php+smarty+ezSQL. Udostępnij ten post Link to postu Udostępnij na innych stronach
patryk 451 Zgłoś post Napisano Kwiecień 12, 2005 Tylko serwer dedykowany/kolokacja. Starczy do tego jakies Pentium 4 2,4 czy nawet Celek 2,6 + conajmniej 1,5 GB RAMu + dyski SCSI bo przy takiej liczbie odwołań do bazy dyski IDE będa wąskim gardłem. Udostępnij ten post Link to postu Udostępnij na innych stronach
patS 0 Zgłoś post Napisano Kwiecień 12, 2005 Witam, ezSQL to tylko (o ile się nie mylę abstrakcja na bazę danych), PHP jest językiem który się określa potocznie jako język pozwalający pisać "brudny/niechlujny" kod, ale znane są mi osobiście przykłady stworzenia 'pięknych' narzędzi w oparciu o niego. Smarty (biblioteka szablonów) - potężna i chyba najlepiej napisana biblioteka szablonów jaką widziałem w ostatnim czasie dla języka PHP, umiejętnie stosowana pomaga wiele. Ale teraz do rzeczy... 50/60 tys odslon dziennie... hmm.. ale co się kryje pod jedną odsłoną? Jedno/dwa zapytania SQL? Czy też może po 20 zapytań SQL? A być może 5 zapytań SQL ale napisanych źle, dla nie wydajnie zaprojektowanej bazy danych. Tak więc tą kwestię należało by rozstrzygnąć jako pierwszą. Kolejną sprawą jest cachowanie wyników, czy jest to rozwiązane optymalnie i czy jest wspólne dla wszystkich elementów? Czy też podzielone jest cachowanie na cachowanie wyników zapytań do bazy danych, cachowanie szablonów itd? A w samym outpucie czy cachowana jest całość czy tylko bloki dynamiczne? Powiem wprost, jest to troszeczkę wróżenie z fusów, swoiste mówienie o rybie w morzu, trudno bowiem określić rozwiązania sprzętowe pod coś co jest nie znane. Reasumując, jeżeli człowiek to kodujący, robił to z głową i nie jest to pierwsza tego typu aplikacja stworzona przez niego to jego należy spytać , to on powinnien jako jednocześnie analityk określić jak będzie wyglądało zużycie zasobów, oczywiście w jakimś progresywnym wykresie. Pozdrawiam _____ Edit: @patryk - nie do końca się zgodzę, 50-60 tyś wywołań to dla dobrze napisanego rozwiązania żadne obciążenie, odpowiedni mechanizm cachujący dla różnych aspektów aplikacji, dobrze zaprojektowana baza danych (nie 150 tabel i przy jednym wywołaniu 5 zapytań i joiny przez pół bazy), do tego kilka innych aspektów i napewno 1,5GB ramu nie będzie potrzebne, podobnie SCSI i 2,5Ghz procesor Oczywiście byłaby to sytuacja porządana ale nie róbmy paniki . @marian - ważnym aspektem jest też rozłożenie tych użytkowników w czasie (tzn wywołań serwisu), jak się będzie rozkładało czy będzie to 40 tyś odwołań miedzy 12-14 i pozostałe rozłożone czasowo przez całą dobę , czy też całość się rozkłada w miarę przystępny sposób w ciągu dnia?. Udostępnij ten post Link to postu Udostępnij na innych stronach
mariann 0 Zgłoś post Napisano Kwiecień 12, 2005 Dziekuje wszystkim za odpowiedz, Wiem teraz troche wiecej o tym na co mam zwrac uwage. Udostępnij ten post Link to postu Udostępnij na innych stronach
patryk 451 Zgłoś post Napisano Kwiecień 12, 2005 patS: oczywiscie, masz racje, ze jesli nie bedzie to PHPNuke + PHPBB by Przemo to obciazenie nie bedzie wysokie. Nie zmienia to jednak faktu, ze taki serwis nie ma raczej prawa bytu na zwykłym serwerze wirtualnym czy VPSie w ktores z popularnych firm bo nie sa one nastawione na klientow ktorzy zuzywaja tyle transferu i procka - nie mowiac juz o braku dostepu do powloki czy mozliwosci dowolnej "aranzacji" apache'a, czy php - dlatego dedyk wydaje mi sie jedynym rozwiazaniem.. Miałem "przyjemność" testowania popularnego oprogramowania CMS na średnio obciążonej maszynie z procesorem Duron 1400 i 256 MB RAMu i czasy generowania stron były nieakceptowalne, a wydajności tego właśnie zestawu dorównuje większość VPSów. Udostępnij ten post Link to postu Udostępnij na innych stronach