MaXyM

Za to ja musze powiedziec po pol roku uzywania hostingu progreso (s7), ze nie mamy zadnych problemow. Strona ktora u innego hostera kulala i wymagano od nas ciagle optymalizacji skryptow, tu smiga bez problemow mimo ze dzienna ilosc odwiedzin sie prawie podwoila. Takze, jesli kto potrzebuje dobrego hostingu - moge szczeze polecic.

NO i bardzo dobrze ze bedzie taka firma krzak o ile obok beda do wyboru rzetelne alternatywy. Wtedy jeden klient z drugim po pol roku stwierdzi ze nie ma co siedziec u krzakow. i albo pusci ich z torbami zglaszajac sprawe do sadu, albo po prostu przejdzie do lepszej choc i drozszej moze firmy.

Powiem ze jest OK. Na takiej zasadzie dziala kazde forum. Uprzedze moze: wielkosc bazy danych nie ma tu zadnego znaczenia, bo przy poprawnym modelu db, czy to jest 100MB czy 20GB to jest obojetne. Problem w tym, ze zeby wyprowadzic z bazy te 20GB textu musi nastapic duzo hitow na strone. A tego juz hostingi shared nie potrafia czasem udzwignac. Tylko skad wlasciciel takiego forum ma wiedziec gdzie jest granica? jesli ilosc hitow/unique i czegokolwiek innego nie jest nigdzie zdefiniowana? Zreszta pare osob Ci juz napisalo, wiec nie proboj wciskac ludziom ze czarne jest biale. Dopoki nie ma w regulaminie/umowie podanych parametrow tych ograniczen, to w swietle prawa one nie istnieja. A uzytkownik ma prawo sobie wyprowadzac te 20GB limitu jesli ma taka ochote. No ale obecnie zadna firma takich limitow nie poda bo.... konkurencja nie podaje. I jak sie poczyta to forum to okazuje sie ze znaczna wiekszosc firm hostingowych w PL robi takie numery, czyli sprzedaje wiecej niz ma.

Jest bardzo istotnym elementem zakladu. Jesli bazy sa dostepne to znaczy ze mozna a nawet nalezy z nich korzystac. No chyba ze umiesz korzystac z bazy nie uzywajac jej, a dynamicznych stron nie robisz. Tylko jaka bylaby zasadnosc udostepniania baz skoro nie mozna z nich korzystac dynamicznie?

jesli wykorzystanie mysql (cokolwiek to ma oznaczac) nie bedzie polegalo na wypchaniu go danymi a potem nieuzywaniu go, to ja sie zaloze. Najlepiej, wypchaj baze w 95% (wszystkie 100) a potem tymi danymi wygeneruj 95% transferu. Mysle ze zalozy sie z Toba wiecej ludzi.

Ertcap, poza tym gdy twoj doskonale napisany skrypt dla super zaprojektowanej bazy danych trafi na duze obciazenie maszyny to: 1. php bedzie czekalo na odpowiedz bazy danych, ktora jest zajeta obslugiwaniem innych userow ew walczy z obciazeniem IO/CPU 2. apache zglosi w tym czasie 100% zajetosci CPU 3. twoj prosty SQL wykonywac sie bedzie x sekund a w zaleznosci od timeoutow i innych ustawien moze sie w ogole nie wykonac W konsekwencji Ty dostaniesz maila od hostingu ze obciazasz ponad norme shared hosting. I jak sie bedziesz czul w sytuacji gdy jestes pewien ze twoj bezbledny i super zoptymalizowany skrypt nie daje rady?

