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

do góry

W dniu środa, 1 maja 2013 12:55:20 UTC+2 użytkownik firr kenobi napisał:

> [...]
> dawne bramki onetu i gazety byly lepsze
> (zwlaszcza onetu )

Też sobie cenie serwisy za to że pełnią jakąś użyteczną rolę. Niestety
od dłuższego czasu jest nagonka na nowości w aplikacjach webowych.
Rzadko kto zdaje sobie sprawę, że wykonanie aplikacji dynamicznej z
wieloma bajerami wymaga nakładu pracy 10-20 razy większego, niż
prostej statycznej strony działającej na zasadzie: wyślij
zapytanie - trochę przetwarzaj po stronie serwera - pobierz całą stronę.
No i mamy wiele nowych niedokończonych stronek, które są gorsze niż stare.

Pozdrawiam

do góry

On 01.05.2013 22:32, M.M. wrote:
>> 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.

Jak facebook sobie poradził, to ty też sobie poradzisz :)

>
> 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.

Facebook jak dotarł do problemu spadku wydajności to zaczął tworzyć
rozszerzenia do PHP, które przecież mogą być natywne a dzięki temu
szybsze od kodu pod maszynę wirtualną. Czyli część kodu php można
zamienić na jedną linię kodu z biblioteki dołączanej. Zresztą są inne
rozwiązania, choćby facebookowe HipHop dla PHP.

>> 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.

Fakt, nie chodzi o logikę w sensie MVC, ale w tym konkretnie przypadku o
niedeklaratywny kod realizujący też jakiś rodzaj logiki (łączenie
elementu interfejsu z akcją).

>> 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).

Cake uważam za jedną z tych warstw, które oddalają mnie od generowanego
HTMLa i tak jak pisałem, imo pomagać może, nie musi a w małych
jednoosobowych projektach może nawet przeszkadzać.
Chodzi też o to, że za pomocą Cake mogę utworzyć interfejs strony, która
zostanie pobrana raz, więc za pomocą JS mogę go wtedy już tylko w
niewielkim stopniu wygodnie modyfikować, aktualizować dane, ale... są
miejsca, gdzie muszę używać dużo JS a większość na stronie powstaje za
pomocą jQuery+ajax, aby zapewnić większą "responsywność" dla użytkownika
i strona może wyglądać tak:
<body>
...
<div id="#controlsContainer"></div>
...
<script>
...
deklaracje funkcji
...
wywołania funkcji tworzących (inicjujący) interfejs
w controlsContainer
...
wywołania funkcji inicjujących logikę na stronie,
podpięcie zdarzeń.
</script>
</body>
Nie widzę tu miejsca dla Cake, skoro strona serwerowa będzie głównie
odpowiadała za zwracanie JSONów.

do góry

On 01.05.2013 22:52, M.M. wrote:
> W dniu środa, 1 maja 2013 12:55:20 UTC+2 użytkownik firr kenobi napisał:
>
>> [...]
>> dawne bramki onetu i gazety byly lepsze
>> (zwlaszcza onetu )
>
> Też sobie cenie serwisy za to że pełnią jakąś użyteczną rolę. Niestety
> od dłuższego czasu jest nagonka na nowości w aplikacjach webowych.
> Rzadko kto zdaje sobie sprawę, że wykonanie aplikacji dynamicznej z
> wieloma bajerami wymaga nakładu pracy 10-20 razy większego, niż
> prostej statycznej strony działającej na zasadzie: wyślij
> zapytanie - trochę przetwarzaj po stronie serwera - pobierz całą stronę.
> No i mamy wiele nowych niedokończonych stronek, które są gorsze niż stare.

Myślę, że prawda leży gdzieś pośrodku. Te 10-20 razy to trochę przesada.
Zawsze trzeba patrzeć na to co jest celem danej strony/podstrony. Też
wolę w PHPie wyklepać statyczną stronę, ale... w JS też mamy już bogate
biblioteki, którymi można przyspieszać pisanie. Nawet sama
autokompletacja to już nie jest większy problem dla współczesnych IDE.
Ale fakt, jest wolniej, tyle, że czasem może dać lepszy efekt, wszystko
jak zwykle zależy od wielu czynników. Kilka zmian w samym języku mogłoby
uprościć sprawę (typowanie zmiennych z kontrola typów, interfejsy itp.)
przez lepszą kontrolę nad jakością kodu i lepsze wsparcie ze strony IDE,
które nam powie, że próbujesz "stringa" przypisać do zmiennej "int".
Wiem, wiem... środowiska dają wsparcie poprzez komentarze, ale te
konkretnie komentarze (typowanie zmiennych) to niepotrzebna proteza
niepotrzeba, która i tak problemów często nie rozwiązuje.

