Temat: Szybkość aplikacji

Strony internetowe na pisane w jakim języku i w połączeniu z jaką bazą danych działają najszybciej ? Oczywiście szybkość również zależy np. od najoptymalniejszych zapytań do bazy itp. Ale chodzi mi o tylko teoretyczne podejście.

Załóżmy, że do wykonania jest strona na wzór http://istockphoto.com

Temat: Szybkość aplikacji

Z reguły baza MySQL jest najszybsza - jednak to zależy od tego, jakie zapytania będziemy robić. Jeśli mają to być proste zapytania, bez wielopoziomowych złączeń, jakichś procedur wbudowanych i na dużych (naprawdę dużych :)) zestawach danych itp. - MySQL chyba wygrywa.
Jeśli jednak chodzi o strony - według mnie jakikolwiek mechanizm, który do wygenerowania strony będzię się "pingał" do bazy danych nie wytrzymuje konkurencji z systemami, w których strony są prekompilowane do HTMLa i operujemy tak naprawdę bezpośrednio na plikach. Tak mamy zbudowany nasz system COBAEX CMS - właśnie pod kątem (m.in.) wydajności system działa na 2 serwerach: na jednym mamy administrację systemem (gdzie robimy operacje na bazach), a drugi jest tylko prezentacyjnym. Strony na tym drugim są albo w całości prekompilowane do HTMLa, albo ich elementy są prekompilowane (tak np. działa bardziej zaawansowany portal - jak np. www.twoje-zdanie.pl). Elementy te następnie są odpowiednio składane w stronki. W takim podejściu na serwerze prezentacyjnym owszem istnieje baza danych (MySQL), ale posiada ona tak naprawdę w pewnym stopniu również "skompilowane" dane wykorzystywane tylko do odczytu czy wyszukiwania. Dzięki temu możemy sobie pozwolić na np. nie wykorzystywanie kluczy obcych (które z definicji spowalniają działanie).

Temat: Szybkość aplikacji

teoretycznie najszybciej będzie w assemblerze, a baza z tabelami załadowanymi do ramu :)

Temat: Szybkość aplikacji

Wojciech Zieliński:
Z reguły baza MySQL jest najszybsza - jednak to zależy od tego, jakie zapytania będziemy robić. Jeśli mają to być proste zapytania, bez wielopoziomowych złączeń, jakichś procedur wbudowanych i na dużych (naprawdę dużych :)) zestawach danych itp. - MySQL chyba wygrywa.
Jeśli jednak chodzi o strony - według mnie jakikolwiek mechanizm, który do wygenerowania strony będzię się "pingał" do bazy danych nie wytrzymuje konkurencji z systemami, w których strony są prekompilowane do HTMLa i operujemy tak naprawdę bezpośrednio na plikach. Tak mamy zbudowany nasz system COBAEX CMS - właśnie pod kątem (m.in.) wydajności system działa na 2 serwerach: na jednym mamy administrację systemem (gdzie robimy operacje na bazach), a drugi jest tylko prezentacyjnym. Strony na tym drugim są albo w całości prekompilowane do HTMLa, albo ich elementy są prekompilowane (tak np. działa bardziej zaawansowany portal - jak np. www.twoje-zdanie.pl). Elementy te następnie są odpowiednio składane w stronki. W takim podejściu na serwerze prezentacyjnym owszem istnieje baza danych (MySQL), ale posiada ona tak naprawdę w pewnym stopniu również "skompilowane" dane wykorzystywane tylko do odczytu czy wyszukiwania. Dzięki temu możemy sobie pozwolić na np. nie wykorzystywanie kluczy obcych (które z definicji spowalniają działanie).

słowo "skompilowane" w twojej wypowiedzi zamieniłbym na "zcache'owane"

wracając do tematu, ja bym postawił na pythona + postgreSQL (nie wiem jak ten tandem działa w praktyce, ale postgres swego czasu bardzo mnie odprężał w połączeniu z phpem, o milion razy bardziej niż mysql...).Wojciech Sznapka edytował(a) ten post dnia 02.09.09 o godzinie 18:02

Temat: Szybkość aplikacji

