konto usunięte

Temat: Cachowanie, includowanie, kodowanie, pytania amatora

Mateusz Pięta:
1. Dobre serwisu mają regularnie cachowane dane z bazy SQL. I tu pojawia się moje pytanie, dlaczego bazy danych są aż tak popularne i często używane, skoro pobieranie z nich danych jest wolniejsze niż np. z plików tekstowych?
Programując serwis, artykuły będę umieszczał w plikach tekstowych, lub oddzielnych .php na serwerze i includował je, bądź zapisywał jako tabele i wyświetlał. Dobrze myślę? Wg mnie wiele rzeczy można zrobić be użycia bazy.
Na pewno będzie to szybsze rozwiązanie i czy nie praktyczniejsze?

Pliki są szybsze o ile nie musisz ich przeszukiwać lub wiązać ze sobą w relacje.

Rozwiązanie o którym piszesz - jeden artykuł/jeden plik będzie najszybsze, zwłaszcza jeśli będzie to plik HTML. Drupal ma nawet podobne rozwiązanie -
http://drupal.org/project/boost

Tylko jest wiele "ale" dla takiego rozwiązania:
1) znalezienie czegokolwiek wśród takich artykułów będzie trzeba pracowicie robić na piechotę. Małe szanse że będzie to optymalne od razu.
2) jeśli zamierzasz mieć więcej niż 10 artykułów to możesz mieć problem z zarządzaniem nimi
3) analiza takiego rozwiązania dla osoby która będzie się opiekować tym serwisem po Tobie będzie utrudniona - to jest plus dla Ciebie, ale minus dla właściciela serwisu
4) pliki to po prostu niższy poziom abstrakcji w stosunku do bazy danych. Duże serwisy mogą ich używać ale jako drugą linię (cache, dane statyczne - CSS, JS, JPG).
Mateusz Pięta

Mateusz Pięta matinet.pl |
wyrusze.pl |
polskimechanik.pl

Temat: Cachowanie, includowanie, kodowanie, pytania amatora

W takim razie zmieniam pierwotną koncepcję stworzenia "prostego silnika" (jeżeli tak to można nazwać) dla Wyrusze i będę wczytywał teksty z bazy.

Korzystając z okazji:

1. Wczytując jeden tekst z bazy wykonujemy jeden request, prawda? Koledzy z innej grupy (Start-up) dali mi "delikatnie" do zrozumienia, że dobry serwis potrzebuje 10 - 20 requestów, żeby się załadować.
Jak taki wynik osiągnąć, skoro wczytywane będzie na pewno kilkadziesiąt pociętych grafik, wczytywane zajawki z bazy, CSSy i inne pierdoły? (20 to nie osiągnę, ale 50?)

2. Czy tnąc i kodując stronę mam skupić się na tym, żeby elementów było możliwie najmniej (skoro wczytanie jednej grafiki to 1 rqst)? Czy wczytanie jednej klasy CSS to też jeden request? Jeżeli tak, to bardziej opłacalne jest cięcie na jak najmniejsze elementy i potem ich powielanie?

Pozdrawiam i dziękuję za przyszłe i wcześniejsze wypowiedzi.
Przepraszam za typowo amatorskie pytania...

konto usunięte

Temat: Cachowanie, includowanie, kodowanie, pytania amatora

Nie do końca.

Klient (użytkownik) chodząc na konkretny link, wywołuje odpowiednie żądanie.
Reakcją na to żądanie jest wygenerowanie się jakiejś tam stronki i przesłanie jej klientowi. W reakcji na to - klient, na podstawie przesłanej stronki, wczytuje - kolejne żądania ale nie do PHP'a a do serwera o konkretne pliki, CSS, JS, obrazki. Im mniej requestów tym lepiej - więc warto łączyć pliki.

Nie ma zależności między ilością zapytań do DB a ilością requestów.

konto usunięte

Temat: Cachowanie, includowanie, kodowanie, pytania amatora

