Od dawna stosowane są mechanizmy służące do zapisywania wyników z bazy danych w plikach tekstowych, w celu przyspieszenie pracy skryptów (cash). I jest to całkiem logiczne, szczególnie w przypadku bardziej złożonych zapytań.
Jednak ostatnio, chyba wraz z pojawieniem się najnowszej wersji xmb_forum (Partagium) zwróciłem uwagę na nową tendencję: zastępowanie plików tekstowych bazą danych. W forum tym wszystkie pliki szablonów (templates) zostały umieszczone w bazie. I przyznam się szczerze, że mocno mnie to zaskoczyło. Bo choć do zalet stosowania zapisu w bazie chyba nikogo nie trzeba przekonywać (łatwość w aktualizacji, katalogowaniu, brak problemów z nadawaniem CHMOD itp.) to jednak przekonany byłem, że rozwiązanie takie musi być o wiele wolniejsze.
Skłoniło mnie to do przeprowadzenia serii testów. Umieszczam tu kilka z wyników, które mam nadzieję skłonią Was do zastanowienie się nad tym tematem. Wszystkie zostały wykonane przy pomocy malutkiego skryptu zapisującego i przeliczającego wyniki, który można ściągnąć stąd:
www.mStudio.nQ.pl/download/scrypty/czas/czas.zip na Windows XP, z Apachem 1,3, php 4.3 oraz MySQL 3.23
A tu jest przykład kodu testów

A1. wyświetlamy zawartość małego pliku (1,4 KB) z pliku tekstowego (wyniki w sekundach):A2. Ten sam tekst z bazy MySQL zawierającej tylko ten jeden rekord:A3. Taki sam tekst, lecz z tabeli zawierającej około 200 rekordów

-----------------------------

B1. wyświetlamy zawartość pliku (61 KB) z pliku tekstowego (wyniki w sekundach):B2. Ten sam tekst z bazy MySQL zawierającej tylko ten jeden rekord:
B3. Taki sam tekst, lecz z tabeli zawierającej około 200 rekordów
Podsumowanie:
Pliki rzeczywiście zazwyczaj są szybsze, ale nie tak bardzo, jak by się mogło wydawać. Zaskakujące efekty dało również porównanie wyników MySQL. Okazało się, że wielkość bazy (przynajmniej w porównaniu 1-200) nie ma wpływu na prędkość wykonywania zapytań. Czasami wręcz (sic!) większa baza jest szybsza...
Co o tym sądzicie?

Jezeli chodzi o mnie to ja zawsze bylem bazodanowcem i wszystko pakowalem w baze. mySQL daje to czego z txt nie osiągniesz - dane statystyczne - praca z baza z zalozenia jest znacznie latwiejsza.

Szybkosc otwierania strony to jeden z glownych czynnikow na ktory zwraca uwage uzytkownik internetu. I w momencie kiedy mySQL szwankuje na serverze to czas otwierania strony moze maaaaxymalnie sie zwiekszyc. Dzis mialem ta przykrosc na home.pl (wielki dostawca ale mySQL szwankuje tam juz od tygodnia).

Konczac jestem zawsze i wszedzie za baza danych ....

Pozdrawiam

Odkąd przerzucilem sie z plików na BD, to nie mam zamiaru wracać. Od zawsze otwieranie, zamykanie i operacje na plikach byly czyms czego nie lubiłem. A to że czasami troszke wolniejsze? Niech będzie i wolniejsze, jesli tylko jest wygodniejsze.

Jednak pojawia się pytanie: Jak daleko się posuwać?
Przecież można by w bazie przechowywać praktycznie wszystko.
Już wspomniałem o plikach cashu - może zamiast plików warto by używać mechanizmów zapisujących wyniki trudniejszych zapytań z bazy właśnie w bazie?
Na innym Topicu na tym forum poruszony jest temat przechowywania zmiennych sesjowych w bazie. Czy ma to sens?
A może posuniemy się do skrajności, i zaczniemy przechowywać w bazie również pliki, choćby grafikę?
Czy gdzieś tu zaczyna się paranoja?

cos co moze umkleo - kiedy umiejetnie cachujemy "ile sie da" wyniki skryptow (chociaz ich fragmentow) jestesmy nie tylko dostarczyc tresc szybciej ale i funkcjonowac w miare stabilnie gdy wlasnie zabraklo bazy danych (np padla).