Wojciech Zieliński:
Z reguły baza MySQL jest najszybsza - jednak to zależy od tego, jakie zapytania będziemy robić. Jeśli mają to być proste zapytania, bez wielopoziomowych złączeń, jakichś procedur wbudowanych i na dużych (naprawdę dużych :)) zestawach danych itp. - MySQL chyba wygrywa.

to nie jest rok 2000. MySQL jest w chwili obecnej najgorszym chyba darmowym silnikiem bazy danych. Postresql wygrywa chyba pod każdym względem, przede wszystkim w serwisach z większym ruchem. Co do języka - php do wydajnych nie należy, do tego dochodzi jeszcze narzut frameworka, kompilacja szablonów (czy to smarty, czy xslt, zawsze "coś" narzuci).

Mimo tego - duet php + postgresql nadaje się do praktycznie wszystkich zastosowań.

Jeśli jednak chodzi o strony [...]

a ten spam o tym, że macie cache w swoim systemie obsługującym AŻ dwa serwery to mogłeś sobie jednak darować...

Dzięki temu możemy sobie pozwolić na np. nie wykorzystywanie kluczy obcych
(które z definicji spowalniają działanie).

a o integralność danych dbają skompilowane dane. Jezu jaki bełkot.

Temat: Szybkość aplikacji

Wojciech Potocki:
Strony internetowe na pisane w jakim języku i w połączeniu z jaką bazą danych działają najszybciej ? Oczywiście szybkość również zależy np. od najoptymalniejszych zapytań do bazy itp. Ale chodzi mi o tylko teoretyczne podejście.

Teoretycznie to CGI jest najszybsze z rozsądnych. Oceniając szybkość strony to nie generacja, ale efekt wyjściowy (kod) ma największy wpływ na odczucie szybkości. Optymalizacje ładowania CSSów, JSów, samego HTMLa, obrazków, dokładny dobór sposobów cache na te elementy, lokalizacja serwera geograficzna to temat rzeka, a sam google wie o tym bardzo dużo.

Temat: Szybkość aplikacji

Paweł Chalacis:

a ten spam o tym, że macie cache w swoim systemie obsługującym AŻ dwa serwery to mogłeś sobie jednak darować...

No też mnie to zastanawia. Wojtku Z. Czy mógłbyś ten temat rozwinąć? Rozumiem, że system pracuje szybciej, ponieważ serwer który stoi na pierwszej linii frontu user->serwis serwuje statyczne pliki. Tylko, czy jest to:
1) wygodne
2) drogie - dwa serwery, to nie jeden
3) po co cms w takim razie - frontpage robi to samo

Temat: Szybkość aplikacji

Sebastian Pienio:
Teoretycznie to CGI jest najszybsze z rozsądnych.

? Chyba, że masz zamiar w C pisać.

Temat: Szybkość aplikacji

Dariusz Ormicki:

Sebastian Pienio:
Teoretycznie to CGI jest najszybsze z rozsądnych.

? Chyba, że masz zamiar w C pisać.

CGI jest protokołem niskiego poziomu (a więc szybkim), jak lubisz możesz pisać w C (stdin/stdout). Jak się kiedyś miało "serwer" Pentium100MHz/16MB RAMu to pisało się stronki w C++ pod Debianem :)

Temat: Szybkość aplikacji

Sebastian Pienio:
CGI jest protokołem niskiego poziomu (a więc szybkim), jak lubisz możesz pisać w C (stdin/stdout). Jak się kiedyś miało "serwer" Pentium100MHz/16MB RAMu to pisało się stronki w C++ pod Debianem :)

Kiedyś, jak nie było np. FastCGI, uruchamianie większych aplikacji w językach wysokiego poziomu jako CGI jest samobójstwem.

Temat: Szybkość aplikacji

Dlatego wymyślono FastCGI, SCGI, mod_python, mod_wsgi itd. I generalnie sprawdza się to dość dobrze.

Temat: Szybkość aplikacji

Największą wadą CGI jest to, że jest tylko(!) interfejsem, nie tworzy środowiska z aplikacją (jak np. FastCGI), a jedynie "bezmyślnie" wywołuje za każdym razem wszystko od nowa.. to zawsze była kwestia czasu kiedy zostanie zastąpiony czymś innym, przecież internet nie może opierać się jedynie na firmowych stronkach napisanych w Perlu ;-]Dariusz Ormicki edytował(a) ten post dnia 03.09.09 o godzinie 02:34

