Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.lang.php > #15829 > unrolled thread

Wydajność Laravel'a - prawda czy mit?

Back to article view | Back to pl.comp.lang.php

Contents

  Wydajność Laravel'a - prawda czy mit? Marek S <precz@spamowi.com> - 2018-11-30 23:49 +0100
    Re: Wydajność Laravel'a - prawda czy mit? Borys Pogoreło <borys@pl.edu.leszno> - 2018-12-01 20:25 +0100

#15829 — Wydajność Laravel'a - prawda czy mit?

Zapoznaję się z tym frameworkiem od jakiegoś czasu. Ponoć jest on 
mega-wydajny. Jak to możliwe gdy:

1. Zamiast zapytań SQL'owych stosuje się coś w rodzaju active record lub 
query builder'a.

2. Zamiast inicjowania wymaganych obiektów w miejscu użycia i potem 
wielokrotnego wykorzystania instancji, robi się to w fasadach za każdym 
razem inicjując obiekt od nowa.

3. Cache dotyczy całości URI a nie poszczególnych składowych danej 
strony WWW lecz całości i czasem wiąże się to z odwołaniami do bazy 
danych by stwierdzić czy coś się zmieniło zamiast do statycznych plików.

4. Zastosowanie DAO do odczytu danych powoduje załadowanie do RAM np. 
100 rekordów i potem w pętli ich przetwarzanie na HTML zamiast odczytu 
sekwencyjnego z bazy.

WTF?

-- 
Pozdrawiam,
Marek

[toc] | [next] | [standalone]

#15830

Dnia Fri, 30 Nov 2018 23:49:01 +0100, Marek S napisał(a):

> Zapoznaję się z tym frameworkiem od jakiegoś czasu. Ponoć jest on 
> mega-wydajny. Jak to możliwe gdy:

Gdzie takie rewelacje wyczytałeś? Wydajność jest taka sobie, jego siłą są
dostarczane rozwiazania (potęga Symfony + mnóstwo gotowych rozwiązań
typowych problemów). Ale po włączeniu wszelkich cache nie jest źle.

> 1. Zamiast zapytań SQL'owych stosuje się coś w rodzaju active record lub 
> query builder'a.

Nie ma to większego znaczenia w kontekście samych zapytań. Wydajnościowo
jest o tyle lepsze, że masz wbudowany cache i potrafi optymalizować
zapytania (częściowo automatycznie, a częściowo ręcznie, np. przez with()).

> 2. Zamiast inicjowania wymaganych obiektów w miejscu użycia i potem 
> wielokrotnego wykorzystania instancji, robi się to w fasadach za każdym 
> razem inicjując obiekt od nowa.

"Fasady" to tylko inny sposób dostępu do kontenera IoC. Dość dyskusyjny
zresztą. Ja za nim nie przepadam.

> 3. Cache dotyczy całości URI a nie poszczególnych składowych danej 
> strony WWW lecz całości i czasem wiąże się to z odwołaniami do bazy 
> danych by stwierdzić czy coś się zmieniło zamiast do statycznych plików.

Ale jaki cache? Bo w cache możesz trzymać przeróżne rzeczy. Cache widoków?

> 4. Zastosowanie DAO do odczytu danych powoduje załadowanie do RAM np. 
> 100 rekordów i potem w pętli ich przetwarzanie na HTML zamiast odczytu 
> sekwencyjnego z bazy.

I bardzo dobrze, w czym tu widzisz problem? Baza tylko raz musi przetwarzać
zapytanie i sięgnąć do dysku.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

[toc] | [prev] | [standalone]

Back to top | Article view | pl.comp.lang.php

csiph-web