wczoraj uswiadomilem sobie ze jesli wystarczajaco dobrze sie usiadzie to nawet gdy bedziemy mieli krytyczne padniecie bazy danych seriws bedzie chodzil zachowujac wszystkie pozory.

Prędkość liniowego odczytu danych z bazy jest zwykle porównywalna z odczytem z systemu plików. Tutaj nie ma co szukać przewagi któregoś z rozwiązań - jeśli wszystko jest dobrze skonfigurowane to różnice powinny być na poziomie błędu statystycznego.
Co innego jeśli chcemy czegoś poszukać - tutaj baza jest absolutnie bezkonkurencyjna. Dlatego jeśli potrzebujemy wydajności, najlepiej trzymać co się da w bazie danych i zadbać równocześnie o to, żeby sama baza i sprzęt na którym pracuje były skonfigurowane optymalnie. Na co warto zwrócić uwagę?

Jeśli to możliwe, należy przygotować sobie osobną maszynę dla bazy danych i połączyć szybką sieciówką z serwerem www. Najważniejszymi elementami serwera bazodanowego są dyski twarde i pamięć ram. Jeśli chodzi o dyski to świetnie podnosi wydajność konfiguracja typu raid-0. Jeśli musimy liczyć się z kosztami to możemy zacząć od kupna płyty głównej z kontrolerem raid (zwykle różnica cenowa jest niewielka) i dwóch identycznych dysków twardych ATA. Dobrze jeśli dysk ma 8MB cache - przy intensywnym użytkowaniu jest to ważne. Dla przykładu w hurtowni Maxtor DiamondMax +9 80 GB (ATA/133, 8MB cache) kosztuje około 500 PLN. Połączenie dwóch takich dysków w system raid-0 daje nam jeden dysk o pojemności 160GB, w dodatku o wydajności 195% pojedynczego. Jeśli ktoś cierpi na nadmiar gotówki to polecam specjalny kontroler scsi raid i do tego kilka dysków takich jak np. Seagate Cheetah X15K.3 36.7 GB - to cudeńko ma 15.000 obr./min i średni czas dostępu na poziomie 4,3 ms - tylko niestety słono kosztuje. Ram powinien być szybki, ale nie należy przesadzić. DDR-433MHz Corsair we wspólpracy z Athlonem 2000+ zachowuje się nieprzewidywalnie. Najlepiej zadbać po prostu o synchronizację procesora z ramem. Czyli np. Athlon 2600+ (szyna 333MHz) i DDR-RAM Kingston'a 333MHz to najzdrowsze zestawienie.

Kilka słów o konfiguracji MySQL'a. Zakładam, że jeśli ktoś wydał kasę na sprzęt to teraz chce oszczędzić na sofcie i instaluje na serwerze linuxa - słuszne posunięcie. :wink: Jak powinien wyglądać plik konfiguracyjny MySQL'a? Oczywiście muszą w nim być podstawowe informacje:Logi mogą nam oczywiście zacząć rosnąć w niepochamowanym tempie, w związku z czym trzeba pomyśleć o ich rotacji. Jeśli chodzi o dostosowywanie ustawień bazy danych do specyfiki sprzętowej to warto zerknąć do przykładów w podkatalogu /support-files. Dobre dobranie buforowania pozwoli nam wycisnąć ze sprzętu co się da. Jeśli mamy niezbyt wydajną platformę sprzętową nasz plik my.cnf może wyglądać tak:Jeśli natomiast kupiliśmy sobie mocny serwer to musimy umożliwić mysql'owi wykorzystanie go odpowiednio. Co warto więc zmodyfikować? To tyle w zarysie jeśli chodzi o wydajność samej bazy danych.

A co sadzicie o XMLu jako pewnym zamienniku bazy danych przy malych projektach ?


P.S. Doszyly mnie sluchy, ze nowy system Redmonda ma posiadac system plikow oparty o baze danych, tak wiec to co mowicie o przechowywyaniu plikow graficznych itp w bazie chyba ma jakies uzasadnienie. Poza tym sam w pracy mam doczynienia z systemem plikow opartych o baze danych.