Temat: Szybkość aplikacji

Wojciech Zieliński:
Z reguły baza MySQL jest najszybsza

A Oracle, MSSQL, Sybase ... ?

Temat: Szybkość aplikacji

Wojciech Potocki:
Strony internetowe na pisane w jakim języku i w połączeniu z jaką bazą danych działają najszybciej ? Oczywiście szybkość również zależy np. od najoptymalniejszych zapytań do bazy itp. Ale chodzi mi o tylko teoretyczne podejście.

Załóżmy, że do wykonania jest strona na wzór http://istockphoto.com

Wiesz, musisz jeszcze uwzględnić w jakich okolicznościach (jak np. liczba jednoczesnych sesji na serwerze czy infrastruktura sprzętowa) "język" i "baza" będą ze sobą współpracować.
Nie wiem jak to wygląda w przypadku PHP ale jeśli chodzi o Javę to gdy masz serwer dostawcy X i bazę Y to i tak wydajność w dużym stopniu zależy od tego jak w oparciu o test wydajności skonfigurujesz parametry bazy,serwera czy JVM.
Także według mnie nie ma czegoś takiego jak "język i baza działające najszybciej".

PS. Z tego co do tej pory zaobserwowałem to i tak największy wpływ na wydajność systemu mają błędy ludzkie.

pzdr

Temat: Szybkość aplikacji

Wojciech Zieliński:
Z reguły baza MySQL jest najszybsza - jednak to zależy od tego, jakie zapytania będziemy robić. Jeśli mają to być proste zapytania, bez wielopoziomowych złączeń, jakichś procedur wbudowanych i na dużych (naprawdę dużych :)) zestawach danych itp. - MySQL chyba wygrywa.
Jeśli jednak chodzi o strony - według mnie jakikolwiek mechanizm, który do wygenerowania strony będzię się "pingał" do bazy danych nie wytrzymuje konkurencji z systemami, w których strony są prekompilowane do HTMLa i operujemy tak naprawdę bezpośrednio na plikach. Tak mamy zbudowany nasz system COBAEX CMS - właśnie pod kątem (m.in.) wydajności system działa na 2 serwerach: na jednym mamy administrację systemem (gdzie robimy operacje na bazach), a drugi jest tylko prezentacyjnym. Strony na tym drugim są albo w całości prekompilowane do HTMLa, albo ich elementy są prekompilowane (tak np. działa bardziej zaawansowany portal - jak np. www.twoje-zdanie.pl). Elementy te następnie są odpowiednio składane w stronki. W takim podejściu na serwerze prezentacyjnym owszem istnieje baza danych (MySQL), ale posiada ona tak naprawdę w pewnym stopniu również "skompilowane" dane wykorzystywane tylko do odczytu czy wyszukiwania. Dzięki temu możemy sobie pozwolić na np. nie wykorzystywanie kluczy obcych (które z definicji spowalniają działanie).

Tak z ciekawości. Co dokładnie was skłoniło do zaprojektowania właśnie takiej architektury?

pzdr

Temat: Szybkość aplikacji

Stanisław Głogowski:

Wojciech Zieliński:
Z reguły baza MySQL jest najszybsza

A Oracle, MSSQL, Sybase ... ?

Nie ma obiektywnych testow porownujacych bazy danych. Mozna powiedziec, ze najszybszy jest:

mySQL gdy zapytania sa wzglednie proste

postgreSQL gdy zapytania sa bardziej zlozone, a ciagle chcemy darmowej bazy

MsSql/Sybase gdy potrzebujemy latwo skalowalnego silnika sprawujacego sie bardzo dobrze w wiekszosci zastosowan

Oracle gdy jedynym kryterium jest szybkosc bazy lub potrzebujemy duzo triggerow

Temat: Szybkość aplikacji

Paweł Chalacis:

Wojciech Zieliński:
Z reguły baza MySQL jest najszybsza - jednak to zależy od tego, jakie zapytania będziemy robić. Jeśli mają to być proste zapytania, bez wielopoziomowych złączeń, jakichś procedur wbudowanych i na dużych (naprawdę dużych :)) zestawach danych itp. - MySQL chyba wygrywa.

