[seek-dev] {Filename?} Digir Ecogrid server performance.

Kevin Ruland kruland at ku.edu
Mon Nov 14 09:51:29 PST 2005


Warning: This message has had one or more attachments removed
Warning: (new-8.bmp, old-21.bmp, old-8.bmp, new-41.bmp).
Warning: Please read the "NCEAS-Attachment-Warning.txt" attachment(s) for more information.

Hi all.

If you didn't see the big commit earlier, you missed out.

The Digir Ecogrid server now dynamically discovers all the available
Digir providers at run time.  It uses the GBIF UDDI repository to
accomplish this.  At any given time, there are between 350-400+
available digir providers which are queried for each query.

The old server code would construct a single query with all the
requested providers and pass to a single Digir Portal Servlet to perform
the query and aggregation.  This particular process was a little bit
cumbersome because the Portal Servlet would simply concatenate all the
responses together and return to the Ecogrid server.  The Ecogrid server
would then have to parse this very large xml document and reconstruct
into an Ecogrid resultset.  What I've discovered is this mechanism could
not handle even a reasonable load because the Ecogrid service would end
up timing out before the portal would begin its response.  The graphs
old-8.bmp and old-21.bmp demonstrate the problem.  In old-21.bmp, the
responses for clients 17-20 timed out.

In order to alleviate this problem, I integrated the functionality of
the portal servlet into the Digir Ecogrid query code.  The service now
issues an individual request to each provider and consolidates the
results directly.  This improves performance greatly, particularly for
light loads.  However, the thread pool implementation is rather limited
and the results are during heavy (-ier) load, all responses are
delayed.  Basically what is happening is every individual thread is
treated with the same priority - so provider requests which are part of
the 15th request get mingled with those from the 1st request and end up
delaying the completion of the 1st request.  I intend on rectifying this
by having the requests have more of a first-in-first-out policy for
thread scheduling.

The diagrams new-8.bmp and new-41.bmp show this problem.  When there are
8 requests, essentially none of them are significantly delayed. 
However, when there are 41 clients, even the first client's response is
slowed dramatically.

A note about the load simulation.  The load is simulated by requesting
each of 4 different queries repeatedly.  The query for client # 10 is
the same a that for client # 6.  The clients are started at 5 second
intervals.  The blue bar on the bottom represents the delay time before
the client has been started.  The red bar (in series 2) is the amount of
time between the start of the client and the query request itself
(factory creation time).  In general this time is insignificant.  Even
though many of the requests in the new-41.bmp appear to take 600
seconds,   the responses were complete.

A couple of notes about hardware:

The servers used in this comparison are not equivalent.  The "old"
server configuration is significantly more powerful than that used to
test the "new" code.  The old ecogrid server and portal servlet are on a
Dell system with 2 Xenon 2.8Ghz processors w/ 2G Ram.  The new ecogrid
server code is running on a Dell desktop with 1 P4 3.0Ghz processor w/
1G Ram.  Moving the new server code to the old hardware will result in
some significant speed improvements.

Kevin
-------------- next part --------------
This is a message from the MailScanner E-Mail Virus Protection Service
----------------------------------------------------------------------
The original e-mail attachment "old-8.bmp"
is on the list of unacceptable attachments for this site and has been
replaced by this warning message.

If you wish to receive a copy of the original attachment, please
e-mail helpdesk and include the whole of this message
in your request. Alternatively, you can call them, with
the contents of this message to hand when you call.

At Mon Nov 14 10:25:00 2005 the virus scanner said:
   MailScanner: Possible buffer overflow in Windows (old-8.bmp)

Note to Help Desk: Look on Mercury in /var/spool/MailScanner/quarantine/20051114 (message 2C16A3582C7.C0CBE).
-- 
Postmaster
NCEAS
www.nceas.uscb.edu

MailScanner thanks transtec Computers for their support
-------------- next part --------------
This is a message from the MailScanner E-Mail Virus Protection Service
----------------------------------------------------------------------
The original e-mail attachment "old-21.bmp"
is on the list of unacceptable attachments for this site and has been
replaced by this warning message.

If you wish to receive a copy of the original attachment, please
e-mail helpdesk and include the whole of this message
in your request. Alternatively, you can call them, with
the contents of this message to hand when you call.

At Mon Nov 14 10:25:00 2005 the virus scanner said:
   MailScanner: Possible buffer overflow in Windows (old-21.bmp)

Note to Help Desk: Look on Mercury in /var/spool/MailScanner/quarantine/20051114 (message 2C16A3582C7.C0CBE).
-- 
Postmaster
NCEAS
www.nceas.uscb.edu

MailScanner thanks transtec Computers for their support
-------------- next part --------------
This is a message from the MailScanner E-Mail Virus Protection Service
----------------------------------------------------------------------
The original e-mail attachment "new-41.bmp"
is on the list of unacceptable attachments for this site and has been
replaced by this warning message.

If you wish to receive a copy of the original attachment, please
e-mail helpdesk and include the whole of this message
in your request. Alternatively, you can call them, with
the contents of this message to hand when you call.

At Mon Nov 14 10:25:00 2005 the virus scanner said:
   MailScanner: Possible buffer overflow in Windows (new-41.bmp)

Note to Help Desk: Look on Mercury in /var/spool/MailScanner/quarantine/20051114 (message 2C16A3582C7.C0CBE).
-- 
Postmaster
NCEAS
www.nceas.uscb.edu

MailScanner thanks transtec Computers for their support
-------------- next part --------------
This is a message from the MailScanner E-Mail Virus Protection Service
----------------------------------------------------------------------
The original e-mail attachment "new-8.bmp"
is on the list of unacceptable attachments for this site and has been
replaced by this warning message.

If you wish to receive a copy of the original attachment, please
e-mail helpdesk and include the whole of this message
in your request. Alternatively, you can call them, with
the contents of this message to hand when you call.

At Mon Nov 14 10:25:00 2005 the virus scanner said:
   MailScanner: Possible buffer overflow in Windows (new-8.bmp)

Note to Help Desk: Look on Mercury in /var/spool/MailScanner/quarantine/20051114 (message 2C16A3582C7.C0CBE).
-- 
Postmaster
NCEAS
www.nceas.uscb.edu

MailScanner thanks transtec Computers for their support


More information about the Seek-dev mailing list