Od biedy można spróbować posłużyć się XML'em jako zamiennikiem bazy danych ale musisz wtedy obsłużyć wszystkie operacje wyszukiwania, dodawania i zamiany na poziomie php, a takie technologie jak XMLQuery są jeszcze bardzo niedojrzałe. Natomiast świetnie sprawdza się XML przechowywany w bazie danych. Do pewnego poziomu abstrakcji przechowujesz dane w polach bazy danych, a poniżej tego poziomu w XMLu (w jednym z pól bazy). Np. przechowując artykuły możesz datę publikacji, tytuł i autora przechowywać w osobnych polach, a sam artykuł z podziałem na paragrafy, sekcje, cytaty, słowa kluczowe itd. trzymać w jednym z pól w XML-u. W Oracle'u możesz nawet wydawać zapytania do wnętrza tego XML'a ale jak wiadomo na komercyjną licencję Oracle'a mało kogo stać. Postgres jeszcze tego nie umie (o MySQL'u nawet nie wspominam, bo projektanci głośno się wypowiedzieli, że nawet nie mają planów się za coś takiego brać). Mimo wszystko jest to wygodne. Można sobie wyszukać co trzeba z bazy, a potem XML + parser z php zapewnią prawidłowe formatowanie itp.

Czyli XML tylko jako wzorzec ?

No, powiedzmy jako źródło informacji na poziomie szczegółowym.

juz rozumiem

Ja tam uważam, że każdy musi subiektywnie podejśc do tego zagadnienia. Uświadomoić sobie co jest dla niego ważniejsze = wygoda tworzenia, czy mikrosekundowe zyski w oglądaniu.

Heh. Nie wiem co powiedziec.
Na plikach zaczynalem ale to przeszlosc. Potem dlugo dlugo mysql.

Ostatnim czasem jednak nie korzystam z mysqla. Zaczalem uzywac PostgreSQLa i Interbase'a(FireBird).
Aktualnie mam na swoim 486 80 MHz 16 MB Ramu odpalonego php 4.2.3 i Psosstgresa 7.2 + FireBird juz nie pamietam jaki .
okolo 1-3 minut zajmuje mi wylistowanie 20000 rekordow z warunkiem (WHERE KOD=.....). Podobny okres czasu zajmuje mi wylistowanie WHERE + LIKE kilka razy . To na Interbasie - jego odpowiedniku FireBirdzie.
Własnie importuje 20000 rekordow do PostgreSQLa w ktorym robilem juz kilka rzeczy, chce porownac ich szybkosci. MySQLa porzucilem bo nie daje juz takich mozliwosci, poza tym do zastosowan komercyjnych trzeba miec na niego licencje....
Brakuje mi w ankecie czegos takiego jak Bazy Danych inne niz mysql .

Pozdrawiam

W sumie pliki są bardziej powszechne... W necie o free MySQL dość trudno... A dla małych porcji informacji pliki to niezłe wyjście... Ale osobiście przystaję za MySQL... 8)

Jakich konkretnie? Pytanie troche podchwytliwe, wiem czego brakuje w MySQL, ale uwazam, ze w wiekszosci zastosowan widoki nie sa niezbedne, a subquery, tranzakcje itp. juz MySQL 4.1 ma.
Natomiast z cala pewnoscia MySQL jest najszybszy z wymienionych.



O... to ciekawe. Mozesz podac odpowiedni fragment licencji? Kiedys trwala o tym dyskusja na pl.comp.www i stanelo na tym, ze jednak nie jest potrzebna. Ze platna licencja jest potrzebna, tylko kiedy MODYFIKUJESZ zrodla MySQLa.

Z tego co wiem płatna licencja jest potrzebna gdy za MySQL pobiera sie pieniądze czy jakoś tak...

Wlasnie najbardziej potrzebne mi sa widoki (laczenie tabel i inne...) Mozliwosc implementacji skryptow perlowych, laczenia tabeli....

Druga sprawa jest to, ze tak narawde licencji nie czytalem, ale ostatnio bardzo duzo grup dyskusyjnych zwiedzalem a tam kilka razy bylo to poruszane, ale potem tego sam poszukam w warunkach licencyjnych . Fakt faktem ze mysql jest najprostszy

ja tam jestem za mysql

po 1. 0.001 sek to dla mnie niezbyt duzo, a wygoda jest o wieeele wieksza.
po 2. pliki zawsze doprowadzaly mnie do szalu
po 3. jak sie ma szybkiego serwa to tylko wygoda sie liczy

I jeszcze mala odwiedzalnosc...

Gratuluje pomyslu. Przyszlosc programisty, dla ktorego najwazniejsza jest wygoda jest zaprawde swietlana.