http://blog.kamilbrenk.pl/minimalizacja-zapytan-http/
nie żebym się reklamował, ale pisałem już o zmniejszaniu ilości requestów i może się przydać dla początkującego :)

konto usunięte

Temat: Cachowanie, includowanie, kodowanie, pytania amatora

Mateusz Pięta:
1. Wczytując jeden tekst z bazy wykonujemy jeden request, prawda? Koledzy z innej grupy (Start-up) dali mi "delikatnie" do zrozumienia, że dobry serwis potrzebuje 10 - 20 requestów, żeby się załadować.
Jak taki wynik osiągnąć, skoro wczytywane będzie na pewno kilkadziesiąt pociętych grafik, wczytywane zajawki z bazy, CSSy i inne pierdoły? (20 to nie osiągnę, ale 50?)

Koledzy mieli zapewne na myśli requesty do bazy danych, które zależą ogólnie mówiąc od tego co znajduje się po stronie serwera. Requesty z przeglądarki użytkownika to inna sprawa i zależą od tego jak zbudowany jest kod html/css serwisu i tu na pewno pomoże Ci blog Kamila.

konto usunięte

Temat: Cachowanie, includowanie, kodowanie, pytania amatora

z tymi requestami do bazy to bym nie przesadzał, bo czasem nie liczy się ile, tylko jakie. Jedno idiotycznie skonstruowane zapytanie na niezoptymalizowanych danych może być bardziej kosztowne niż setka zoptymalizowanych

konto usunięte

Temat: Cachowanie, includowanie, kodowanie, pytania amatora

Dokładnie. Raz miałem nieprzyjemność pracować ze źle skonfigurowanym serwerem, na którym right join zabijał bazę - obojętnie co by było join'owane - jeśli right join - baza trup. :D
Mateusz Pięta

Mateusz Pięta matinet.pl |
wyrusze.pl |
polskimechanik.pl

Temat: Cachowanie, includowanie, kodowanie, pytania amatora

Dziękuję, z blogu, którego adres jest wyżej na pewno nie raz skorzystam.

Jeszcze jedno pytanie:

- Czy optymalnej jest wczytywać klasy CSS z oddzielnego pliku arkuszy kaskadowych, czy gdy są one w pliku html/php, razem z treścią?

konto usunięte

Temat: Cachowanie, includowanie, kodowanie, pytania amatora

Mateusz Pięta:
Dziękuję, z blogu, którego adres jest wyżej na pewno nie raz skorzystam.

Jeszcze jedno pytanie:

- Czy optymalnej jest wczytywać klasy CSS z oddzielnego pliku arkuszy kaskadowych, czy gdy są one w pliku html/php, razem z treścią?

trzymaj to odzienie
mniej zabawy jak będziesz chciał coś zmienić - to się nazywa optymalizacja czasu pracy ;)
Wojciech Soczyński

Wojciech Soczyński Programista
eksplorator -
blog.wsoczynski.pl

Temat: Cachowanie, includowanie, kodowanie, pytania amatora

Żeby optymalizować, trzeba jeszcze wiedzieć co chodzi wolno - a nie co nam się wydaje, że chodzi wolno. Polecam profilowanie kodu za pomocą Xdebug (do przeglądania przyda się np. WinCacheGrind).
Jakub L.

Jakub L. Programista

Temat: Cachowanie, includowanie, kodowanie, pytania amatora

Przemysław R.:
Mateusz Pięta:
Dziękuję, z blogu, którego adres jest wyżej na pewno nie raz skorzystam.

Jeszcze jedno pytanie:

- Czy optymalnej jest wczytywać klasy CSS z oddzielnego pliku arkuszy kaskadowych, czy gdy są one w pliku html/php, razem z treścią?

trzymaj to odzienie
mniej zabawy jak będziesz chciał coś zmienić - to się nazywa optymalizacja czasu pracy ;)

Zawsze można to wrzucić w HTML idący do przeglądarki, jeden request mniej a i tak trzeba to przeczytać.
Z drugiej strony klient może mieć w cache.

