🚀 go-pugleaf

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.