Wg mnie nie ma tu paranoi trzymanie grafiki w bazach danych to nie nowosc i w pewnych sytuacjach moze sie przydac. Co do predkosci i wydajnosci (jedno i to samo?) pliki nadaja sie do mniejszych stron ale jesli wiecej uzytkownikow kozysta z serwisy baza jest niezbedna chocby ze wzgledu na kolejkowanie zapytan typu insert i select oraz ich priorytety, bazy danych optymalizuja rowniez zapis fizyczny na dyskach inteligentnie rozmieszczajac dane (jak ktos wie co to sa B-drzewa to wie o czym mowie innych odsylam do podrecznikow algorytmiki;-)).

Pliki są wygodniejsze nie tylko dla mn iejszych stron ale i dla mniejszych skryptów...

cale rozwazania tocza sie nad przewaga plikow nad baza (czy tez odwrotnie) w trzymaniu danych takich jak grafika - ale niewiedziec czemu nikt nie wspomnial tu o jednej dosc istonej rzeczy - zamiast trzymac grafike, jezyk, etc na dysku mozna to wszystko wrzucic do pamieci,
grafika + jezyk z calej strony przewaznie nie zajmuje wiecej jak kilka M - dla przykladu jezyk z phpBB jesli mnie pamiec nie myli zajmuje raptem kilkadziesiat K, pojedynczy theme to jakies kilkaset k (galeria avatarow, czy jakakolwiek galeria na stronie to oczywiscie inna para kaloszy) dosc duza gra internetowa RedDragon ma grafike ktora zajmuje niecale 2M i mimo ze wspiera 4 jezyki to w sumie wszystkie zwroty zajmuja kilkaset k (200k o ile dobrze pamietam) - to stosunkowo niewiele nawet dla najslabszych serverow - a trzymanie wszystkiego na stale w pamieci powinno w dosc duzym stopniu odciazyc dysk
dla jezyka i jemu podobnych danych warto zastanowic sie nad uzyciem bazy z tabela przechowywana w pamieci - dodatkowo indexowanie zapewnia nam nie tylko szybszy dostep ale i wyszukuwanie (wspomniane b-drzewa)
z grafika jest juz gorzej bo nie da sie tego trzymac w tabelach przechowywanych w pamieci (a moze jest jakis sposob? ) - programista z ktorym wspolpracuje napisal ostatnio prosty serverek ktorego jedynym zadaniem jest trzymanie grafiki - i tak caly html leci z apache'a, a grafa przez inny port
takie rozwiazanie wydaje mi sie najszybsze, choc napewno nie najprostrze - a moze ktos ma inny/lepszy pomysl na przechowywanie tego typu danych?

Jaką pamięć masz na myśli? Mówisz o shared memory czy o własnym serwerze, który trzyma w pamięci dane, udostępniane na żądanie? Na takie rozwiązanie mało kto może sobie pozwolić.

Konkretnie to jeżeli sprzedajesz dany produkt z instalką MySQL. Jeżeli mówisz klientowi - musi sobie pan sam zainstalowac serwer MySQL, wtedy nie ma problemu.

Z MySQLem jest tak, ze tak na prawde jest bardzo wydajny ale mam wrazenie ,ze czesto ludzie nie potrafia albo go odpowiednio skofigurowac albo dobrze zoptymalizowac tabel (szczegolnie odpowiednie indeksy ale tez dlugosc pol [mozna stosowac char zamiast varchar] stosowanie likeow z % z przodu [zabojcze ale tez da sie to zrobic] itp). Niejednokrotnie spotkalem sie z w ogole nieoptymalizowana baza gdzie zapytania wykonywaly sie kilka (sic!) a nawet nascie sekund. To jest niedopuszczalne! Dzialo sie to na bazie z 20 tys rekordow a pracowalem rowniez na bazach z milionami rekordow - tam juz trzeba ostro optymalizowac - ale jak praktyka pokazuje - się da...

Co do licencji na MySQLa to owszem trzeba go kupic ale tylko jesli dolacza sie jego zrodla do programu ktory sprzedajemy. Co raczej nie dotyczy ludzikow uzywajacych php.

Fakt jest natomiast taki, ze w MySQLu ciagle brakuje wsparcia dla UTFa (przynajmniej w wersji produkcyjnej) nad czym bardzo ubolewam - natomiast wydajnosciowo wypada niezle - czasami tylko trzeba troche poglowkowac, czesto okazuje sie, ze niektore obliczenia moze wykonac sam php o wiele szybciej.

