Re: jsp vs php - Grupy dyskusyjne w eGospodarka.pl

eGospodarka.pl › Grupy › pl.comp.programming › jsp vs php › Re: jsp vs php

Data: 2013-05-02 05:11:21
Temat: Re: jsp vs php
Od: u...@d...invalid szukaj wiadomości tego autora
[ pokaż wszystkie nagłówki ]
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.