🚀 go-pugleaf

W dniu 2019-04-28 o 14:50, Wojciech Bancer pisze:

>> Nie, wcale nie 2 sekundy. Pisałem wcześniej, że przy ok pół miliona
>> operacji (w ciągu nocy) udało mi się zaoszczędzić 2h pracy serwera
>> (50%). Może nawet więcej. Nie pamiętam konkretnych liczb.
> 
> No nie obraż się, ale pokazujesz że nie masz na tyle ogólnej współczesnej
> wiedzy odn. architektury systemów by obiektywnie ocenić gdzie optymalizacja
> mogłaby być najlepsza.

Ależ zgadzam się w 100%!

> Może masz rację, ale może nie. Może niekoniecznie
> optymalizacja powinna skupiać się na triggerach, może lepsze byłoby
> przemodelowanie procesu importu danych.

Przemodelowałem obie te rzeczy. Modyfikacja algorytmu importu też 
wniosła pozytywny wpływ, ale nie aż tak spektakularny.

Dobra, załóżmy, że jestem kretynem i metodą prób i błędów spowodowałem 
zaoszczędzenie czasu pracy serwera. Wpisywałem jedynie przypadkowe znaki 
z klawiatury. Po dwóch miliardach prób nawet zadziałało. Co z tego wynika?

>> ojej... system się nie wyrabia przy 500k.
> 
> A miał się wyrabiać przy pisaniu tej aplikacji?

Oczywiście, ze nie. Nikt nie zakładał tak dużego sukcesu firmy w 
pozyskiwaniu klientów.

I o to mi właśnie chodzi. Współczesny informatyk, wg Twojego opisu, to 
bezmózgi rzemieślnik, który jedynie jest w pełni świadom swoich 
niedomagań i w związku z tym implementuje byle jaki kod - aby tylko 
działał w trakcie testów i zaraz po uruchomieniu produkcyjnym. Chwilę 
potem może się walić... bo nie było w założeniach rzetelności jego 
pracy. Jeśli można napisać kod dobrze lub źle, nawet jeśli podobna ilość 
czasu jest na to potrzebna, to lecimy w wariant "źle".

Szerze mówiąc, przyznaję Ci rację w tym zakresie. Nierzadko przysłuchuję 
się rozmowom rekrutacyjnym i to jest niestety cechą frameworkowców. 
Czasem nie wiedzą czym protecetd różni się od public... To cytat z dziś.

>> Gdyby Ci informatycy wzięli się za uczciwą robotę i nawet dla
>> niewielkiego początkowo przedsięwzięcia postąpili zgodnie z kunsztem
>> programowania zwracając uwagę na detale, to problem wystąpiłby dopiero
>> po dojściu do możliwości serwera a nie możliwości kiepskich algorytmów.
> 
> A ja widzę typowe błędy zarządcze.

Bo kłopot jest w tym, że zarząd zwykle nie wie czym jest baza danych, 
API, PHP i inny informatyczny bełkot. Tu pełna zgoda. Jednakże nie 
bardzo znajduję w tym wszystkim preferowane przez Ciebie wykorzystywanie 
ich niewiedzy na rzecz własnego lenistwa.

> No ale idąc dalej, to jak myślisz, jak ktoś oceni Twoją pracę "za kilka
> lat", jak firma rozwinie się jeszcze bardziej, dostawi się jeszcze
> kilka maszyn i jednak wyjdzie, że optymalizacje które zrobiłeś teraz
> już nie działają i mimo dostawienia maszyn system nadal się czka?
> 
> Ciekawe czy Twój następca wystawi Ci taką samą laurkę jak Ty swoim :)

Zajebisty jesteś w tym momencie. :-D Zakładasz zatem, że dobrze napisana 
wyszukiwarka Google powinna działać na przydomowym serwerze. Mało tego, 
dostawienie Facebooka i Pinteresta też nie powinno wnieść istotnego 
obciążenia dla CPU :-D Aha... i łącze 1Mbps spokojnie wydoli.

A jak nie wydoli ... to będziemy pisać laurki na to, że jakiś kmiot 
informatyczny nie jest w stanie pchać przez łącze 1Mbps 10.000x tyle.

Tylko pogratulować takiego podejścia.

>> Co do w/w optymalizacji, to faktycznie praca była mrówcza. Np. zamiast
>> indeksować całe pole typu array() należało rozbić indeks na dwa:
>> przeindeksować tylko część tablicy - bo okazało się, że zdecydowana
>> większość zapytań właśnie o te części pytała. Podobnie było z
>> zapytaniami SQL. Zamiast jakiejś tam konstrukcji zastosowano inną i znów
>> progress wydajnościowy. Tymczasem od początku można było zrobić to
>> dobrze...
> 
> Rzecz w tym że "dobrze" ma więcej niż jedną postać.
> I to jest przedmiotem dyskusji w tym wątku.

Tyle tylko, że Ty wymagasz przekroczenia barier fizyki aby nie było 
beznadziejnie.

>>> Query builder *nie* jest żadnym łataniem, ani też żadnym SQLem.
>>> Jest narzędziem do budowania zapytań.
>>> Jak chciałbyś odpytywać bazę inaczej?
>>
>> Raw SQL? Doctrine ma implementację czegoś takiego.
> 
> Czyli chcesz używać ORM bez zalet ORM i z wadami ORM.
> Fascynyjące :) 

Próbujesz naginać teraz moje wypowiedzi do tego by pasowały do Twoich 
szyderstw. Ja planuję używać SQL do insertów/update'ów w sekcjach 
wymagających wydajności.

> Poczytaj o Unit of Work, o cache,
> o tym jak się pracuje z obiektami:

Sugerujesz, że są próby ratowania koncepcyjnej niedoróbki ORM w 
kolejnych segmentach Doctrine?

> https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/working-with-objects.html
> https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/unitofwork.html
> https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/caching.html

Poczytam, ale nie wszystko na raz. Krok za krokiem przemierzam i testuję 
famework.

>> ...i baza to zrozumie? Nie sądzę. Zawsze na końcu będzie SQL. Resztę
>> wypowiedzi dopiszę poniżej.
> 
> No to znowu, po co Ci ORM?

Pisałem już: do wszystkiego, co nie musi być wydajne, bo jest za to 
wygodne. Np. zwykłe formularze fantastycznie proso się integruje z 
Doctrine. Ich wydajność może być tragiczna - nikt tego nie zauważy nawet.

> Ale to *TY* spierniczasz bo nie rozumiesz narzędzia które używasz,
> a starasz się go używać tak jakby go nie było i był czysty SQL.

Mam nadzieję, że doznam jakiegoś olśnienia i uznam, że 2 zapytania SQL 
(z czego wynik pierwszego jest ignorowany) są bardziej wydajne niż jedno.

-- 
Pozdrawiam,
Marek