to nie jest rok 2000. MySQL jest w chwili obecnej najgorszym chyba darmowym silnikiem bazy danych. Postresql wygrywa chyba pod każdym względem, przede wszystkim w serwisach z większym ruchem. Co do języka - php do wydajnych nie należy, do tego dochodzi jeszcze narzut frameworka, kompilacja szablonów (czy to smarty, czy xslt, zawsze "coś" narzuci).

Mimo tego - duet php + postgresql nadaje się do praktycznie wszystkich zastosowań.

Nie ma rzeczy nadających się do wszystkiego - jeśli coś jest do wszystkiego, to jest do niczego :)
Co do duetu, o którym wspomniałeś (jak i kilka innych osób) - Postgres jest owszem wspaniałą bazą. Używamy go nagminnie głównie w naszych aplikacjach. Dostarcza bardzo bogatej funkcjonalności - o niebo bogatszej od MySQLa. Jest dużo uniwersalniejszy i ma efektywniejszy mechanizm przygotowywania planu zapytania.
JEDNAK przez to, że jego funkcjonalność jest bogatsza i ma dalece nieporównywalnie wyższe możliwości w zakresie tworzenia złożonych zapytać - JEST WOLNIEJSZY PRZY PROSTYCH ZAPYTANIACH od baz, które na te prostsze zapytania postawiły główny środek ciężkości. Zmierzam do tego, że jeśli mamy zapytanie: SELECT sth FROM table WHERE sth = 'sth else', a table ma 20 mln rekordów - MySQL będzie szybszy niż Postgres. Wystarczy jednak, że dołożymy JOINa - Postgres zacznie wygrywać.

Paweł Chalacis:

Jeśli jednak chodzi o strony [...]

a ten spam o tym, że macie cache w swoim systemie obsługującym AŻ dwa serwery to mogłeś sobie jednak darować...

Coś mi się widzi, że nie zrozumiałeś... Ale inni tak, więc jeśli potrzebujesz dodatkowego wsparcia - zapraszam na prv :)

Dzięki temu możemy sobie pozwolić na np. nie wykorzystywanie kluczy obcych
(które z definicji spowalniają działanie).

a o integralność danych dbają skompilowane dane. Jezu jaki bełkot.

No tak - zdecydowanie nie zrozumiałeś...
Dane na serwerze prezentacyjnym służą TYLKO odczytowi - nie są NIGDY modyfikowane - jedynie ładowane na zasadzie bulk-loadu. Dane na serwerze administracyjnym, którego obciążenie jest nieporównywalnie mniejsze są w pełni relacyjne i nota bene stoją na Postgresie.

Peter Kowalski:
No też mnie to zastanawia. Wojtku Z. Czy mógłbyś ten temat
rozwinąć? Rozumiem, że system pracuje szybciej, ponieważ serwer
który stoi na pierwszej linii frontu user->serwis serwuje
statyczne pliki. Tylko, czy jest to:
1) wygodne
2) drogie - dwa serwery, to nie jeden
3) po co cms w takim razie - frontpage robi to samo

