Propel, relacja "n do m", niska wydajność Opcje

[joebezucha]

Witam,

Pracuje wlaśnie nad projektem z wykorzystaniem frameworka Symfony i pojawił sie pierwszy problem. Problemem jest wydajność Propel-a.

Fragment opisu schematu bazy danych:

[SQL] pobierz, plaintext 
CREATE TABLE `answer`
(
	`id` INTEGER  NOT NULL AUTO_INCREMENT,
	`question_id` INTEGER  NOT NULL,
	`no` INTEGER  NOT NULL,
	`body` TEXT  NOT NULL,
	`scale` INTEGER,
	`grade` INTEGER,
	PRIMARY KEY (`id`),
	INDEX `FI_answer_1` (`question_id`),
	CONSTRAINT `FK_answer_1`
		FOREIGN KEY (`question_id`)
		REFERENCES `question` (`id`)
		ON DELETE CASCADE
)Type=InnoDB;
 
CREATE TABLE `test`
(
	`id` INTEGER  NOT NULL AUTO_INCREMENT,
	`status` INTEGER  NOT NULL,
	`test_type` INTEGER  NOT NULL,
	`lname` VARCHAR(40)  NOT NULL,
	`fname` VARCHAR(24)  NOT NULL,
	`birthdate` DATE  NOT NULL,
	`sex` CHAR  NOT NULL,
	`school_type` INTEGER  NOT NULL,
	`user_id` INTEGER  NOT NULL,
	`password` VARCHAR(20),
	`created_at` DATETIME,
	`timestart` DATETIME,
	`timefinish` DATETIME,
	`ip` VARCHAR(15),
	PRIMARY KEY (`id`),
	INDEX `FI_test_1` (`user_id`),
	CONSTRAINT `FK_test_1`
		FOREIGN KEY (`user_id`)
		REFERENCES `user` (`id`)
		ON DELETE CASCADE
)Type=InnoDB;
 
CREATE TABLE `test_answer`
(
	`test_id` INTEGER  NOT NULL,
	`answer_id` INTEGER  NOT NULL,
	PRIMARY KEY (`test_id`,`answer_id`),
	INDEX `FI_ta_1` (`answer_id`),
	CONSTRAINT `FK_ta_1`
		FOREIGN KEY (`answer_id`)
		REFERENCES `answer` (`id`)
		ON DELETE CASCADE,
	CONSTRAINT `FK_ta_2`
		FOREIGN KEY (`test_id`)
		REFERENCES `test` (`id`)
		ON DELETE CASCADE
)Type=InnoDB;
[SQL] pobierz, plaintext 

Jak widać są tu 3 tabele test, asnwer, i tabela test_answer która odpowida za relacje "n do m"

W skrypcie PHP mam:

[PHP] pobierz, plaintext 
<?php
$this->test = TestPeer::retrieveByPk($this->getRequestParameter('id')); // 1*
$c = new Criteria();
$c->setLimit(10);
$test_answers = $this->test->getTestAnswersJoinAnswer($c);   // 2*
foreach ($test_answers as $test_answer){
  $answer = $test_answer->getAnswer();
}
?>
[PHP] pobierz, plaintext 

No i w tym momencie pojawił się problem z wydajością PROPELa. Czas tworzenia kolekcji $test_answers rośnie po exponencie;) przy limicie ustawionym na 200 skrypt zostaje zakończony w wyniku przekroczenia limitu czasu(60sekund). No a wszystkich odpowiedzi mam do pobrania 214.

W narzędziu WebDebug (część frameworka Symfony) widze, że wykonywane są tylko dwa zapytania do bazy:
1* pobranie testu
2* pobranie danych z tabel test_answer złączonej z answer

Czyli nie ma problemu z zapętlaniem zapytań do bazy danych.
Zresztą robie wszytsko zgodnie z instrukcją propel.phpdb.org/trac/wiki/Users/Documentation/1.2/ManyToManyRelationships

Czy Propel jest aż tak mało wydajny?

