[ome-devel] Omero server performance issue
Luca Lianas
luca.lianas at crs4.it
Thu Aug 6 12:31:43 BST 2009
Hi Chris
13 minutes is the result for 50.000 inserts, sorry I reported only my last
test. The test with 1000 images was completed in about 36 seconds.
Luca
2009/8/6 Chris Allan <callan at blackcat.ca>
> On Thu, 2009-08-06 at 12:50 +0200, Luca Lianas wrote:
> > Hi Chris
>
> Hi Luca.
>
> >
> > thanks for your advice. As suggested by you, I modified the script and
> > created only 4 LogicalChannelI objects linked to the image's channels
> > (I looked into the xml model file and found the many-to-one
> > relationship between channel and logicalchannel), now the execution
> > time takes only 13 minutes.
>
> 1 minute and 42 seconds --> 13 minutes? (did you mean seconds? :))
>
> As OMERO's objects are graph oriented you also don't need to save the
> LogicalChannels you are re-using. So just, the following at the top of
> your try block is fine:
>
> adenine = om.model.LogicalChannelI()
> adenine.setName(omt.rstring('ADENINE'))
> citosine = om.model.LogicalChannelI()
> citosine.setName(omt.rstring('CITOSINE'))
> guanine = om.model.LogicalChannelI()
> guanine.setName(omt.rstring('GUANINE'))
> thymine = om.model.LogicalChannelI()
> thymine.setName(omt.rstring('THYMINE'))
>
> OMERO knows how to inspect the graph for duplicates, how to ensure
> references are properly represented, calculate the INSERT plan, etc.
>
> > I attach the script in order to provide an example if anybody needs
> > one.
> >
> > Luca
>
> -Chris
>
> > 2009/8/5 Chris Allan <callan at blackcat.ca>
> > Hi Luca,
> >
> > One big thing is to be very careful with enumerations:
> >
> > 26 do = om.model.DimensionOrderI()
> > 27 do.setValue(omt.rstring('XYZCT'))
> > 28 pt = om.model.PixelsTypeI()
> > 29 pt.setValue(omt.rstring('uint16'))
> >
> > This is creating brand new enumerations for every image
> > inserted, which
> > will slow any enumeration queries to a crawl and is causing
> > 3000 extra
> > INSERTs, significant graph inspection overhead, etc. You want
> > to
> > retrieve the existing enumerations through IQuery and then use
> > an
> > unloaded version of the object to help you out, for example
> > (pseudo-code):
> >
> > ...
> > dimension_orders = iquery.findAll("DimensionOrder")
> > xyzct = filter(lambda a: a.value.val == 'XYZCT')[0]
> > syzct.unload()
> > ...
> > for image in range(0, 100):
> > ...
> > p.setDimensionOrder(xyzct)
> >
> > The above applies to FormatI, DimensionOrderI and PixelsTypeI.
> > In fact,
> > you've sort of corrupted your database in a way for the
> > particular user
> > you've logged in as by adding 1000's of bogus enumerations.
> >
> > Give that a try first after deleting your bogus enums and see
> > where you
> > get to.
> >
> > -Chris
> >
> >
> > On Wed, 2009-08-05 at 16:06 +0200, Luca Lianas wrote:
> > > Sorry, i forgot the attachment...
> > >
> > >
> > > 2009/8/5 Luca Lianas <luca.lianas at crs4.it>
> > > I belong to the biomedical reserch group at CRS4, a
> > research
> > > centre in Italy; we are currently using omero in
> > several
> > > projects and we are running some performance tests
> > during
> > > these days.
> > > We noticed that the server has low performances when
> > loading a
> > > large amount of data (I tried to load the
> > meta-informations
> > > for 50.000 4-channel images).
> > > I did a smaller test loading 1000 images using a
> > python script
> > > and it took 1 minute and 42 seconds to load the data
> > (as said
> > > before, I only wrote the meta-data of the images
> > into the
> > > database, the real pixels are stored into a HDFS
> > file system).
> > > I used the compiled version of Omero downloaded from
> > the
> > > website and with default configuration. Omero runs
> > on a Linux
> > > server (Fedora core 11) with a dual opteron
> > processor (248
> > > model) and 4GB of RAM.
> > > I'm wondering what is the problem and if there are
> > some hints
> > > to improve the performances on the server. Any help
> > is
> > > appreciated.
> > >
> > > Please see the script I'm using, as per attachment
> > (maybe is
> > > the script itself my problem).
> > >
> > > Thanks for you attention
> > >
> > > Luca
> > >
> >
> > > _______________________________________________
> > > ome-devel mailing list
> > > ome-devel at lists.openmicroscopy.org.uk
> > >
> > http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmicroscopy.org.uk/pipermail/ome-devel/attachments/20090806/5e47bd17/attachment.htm
More information about the ome-devel
mailing list