Ogólnie - serwer prezentacyjny tylko w określonych sytuacjach serwuje statyczne pliki. Częściej "składa" stronę ze statycznych plików (więc trochę "logiki" ma). Przykładowo - składa stronę z pliki "naglowek.html", "tresc.html" i "stopka.html". Inny przykład - wyniki wyszukiwania - w bazie MySQL system znajduje wszystkie wiersze spelniajace kryteria (np. dla www.twoje-zdanie.pl wszystkie firmy z okreslonego wojewodztwa). Następnie dostaje listę IDkow, ktore jednoczesnie sa nazwami plikow, w ktorych mamy skompilowane "itemy" listy - i sklada z niej liste.
Statyczne pliki są tworzone w przypadku stron, na ktorych tresc w zaden sposob nie wplywa ogladajacy - przykladem takiej strony jest strona typu wizytówkowego.
Tak naprawdę to, co determinuje które elementy i strony w jaki sposób są kompilowane (w całości, częściowo, przy publikacji, ad-hoc automatycznie, w momencie wystąpienia jakiegoś zdarzenia, o określonej porze itp.) determinowane jest przez tzw. komponenty, z których zbudowana jest strona. Ale to historia na inny chyba wątek :)
Ad. 1. conajmniej tak samo wygodne jak std CMS - bo cala zabawa w kompilacje, potencjalne kompilacje automatyczne itp. sa wykonywane całkowicie przezroczyscie. Jedyną może różnicą (choć niektóre CMSy dostarczają takiej funkcjonalności - u nas jest to niejako "wymuszone") jest fakt, że po wprowadzeniu zmian na stronie (w interfejsie CMSa) trzeba je "opublikować" - czyli kliknąć "Publikuj" aby system wysłał zmiany na serwer prezentacyjny (oczywiście jest też wcześniejszy "podgląd" na serwerze administracyjnym).
Ad. 2. serwery moga być logiczne - mamy instalacje systemów na jednym serwerze, jedynie z rozbiciem logicznym. Przy takiej architekturze sprzętowej więc nie jest to droższe. Jeśli jednak chcemy zastosować architekturę "z prawdziwego zdarzenia" (którą sugerowałbym w przypadku większych stron) - wtedy rzeczywiście 2 serwery sprzętowe są droższe niż jeden :)
Ad. 3. odpowiedź jest taka sama, jak dlaczego stosujemy CMSy a nie robimy strony we Frontpage. Od strony użytkownika to działa i wygląda jak CMS. Od strony technicznej to wygląda inaczej :)

Paweł Włodarski:
Tak z ciekawości. Co dokładnie was skłoniło do
zaprojektowania właśnie takiej architektury?

Głównym elementem było zastanowienie się, jak większość CMSów działa. Otóż mamy sobie bazę danych do której z jednej strony mamy podpięty interfejs administracyjny, a z drugiej stronkę. Jak chcemy coś zmienić na stronie, przez interfejs administracyjny zmieniamy coś w bazie. Jeśli chcemy odświetlić stronę, strona za każdym razem "pinga" się do bazy, aby wiedzieć co pokazać.
I teraz kluczowe pytanie - jak często zmieniamy stronę, a jak często jest ona prezentowana ? Wydaje mi się, że częściej jest ona prezentowana... Co oznacza, że wielokrotnie "pingamy" się do tej bazy bez sensu - bo dane, które dostaniemy i tak są takie same.
Oczywiście - można by stwierdzić, że taką rolę pełni jakiś uniwersalny cache. Ale cache jest z reguły czasowy - a nasza architektura jest bardziej funkcyjna - czyli zmienia zawartość "cache" (serwera prezentacyjnego) TYLKO kiedy jest rzeczywiście taka konieczność.
Jest oczywiści jeszcze kilka innych elementów, które według nas powodują, że architektura jest lepsza:
- bezpieczeństwo - kompletna separacja danych od ich widoku - serwer prezentacyjny nie ma bezpośredniego (a czasem i pośredniego) dostępu do serwera administracyjnego, więc włam na warstwę prezentacyjną nie niszczy tak naprawdę danych (czasem również chroni dane wrażliwe - jak np. w jednym z naszych wdrożeń systemu Akademickiego Biura Karier dane na temat CV studentów)
- łatwość odtworzenia - załóżmy, że ktoś się włamał na nasz serwer prezentacyjny (stronkę) i zniszczył wszystkie podstrony, jak i bazę, o której w jakiś sposób się dostał. Odtworzenie polega praktycznie na kliknięciu "Publikuj" na serwerze administracyjnym i wszystko jest od nowa kompilowane i wrzucane na prezentacyjny. Innymi słowy - dumny włamywacz jedynie zaatakował i zniszczył kopię :)
Jest jeszcze jeden powód wykorzystania tego rodzaju architektury. Mianowicie nasz COBAEX CMS działa na naszej platformie COBAEX. Platforma ta pozwala na instalowanie różnorodnych aplikacji - w tym systemów raportujących (COBAEX RPT) czy dedykowanych systemów CRM/ERP. Takie systemy nie powinny raczej działać gdzieś na jakimś serwerze w internecie, a wewnątrz sieci firmowej. Jednocześnie w obecnych czasach odchodzi się od samodzielnego utrzymywania strony w ramach swoich serwerów, a wyrzuca się ją na zewnętrz na serwery typu home.pl czy kei. Jednak wygodnie byłoby, aby zarządzać tą stroną z naszego systemu zintegrowanego - chociażby z uwagi na możliwośći użycia single-logon czy powiązania strony z naszymi systemami sprzedażowymi.
Zastosowanie opisanej architektury pozwala właśnie na odseparowanie warstwy administracyjnej od prezentacyjnej. I pozwala na de-facto uzyskanie pełnej inercji i integracji naszych innych rozwiązań z naszym systemem CMS przy jednoczesnym utrzymywaniu strony (serwera prezentacyjnego) na zewnętrz.

