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?(IMG:http://forum.php.pl/style_emoticons/default/questionmark.gif)

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?(IMG:http://forum.php.pl/style_emoticons/default/questionmark.gif) (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

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

[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 (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) , 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 (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)