Jesli ktos bedzie zainteresowany moge podac przyklady.

Z doświadczenia polecam stosowanie squid-a w roli reverse proxy i ogranicznie logowania z apache,mysql,squida prawie do zera - zapis logów dowala trochę maszynie

A i owszem, znaczna część koderów PHPa bazy danych okjarzy tylko z SQL'em i nawet nie wie, że to tylko narzędzie, a cała zabawa polega na projektowaniu samej struktury bazy, na procesie normalizacji etc.

Z drugiej jednak strony, czasem nie można pozwolić sobie na 3 formę normalną, bo kończy się to robiciem tabeli na kilka i albo zapytaniami złożonymi albo kilkoma następującymi po sobie zapytaniami, w celu wyciągniecia konkretnej porcji danych... Na wszystko jest odp. miejsce i czas

Ja używam plikuw *.php jako bazy i mam to co z txt tylko szypszy otczyt.
Do odczytu includuje plik z bazom o mniej więcej takim schemacie:
[php:1:23a0b21ab0]<?php
$zmienna=array();
$zmienna[0]="cos";
$zmienna[1]="costam";
?>[/php:1:23a0b21ab0]
A do zapisu to otwieram plik fopen()'em

Mimo wszystko na plikach nie mas zdo dyspozycji SQL'a
Napisanie nawawet najprostrzego skryptu operującego na bazie jest dużo wygodniejsze niż napisanie takiegoż samego skryptu pracującego na plikach. No i pozostaje pytanie, czy porwałbyś się pisać serwis średniego rodzaju, który składa się np. z 10-15 sekcja, zawartość każdej z nich generowana dynamicznie i każdą z sekcji można zarządzać z poziomu WWW etc. ? Dla mnie to by było samobójstwo, gdyby któs chciał żebym mu napisał cały serwis na plikach to bym chyba umarł ze śmiechu...

Witam!!
Ja na serverze nie mam dostępu do bazy danych, ale nie przeszkodziło mi to, w napisaniu servisu opartego o pliki. Jest rozbudowany panel administracyjny, 4 działy i wszystko się dynamicznie wyświetla, sortuje, wyszukuje. To w gruncie rzeczy nie jest takie trudne ;P

Tak wlasnie sobie to czytam i pomyslalem że cała dyskusja nie ma większego sensu - jest próbą podwarzenia czegoś na czym pracuje cały świat i miliardów dolarów które zarobił np. oracle Baza danych będzie zawsze bazą danych i NIE MOŻNA porównywać tego z przetrzymywaniem danych w plikach. Dobra baza danych to nie tylko SQL, to funkcje, triggery, transakcje, środowiska w stylu Oracle Forms itp itd.... Wiem że to kosztuje - ale jeśli jest ktoś kto jest gotów za to zapłacić to znaczy że ma to sens.

Powtorze za poprzednikiem, że nie ma sensu prowadzic tej dyskusji bowiem BD to nic innego jak pliki tylko wzbogacone o pewna funkcjonalnosc, ktorej nie sposob przecenic. Mozna sie bawic w pliki jezeli nie mamy dostepu do serwera bazy ale to tak samo jak z uzywaniem recznej pily jak sie nie ma gumowki. Jak chcesz przyciac listewke to brzeszczot moze okazac sie szybszy od pily elektrycznej, ktorej samo uruchomienie i przygotowanie do pracy zajmuje troche czasu, ale sprobuj przy pomocy brzeszczota zrobic zestaw mebli kuchennych.

Co do przechowywania grafik, plikow dzwiekowych, czy filmow w BD to ten pomysl nie jest wcale nowy. W koncu pocos wymyslono obiektowe bazy danych.

Natomiast mam prosbe do dooshek

Jestem zainteresowany, ktore obliczenia lepiej powierzyc BD, a ktore php

Pisalem ostatnio database_layer z automatyczną obsługą cachowania...
Narazie działa 3 razy wolniej:P niz sam mysql ale jak popracuje nad zamianą serialize() w pętlach na cos wydajniejszego to sie zacznę zastanawiac czy nie zacząc tego uzywac... Pozatym jestem zdania ze przy naprawde prostych skryptach nie warto uzywac baz danych np. Licznik