Uff - mam nadzieję, że rozwiałem wszelkie wątpliwości :) Jeśli jednak nie - zapraszam do dalszej dyskusji :)

Temat: Szybkość aplikacji

Wojciech Potocki:
Strony internetowe na pisane w jakim języku i w połączeniu z jaką bazą danych działają najszybciej ? Oczywiście szybkość również zależy np. od najoptymalniejszych zapytań do bazy itp. Ale chodzi mi o tylko teoretyczne podejście.

W praktyce czy to będzie php, ruby czy python nie jest decydujące.
Nieistotne jest to co jest najszybsze tylko to co się skaluje.

Ty pytasz jak szybko dostarczysz stronę jednemu użytkownikowi a istotne jest czy dostarczysz ją jednocześnie np 1000 w akceptowalnym dla użytkownika czasie.
To który to będzie język programowania to najmniejszy problem w porównaniu z architekturą system, kontrolą poprawności danych w X warstwach cachujących etc, etc (zagadnienia nie związane z konkretnym językiem programowania).
Jakiś zarys problemu starał się pokazać Wojciech przy okazji "nieco" promując/linkując swój produkt.

Temat: Szybkość aplikacji

Wojciech Zieliński:

Paweł Włodarski:
Tak z ciekawości. Co dokładnie was skłoniło do
zaprojektowania właśnie takiej architektury?

Głównym elementem było zastanowienie się, jak większość CMSów działa. Otóż mamy sobie bazę danych do której z jednej strony mamy podpięty interfejs administracyjny, a z drugiej stronkę. Jak chcemy coś zmienić na stronie, przez interfejs administracyjny zmieniamy coś w bazie. Jeśli chcemy odświetlić stronę, strona za każdym razem "pinga" się do bazy, aby wiedzieć co pokazać.
I teraz kluczowe pytanie - jak często zmieniamy stronę, a jak często jest ona prezentowana ? Wydaje mi się, że częściej jest ona prezentowana... Co oznacza, że wielokrotnie "pingamy" się do tej bazy bez sensu - bo dane, które dostaniemy i tak są takie same.

Wiesz, spodziewałem się bardziej odpowiedzi typu "przeprowadziliśmy testy obciążeniowe i na ich podstawie doszliśmy do wniosku ,że generowanie stron 'live' jest wąskim gardłem aplikacji". Wydaje mi się ,że to co podałeś to przykład "premature optimization" ,ale pytałem tylko z ciekawości.

pzdr

Temat: Szybkość aplikacji

Wojciech Potocki:
Strony internetowe na pisane w jakim języku i w połączeniu z jaką bazą danych działają najszybciej ? Oczywiście szybkość również zależy np. od najoptymalniejszych zapytań do bazy itp. Ale chodzi mi o tylko teoretyczne podejście.

Załóżmy, że do wykonania jest strona na wzór http://istockphoto.com

osobiście polecam Javę, aczkolwiek prawda jest taka ze każde w miarę nowoczesne środowisko powinno spełnić Twoje wymagania o ile aplikacja jest poprawnie zaprojektowana

np. Twitter - do niedawna całość była napisana w Ruby'm i obsługiwali ogromną liczbę zapytań na sekundę

owszem, problemy z wydajnością się pojawiły przez co musieli przepisać część aplikacji w Scali, ale na Twoim miejscu bym się o to nie martwił :-) jak będziesz mieć taki ruch jak wspomniany twitter to pieniądze na dodatkową optymalizację same się znajdą :-)