Bladewatch.com

Was having a conversation about grid with Bill (that’s what we’ll call him), one of the grid guys for a bank, and we were discussing two things, the state of grid, and also what it was supposed to be.

I’ve discussed this before so we wont go over it too much, but still feel grid is in essence middleware, as did my colleague, the challenge is in the support.  Say my derivatives calculation fails, as grid support I log on check the grid logs and see what’s going on, but I might also want to log on to the engine, check the event logs, check the engine logs, may check versions etc, in that respect there is a set level of access I need to the infrastructure, and at the same time, knowledge of the application.  Having a team sit somewhere in the middle can be a tricky excerise.

Now back to what grid is supposed to be. So they have got an application which submits lots of small tasks very quickly one after the other to the grid.  The problem they have is the performance is fantastic on a small scale, but when it’s scaled up, the performance dies.

The development team state that there is obviously a fault with the grid middleware, because it can’t run an inventory pf the engines and allocate jobs fast enough. As an issue, it’s set to continue, until either the grid vendor or the application team decide how its fixed.

It raised an issue though, I always thought grid was for those batch type jobs which would take hours to run, that could be split amongst a larger number of smaller engines to process.  Using grid to process many small tasks one after the other sounds like a very inefficient way of processing..

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.