Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: [inny]Czasy wykonywania - różne Frameworki.
Forum PHP.pl > Forum > PHP > Frameworki
iksigrek
Proszę o podanie informacji na temat czasu wykonywania całego skryptu na frameworkach jakich używacie (Czas - Nazwa frame'a (ew. parametry). Złożoność skryptu przy danym odświeżeniu (ogólnie)).

Np. 0.300 ms - CI (localhost, procesor, ram). Połączenie z bazą, wykonanie prostego selecta, przefiltrowanie danych, wyświetlenie X wpisów o długości do 3Kb. itp...

Robię FW właśnie i jestem ciekaw, czy jestem do przodu, czy gra jest nie warta świeczki.
U mnie na razie wygląda to tak:

0,095 ms - Autorski FW (localhost, Core 2 Duo T5850, 3 GB RAM, Windoza). Od pierwszej linii - Dołączenie uznanych przeze mnie za wymagane elementów FW, sprawdzenie danych logowania poprzez połączenie do bazy i proste zapytanie, wyświetlenie prostego fragmentu strony ok 1 KB tekstu dołączonego z pliku - to na DIV.
wookieb
Chyba żaden framework nie będzie szybszy i lepszy od autorskiego, dostosowanego do serwisu.
Zend_Framework jest chyba mistrzem w marnotrawieniu pamięci. Poza tym weź pod uwagę możliwości twojego frame'a w porównaniu do innych. A to jest bardzo ważne. Wydaje mi się, że jednym z szybszych frameworkó będzie symfony ale głowy nie dam.
Crozin
Ktoś musiałby Ci dać kompletny kod jaki wykonał + całą konfigurację FW. Poza tym i tak nie byłoby to wiele warte bo co Ci z tego, że dany kod wykonuje się tyle i tyle na takiej i takiej maszynie skoro raczej nikt Ci nie poda aktualnego obciążenia tej maszyny i dziesiątek innych zmiennych.

Chcesz mieć porównanie? Odpal dwa skrypty u siebie na komputerze, zadbaj o to by warunki testu były jak najbardziej stałe. Test wykonaj naście razy. Poza tym, nawet jakby Ci wyszło, że takie same zadania w dwóch różnych FW wykonują się w czasie np. 0.2 sek, a w drugim w 0.3 sek to co z tego? Szybkość działania jest ważnym kryterium "dobroci", ale nie najważniejszym w przypadku FW.
wookieb
Cytat(Crozin @ 2.09.2009, 14:43:45 ) *
Szybkość działania jest ważnym kryterium "dobroci", ale nie najważniejszym w przypadku FW.

Dlaczego? Ja np jestem ANTY do frameworków php-owych (może jeszcze nie poznałem takiego, który by mnie zadowolił) ze względu na ogromną nadmiarowość, której np w przypadku Zenda nie zniwelujesz (niemożność edycji silnika zenda).
A uwierz to ma ogromne znaczenie.

Kiedyś przepisywałem pewien serwis na bardzo bardzo mały "framework" (dosłownie sam szkielet. Odpalenie modułu i widoku, obsługa baz danych) i przegrało to w starciu ze standardowym, prawie że czystym php-em.
Dlaczego? Jest to serwis wyników sportowych w którym jest ogromna ilość wywołań plików danych dla ajaxa i dużo się traciło na takich rzeczach jak choćby wybieranie modułu (gdybym użył PDO to byłaby jeszcze większa kicha), strach pomyśleć co by było gdybym postawił to na zendzie.
Crozin
Generalnie to dyskusji nie podlega fakt, że FW to dodatkowe obciążenie dla maszyny. Ale jest to odciążenie programisty. A rachunek za tydzień dodatkowej pracy programisty (która byłaby np. konieczna w przypadku braku FW) jest jednak mniejszy niż zakup nieco mocniejszej maszyny.
W dodatku korzystając z FW otrzymujemy kod z miejsca zrozumiały (w części lub w całości - w przypadku nie korzystania z jakiś własnych bibliotek etc) dla jakiejś grupy programistów, a nie jednego, który go stworzył. Oczywiście mowa tu o ogólnodostępnych FW.

Czas działania jest bardzo ważny i to również nie podlega dyskusji... ale po prostu pewne rzeczy są ważniejsze.
phpion
Również jestem zdania, że patrzenie tylko na czas wykonywania skryptu jest bez sensu. Idąc tym tokiem myślenia należałoby zrezygnować np. z PDO (jak napisałeś), a także odstawić programowanie obiektowe. Zgodzę się, że w ekstremalnych przypadkach można się o to pokusić ale chyba lepiej przejść na mocniejszą maszynę.

Symfony jako jeden z szybszych frameworków? Kłociłbym się smile.gif Z tego co się orientuję (bazując na opiniach innych) to Yii jest całkiem żwawy. Z własnego doświadczenia mogę powiedzieć, że Kohana jest dość szybka (dość jak na framework bo przy czystym PHP zawsze przegra). Ma kilka ciekawych funkcji, które potrafią skutecznie dodać kopa (np. cache ścieżek includowanych plików).

PS: ZF to muuuł... swego czasu (nie wiem jak teraz) Magento miało poważne problemy wydajnościowe. Swoją drogą: nowy osCommerce (pod nazwą osQuantum) ma powstać na Kohanie smile.gif osobiście czekam z niecierpliwością.
Riklaunim
Im krótszy czas wykonywania się kodu tym mniej ten kod potrafi - taka jest generalnie zasada i trzeba napisać naprawdę zły kod by aplikacja wysiadła wydajnościowo przez kod, a nie np. przez dostęp do bazy danych (zakładając sensowną konfigurację wszystkiego).
vokiel
Ja tak tylko odnośnie PDO - chyba tylko wcześniej tak było, że był dużo wolniejszy. Obecnie niewiele odstaje od np mysqli.
Wczoraj robiłem sobie testy porównania mysqli z PDO. Robię mini-projekcik i chciałem wybrać najszybszy silnik.

Środowisko testowe:
Intel Core 2 Quad Q8200 2.33GHz, 3GB RAM, Windows XP sp3, MySQL 5.0.51b,Typ tabeli: MyISAM

Testy:
1000 powtórzeń, insert, update, delete

mysqli
1000 inserts in 0.18801 seconds or 5319 inserts per second.
1000 row reads in 0.01852 seconds or 53996 row reads per second.
1000 updates in 0.01823 seconds or 54855 updates per second.

pdo
1000 inserts in 0.18514 seconds or 5401 inserts per second.
1000 row reads (fetch) in 0.02085 seconds or 47962 row reads per second.
1000 row reads (fetchAll) in 0.0011 seconds or 909091 row reads per second.
1000 updates in 0.0188 seconds or 53191 updates per second.
wookieb
Zobacz jak na forum jest tępione nie podawanie kodu. A ty Vokiel też go nie podałeś. Też mamy cię tępić? Pamiętaj, że tu chodzi NIE TYLKO o wykonywaniu zapytanie ale takze o jego przygotowanie, bindowanie zmiennych.
vokiel
@wookieb nie chciałem wrzucać kodu i robić OT jeśli nie byłoby zainteresowania, wątek co by nie powiedzieć dotyczy frameworków. Przyznaję rację: benchmark bez podawania kodu, środowiska, konfiguracji nie jest szczególnie wiarygodny.

W tym teście są proste zpaytania, zwykłe inserty bez bindowania. Chciałem porównać to samo zapytanie na własnej maszynie, aby mieć pogląd. W necie spotyka się trochę benchmarków, jednak dość różne wyniki.
Np: http://dealnews.com/developers/php-mysql.html
Select:
extension req/s
------------------------
mysqli 164
mysql 162
PDO 88
mysqli (prepared) 86
PDO (prepared) 81

Insert:
extension time
--------------------------
pdo (extended) 18.17s
mysqli (extended) 18.40s
mysql (extended) 18.46s
pdo (prepared) 25.04s
mysqli (prepared) 36.93s
mysqli 50.43s
mysql 53.09s
pdo 59.96s

Różnice są pomiędzy insert/select, przy prepared.

Aby osiągnąć konkretne, dające się porównać wyniki należałoby wykorzystać rzeczywistą sytuację - jakąś małą aplikcję w wersjach różniących się tylko silnikiem bazy. Zrobić kilka powtórzeń po X k zapytań w serii, uśrednić wyniki. Na razie mi się po prostu nie chce smile.gif no i nie mam pod ręką projektu z bardziej złożonymi zapytaniami, dającego się łatwo przepisać na inny silnik bazy.

Do testów wykorzystałem część projektu PHP MySQL Benchmark Tool (PMBT v. 0.2), i po drobnych modyfikacjach moje zapytania wyglądały tak:
  1. echo '<h1>mysqli</h1>';
  2. // INSERT Testing ***************************************************************
  3. //Timer Start
  4. $starttime = microtime();
  5. $startarray = explode(" ", $starttime);
  6. $starttime = $startarray[1] + $startarray[0];
  7. // Insert Rows
  8. $insertQuery = "INSERT INTO `$dbName`.`$tableName` (`id` ,`testcolumn`)VALUES (NULL , 'teststuff')";
  9. for ($i = 0 ; $i < $totalIters ; $i++ ){
  10. mysqli_query($linkDBTest, $insertQuery);
  11. // echo "$i Insert<br>";
  12. }
  13. // Get run time for display
  14. $endtime = microtime();
  15. $endarray = explode(" ", $endtime);
  16. $endtime = $endarray[1] + $endarray[0];
  17. $totaltime = $endtime - $starttime;
  18. $totaltime = round($totaltime,5);
  19. $IPS = round($totalIters/$totaltime);
  20. echo "$totalIters inserts in $totaltime seconds or <h2><strong><font color=\"green\">$IPS</font></strong> inserts per second.</h2>";
  21.  
  22. echo '<h1>PDO</h1>';
  23. $dns = 'mysql:dbname='.$dbName.';host=localhost';
  24. $pdo = new PDO($dns, 'root', '');
  25. // INSERT Testing ************************************************************
  26. //Timer Start
  27. $starttime = microtime();
  28. $startarray = explode(" ", $starttime);
  29. $starttime = $startarray[1] + $startarray[0];
  30. // Insert Rows
  31. $insertQuery = "INSERT INTO `$dbName`.`$tableName` (`id` ,`testcolumn`)VALUES (NULL , 'teststuff')";
  32. for ($i = 0 ; $i < $totalIters ; $i++ ){
  33. $pdo->exec($insertQuery);
  34. // echo "$i Insert<br>";
  35. }
  36. // Get run time for display
  37. $endtime = microtime();
  38. $endarray = explode(" ", $endtime);
  39. $endtime = $endarray[1] + $endarray[0];
  40. $totaltime = $endtime - $starttime;
  41. $totaltime = round($totaltime,5);
  42. $IPS = round($totalIters/$totaltime);
  43. echo "$totalIters inserts in $totaltime seconds or <h2><strong><font color=\"green\">$IPS</font></strong> inserts per second.</h2> ";
iksigrek
Pomijając już brak kodu (załóżmy, że na "czysto" prawie test wykonywany), przeraziłeś mnie przez chwilę Vokiel biggrin.gif

Do tego stopnia, że moja leniwa osoba przetestowała inserta na mysqli.. i wyszło na to, że po pierwsze - jak na razie moja własna obsługa wychodzi o ok. 0.200 ms szybciej od tej z mysqli (pewnie dlatego, że nie mam tam zbyt rozbudowanego kodu..).

Przeraziłeś mnie natomiast z tego powodu, że u mnie przy 100 zapytaniach wyszło ok 2.800 exclamation.gif Myślałem najpierw, że to kwestia procka (bo reszta właściwie jest podobna), jednak z tego co wiem XP i nie wykorzystuje quada jak powinien, więc szukałem gdzie indziej.. heeh... no i babol leżał po stronie InnoDB. Zmiana na MyISAM pomogła natychmiast. Tak, więc mimo, że się o tym wie - przy testach nie można pomijać tej ważnej składowej jaką jest mechanizm. Pytanie tylko zrodziło mi się dodatkowe - z tego co wiem, InnoDB jest szybszy przy odczycie, natomiast powolny przy dopisywaniu - dlaczego więc mimo wszystko MyISAM wypada lepiej zarówno przy zapisie jak i przy odczycie ? Myślałem, że w przypadku przewagi odczytów lepiej stosować Inno, a tu jednak nie do końca tak jest...
Riklaunim
InnoDB używasz gdy potrzebujesz transakcji - zachowania integralności danych np. przy szeregu insert/update
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.