Potrzebuję pełnych danych odpowiedzi na pytania testowe do przeliczenia wyników końcowych. Mogę oczywiście obejść Propela, skorzystac bezposrednio z Creola i operować na tablicach zamiast na obiektach. No ale zastanawia mnie ta bardzo niska wydajność.

Jakieś pomysły?

Ten post edytował joebezucha 2.07.2007, 15:19:31

[pawel_k]

żeby mi działało zrobiłem takiego sql'a (bo masz odwołania do tabel których nie ma)

[SQL] pobierz, plaintext 
CREATE TABLE `answer`
(
`id` INTEGER NOT NULL AUTO_INCREMENT,
`no` INTEGER NOT NULL,
`body` TEXT NOT NULL,
`scale` INTEGER,
`grade` INTEGER,
PRIMARY KEY (`id`)
)Type=InnoDB;
 
 
CREATE TABLE `test`
(
`id` INTEGER NOT NULL AUTO_INCREMENT,
`status` INTEGER NOT NULL,
PRIMARY KEY (`id`)
)Type=InnoDB;
 
 
CREATE TABLE `test_answer`
(
`test_id` INTEGER NOT NULL,
`answer_id` INTEGER NOT NULL,
PRIMARY KEY (`test_id`,`answer_id`),
INDEX `FI_ta_1` (`answer_id`),
CONSTRAINT `FK_ta_1`
FOREIGN KEY (`answer_id`)
REFERENCES `answer` (`id`)
ON DELETE CASCADE,
CONSTRAINT `FK_ta_2`
FOREIGN KEY (`test_id`)
REFERENCES `test` (`id`)
ON DELETE CASCADE
)Type=InnoDB;
[SQL] pobierz, plaintext 

do tego wstawiałem:
- 1 wiersz do tabeli "test" (bo jak robisz $this->test = TestPeer::retrieveByPk(1); to więcej mi nie trzeba)

[SQL] pobierz, plaintext 
INSERT INTO test (STATUS) VALUES (1);
[SQL] pobierz, plaintext 

- 200 wierszy do tabeli "answer"

[SQL] pobierz, plaintext 
INSERT INTO answer (body,no,scale,grade) VALUES ("hahaha1", 1, 1, 1);
...
INSERT INTO answer (body,no,scale,grade) VALUES ("hahaha1", 200, 200, 200);
[SQL] pobierz, plaintext 

- 200 wierszy do tabeli "test_answer"

[SQL] pobierz, plaintext 
INSERT INTO test_answer (test_id,answer_id) VALUES (1,1);
INSERT INTO test_answer (test_id,answer_id) VALUES (1,2);
...
INSERT INTO test_answer (test_id,answer_id) VALUES (1,200);
[SQL] pobierz, plaintext 

widok dla akcji:

[PHP] pobierz, plaintext 
<?php
var_dump(sizeof($test_answers));
var_dump(sizeof($arr));?>
[PHP] pobierz, plaintext 

i teraz dla wywołania akcji:

[PHP] pobierz, plaintext 
<?php
public function executeIndex()
	{
		$this->test = TestPeer::retrieveByPk(1); // 1*
		$c = new Criteria();
		$c->setLimit(10);
		$this->test_answers = $this->test->getTestAnswersJoinAnswer($c);   // 2*
 
		$arr = array();
		foreach ($this->test_answers as $test_answer){
			$arr[] = $test_answer->getAnswer();
		}
		$this->arr = $arr;
	}
?>
[PHP] pobierz, plaintext 

robi 2 zapytania

[SQL] pobierz, plaintext 
1. [0.90 ms] SELECT test.ID, test.STATUS FROM test WHERE test.ID=1
   2. [0.91 ms] SELECT test_answer.TEST_ID, test_answer.ANSWER_ID, answer.ID, answer.NO, answer.BODY, answer.SCALE, answer.GRADE FROM test_answer, answer WHERE test_answer.TEST_ID=1 AND test_answer.ANSWER_ID=answer.ID LIMIT 10