Hmmm, zawsze sie uczylem zeby wszystko co jest mozliwe do wykonania przez baze powierzyc wlasnie jej co wydawalo mi sie logiczne bo. np. kod w c dziala szybcej, baza sama wiec jak skladuje dane i jak najlepiej cos obliczyc nie popbierajac zbednych rekordow jakie byc moze do php trzeba by zwrocic, poza tym optymalizacja - baza danych to takie cos gdzie nie zajmujesz sie jak cos uzyskach tylko powierzasz to bazie danych a setki (tysiace) proramistow tej bazy mysli nad tym jak to zoptymalizowac, dostosowac i zwrocici iednemu userowi to co sobie wymarzyl

W bazie po prostu piszesz zapytanie, a baza zwraca wynik... na plikach trudniej jest zrobić coś takiego w dwóch liniach, i to do tego tak przejrzysto.

To prawda. Wiedza (wraz z zastosowaniem), czym sie rozni zklastrowane drzewo B+ od indeksu mieszajacego, moze czasem zwiekszyc wydajnosc zapytan o kilka rzedow wielkosci, ale co na to poradzic, kiedy w zwyklym manualu normalnie o takich rzeczach nie pisza.
Pytanie jeszcze, czy i jak syst. BD pozwoli te wiedze wykorzystac.

Natomiast nikt nie wymienil tu jeszcze jednej waznej rzeczy dla ktorej stosuje sie bazy danych: niezawodnosci. Jesli przechowujemy jakies dane w pliku, to mozemy je latwo popsuc/zgubic itd. Jesli przechowujemy je w BD to tez, ale dobre syst. baz danych (Oracle, DB/2, MSSQL, no i ujdzie jeszcze PostgreSQL) daja zwykle porzadny zestaw narzedzi umozliwiajacych uzyskanie bezpieczenstwa danych nawet w przypadku wylaczenia pradu w czasie wykonywania zapytania typu UPDATE. Mysle, ze nawet w przypadku malego sklepu internetowego moze to byc istotne. Nikt chyba nie chcialby, zeby mu oferta kilku tysiecy produktow "poszla z dymem".

Cacheowanie grafiki w pamieci: to jest to co tygryski lubia najbardziej. Nalezaloby to dodac do "wishlisty" php.

mysql -> dane
pliki cache -> buforowanie

To mój pierwszy post na Forum php Pro. Oby wyszedł dobrze

Ponieważ w mojej pracy dyplomowej mam do czynienia z dużą ilością cache-owalnych danych różnego rodzaju (wygenerowane strony, pliki XML, starsze statystyki) postanowiłem przeprowadzić test porównawczy dla różnych rodzajów danych.

Test składa się z 3 plików, 1 jest tworzony podczas pracy. Więcej szczegółów w źródłach.

Wyniki pracy na moim komputerze (Celeron 800, 394MB RAM, Win XP Prof, php 5.0.2):

Include z kodem php: 5.17731785774
Plik z 'serializowana' tablica: 3.72141003609
Tabela MySQL z 'serializowana' tablica: 4.31501793861
Pamięć współdzielona: 0.0416531562805

Edit:
Link do zipa z plikami testu: http://shaxbee.net/benchmark.zip - tym razem Dziala

Plik benchmark.php

[PHP] pobierz, plaintext 
<?
 