do góry

Użytkownik <u...@d...invalid> napisał w wiadomości
news:klsmdc$oon$1@news.mm.pl...
> On 01.05.2013 22:52, M.M. wrote:
>> W dniu środa, 1 maja 2013 12:55:20 UTC+2 użytkownik firr kenobi napisał:
>>
>>> [...]
>>> dawne bramki onetu i gazety byly lepsze
>>> (zwlaszcza onetu )
>>
>> Też sobie cenie serwisy za to że pełnią jakąś użyteczną rolę. Niestety
>> od dłuższego czasu jest nagonka na nowości w aplikacjach webowych.
>> Rzadko kto zdaje sobie sprawę, że wykonanie aplikacji dynamicznej z
>> wieloma bajerami wymaga nakładu pracy 10-20 razy większego, niż
>> prostej statycznej strony działającej na zasadzie: wyślij
>> zapytanie - trochę przetwarzaj po stronie serwera - pobierz całą stronę.
>> No i mamy wiele nowych niedokończonych stronek, które są gorsze niż
>> stare.
>
> Myślę, że prawda leży gdzieś pośrodku. Te 10-20 razy to trochę przesada.
> Zawsze trzeba patrzeć na to co jest celem danej strony/podstrony. Też wolę
> w PHPie wyklepać statyczną stronę, ale...

Alez wy jestescie chlopcy malo ambitni :-)

do góry

W dniu czwartek, 2 maja 2013 05:11:21 UTC+2 użytkownik u...@d...invalid napisał:
> Jak facebook sobie poradziďż˝, to ty teďż˝ sobie poradzisz :)
Ciekawe czy by sobie poradzili ludzie od facebooka z moim problemem,
jakby mieli taki sam budżet jak ja ;-)


> Facebook jak dotar� do problemu spadku wydajno�ci to zacz�� tworzy�
> rozszerzenia do PHP, kt�re przecie� mog� by� natywne a dzi�ki temu
> szybsze od kodu pod maszyn� wirtualn�. Czyli cz�� kodu php mo�na
> zamieni� na jedn� lini� kodu z biblioteki do��czanej. Zreszt� s� inne

> rozwi�zania, cho�by facebookowe HipHop dla PHP.
Nom, ale to tylko przyspieszenie obliczeń. Od strony technicznej, bardziej
obawiam się problemów z dostępami do dysku. Od strony ekonomicznej,
obawiam się kosztów utrzymania ludzi. Czasami myślę, żeby w ogóle serwer
http wywalić i napisać wszystko w C++. Wtedy wszystkie drobiazgi można
trzymać w RAM, a co ważniejsze, można dane z bazy trzymać w przystosowanych
strukturach danych w RAM. Ale z tego co się rozglądałem, to zatrudnienie
ludzi wprawnie posługujących się C++ za średnie wynagrodzenie jest
praktycznie niemożliwe. W praktyce bym musiał zrobić wszystko sam, albo
prawie sam.



> Fakt, nie chodzi o logikďż˝ w sensie MVC, ale w tym konkretnie przypadku o
> niedeklaratywny kod realizuj�cy te� jaki� rodzaj logiki (��czenie
> elementu interfejsu z akcjďż˝).
Rozumiem że byś chciał, aby po zmianie nazwy kontrolera lub akcji, ta
funkcja też poprawnie działała, bez zmiany stringów? W Cake można osiągnąć
taki efekt... na 2-3 sposoby.

W swoim mini-frameworku bardziej zależało mi na tym, aby linki w języku
użytkownika pojawiały się zaraz po tym jak przetłumaczy tłumacz - dlatego
u mnie te funkcje pobierają odpowiednie ID nazw.

> Cake uwa�am za jedn� z tych warstw, kt�re oddalaj� mnie od
> generowanego HTMLa i tak jak pisa�em, imo pomaga� mo�e, nie musi
> a w ma�ych jednoosobowych projektach mo�e nawet przeszkadza�.
To nie rozumiem dlaczego Ci to przeszkadza, w prostych aplikacjach
Cake i inne frameworki przyspieszają proces tworzenia.


