Grails performance problem, or weak design?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Grails performance problem, or weak design?

grampajohn
Administrator
I now know where the missing 4-7 seconds is going in each 5-second timeslot (see issue #222). It takes that long for the four gencos to enter shouts for each of the 23 open timeslots. This is just 92 shouts during each 5-second timeslot, without any broker shouts.

At this point, I'm not sure what to do. Even an order of magnitude speedup would probably not be enough. It takes about a minute (on my dual-processor laptop) to get the customer model set up.

We clearly cannot release the server in this state. It simply will not work, unless we extend the timeslots to something like 15 seconds. I don't think that makes sense unless there is hope of significant speedup in auctionService.processShout(). If this is possible, then perhaps a release with long timeslots would not be overly objectionable.

I invite your thoughts.

John
Reply | Threaded
Open this post in threaded view
|

Re: Grails performance problem, or weak design?

ddauer
Logging to stdout might be slowing thing down, so we should have logfile-logging only.

Another way to speed up things is to use "export JAVA_OPTS='-Xmx1024M -XX:MaxPermSize=1024m'". Grails runs noticeably faster with more memory. 

Hope that helps.

Cheers,
David

On Mon, May 16, 2011 at 4:44 AM, grampajohn [via Power TAC Developers] <[hidden email]> wrote:
I now know where the missing 4-7 seconds is going in each 5-second timeslot (see issue #222). It takes that long for the four gencos to enter shouts for each of the 23 open timeslots. This is just 92 shouts during each 5-second timeslot, without any broker shouts.

At this point, I'm not sure what to do. Even an order of magnitude speedup would probably not be enough. It takes about a minute (on my dual-processor laptop) to get the customer model set up.

We clearly cannot release the server in this state. It simply will not work, unless we extend the timeslots to something like 15 seconds. I don't think that makes sense unless there is hope of significant speedup in auctionService.processShout(). If this is possible, then perhaps a release with long timeslots would not be overly objectionable.

I invite your thoughts.

John



If you reply to this email, your message will be added to the discussion below:
http://power-tac-developers.975333.n3.nabble.com/Grails-performance-problem-or-weak-design-tp2946231p2946231.html
To start a new topic under Power TAC Developers, email [hidden email]
To unsubscribe from Power TAC Developers, click here.

Reply | Threaded
Open this post in threaded view
|

Re: Grails performance problem, or weak design?

Daniel Schnurr
In reply to this post by grampajohn
In relation to the AuctionService design:

processShout does only 2 things: saving incoming shouts to the database (i) and update the orderbook (ii).

I cannot see any point how to improve (i) (besides David's propositions). You can check if (ii) is causing performance problems by commenting out the method call "updateOrderbook(incomingShout)" in line 118 of the AuctionService.

If this is really causing problems we have to reconsider the implementation of (ii), although I don't see much overhead in the current design at the moment.
Reply | Threaded
Open this post in threaded view
|

Re: Grails performance problem, or weak design?

Daniel Schnurr
Another thought: is there any chance that the audit plugin has an effect on the performance?
Reply | Threaded
Open this post in threaded view
|

Re: Grails performance problem, or weak design?

grampajohn
Administrator
If I cut the number of open timeslots from 23 to 17 (18-hour trading horizon) I get a server per-timeslot processing time very close to 5 seconds on my laptop, without any brokers running. Even on this small machine (1Gb) I would be much less nervous with something like 2 seconds. We are running only one customer model, after all.
Reply | Threaded
Open this post in threaded view
|

Re: Grails performance problem, or weak design?

chris.flath
I just ran the server with 23(24?) open timeslots and my simple trading default broker creating bids.

I had an average timeslot duration (measured from log statement phase activation to phase activation)  of 5.055s with a minimum duration of 4.132s and a maximum of 6.761s. For this I had setup grails with 4gigs of memory but the task only uses only 1.7. There is still an awful large amount of console output so I feel we have a lot of optimization potential still at hand.
Reply | Threaded
Open this post in threaded view
|

Re: Grails performance problem, or weak design?

chris.flath
Moreover, market positions for already timeslots keep being updated as noted in my mail concerning the simple trading default broker. This effect also leads to more and more market position being updated and the performance degrading significantly - after 100 time slots I was at about 8-10seconds for each timeslot.

I will look into this issue with Daniel and David tomorrow latest.
Reply | Threaded
Open this post in threaded view
|

Re: Grails performance problem, or weak design?

grampajohn
Administrator
In reply to this post by chris.flath
chris.flath wrote
I just ran the server with 23(24?) open timeslots and my simple trading default broker creating bids.

I had an average timeslot duration (measured from log statement phase activation to phase activation)  of 5.055s with a minimum duration of 4.132s and a maximum of 6.761s. For this I had setup grails with 4gigs of memory but the task only uses only 1.7. There is still an awful large amount of console output so I feel we have a lot of optimization potential still at hand.
There should be no printing directly to standard output - it should all be log.xxx output. Log output does not appear to be significant if you redirect to a file. I've experimented a bit with this and cannot see much difference. On the other hand, log inspection is very important to confirm that the server is running as expected.

John