Zgadza sie. Tyle ze paru userow z duzymi systemami zwykle oznacza dosyc duza sile opiniodawcza. Jesli im sie przytrafiaja notoryczne 503 a uslugodawca nie reaguje to 1. nigdy tej firmy nikomu nie poleca 2. beda ja odradzac 3. obsmaruja firme gdzie sie da (czyt w branzy) A wiec firmie teoretycznie nie powinno na tym zalezec. Bo rynek to jest cos co sie samoreguluje. Obojetne czy ktos wygra proces czy nie. firma da ciala - bardzo szybko sie to odbije na jej kondycji. pytanie jak szybko zniknie zapach kwasu. No i pozostaje ciagle kwestia je "wielkosci" systemu jaki moze uciagnac shared hosting. Jesli mam 1000 userow, 4000 unique miesiecznie, w szczycie odwiedzalnosci 40 userow na forum a na dodatek nie jest to dzialanosci zarobkowa, to chyba nie sadzisz ze powinienem isc na dedyka. Uprzedzajac, skrypty mam zoptymalizowae i najlepsze jakie sie da. Tylko co mi z tego jak ze slow loga wychodzi prosty pojedynczy select z tabeli z 4 rekordami ktory wykonuje sie 15 sek... A moze Panowie nie ma rozwiazania tej sytuacji. I nie potrzebnie sie tu strzepimy a rynek faktycznie zrobi swoje. kiedys jechalismy na modemach 9600 czy 14400 w porywach przez dial-up. a teraz kazdy ma min 1Mbps w domu.

Nie ma? nie ma formuly ze firma gwarantuje nieprzerwane swiadczenie uslug w okresie waznosci umowy? a potem zwykle jest ze firma ma prawo do przerw technicznych zwiazanych z konserwacja H/W w takim a takim % czasu etc. NO jak nie ma to faktycznie user sam sobie winien. A moze w umowie nie ma a w regulaminie jest?

I racja. Ale lepiej niech chodzi wolno nic wcale (biale strony, 503 etc). To raz. Dwa w regulaminie/umowie jest lub powinno byc ze firma gwarantuje swiadczenie uslugi na takim a takim poziomie. I oczywiscie jesli konto demo dziala dobrze a po zaplaceniu sie wlecze i strony sie otwieraja po 1 minucie to jest to niewywiazywanie sie z obowiazkow przez uslugodawce.

Patryk, a mnie irytuje Twoje "niedowidzenie" faktow. Zakladke wczesniej ktos pisal ze mu home wyslalo slow-loga z zapytaniem SELECT do tabeli ktora ma 4 rekordy, ktore wykonuje sie iles tam sekund. Wiec jak to jest z tym przeklamywaniem wydajnosci... pozdrawiam

patryk, znowu zaczynasz? Podaj propozycje wydajnego i dobrze napisanego CMSa. Najlepiej zeby Twoja propozycja zostala uznana przyez wszystkie hostingi jako standard. Bo niestety dla shared hostingow za ciezkie sa wszystkie CMSy czy to jest yoomla, mk_portal, post_nuke czy vbadvance. I tak dobrze ze wiekszosc z nich zasuwa na tabelach MyISAM. Bo jakby byly to InnoDB z transkacjami to nie wiem jak by hostingi to przezyly. Podsumowujac: nigdzie nie jest w regulaminach zdefiniowane od kiedy sie zaczyna utrudnianie egzystencji innym uzytkownikom. A sprowadza sie to do tego ze hosting ma prawo wypowiedziec umowe bez uzasadnienia w kazdej chwili. tzn hostingom sie tak wydaje ze maja do tego prawo...

Ja sie zgadzam. Przypomina mi to moja korespondencje z inna firma z ktora juz nie wspolpracujemy. Jakby nie bylo (obojetne czy taka sprawe mozna wygrac czy nie), faktem jest ze zapytanie do takiej malej tabeli nie ma szans wykonywac sie tyle czasu. a jesli sie wykonuje to jest to wina ogolnego obciazenia maszyny. Niestety administratorzy bardzo czesto wyciagaja SQLa ze slow-loga i nieprobujac go odpalic na maszynie wysylaja do klienta. notabene index tu nie jest potrzebny ale to nie wplywa na wydajnosc - mogloby wplywac przy czestej zmianie zawartosci kolumny year, poniekad tez w minimalnym stopniu) pozdrawiam