> Chodzi te� o to, �e za pomoc� Cake mog� utworzy� interfejs
> strony, kt�ra zostanie pobrana raz,
> wi�c za pomoc� JS mog� go wtedy ju� tylko w
> niewielkim stopniu wygodnie modyfikowaďż˝, aktualizowaďż˝ dane, ale... sďż˝
> miejsca, gdzie musz� u�ywa� du�o JS a wi�kszo�� na stronie powstaje
za
> pomoc� jQuery+ajax, aby zapewni� wi�ksz� "responsywno��" dla
u�ytkownika
> i strona mo�e wygl�da� tak:
Opisujesz przykład, w którym Cake nie spełni swojej roli w 100%, ale i tak
trochę może pomóc. Inaczej rozwiązujesz warstwę prezentacyjną i tutaj
Cake na niewiele się zda. Jednak są jeszcze dwie warstwy: obliczeniowa i
danych. Więc nadal możesz skorzystać, choćby z automatycznego budowania
zapytań SQL z bezpieczną parametryzacją.


> <body>
> <div id="#controlsContainer"></div>
> <script>
> deklaracje funkcji
> wywo�ania funkcji tworz�cych (inicjuj�cy) interfejs
> w controlsContainer
> wywo�ania funkcji inicjuj�cych logik� na stronie,
> podpi�cie zdarze�.
> </script>
> </body>
Przerzucasz odpowiedzialność za warstwę prezentacyjną na kod JavaScript -
więc frameworki PHP siłą rzeczy tutaj nie mogą pomagać :D



> Nie widz� tu miejsca dla Cake, skoro strona serwerowa b�dzie g��wnie
> odpowiada�a za zwracanie JSON�w.
Jest miejsce dla Cake :)


Pozdrawiam

do góry

W dniu czwartek, 2 maja 2013 05:28:04 UTC+2 użytkownik u...@d...invalid napisał:
> Myślę, że prawda leży gdzieś pośrodku. Te 10-20 razy to trochę przesada.
Zależy od aplikacji. Czasami nawet łatwiej jest trzymać jakiś zestaw
częściowych danych (np. listę zamówionych towarów przed zakończeniem
zamówienia) niż je ciągle przesyłać na serwer, a tam zakładać specjalne
tabele na dane tymczasowe, albo zapychać sesję.



> Zawsze trzeba patrzeć na to co jest celem danej strony/podstrony. Też
> wolę w PHPie wyklepać statyczną stronę, ale... w JS też mamy już bogate
> biblioteki, którymi można przyspieszać pisanie. Nawet sama
> autokompletacja to już nie jest większy problem dla współczesnych IDE.
> Ale fakt, jest wolniej, tyle, że czasem może dać lepszy efekt, wszystko
> jak zwykle zależy od wielu czynników. Kilka zmian w samym języku mogłoby
> uprościć sprawę (typowanie zmiennych z kontrola typów, interfejsy itp.)
Był niedawno wątek o typowaniu statycznym vs dynamicznym :)



> przez lepszą kontrolę nad jakością kodu i lepsze wsparcie ze strony IDE,
> które nam powie, że próbujesz "stringa" przypisać do zmiennej "int".
> Wiem, wiem... środowiska dają wsparcie poprzez komentarze, ale te
> konkretnie komentarze (typowanie zmiennych) to niepotrzebna proteza
> niepotrzeba, która i tak problemów często nie rozwiązuje.
Trudno mi powiedzieć, jakby się programowało gdyby JavaScript była jak Java.
Może lepiej, może gorzej. Generalnie Javę lubię, JavaScript lubię bo muszę :)
W Javie by się na pewno przyjemniej pisało, ale czy szybciej, to nie wiem.


Pozdrawiam

do góry

W dniu 02.05.2013 13:06, M.M. pisze:
> W dniu czwartek, 2 maja 2013 05:11:21 UTC+2 użytkownik u...@d...invalid
napisał:
>> Jak facebook sobie poradziďż˝, to ty teďż˝ sobie poradzisz :)
> Ciekawe czy by sobie poradzili ludzie od facebooka z moim problemem,
> jakby mieli taki sam budżet jak ja ;-)
>
>
>> Facebook jak dotar� do problemu spadku wydajno�ci to zacz�� tworzy�
>> rozszerzenia do PHP, kt�re przecie� mog� by� natywne a dzi�ki temu
>> szybsze od kodu pod maszyn� wirtualn�. Czyli cz�� kodu php mo�na
>> zamieni� na jedn� lini� kodu z biblioteki do��czanej. Zreszt� s�
inne
>> rozwi�zania, cho�by facebookowe HipHop dla PHP.
> Nom, ale to tylko przyspieszenie obliczeń. Od strony technicznej, bardziej
> obawiam się problemów z dostępami do dysku. Od strony ekonomicznej,
> obawiam się kosztów utrzymania ludzi. Czasami myślę, żeby w ogóle serwer
> http wywalić i napisać wszystko w C++. Wtedy wszystkie drobiazgi można
> trzymać w RAM, a co ważniejsze, można dane z bazy trzymać w przystosowanych
> strukturach danych w RAM. Ale z tego co się rozglądałem, to zatrudnienie
> ludzi wprawnie posługujących się C++ za średnie wynagrodzenie jest
> praktycznie niemożliwe. W praktyce bym musiał zrobić wszystko sam, albo
> prawie sam.
>

