[ome-users] tech queries

[Ilya Goldberg]

On Jun 10, 2005, at 7:00 AM, Chris Allan wrote:

> On Fri, Jun 10, 2005 at 11:21:41AM +0100, Alastair Kerr wrote:
>> Dear all,
>
> Hi Alastair.

Hey Kids

>>
>> "Can OME utilise 64 bit dual processor systems - is this worth it"
>> [Alastair: If perl does, OME should - it this correct? I imagine there
>> would be not much speed boost but I can't see why it would be
>> detrimental]
>
> Yes, and in fact in order to work with images larger than ~800MB at
> present you need a 64-bit machine. This 64-bit requirement for such
> images will disappear in 2.4.2.


OME uses swarms of many processes to do its stuff, so every CPU will 
end up being used - even with a single user.  With many users, the more 
CPUs the merrier.  64-bit systems (Opterons) are used routinely here at 
NIH and Dundee (64-bit OS and libraries).  They "don't suck".

>
>> 2. OMEIS + OME Can be in separate partitions. Do not know enough to
>> figure out how to spread between partitions or to add a partition 
>> later
>> ]
>>

OMEIS can be run on an entirely separate system (or systems).  The OME 
back-end and OME clients accesses OMEIS using HTTP - even when they are 
on the same system.  You can also put the Postgres server itself on a 
separate system (or systems).  So you can put OMEIS on a system that 
has some kind of more direct connection to your SAN than NFS.  OMEIS 
runs a binary CGI behind Apache - it does not need perl or mod_perl.  
Then you can put OME itself on a separate box that talks to your OMEIS 
over a network (faster is better obviously).

>
> /OME/OMEIS can be symlinked anywhere you like. Repository files can be
> moved anywhere you like as long as you symlink them as well. Example:
>
> mv /OME/OMEIS /really_big_fs
> ln -s /really_big_fs/OMEIS /OME/OMEIS
>
> --and--
>
> mv /OME/OMEIS/Dir-001 /really_big_fs2
> ln -s /really_big_fs2/Dir-001 /OME/OMEIS/Dir-001
>
> Obvously this does require maintenance and a brief understanding of how
> much data is in which folders.

These are all good ways to manage OMEIS storage.  It dynamically builds 
a "balanced" directory tree, so you can move its top-level directories 
to different drives/partitions/etc.

-Ilya


>
>>
>>
>> "We have a cosign/kerberos based authentication system which can be 
>> used
>> for general ssh logins and web authentication - can OME utilise this,
>> particularly for the java side (possibly with tomcat?)"
>> [Alastair: I think this could be an issue  but I do not fully 
>> understand
>> the problem]
>
> OME, at present, has no support for extended authentication systems. I
> also don't see us intergrating with or implementing Cosign single 
> sign-on
> authentication in our software in the near future.
>
>>
>> "As the server can analyse data what RAM or swap space requirements 
>> does
>> it have, especially if it works on movies"
>> [Alastair: I assume that the analysis using shoola/web is performed
>> server side and not client side - therefore I think: as much as
>> possible...]
>
> More is done on the client side with the Shoola Java client but *all* 
> is
> done on the server side with the web interface. So yes, "as much as
> possible" certainly fits the bill quite accurately. 2GB would certainly
> be adequate but it really does depend on your usage 4 or 8GB would not
> be unreasonable.
>
>>
>> "is all OME functionality usable in the situation where all storage 
>> for
>> the program is available as a single NFS mounted volume, and where 
>> only
>> a single uid/gid  (eg OMEuser) is used on that storage"
>> [Alastair: not sure]
>
> As long as you maintain the configured UID and GID, yes. OME makes no
> use of filesystem ACLs.
>
> A note, your performance milage with mmap(2) on an NFS mounted volume
> may vary. OMEIS uses mmap(2) for almost all its I/O routines and you
> will have to evaluate the performance penalty of having the OMEIS
> repository on NFS. I would not suggest you architect your system this
> way if you want to achieve reliability and performance. Without a more
> accurate picture of your network topology and the equipment involved I
> can't really comment more on this.
>
>>
>>
>> thanks in advance for your input
>
> You're welcome.
>
>> - Alastair
>
> Ciao.
>
> -Chris
> _______________________________________________
> ome-users mailing list
> ome-users at lists.openmicroscopy.org.uk
> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-users
>