/*
 
 Simple Data Sources Access Benchmark
 Author: Zbyszek \"ShaXbee\" Mandziejewicz
 E-mail: shax at shaxbee dot net
 
 Sharemem benchmark requires enabled module php_shmop.dll (Win) and dosen't run on
 Windows 9x/Me
 
 Before running MySQL Benchmark change _SQL_HOST, _SQL_USER, _SQL_PASS,
 _SQL_DB and execute bench.sql
 
 Results on my machine (Celeron 800, 394MB RAM, Win XP Prof, php 5.0.2):
 
	php Included File: 5.17731785774
	Serialized file: 3.72141003609
	MySQL table: 4.31501793861
	Shared Memory: 0.0416531562805
 
*/
 
 define(&#092;"_BENCH_INCLUDE\", true); // benchmark include files
 define(&#092;"_BENCH_SERIALFILE\", true); // benchmark files with serialized data
 define(&#092;"_BENCH_SHAREMEM\", false); // benchmark shared memory
 define(&#092;"_BENCH_MYSQL\", false); // benchmark MySQL
 
 define(&#092;"_SQL_HOST\", \"localhost\");
 define(&#092;"_SQL_USER\", \"root\");
 define(&#092;"_SQL_PASS\", \"\");
 define(&#092;"_SQL_DB\", \"test\");
 
 if(!file_exists(&#092;"testinclude.php\")) die(\"Cannot find data source\");
 
// timer class found on forum.php.pl - thx pingu
 class timer{
 
	var $time;
 
	function start(){ $this->time = microtime(true); }
	function stop()
	{
		return (microtime( true ) - $this->time);
	}
 
 };
 
 $time  = new timer();
 
// Included file benchmark
 if(_BENCH_INCLUDE){
 
	 $time->start();
	 for($i=0; $i<5000; $i++) include(&#092;"testinclude.php\");
	 echo &#092;"<b>php Included File:</b> \" . $time->stop() . \"<br>n\";
	 
 };
 
// Serialized data benchmark
 if(_BENCH_SERIALFILE){
 
// Check that serialized data file exists, if not create it
	 if(!file_exists(&#092;"testfile.dat\")){
 
		include(&#092;"testinclude.php\");
		file_put_contents(&#092;"testfile.dat\", serialize($config));
 
	};
 
// Benchmark
	$time->start();
	 for($i=0; $i<5000; $i++){ unserialize(file_get_contents(&#092;"testfile.dat\")); };
	 echo &#092;"<b>Serialized file:</b> \" . $time->stop() . \"<br>n\";
	 
 };
 
// MySQL Benchmark
 if(_BENCH_MYSQL){
 
	mysql_connect(_SQL_HOST, _SQL_USER, _SQL_PASS);
	 mysql_select_db(_SQL_DB);
	 
	 $time->start();
	 for($i=0; $i<5000; $i++){ mysql_result(mysql_query(&#092;"SELECT cache FROM cache WHERE id=1\"), 0); };
	 echo &#092;"<b>MySQL table:</b> \" . $time->stop() . \"<br>n\";
	 
 };
 
// Shared memory benchmark
 if(_BENCH_SHAREMEM){
 
// Check that shared memory block exists, if not create it
	if(!($shnd = @shmop_open(1, &#092;"a\", 0, 0))){
 
		$str = serialize($config);
		$size = sizeof($str);
 
		if(!($shnd = shmop_open(1, &#092;"c\", 0777, 16 + $size))) die(\"Cannot use shmop func.\");
 
		shmop_write($shnd, $size, 0);
		shmop_write($shnd, $str, 16);
 
	};
 
	shmop_close($shnd);
 
	 $time->start();
	 $shnd = shmop_open(1, &#092;"a\", 0, 0);
	 for($i=0; $i<5000; $i++){ $size = (integer) shmop_read($shnd, 0, 16); shmop_read($shnd, 16, $size); };
	 echo &#092;"<b>Shared Memory:</b> \" . $time->stop() . \"<br>n\";
 
	 shmop_delete($shnd);
	 
 };
 
?>
[PHP] pobierz, plaintext 

Plik testinclude.php

[PHP] pobierz, plaintext 
<?
 
$config = Array(
 
	&#092;"debug\" => true,
	&#092;"cache\" => false,
 
	&#092;"panels\" => Array(
 
		&#092;"menu\" => Array(
 
			&#092;"use_router\" => false,
			&#092;"use_stack\" => false,
			&#092;"def_action\" => \"menu/display\"
 
		),
 
		&#092;"main\" => Array(
 
			&#092;"use_router\" => true,
			&#092;"use_stack\" => true,
			&#092;"def_path\" => \"List\"
 
		)
 
	)
 
);
 
?>
[PHP] pobierz, plaintext 

Plik bench.sql

[SQL] pobierz, plaintext 
CREATE TABLE `cache` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `cache` tinytext NOT NULL,
  PRIMARY KEY  (`id`)
) TYPE=MyISAM AUTO_INCREMENT=2 ;
 
INSERT 
INTO `cache` VALUES (1, 'a:3:{s:5:"debug";b:1;s:5:"cache";b:0;s:6:"panels";a:2:{s:4:"menu";a:3:{s:10:"use_router";b:0;s:9:"use_stack";b:0;s:10:"def_action";s:12:"menu/display";}s:4:"main";a:3:{s:10:"use_router";b:1;s:9:"use_stack";b:1;s:8:"def_path";s:4:"List";}}}');
[SQL] pobierz, plaintext 

Czekam na opinie i komentarze

a propo

Pomijając prostą kwestię istnienia lub nie istnienia plików , dochodzimy do prostego wniosku: (de)serializacja jest szybsza niż czysty kod php. I to jest dla mnie ważne. Sam to kiedyś zauważyłem i przerobiłem swój framework. Czytasz XMLa, przerabiasz na obiekt, serializujesz i dalej jest to już szybsze niż napisanie tego samego w php.

I tu tkwi problem. Uzywam PHP5 i SimpleXML. Niestety po dokonaniu serializacji obiektu z danymi, zapisaniu na dysku i ponownym odtworzeniu wszystko sie sypie. Powod? Brak jawnej definicji obiektow uzytych w SimpleXML. Mozna to jakos obejsc?

Edit:
No i jeszcze jedna sprawa - zacząłem tworzyć klasę umożliwiającą przetrzymywanie 'wirtualnych' plików w shared memory Pytanie tylko czy przy odczytywaniu max. 10 'zserializowanych' plikow warto tego uzywac... Zastanawiam sie takze nad napisaniem wlasnego cache handlera w smarty - kazdy output (tak nazywam to co wypluwa z siebie akcja) mialby swoj licznik odwolan i np. 20% najczesciej wywolywanych i przekraczajacych okreslona wartosc stron byloby przechowywanych w shared memory.

Co do SimpleXML: to jest znany bug php. Workaround: nie serializować SimpleXML. Wydaje mi się, że kiedyś podawałem na tym forum linki do szczegółowego opisu.

Co do shm: a czemu nie użyć po prostu tmpfs? Zaleta: niezależny od rozszerzeń php i od kodu serwisu w ogóle.

@hawk czym jest tmpfs i daj jakis link

System plików siedzący w pamięci. Link: http://www.google.pl. Wiem tylko że takie coś istnieje. Zresztą to na pewno nie jedyny system plików w pamięci - jest jeszcze chociażby głupi ramdisk.

Linux automatycznie cache'uje pliki w pamieci. Jak jest dostatecznie duzo RAMu, to wszystkie uzywane pliki w koncu wyladuja w pamieci i prawdopodobnie bedzie to szybsze niz jakis wlasny mechanizm napisany w php. Dwa odczyty tego samego pliku pojda duzo szybciej niz dwukrotny czas pojedynczego odczytu. Systemy baz danych tez maja swoj cache - tylko trzeba go dobrze ustawic (nie moze byc za maly, ale tez i nie moze byc za duzy - bo niepotrzebnie bedzie zabieral miejsce, ktore system moglby wykorzystac rozsadniej).

Pamiec wspoldzielona jest chyba kiepskim pomyslem - co jak siadzie prad? Chyba ze tylko do trzymania plikow tymczasowych. Ale nieprzenosne i tez nie tak szybkie jak "normalna" pamiec procesu. I znowu dochodzimy do tego samego - przydalby sie porzadny serwer aplikacyjny dla php.

MySQL i pewnie inne bazy ma typ tabeli ktora przetrzymuje w pamieci RAM nie znam szczegolow ale napewno zwieksza to wydajnac operacji i mamy wielodostep zapewniony przez SZBD

IMHO - dyskusja lekko pozbawiona sensu - trzebaby określi o jakiej wielkośći serwisie rozmawiamy - ja ostatnio obcuje z cache - czyli pliki i MySQl na spółke i jak narazie jes to najlepsze rozwiązanie - męczę się troche z przepisaniem layera aby współpracował w jakis sensowny sposób - ale jak dla mnie to jest właśnie przyszlość.

Inne moje doświadczenie - buduje system, ktory wszystko cachuje - chhoć jak pisałem, nie wiedziałem, że robie własne to. Owszem serwere musi torche mieć miejsca - ale działa calkeim fajnie - enginek generuje cache, w XML-ku mamy opisik co jest w tym cache i podrzucamy userowi
input -> engine -> output - gdzie engine nie ma nic do gadania co jest wyświetlane. I widze, że takie rozwiązanie ma przyszłośc - tzn. cache

PS. Zmieńcie ankietę.

@squid chodzi ci pewnie o HEAP, jest jeden problem - nie mogą posiadać następujących typów kolumn TEXT, BLOB i auto_ increment no i trzeba jeszcze określać parametr max_rows

co do optymalizacji najlepiej sprawdzać zapytania za pomocą explain + buforowanie

Trochę odgrzeje jeśli można

Co jest lepsze czysty parsing plikow .ini- czy tez cachowanie ich jako np. zserializowana tablica ? Ma ktoś jakieś doświadczenie ?

Hwao gdzieś benchmark zrobił, poszukaj