A o Memcacheu, albo Redisie slyszal? Trzyma wszystko w RAMie
i bardzo dobrze wspolpracuje z PHP i Java.

>
>> Fakt, nie chodzi o logikďż˝ w sensie MVC, ale w tym konkretnie przypadku o
>> niedeklaratywny kod realizuj�cy te� jaki� rodzaj logiki (��czenie
>> elementu interfejsu z akcjďż˝).
> Rozumiem że byś chciał, aby po zmianie nazwy kontrolera lub akcji, ta
> funkcja też poprawnie działała, bez zmiany stringów? W Cake można osiągnąć
> taki efekt... na 2-3 sposoby.
>
> W swoim mini-frameworku bardziej zależało mi na tym, aby linki w języku
> użytkownika pojawiały się zaraz po tym jak przetłumaczy tłumacz - dlatego
> u mnie te funkcje pobierają odpowiednie ID nazw.
>
>> Cake uwa�am za jedn� z tych warstw, kt�re oddalaj� mnie od
>> generowanego HTMLa i tak jak pisa�em, imo pomaga� mo�e, nie musi
>> a w ma�ych jednoosobowych projektach mo�e nawet przeszkadza�.
> To nie rozumiem dlaczego Ci to przeszkadza, w prostych aplikacjach
> Cake i inne frameworki przyspieszają proces tworzenia.
>
>
>> Chodzi te� o to, �e za pomoc� Cake mog� utworzy� interfejs
>> strony, kt�ra zostanie pobrana raz,
>> wi�c za pomoc� JS mog� go wtedy ju� tylko w
>> niewielkim stopniu wygodnie modyfikowaďż˝, aktualizowaďż˝ dane, ale... sďż˝
>> miejsca, gdzie musz� u�ywa� du�o JS a wi�kszo�� na stronie powstaje
za
>> pomoc� jQuery+ajax, aby zapewni� wi�ksz� "responsywno��" dla
u�ytkownika
>> i strona mo�e wygl�da� tak:
> Opisujesz przykład, w którym Cake nie spełni swojej roli w 100%, ale i tak
> trochę może pomóc. Inaczej rozwiązujesz warstwę prezentacyjną i tutaj
> Cake na niewiele się zda. Jednak są jeszcze dwie warstwy: obliczeniowa i
> danych. Więc nadal możesz skorzystać, choćby z automatycznego budowania
> zapytań SQL z bezpieczną parametryzacją.
>
>
>> <body>
>> <div id="#controlsContainer"></div>
>> <script>
>> deklaracje funkcji
>> wywo�ania funkcji tworz�cych (inicjuj�cy) interfejs
>> w controlsContainer
>> wywo�ania funkcji inicjuj�cych logik� na stronie,
>> podpi�cie zdarze�.
>> </script>
>> </body>
> Przerzucasz odpowiedzialność za warstwę prezentacyjną na kod JavaScript -
> więc frameworki PHP siłą rzeczy tutaj nie mogą pomagać :D
>

A requesty ajaxowe to kto najlepiej obsluzy jak nie framework?

>
>> Nie widz� tu miejsca dla Cake, skoro strona serwerowa b�dzie g��wnie
>> odpowiada�a za zwracanie JSON�w.
> Jest miejsce dla Cake :)
>
>
> Pozdrawiam
>

--
Pozdrawiam
Lopez

do góry

W dniu czwartek, 2 maja 2013 23:45:04 UTC+2 użytkownik Lopez napisał:

> A o Memcacheu, albo Redisie slyszal? Trzyma wszystko w RAMie
> i bardzo dobrze wspolpracuje z PHP i Java.
Poszukam, dzięki za info.


> A requesty ajaxowe to kto najlepiej obsluzy jak nie framework?
Chodziło o coś innego. Chodzilo o taki banał, ze jak JS buduje
warstwe prezentacyjna, to siłą rzeczy, framework PHP ich nie buduje :)

Pozdrawiam

do góry

Użytkownik "Lopez" <l...@p...onet.pl> napisał w wiadomości
news:klump1$ini$1@node1.news.atman.pl...
>
> A requesty ajaxowe to kto najlepiej obsluzy jak nie framework?

W jakim sensie "najlepiej"?

do góry