[prev in list] [next in list] [prev in thread] [next in thread] 

List:       slide-dev
Subject:    RE: Performance
From:       "Ray Sprinkle" <rsprinkle () vhainc ! com>
Date:       2005-11-07 14:53:35
Message-ID: AA5064D86D1C2445A0D3462DD5FD5A7606318C () sbsdc ! vhainc ! local
[Download RAW message or body]


I am using the RDBMS store and it has the same problem with respect to
role and group membership.   The membership list is stored as a single
property instead of a collection.  This causes scalability problems for
large groups/roles and limits the databases ability to do efficient
membership searches.  For RDBMS,  Slide only works efficiently when all
of this information can be pulled into memory.  
 
________________________________

From: Michael Oliver [mailto:ollie@alariussystems.com] 
Sent: Friday, November 04, 2005 6:07 PM
To: Slide Dev Mailing List
Subject: Performance



Hi gents,

 

I just have a quick question on design or architecture related to Slide
2.1 and performance.

 

I have been using and developing on slide now since before version 2.0
and have even written some tutorials for slide on IBM DeveloperWorks.  I
say this only so a responder won't waste time on trivialities.

 

Now let me start by saying there are many ways to skin a cat and I am
not trying to be critical of something I hold so highly.  However there
are a few things that bother me about the design and lead to what I
believe are bottlenecks in scaling slide to more users and more kinds of
implementations built on slide.

 

One is the practice of storing a list of child nodes in the metadata of
a collection node...seems like a waste to me.  For example on the
filesystem and therefore with the TxFile* stores, the list of children
doesn't need to be stored in the metadata (as far as I can tell) because
it is readily available in the file object for the folder.  Opening,
reading, inserting, and writing the collection's .def.xml (or the
equivalent in the db) and the potential for deadlocks, contention and
conflict with two or more users adding children at the same time to the
same collection seems intuitively obvious.  So why do it?

 

Similarly, the 'group-member-set' for roles while not a factor in
performance, seems awkward and cumbersome compared to a users collection
and children.  I mentioned this before and got "they aren't the same"
and while that is certainly true logically the members of a role are not
different than the members of a collection of users.  Adding a user by
simply doing a mkcol under /slide/users/ makes perfect sense, but so
would simply doing a mkcol under /slide/roles/ for a username to be
added to a role.  Simple and consistent.

 

If this august group's response is, Ok why don't you volunteer, I would
say, ok I will.  I will contribute a patch for the
TxFileDescriptorsStore/XMLResourceDescriptor to fix the handling of
collections metadata which I believe is the biggest problem and if that
is received well I will contribute more.

 

 <http://www.alariussystems.com> 

Highly Cohesive and Loosely Coupled <http://mikeoliveraz.blogspot.com> 

 

Mike Oliver
CTO 

Alarius Systems LLC
6800 E. Lake Mead Blvd
Apt 1096
Las Vegas, NV 89156
<http://maps.yahoo.com/py/maps.py?Pyt=Tmap&addr=6800+E.+Lake+Mead+Blvd&c
sz=Las+Vegas%2C+NV+89156&country=us>  

ollie@alariussystems.com <mailto:ollie@alariussystems.com> 
http://www.alariussystems.com/ <http://www.alariussystems.com/>  

tel: 
fax: 
mobile: 

(702)953-8949 
(702)974-0341
(518)378-6154 

 

Add me to your address book...
<https://www.plaxo.com/add_me?u=25769982367&v0=355403&k0=305933374> 

Want a signature like this? <http://www.plaxo.com/signature> 

 



[prev in list] [next in list] [prev in thread] [next in thread]