Nie jestem przekonany do koniecznosci wykorzystania indexu kompozytowego w tym wypadku. Taki index jest pomocny gdy sie wykonuje operacje poszukiwania tylko po danej kombinacji pol (najczesciej sortowanie po tych polach i to w tej samej kolejnosci). Tu mamy user_id wykorzystywane tak do joina jak i do okreslenia wartosci. Oczywiscie mozna tu optymalizowac pojedyncze zapytanie, na przyklad zastowac JOINa zamiast linku w WHERE, uzyc u.user_id NOT IN (-1, 609) zamiast osobnych warunkow. Ale to ciagle nie powinno miec znaczenia przy stosunkowo malych bazach danych (czyli takich ktorych ilosc rekordow nie przekracza milionow). Z drugiej strony zapytania SQL sa czesto skladane jakims algorytmem i ich postac jest wymuszona przez logike aplikacji. Oczywiscie wszystko mozna napisac tylko czasem nie jest warto poswiecac czasu jesli docelowy zysk bedzie pomijalny. wszystko to kwestia zbilansowania kosztow i zyskow. 20 lat temu sie wszystko pisalo tak aby jak najbardziej optymalizowac programy pod wzgledem zyzycia pamieci i zwiekszenia predkosci. Liczylo sie nawet cykle procesora. Za to pozniejsza analiza kodu czy debuging to byl kosmos. teraz sie pisze w jezykach wysokiego poziomu (Java, C#) bo czas jest drozszy niz H/W. Inna sprawa, ze ja piszac w PHP od poczatku obiektowo (na tyle na ile sie da) z 5 lat temu spotkalem sie z opinia ze to jest fajne i w ogole, ale obciaza zbyt serwery. No ale widzialem tez kod php inline'owany do htmla. Podobno wydajne, ale wspolczuje komus szukac w tym bledow, poprawiac etc. Co ciekawe takiego "brzydkiego" programowania uczy wiele szybkich kursow publikowanych w inecie - choc nie jestem przekonany czy celowo. raczej z nieswiadomosci istnienia OP. ale to juz tak OT sie zrobilo. Jedno co bym sprawdzil to czy tabela phpbb_read_history ma index po user_id - ale na pewno ma. EDIT: Wlasnie doczytalem ze ma Co do wypowiedzi P. Holdena odnosnie "kaszy" mysqla to calkowita racja. Odczulem to na wlasnej skorze gdy wybierajac dane z tabeli o zawartosci ok 4mln rekordow (z JOINem do slownika) trwalo to ponad minute. Po zwiekszeniu buforow InnoDB to samo zapytanie wykonywalo sie w ulamek wrecz sekundy. Tak wiec wniosek jest taki ze podstawa to poprawnie skonfigurowany silnik bazy danych. bez tego zostanie on zabity nie tyle przez pojedyncze zapytanie ale przez wiele zapytan na raz. nastapi eskalacja obciazenia i potem wychodza kwiatki, ze komus prosty SQL sie wykonuje 10 sek, gdzie w normalnych warunkach na tej samej maszynie (np. pol godziny pozniej) juz tylko 0,01 sek. Tyle ze jestem zdania ze firma przed wyslaniem upomnienia do klienta powinna sprawdzic ile tak naprawde takie zapytanie sie wykonuje. Niestety mam wrazenie ze korzystaja oni z logow gdzie maja zapisany SQL i czas wykonania, a nie biora pod uwage ze ten czas to pochodna ogolnego obciazenia maszyny. Niestety takie praktyki stosuja tez inne firmy hostingowe, i nie daja sobie wmowic ze nie maja racji. Szczesliwego Nowego Roku

Jesli masz swoj wlasny dom, i ktos Ci przybije, bez twego pozwolenia, na jednej ze scian wielki bilboard reklamujacy... cokolwiek, lokalna siec internetowa, piwo bezalkoholowe etc to masz pawo do wynagrodzenia za uzywanie twej "powierzchni" do reklamowania czy nie? Szczegolnie ze ktos inny na tej reklamie zarabia. Moim zdaniem masz, mimo ze nie tylko ta reklama Ci nie szkodzi ale i mozna dowodzic ze pomaga (chroni przed wiatrem, deszczem etc). IMHO Saint ma racje. Pytanie czy polskie sady zrozumieja o co tu chodzi. W kazdym razie wykorzystywanie czyjejs wlasnosci w celach zarobkowych, bez zgody wlasciciela, jest imho niezgodne z prawem. W opisywanym tu przypadku powinna sie pojawic informacja o bledzie strony czy awarii hostingu. Innymi slowy zamiast reklamy powinien byc text w stylu: "przepraszamy, nastapila awaria systemu, lub trafiles na nieistniejaca strone. Skontaktuj sie z administratorem".

Co ciekawe cpanel w i365 oferuje rozwiazania jak post_nuke czy phpbb2, ktore przed rokiem support hostingu ocenil jako "zle zoptymalizowane skrypty".