[ZF/PHPUnit] Veel database engines draaien

[storeman]

Voor mijn applicatie ben ik bezig met Unittests. Ik heb mijn applicatie gebouwd met behulp van het Zend Framework en voor de tests gebruik ik de Zend_Test module. Dit heb ik aardig werkend, maar ik loop tegen een probleem aan wanneer ik alle tests draai. In mijn taakbeheer verschijnen dan namelijk zeer veel postgres.exe processen. Het lijkt er dus op dat de database verbinding niet volledig wordt afgebroken wanneer een test klaar is.

Ik heb al geprobeerd in de __destruct van de Zend_Db_Abstract module een disconnect aan te roepen, maar dit mag niet baten. Ik zou het vreemd vinden als ik in de tearDown() van al mijn tests hier iets voor aan zou moeten roepen.

Heeft iemand een soortgelijk probleem (gehad)? En hier een oplossing voor gevonden?

Hierbij mijn setUp() methode in de meeste testscases:

code:

    protected function setUp(){
        $this->initRequiredData();

        $this->application = new Zend_Application(
            APPLICATION_ENV,
            APPLICATION_PATH . '/configs/application.ini'
        );
        
        $this->bootstrap = array( $this, 'appBootstrap');
        
        parent::setUp();
    }

[kokx]

De objecten worden (als het goed is) niet zomaar verwijderd. De connectie blijft dus feitenlijk open staan. Wat je kunt doen, is in de tearDown dus je database object opvragen en de connectie disconnecten.

Een andere mogelijkheid is het gebruiken van een MockAdapter voor het testen, of een adapter als SQLite.

[storeman]

Het lijkt me toch logisch dat wanneer het Zend_Application object na de test wordt opgeruimd en hiermee ook de databaseconnectie. In de tearDown methode verbreek ik nu de verbinding, maar ook dit lijkt het probleem niet te verhelpen.

[Freeaqingme]

Bestaat de connectie dan nog wel degelijk, of laat postgres z'n processen gewoon nog even bestaan na 't afsluiten?

[kokx]

storeman schreef op dinsdag 05 januari 2010 @ 17:08:
Het lijkt me toch logisch dat wanneer het Zend_Application object na de test wordt opgeruimd en hiermee ook de databaseconnectie.

Dat is 'iets' lastiger dan je denkt. De database adapter word niet alleen in Zend_Application gestored, maar dat word bijvoorbeeld ook in Zend_Db_Table ingeladen. En helaas is de garbage collector van PHP niet altijd slim genoeg omdat ook goed toe te passen.

Daarnaast denk ik net als freakingme dat PostgreSQL die processen niet meteen opruimt, maar nog even laat bestaan.

[cariolive23]

kokx schreef op dinsdag 05 januari 2010 @ 23:43:
Daarnaast denk ik net als freakingme dat PostgreSQL die processen niet meteen opruimt, maar nog even laat bestaan.

Nee hoor, zodra een connectie wordt verbroken, wordt het proces direct gestopt en opgeruimd. Het heeft geen enkele zin om een proces te laten draaien waar niemand ooit nog iets mee kan doen. Dit kun je zelf ook zien op de server, zie de lopende processen, start een connectie (er komt een proces bij) en stop de connectie (proces wordt ook gestopt).

[storeman]

Ik ben er nog niet veel verder mee. Bij sommige controller-tests wordt alles wel netjes opgeruimd maar bij andere controller tests blijven de engines draaien. Hierdoor worden de tests steeds trager, er draaien nu ongeveer 50 postgres.exe's. Als de tests klaar zijn worden dit er weer een stuk of 4.

Alle controller-tests zijn gebaseerd op dezelfde abstracte controllertest met de tearDown functie om de verbinding te verbreken. Ik begin een beetje ten einde raad te raken, iemand enig idee in wat voor richting ik kan gaan zoeken/testen/prutsen? Of andere bronnen om aan te boren?

[kokx]

Nou ja, het hoort niet echt een probleem te zijn dat de unit tests 'langzaam runnen'. Je gaat door enorm veel code heen in korte tijd, dus dat is niet echt verbazingwekkend.

@cariolive23: Het word wel gestopt inderdaad, maar niet snel genoeg.

[storeman]

Heel ernstig is het probleem inderdaad niet. Ik heb net geteld en er draaien 102 postgres.exe's. Dit vind ik wel veel te veel. Daarnaast wordt het echt flink trager, een losse test (dus geen testcase), die er fris ongeveer een seconde over doet, doet er na een hele serie toch minimaal 10 seconden over. Ik vind dit wel een dermate groot verschil dat het voor mij nuttig is om hier naar te kijken.

Daarnaast kan ik er wellicht nog het een en ander van leren .

Ook wordt het aantal testcases nog minimaal verdubbeld, dus als het nu al zo traag wordt, wil ik niet weten wat er gebeurd na een verdubbeling....

[ Voor 13% gewijzigd door storeman op 07-01-2010 09:09 ]

[cariolive23]

Verbreekt Zend Framework / jouw code wel direct de connectie met de database? Zolang dat niet gebeurt, zal de database uiteraard een connectie open hebben staan. 102 processen is niet overdreven veel, klinkt als het maximale aantal connecties (100 stuks) + de basisprocessen.

Heb je PostgreSQL wel geconfigureerd? Zo niet, dan kan de vertraging worden veroorzaakt doordat de database te weinig RAM krijgt toegewezen en de server van de stress in de swap schiet. En swappen is langzaam, erg langzaam. Zie de PostgreSQL-wiki hoe je een gezonde basisconfiguratie kunt opstellen, dat werkt al 100x beter dan de meest minimale opzet (standaard configuratie).

Ps. "maximale aantal connecties" mag je lezen als "maximale aantal connecties in de standaard configuratie". PostgreSQL kan veel meer aan.

[ Voor 9% gewijzigd door cariolive23 op 07-01-2010 11:06 ]

[storeman]

Ik ga eens kijken naar de configuratie van mijn postgresql, wellicht dat daar winst te behalen valt.

Ik heb nog een en ander zitten debuggen en het blijkt dat de connectie niet wordt afgebroken als ik dit niet in de tearDown() functie doe. Dan worden alle connecties pas verbroken nadat alle tests klaar zijn, wat ik vreemd vind. Ik ga in de tearDown ook maar de bootstrap en application opruimen, misschien scheelt dat ook nog.

edit:

Het is me nog niet helemaal duidelijk hoe ZF/PHPUnit/ZF_Test de connecties nu beheerd en misschien komt het door mijn manier van werken, maar nadat ik een verbinding heb opgeroepen en gebruikt verbreek ik de verbinding in de tests weer. Hierdoor worden de verbindingen netjes opgeruimd en blijven er maar een handvol postgres processen draaien .

[ Voor 29% gewijzigd door storeman op 07-01-2010 11:35 ]