[SQL] pobierz, plaintext 

wyświetla

int 10
int 10

czas wykonania według webdebug: # 250 ms

jak usuniesz linie

[PHP] pobierz, plaintext 
<?php
$c->setLimit(10);
?>
[PHP] pobierz, plaintext 

to odpowiednio
robi 2 zapytania

[SQL] pobierz, plaintext 
1. [0.36 ms] SELECT test.ID, test.STATUS FROM test WHERE test.ID=1
   2. [0.45 ms] SELECT test_answer.TEST_ID, test_answer.ANSWER_ID, answer.ID, answer.NO, answer.BODY, answer.SCALE, answer.GRADE FROM test_answer, answer WHERE test_answer.TEST_ID=1 AND test_answer.ANSWER_ID=answer.ID
[SQL] pobierz, plaintext 

wyświetla

int 200
int 200

czas wykonania według webdebug: # 3030 ms

jak widać nic złego się nie dzieje...
sprzęt testowy:
- system ubiuntu 7.04
- sempron 2600+ (64bit)
- 1024 ramu
- mysql Ver 14.12 Distrib 5.0.38, for pc-linux-gnu (i486) using readline 5.2
- PHP Version 5.2.1

nie wiem czemu u Ciebie coś się złego dzieje, chyba że ja coś za bardzo uprościłem ale nie wydaje mi się

Ten post edytował pawel_k 2.07.2007, 17:58:32

[joebezucha]

Dzięki za wysiłek pawel_k

Jeszcze dziś sprawdzę czy z uproszczeniem schematu bazy to będzie hulać jak trzeba...

Bez uproszczeń sprawdzałem wydajność w zależności od setLimit(limit)

czasy są w [ms]

limit; query time; module/action time; full time;
1; 1.99; 459; 1328;
5; 1.72; 356; 1009;
10; 3.30; 529; 1196;
20; 2.20; 1000; 1756;
40; 2.32; 3839; 4487;
80; 2.70; 12414; 13167;
160; 3.90; 46567; 47259;

Jak widać do 20 jest OK ale potem lawinowo wzrasta czas procesu ORM...

Puki co zrobiłem to troche inaczej tzn robie własne złączenie tabel i pobieram bezposrednio obiekty klasy Answer.

w akcji mam:

[PHP] pobierz, plaintext 
<?php
$c = new Criteria();
$c->addJoin(AnswerPeer::ID, TestAnswerPeer::ANSWER_ID, Criteria::LEFT_JOIN);
$c->add(TestAnswerPeer::TEST_ID, $this->getId());
$this->collAnswers = AnswerPeer::doSelect($c);
?>
[PHP] pobierz, plaintext 

No i tutaj działa wszystko OK.
Wyglada na to ze problem z wydajności występuje gdy Propel pobiera obiekty TestAnswer i jednoczesnie agregowane przez nie obiekty Answer.

Moj komp:
Athlon XP 1800+
RAM 896 MB
WIN XP SP2

Dam znać jak wypadły testy z uproszczonym schematem bazy danych

Zrobilem osobny projekt ze schematem uproszczonym do tej postaci co w poscie Pawła K.

Niestety problem wydajnosci ciagle występuje.
Czasy minimalnie sie zmniejszyły pownieważ mniej danych jest pobieranych no ale wykonanie trwa i tak grubo ponad 40sekund:/

Ktoś ma jakies pomysły w czym może tkwić problem??

Paweł jakiej wersji Propela uzywasz?

Ten post edytował joebezucha 5.07.2007, 08:46:59

[pawel_k]

trochę pogadałem z joebezucha, wykonałem kod na zrzucie jego bazy i wszystko jest ok. przy pierwszym sposobie

[PHP] pobierz, plaintext 
<?php
public function executeIndex()
	{
		$this->test = TestPeer::retrieveByPk(1); // 1*
		$c = new Criteria();
		$this->test_answers = $this->test->getTestAnswersJoinAnswer($c);   // 2*
 
		$arr = array();
		foreach ($this->test_answers as $test_answer){
			$arr[] = $test_answer->getAnswer();
		}
		$this->arr = $arr;
	}
