5 svar · 690 visningar · startad av intesa
Vill köra ett batchjobb på en application server, men jag vet inte vilket sätt som är 'best practice' att göra det på.
Jobbet består av runt 3000 deljobb.
Tänkte ha en MDB som 'controller' och en Timer som triggar den.
Ett alternativ är att MDBn slickar 3000 JMS meddelanden med alla småjobben och låter en pool med MDBs processa jobben.
Alternativ två är att skapa runt 10 session beans som processar runt 300 jobb var.
Nu har det väl (antar jag) lite med hur allt ser ut runtomkring, men en pool med MDB:er känns mer Rätt-och-Bra om du frågar mig. Ett jobb = en händelse är Rätt eftersom det frikopplar utförandet av enskilda småjobb från den stora batchkörningen, och Bra eftersom du eventuellt kan tänkas råka ut för att du vill köra ett småjobb fristående från batchkörningen någon gång.
Sen blir det iofs en del overhead av att pumpa 3000 meddelanden genom JMS, så du kanske kan få lite bättre prestanda genom att köra tvåan, men det är inget jag skulle rekommendera om du inte upplever att ettan är besvärande långsamt. (Inte ens då är det säkert att tvåan blir snabbare - oftast vinner man i längden på att ha en ren arkitektur.)
red. Fast om man gör alt. 2, varför inte använda MDB:er där också?
Härligt att jag inte var helt ute o cykla med alternativ 1 :)
Du menar alltså att med alternativ två så skulle min controller kunna skicka 10 stycken JMS-meddelanden med 300 jobb var i till en MDB-pool? Det låter intressant. Ska helt klart göra ett testprogram som fungerar på det sättet också.
Tanken med alternativ 2 var annars att 10 session beans skulle processa ett jobb var i taget. När en session bean sedan är klar med ett jobb skulle den hämta ett nytt jobb från controller MDBn.
Jag vet iofs inte om det ens är möjligt att från en session bean hämta data från en MDB. Idéen var att MDBn skulle skicka med sig själv till alla session beans den skapade så session beansen skulle kunna komma åt metoderna på MDBn, men den strukturen känns inte så optimal :r
Fördelen med att inte dela upp jobben i grupper om 300 är att om jobben tar olika lång tid så kommer endå alla 10 beans få jobba lika länge, vilket jag antar är bra eftersom programmet ska köra på ett flerprocessorssystem.
Som novis innom J2EE känns det ganska svårt att veta exakt när man ska anväda de olika teknikerna, så det är toppen att det finns folk som vill dela med sig av sin kunskap, tack spango!
intesa skrev:
Fördelen med att inte dela upp jobben i grupper om 300 är att om jobben tar olika lång tid så kommer endå alla 10 beans få jobba lika länge, vilket jag antar är bra eftersom programmet ska köra på ett flerprocessorssystem.
Japp, det var så jag resonerade. Skulle du sedan skala upp systemet så att det skulle bli snabbare om du hade 20 trådar som arbetade parallellt, är allt du behöver göra att öka på storleken på MDB-poolen.
intesa skrev:
Som novis innom J2EE känns det ganska svårt att veta exakt när man ska anväda de olika teknikerna, så det är toppen att det finns folk som vill dela med sig av sin kunskap, tack spango!
Lyssna inte för noga på vad jag säger, bara ;) Jag har aldrig behövt koda EJB för brödfödan, så jag kan vara ute på tunt vatten och cykla.
Om man tycker att JMS går lite slött så rekommenderar jag att antingen titta på http://www.spread.org/ eller något av DDS-ramverken (se www.omg.org).
Vi kör DDS från RTI.com och det är en faktor 50 snabbare än JMS.
Men annars tycker jag du är inne på rätt spår.
Har testat lite nu och det flyter på rätt okej med 3000 JMS-meddelanden, så det får bli den strukturen på applikationen.
Spread ser riktigt intressant ut! Ska göra ett test med det på måndag.
Har en liten annan fråga angående prestanda också. Testade att varje MDB som tog emot ett JMS-meddelande skulle lägga till en rad i en databas. Använde mig av en EntityManager som jag körde .persist(Entity) på. Entityn är riktigt simpel med endast en Long för id och en int.
När jag skickade 10 JMS-meddelanden gick detta på några hundradelars sekund. När jag ökade antalet meddelanden till 1000 tog det över en minut.
Brytpunkten när det börjar gå mycket långsammare verkar ligga på 32 meddelanden, så jag antar det är någon inställning som är inställd på 32 samtida anslutningar till databasen eller liknande.
Är det så att EntityManagers inte bör användas i applikationer som fokuserar på prestanda?
Edit: Kan tillägga att jag kör Container Manager Persistence (CMP) och att jag nu fått bekräftat att det är 32 samtidiga anslutningar till databasen.