Czytając ten wątek mam wrażenie, że szykowana jest armata na muchę.
Ile odwiedzin ma mieć ten serwis?
Mateusz Pięta

Mateusz Pięta matinet.pl |
wyrusze.pl |
polskimechanik.pl

Temat: Cachowanie, includowanie, kodowanie, pytania amatora

Jak najwięcej...
Liczę na ok. 1000/dziennie po ok. roku czasu.

Edit:
Tu nawet nie chodzi o liczbę odwiedzin, nie chcę także oszczędzać serwera. Po prostu chcę, żeby strona był szybka, bo użytkownicy i Google takie właśnie promują.Mateusz Pięta edytował(a) ten post dnia 18.10.10 o godzinie 20:43

konto usunięte

Temat: Cachowanie, includowanie, kodowanie, pytania amatora

Mateusz Pięta:
Jak najwięcej...
Liczę na ok. 1000/dziennie po ok. roku czasu.

to nie jest duzo :-)
zajmij sie programowaniem. jesli cos bedzie dzialac wolno - wroc z pytaniami o optymalizacje :>
Maciej M.

Maciej M. Advanced Software
Engineer

Temat: Cachowanie, includowanie, kodowanie, pytania amatora

Zawsze można to wrzucić w HTML idący do przeglądarki, jeden request mniej a i tak trzeba to przeczytać.
Z drugiej strony klient może mieć w cache.

Jeśli użytkownik miał by oglądać tylko stronę frontową i nigdy do niej nie wracać - to ma sens - w dobie HTML5 i nowoczesnych przeglądarek umieszczanie CSS,JS w kodzie strony jest największym błędem webmasterów jaki może być.

Proste wyjaśnienie: CSS, JS (jak i obrazki) z danej strony zaczytają się raz, i zostaną w przeglądarce. Przy przejściu na podstrony (chyba chcemy by użytkownicy czytali newsy które mamy na serwisie?) CSS i JS nie bedzie się wczytywał (brak dodatkowych requestów) a strona będzie o te elementy lżejsza - zysk jest już przy 2 odsłonach.
Jeszcze fajniej gdyby te "fragile" były serwowane z osobnej domeny/serwera "kodu statycznego" wtedy przeglądarka nie dostaje multum dodatkowych informacji razem z obrazkami i cssami i JS - np COOKIE (sugeruje pobawić się Fiddlerem + FireBugiem) - mniejszy ruch browser - serwer (wszystkie większe serwisy tak działają).
Jakub L.

Jakub L. Programista

Temat: Cachowanie, includowanie, kodowanie, pytania amatora

Maciej M.:
Zawsze można to wrzucić w HTML idący do przeglądarki, jeden request mniej a i tak trzeba to przeczytać.
Z drugiej strony klient może mieć w cache.

Jeśli użytkownik miał by oglądać tylko stronę frontową i nigdy do niej nie wracać - to ma sens - w dobie HTML5 i nowoczesnych przeglądarek umieszczanie CSS,JS w kodzie strony jest największym błędem webmasterów jaki może być.

Proste wyjaśnienie: CSS, JS (jak i obrazki) z danej strony zaczytają się raz, i zostaną w przeglądarce. Przy przejściu na podstrony (chyba chcemy by użytkownicy czytali newsy które mamy na serwisie?) CSS i JS nie bedzie się wczytywał (brak dodatkowych requestów) a strona będzie o te elementy lżejsza - zysk jest już przy 2 odsłonach.

Zależnie od ustawień przeglądarki.
Jak się wyłączy cache, to będzie się wczytywał zawsze.
Jak przeglądarka będzie miała ustawiony nieduży cache, może wypaść.
Jak krótki - może wypaść.
Jak user wyczyści - może wypaść.
Jak ma ustawione że ma sprawdzać czy dokument się nie zmienił od danego czasu albo zawsze, request poleci i serwer odda not modified (nie chce mi się sprawdzać kodu http).

