W dniu środa, 1 maja 2013 09:27:30 UTC+2 użytkownik u...@d...invalid napisał:

> <subiektywnie>
> Z góry zwracam uwagę na to, że nie mam zielonego pojęcia JSP... ale się
> wypowiem :)
Dziękuję, subiektywne opinie też bywają pomocne.

> A to dlatego, że koledzy w pracy używają i ciągle słyszę o
> zwisach, problemach, których źródeł nie da się dojść, koniecznościach
> restartow glassfishy i serwerów itp, problemach z klastrami i ogólnie
> rzecz biorąc wszystkim tym co nie jest związane bezpośrednio z kodem
> strony a infrastrukturą. Dlatego samodzielnie podchodząc do tworzenia
> aplikacji webowych zdecydowałem się na PHP :)
Jesteś drugą osobą która zwraca mi uwagę na problem z narzędziami, czyli
coś jest na rzeczy.


> Nie wiem na czym polega
> spadek wydajności przy dużych serwisach, przecież nadal będzie się
> składał z niewielkich części, małych plików PHP.
Mnie martwi nie tyle spadek wydajności w dużych serwisach, co w popularnych.

Załóżmy że mamy 4 godziny szczytowego obciążenia na dobę. Załóżmy że
każdy użytkownik wyśle 50 zapytań w swojej sesji (nie licząc zapytań o
obrazki, pliki html, csv, które podaje się bez żmudnych obliczeń i w
dodatku można buforować po stronie przeglądarki i serwera). Przy 100
użytkownikach w założonym okresie, mamy 3600s * 4 / 50 / 100 = 2.88s na
jedno wygenerowanie strony. Gdy weźmiemy zwykły dysk (nie SSD) to mamy
na wygenerowanie jednej strony limit około 150-200 nastawień głowicy.

Wynika z tego że 3000 userów wymaga 30 jednostek równolegle przetwarzających
jeśli uzyska się liniową skalowalność. W praktyce trudno uzyskać liniową
skalowalność, więc może będzie trzeba 100 równoległych jednostek. Poza tym
zapytania użytkowników nie rozłożą się równolegle w tych 4 godzinach, więc
może 200, może 300.


> A frameworki... no cóż
> one są nie po to, aby Ci się szybciej pisało, tylko aby szybciej się
> pisało GRUPIE i aby GRUPA wiedziała, gdzie czego szukać.
Racja, ale to w dalszej kolejności przekłada się na to, żeby mi się
szybciej pisało. Np. jakaś grupa osób napisze plugin zgodny z danym
frameworkiem, a ja go sobie mogę zainstalować, zamiast klepać od zera.


> Imo, bardziej
> mają znaczenie w usystematyzowaniu i wprowadzeniu reguł wytwarzania
> oprogramowania niźli szybszemu pisaniu.
Tak, ale to też w dalszej kolejności przekłada się na krótszy czas
przygotowania aplikacji, mniej bałaganu, mniej szukania, mniej nieporozumień...


> Ja w PHP robię tylko dla siebie
> więc frameworków nie używam, zresztą... jak widzę te najpopularniejsze
> (np. cakePHP) to się za głowę łapię,
Do prostych aplikacji ta najnowsza wersja Cake była dobra. Jednak często
traciłem masę czasu na szukanie czegoś co rzekomo jest gotowe, a potem
okazywało się, że działa źle, albo konfiguracja jest magiczna, a dokumentacja
gdzieś na jakiś podejrzanych stronach... Do dużych aplikacji Cake się nie
nadaje, jest za mało modułowy, za mało obiektowy, dużo kodu upakowuje
się do jednego pliku (albo traci się korzyści jakie płyną ze zdefiniowana
kontrolerów), Cake ma dużo niepotrzebnych udziwnień wprowadzonych przez
autorów które PHP daje samo z siebie jako język obiektowy, nie ma
zaawansowanej obsługi baz danych, a dostęp do danych w rozbudowanych bazach
przy pomocy standardu Cake jest trudniejszy niż przy pomocy zwykłego SQLa.
Niemniej do małych aplikacji Cake jest naprawdę dobry i wystarczający, i
nawet jest RAD, nie nadaje się do dużych aplikacji.


> bo tworzenie logiki na stringach
> (np. link('Dupa', array('action' => 'maryni')) jest dla mnie
> nieakceptowalne i bym poświęcił kupę czasu na zrobienie
> staticów aby te stringi zastąpić deklaracyjnie :)
Sorry ale tutaj coś nieźle pomyliłeś, do logiki są kontrolery, a podałeś
przykład funkcji bibliotecznej.


> Zresztą, im więcej warstw kodu umieszczam, tym mam gorszy dostęp do
> warstw niższych a sporo robię też za pomocą jQuery i ajax.
Nie wiem jak używasz określenia "warstwa kodu", bo jeśli używasz
tego w standardowym znaczeniu, to warstwy tylko pomagają (no chyba
że w mikro-projektach).

Pozdrawiam