?>
[PHP] pobierz, plaintext 

czas wykonania wynosi dalej ok 3000ms, nawet nie jest to więcej niż przy uproszczeniu, czasem nawet mniej...

przy drugim sposobie

[PHP] pobierz, plaintext 
<?php
public function executeIndex2()
	{
		$c = new Criteria();
		$c->addJoin(AnswerPeer::ID, TestAnswerPeer::ANSWER_ID, Criteria::LEFT_JOIN);
		$c->add(TestAnswerPeer::TEST_ID, 1);//$this->getId());
		$this->collAnswers = AnswerPeer::doSelect($c);
	}
?>
[PHP] pobierz, plaintext 

czas wykonania to ok 250ms
czasu są podawane przez webdebuga.
dla mnie powodem może być widowsowa wersja php...

[joebezucha]

No i chyba juz wiem w czym problem.

Dotąd aplikację odpalełem pod WAMPem. Większośc z podstron generowana byla przez okolo 1sekunde (dość sporo jak na proste wyswietlenie danych obiektów)

Zainstalowałem najnowsze PHP 5.2.3, Upgrade PEAR (z problemami) No ale czas wykonania problematycznego skryptu byl ciągle bliski 1minuty.
Problem nie istnieje natomiast na platformie LAMP (instalacja na Ubuntu 7.04, PHP 5.2.1)
Większość podstron generowana jest w czasie 250-500ms a problematyczny skrypt około 3-4sekund

Także wyglada na to ze ogołnie pod Windowsem jest slabsza wydajnośc przetwarzania skryptów no a moj przypadek to juz wogóle skrajna sytuacja...

Inna sprawa to tez dziwny problem z upgradem PEAR pod windowsem. Przy upgradzie oraz przy instalacji paczek ciągle wywalał błąd braku pamięci (przekroczenie 8MB). Jednak zmiany w php.ini (memory_limit) nic nie pomagały.

Pomogło dopiero dodanie w pliku pearcmd.php lini:

[PHP] pobierz, plaintext 
<?php
ini_set('memory_limit', '100M');
?>
[PHP] pobierz, plaintext 

tak 100MB , zgaduje że jest jakis problem z PEAR z jakąs podstawową operacją w stylu czytanie pliku, ktora pod windowsem stała sie potwornie pamięciożerna.

Przy upgradzie PEAR pod Ubuntu takiego problemu nie było!

Także podsumowując zraziłem sie do WAMPa

[Sh4dow]

a moze ktos z was sproboje sprawdzic to przy pomocy xdebuga i wykryc waskie gardlo ?

[domis86]

Nie wiem jak sie to robi w propelu, ale sprobujcie zrobic tak, zeby wypisalo wszystkie query_stringi jakie robi na bazie.

[pawel_k]

@domis86 - przecież wypisałem wyżej - robi 2 zapytanie...

@Sh4dow - a możesz powiedzieć jak to sprawdzić? z xdebuga korzystał właściwie tylko jako z lepszego var_dump'a

[Sedziwoj]

@Sh4dow - a możesz powiedzieć jak to sprawdzić? z xdebuga korzystał właściwie tylko jako z lepszego var_dump'a

Może to coś pomoże:
http://www.xdebug.org/docs/profiler

[splatch]

Przyczyną na 90% będzie jedna z metod hydrate, która jest zaimplementowana w sposób nie do końca optymalny. Jakiś czas temu opublikowałem notę z poprawionym generatorem, który tworzy wydajniejszy kod, z racji na zastosowanie identity map.

[pawel_k]

ehh, teraz przypominam sobie ze niecały rok temu miałem sprawdzić ale przez nawał obowiązków kompletnie wyleciało mi to z głowy za co teraz przepraszam :/ ale mam też pytanie - czy integrowałeś swoją klasę z propelem zintegrowanym z symfony?