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

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

Path: news-archive.icm.edu.pl!agh.edu.pl!news.agh.edu.pl!newsfeed2.atman.pl!newsfeed.
atman.pl!news.task.gda.pl!news.mm.pl!.POSTED!not-for-mail
From: u...@d...invalid
Newsgroups: pl.comp.programming
Subject: Re: jsp vs php
Date: Thu, 02 May 2013 05:11:21 +0200
Organization: Multimedia Polska SA
Lines: 73
Message-ID: <klsle1$ogf$1@news.mm.pl>
References: <c...@g...com>
<klqg29$o16$1@news.mm.pl>
<0...@g...com>
NNTP-Posting-Host: host-217-172-242-90.gdynia.mm.pl
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: news.mm.pl 1367464193 25103 217.172.242.90 (2 May 2013 03:09:53 GMT)
X-Complaints-To: a...@m...pl
NNTP-Posting-Date: Thu, 2 May 2013 03:09:53 +0000 (UTC)
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130404 Thunderbird/17.0.5
In-Reply-To: <0...@g...com>
Xref: news-archive.icm.edu.pl pl.comp.programming:203045
[ ukryj 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.