Tekst się kompresuje bardzo ładnie.
Jeszcze fajniej gdyby te "fragile" były serwowane z osobnej domeny/serwera "kodu statycznego" wtedy przeglądarka nie dostaje multum dodatkowych informacji razem z obrazkami i cssami i JS - np COOKIE (sugeruje pobawić się Fiddlerem + FireBugiem) - mniejszy ruch browser - serwer (wszystkie większe serwisy tak działają).

Więcej pokazuje Wireshark :)
Bartłomiej Ogryczak

Bartłomiej Ogryczak Backend Developer @
Layar

Temat: Cachowanie, includowanie, kodowanie, pytania amatora

Mateusz Jaworski:
Chciałbym zobaczyć sensowny system tagowania, kategoryzowania i przypisywania autorstwa artykułów oparty o pliki tekstowe. Podejrzewam, że w ekstremalnym tempie zaczęłoby to przypominać relacyjną bazę danych, tylko wyglądającą jak zrobiona przez radzieckich naukowców z drutu i betonu.

RDBMS to naprawdę nie jedyne rozwiązanie, ba wynalazki typu EAV to wręcz zaprzeczenie idei tychże, nie mówiąc już o tym, że w nowoczesnych frameworkach to i tak RDBMS służy wyłącznie jako backend do ORM.

A system tagowania, kategoryzowania i przypisywania autorstwa można by zrobić dużo lepiej np. REDISem (w tutorialu jest przykład jak by to wyglądało: http://simonwillison.net/static/2010/redis-tutorial/ )

konto usunięte

Temat: Cachowanie, includowanie, kodowanie, pytania amatora

to i tak RDBMS służy wyłącznie jako backend do ORM.

Bez urazy, ale to co piszesz, nie jest w żadnym stopniu z sobą logicznie powiązane. ORM jak sama nazwa wskazuje to Object Relational Mapping, zachowaj mi relacje pomiędzy pryliardem plików? I że ORM ma się tym zająć? Toć to można byłoby iść na kawę, fajkę i pewnie obiad jeszcze zjeść.

Z wyrazami szacunku,
Przemysław Czekaj.

P.S. php ma ograniczenia, tj ilość ramu, % procka.
Jakub L.

Jakub L. Programista

Temat: Cachowanie, includowanie, kodowanie, pytania amatora

No i co w tym takiego nielogicznego?
Robi się to dokładnie tak samo jak pomiędzy pryliardem tabel.

konto usunięte

Temat: Cachowanie, includowanie, kodowanie, pytania amatora

Jakub L.:
No i co w tym takiego nielogicznego?
Robi się to dokładnie tak samo jak pomiędzy pryliardem tabel.

bazy mają zoptymalizowane silniki do tego typu operacji, a PHP wręcz przeciwnie, ma nałożone ograniczenia - więc gdzie tu logika postępowania? pliki nie mają indeksów, spójnego podziału na struktury danych i ogólnie są do dupy jeżeli chodzi o robienie z nich bazy danych
Jakub L.

Jakub L. Programista

Temat: Cachowanie, includowanie, kodowanie, pytania amatora

Przemysław R.:
Jakub L.:
No i co w tym takiego nielogicznego?
Robi się to dokładnie tak samo jak pomiędzy pryliardem tabel.

bazy mają zoptymalizowane silniki do tego typu operacji, a PHP wręcz przeciwnie, ma nałożone ograniczenia - więc gdzie tu logika postępowania? pliki nie mają indeksów, spójnego podziału na struktury danych i ogólnie są do dupy jeżeli chodzi o robienie z nich bazy danych

No i?
Cały czas obsweruję jak mylona jest możliwość zrobienia czegoś z sensem robienia czegoś w dokładnie taki sposób.

Da się zrobić bazę na plikach, ograniczenia są łatwe do znalezienia, sposoby na ich obejście też, i to, że w końcu po obchodzeniu tych ograniczeń dostanie się (zapewne kulawy) RDBMS też nie jest trudne do zgadnięcia.

Żeby daleko nie szukać (do PHP mi się nie chciało, ale pewnie też by coś się nzalazł): http://sourceforge.net/projects/csvjdbc/



Wyślij zaproszenie do