@thek, nie zrozumiałeś mnie. W relacyjnych bazadch danych są rzeczy które zajmują dłużej niż inne. Niektóre dane nie są po prostu dostępne w czasie rzeczywistym. Zapuszczasz aplikacje która je przetwarza, a po wszystkim aktualizujesz tabelę wynikową.
Użytkownik witryny kiedy wyświetla jakieś dane, chce je mieć natychmiast. Jeżeli dane nie muszą być "z ostatniej sekundy" to nie ma problemu by zapuścić crona albo jakiś proces na serwerze do zadań specjalnych (tu mowa o prostej aplikacji w C++ czy C).
Taki użytkownik nie czeka 1,5 min na dane widząc "Loading..." tylko dostaje dane z ostatniego przetworzenia. Gdzie maksymalnie mają 1,5 min.
Nie popadaj w skrajności. Nie chodzi o przepisanie czegoś na C++ bo nie tędy droga. Po prostu niektóre części aplikacji nie muszą być realizowane przez samą aplikacje.

Co do kilkudziesięciu obiektów to uwierz mi że widziałem już twory które potrafiły przetworzyć ich znacznie więcej. I nie było z tym problemów. Demony prędkości to nie były ale użytkownik jak czeka 200ms dłużej to i tak tego na ogół nie odczuje zbytnio.

Wiem, że takowe zapytania istnieją, bo sam co jakiś czas je piszę i zrzucam wykonanie gdzieś na godziny poza szczytem do crona czy odpalam je sobie w exec (jakby nie spojrzeć konsola ma wyższy priorytet z reguły) poza głównymi procesami serwera http, w tle.

Problem mają jednak osoby siedzące na kontach shared. Oni większości rzeczy i tak nie użyją, bo mają je poblokowane. Brak sensownego cron, exec czy możliwości kombinowania ze skryptami cgi :) A jeśli są, to mocno ograniczone. No i powiedz mi, czy osoba początkująca będzie potrafiła taki skrypt napisać sama, zazwyczaj nie posiadając wiedzy o komendach systemu? Pół biedy gdy trafią na hosting z windowsem, to może coś z DOSa pamiętają, ale Linux? Nawet gdyby mieli dostęp do ssh, to by nie wiedzieli o tym i jak tego użyć. To o czym piszemy przyda im się za ileś tam set godzin programowania, o ile dobrną do tego etapu nauki.

Te 200ms to faktycznie dłużej nie jest, ale z reguły to co baza przetwarza i tak długo, jeszcze po stronie skryptu bywa modyfikowane a to już kolejny narzut i z 200ms robi się sekunda lub dwie. Dla niewtajemniczonych tylko wyjaśnienie, że silnik bazy jest znacznie szybszy niż skrypt php i jeśli jest możliwość, to na niego zrzuca się już wstępną obróbkę danych (skracanie tekstów, zliczanie wyników i takie tam). Sam nieraz widziałem debilizmy w stylu pobierania wszystkich rekordów bazy z wszystkimi kolumnami do skryptu tylko po to, by je policzyć, zamiast użyć count na poziomie silnika bazy. Takie rzeczy powinny być karcone z wykorzystaniem wysokiego napięcia na delikwencie, by zapamiętał na przyszłość :D

@thek, na hostingu dzielonym jak mówisz nie poszaleje więc i tak im to nie potrzebne. Zauważ też że nie trzeba mocno w takim wypadku obciążyć serwera. Wystarczy wyjść "poza normę" która jest indywidualna na daną okazję i nagle się okazuje że Twoja witryna jest zablokowana a na skrzynce email widnieje powiadomienie że albo coś zrobisz ze swoją witryną albo wykupisz dedyka.

@Dariusz P.: To prawda. Shared nadaje się w zasadzie tylko na wizytówkę w przypadku niektórych firm. A i tak Ci będą chcieli wmówić, że musisz mieć do tego dedyk :) Przerabiałem już takie zagrania ze strony home.pl i po pierwszym numerze się postanowiłem od razu wynieść. Jeśli poza szczytem strona łapie 501, a w jego czasie zwiech na 10 minut w ciągu godziny to jest coś nie tak. Przeniesienie na innego shared, gdzie mam na bieżąco wgląd do statystyk zużycia zasobów. Okazuje się, że nawet nie wykorzystuje połowy tego co próbowali w home.pl mi wmówić, a o czym doskonale wiedziałem. Drugi hosting to az.pl Może domeny warto tam czasem trzymać, ale hosting serwisu? Uciekać od razu, a najlepiej nawet nie zaczynać współpracy pod tym kątem. Jeśli do slowloga łapie się zapytanie o wyświetlenie wszystkich wierszy tabeli, która ma ich raptem 20 (słownie dwadzieścia) i każdy ma tylko 3 kolumny (jakaś tabelka cncat-a) to jest to kpina i tyle :) Ogólnie o hostingach shared można dużo pisać i niekoniecznie dobre opinie.

To zależy. Dla przykładu obecnie korzystam z hekko.pl. Jest to strasznie tani hosting ale jeżeli chodzi o jakość usług to jestem bardzo zadowolony.
W panelu mam log wszystkich czynności które są wykonywane na moim koncie, mam statystyki z obciążeniem, informacje o pracach konserwacyjnych itp.

Mam dostęp do DNS (dzięki czemu dla przykładu przekierowałem sobie pocztę na Google Apps), hosting jest świetnie wyposażony (w tym SSL, OpenSSL, PHP5.3 oraz 6-dev do wypróbowania, dostęp do niektórych opcji php.ini, CGI, PERL, PYTHON, Pear, mod_rewrite, imap, cron itp itd etc).

Był bym zapomniał. Wysłałem do nich kiedyś zapytanie czy jest możliwość bym miał również moduł do PHP w postaci systemu szablonów Blitz Templates.
Wysłałem email z detalami, źródłami, opisem itp, i czekam na odpowiedź... godzinę, dwie, trzy... nagle przychodzi email w którym po prostu napisali:
ZROBIONE :-)

Akurat o hekko także słyszałem i czytałem bardzo wiele dobrego. Nie tylko od osób się nim zajmujących (na forum gdzie jestem mają "przedstawiciela handlowego" o nicku Hekko). Jednak jest to wyjątek od reguły i niestety większość to masówka z oversellingiem strasznym, za który potem winę zwalają na klientów i wciskają, że problemy z dostępem do serwisów to wina źle napisanych skryptów, a nie tym, że na jedną maszynę wciskają ogromne ich ilości.

W chwili obecnej warto się rozglądać za tymi mniejszymi, bo oferują oni znacznie lepszą jakość usług niż giganci branży. Wielokrotnie za ułamek ceny z cennika liderów.