large number of users in standard acl_users ?
Hi, is it possible to store a large number of users in a standard acl_users folder, provided that very few are connected at the same time ? I'd want to store around 20000 user ids there, all six characters long, plus their password. The online shopping website will have a low traffic, I don't think that more than 10 users will ever be logged in at the same time, probably even less than that, but there are 20000 possible users (max). Is there any drawback with this setup ? Should I use something like exUserFolder instead ? bye, and thanks in advance. Jerome Alet
is it possible to store a large number of users in a standard acl_users folder, provided that very few are connected at the same time ?
I'd want to store around 20000 user ids there, all six characters long, plus their password.
The online shopping website will have a low traffic, I don't think that more than 10 users will ever be logged in at the same time, probably even less than that, but there are 20000 possible users (max).
With such a low number of concurrent users, you can probably get away with it server-wise, though your users may be subject to high latency. Better would be a BTreeUserFolder. I can't prove the existence of one at the moment, and it's possible that the regular UserFolder already uses BTrees, in which case, go nuts. Otherwise, it shouldn't be hard at all to make such a thing. Can anyone provide some good info on this? --jcc
I do not think you want 20,000 objects in an acl_users folder. You should take a look at SimpleUserFolder (allows users to be maintained in external mediums, like a relational database. You might be able to modify some of the methods, eg getUserNames and getUserDetail.. For example you could create a table of "unused userIds and passwords". If the UserID is not found in the "normal" table that otherwise populates acl_users, you can "take a look" at the secondary source. If the unused UserID is there and the password is valid you could add it to acl_users then. David ----- Original Message ----- From: "J Cameron Cooper" <jccooper@jcameroncooper.com> To: "Zope user list" <zope@zope.org> Sent: Wednesday, July 16, 2003 4:59 PM Subject: Re: [Zope] large number of users in standard acl_users ?
is it possible to store a large number of users in a standard acl_users folder, provided that very few are connected at the same time ?
I'd want to store around 20000 user ids there, all six characters long, plus their password.
The online shopping website will have a low traffic, I don't think that more than 10 users will ever be logged in at the same time, probably even less than that, but there are 20000 possible users (max).
With such a low number of concurrent users, you can probably get away with it server-wise, though your users may be subject to high latency.
Better would be a BTreeUserFolder. I can't prove the existence of one at the moment, and it's possible that the regular UserFolder already uses BTrees, in which case, go nuts. Otherwise, it shouldn't be hard at all to make such a thing.
Can anyone provide some good info on this?
--jcc
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
J Cameron Cooper wrote:
With such a low number of concurrent users, you can probably get away with it server-wise, though your users may be subject to high latency.
Why high latency?
Better would be a BTreeUserFolder. I can't prove the existence of one at the moment, and it's possible that the regular UserFolder already uses BTrees, in which case, go nuts.
It uses a PersistantMapping, and I don't know how good they are at large numbers of objects... I'll just ask on zodb-dev@zope.org...
Otherwise, it shouldn't be hard at all to make such a thing.
As someone else suggested, SimpleUserFolder would be the way to go. You could store your users as documents (DTML of ZPT) in a BTrreFolder without having to write any filesystem-based code... If you don't mind writing FS-based code, just use SUF's subclassing technique to write a userfolder that stores its user objects in a BTree of some sort... cheers, Chris
With such a low number of concurrent users, you can probably get away with it server-wise, though your users may be subject to high latency.
Why high latency?
Well, I was just guessing that the user authentication lookups probably aren't a constant-time operation and scale at least linearly with the number of users, but I don't actually know this. It could be that it falls on the other side of the space/time tradeoff and will instead go nuts on memory.
Better would be a BTreeUserFolder. I can't prove the existence of one at the moment, and it's possible that the regular UserFolder already uses BTrees, in which case, go nuts.
As someone else suggested, SimpleUserFolder would be the way to go. You could store your users as documents (DTML of ZPT) in a BTrreFolder without having to write any filesystem-based code...
If you don't mind writing FS-based code, just use SUF's subclassing technique to write a userfolder that stores its user objects in a BTree of some sort...
That should be easy enough, but I'm really surprised that there's no BTreeUserFolder, and slightly less surprised that the default userfolder isn't so backed. But then, maybe there are tradeoffs of which I'm not aware. --jcc
On Thu, Jul 17, 2003 at 01:24:26PM -0500, J Cameron Cooper wrote:
With such a low number of concurrent users, you can probably get away with it server-wise, though your users may be subject to high latency.
Why high latency?
Well, I was just guessing that the user authentication lookups probably aren't a constant-time operation and scale at least linearly with the number of users, but I don't actually know this. It could be that it falls on the other side of the space/time tradeoff and will instead go nuts on memory.
I think it would be the latter. PersistentMapping is a subclass of UserDict, which is a small wrapper around the dict type. Accessing a dictionary item is O(1) according to the python Nutshell book. "nuts on memory" might not be a big deal either. User objects are pretty small. However, anything that loops over the items in the dictionary would be O(N), so any page that does this might become noticeable with REALLY large N. Some subjective fiddling at the python prompt suggests to me that 10,000 is not large enough for foo.items() to be noticeably slow unless you do so in a loop; but 100,000 is (it takes about a half second here.) What this means in practice is anybody's guess :-) I don't know if anything in Zope loops over the users, except of course the ZMI display code. All of which is a long way of saying that the ZMI alone might be enough to force you to use another UserFolder. You don't want to visit the Contents tab of a folder with 10,000 items in it! :-) -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's THE SLIPPERY JET! (random hero from isometric.spaceninja.com)
J Cameron Cooper wrote:
Well, I was just guessing that the user authentication lookups probably aren't a constant-time operation and scale at least linearly with the number of users, but I don't actually know this. It could be that it falls on the other side of the space/time tradeoff and will instead go nuts on memory.
How would any other user storage medium make this differ? cheers, Chris
participants (5)
-
Chris Withers -
David Hassalevris -
J Cameron Cooper -
Jerome Alet -
Paul Winkler