Topic: e-Smith scalability

[Jim Huneycutt]

I am trying to get some idea of the scalability of e-Smith in terms of users, etc. I know there are many factors involved. Assuming no significant hardware constraints, what is the largest number of users one could reasonably expect to handle with an e-Smith server? For example, could one e-Smith server handle 300-500 users' email accounts with pop3 and webmail access while hosting say 20-30 small to medium-sized web sites?  Would 50-100 pptp connections be a problem? Has anyone setup what you would consider a large installation (say 50 or more users) on an e-Smith box? If so, what are some of the issues you had to deal with and what kind of hardware requirements were there? I realize my question is very general but I am trying to decide whether to keep pushing the e-Smith platform. So far it has been OK for small offices of less than 10 users, but I would like to have confidence that it can handle larger environments before "selling" it to clients. I am also hopeful that when the bugs are fixed in 5.6 it will be able to handle larger installations.

Any comments would be appreciated.
jim

[Nathan Fowler]

I've got about 50 users, I do about 2GB monthly in traffic.  I host about 13 small business sites, using SSL and HTTP traffic.  Of those 50 users, about 40 use it as their primary mail server.  I'm also doing pop-before-smtp services.

Load averages are about 0.03, 0.04, 0.15
Doing RAID-1 on two 5400 1.2GB drives, disk I/O is fast.
Memory is 256 MB, consumed is about 60MB.
Processor is a Celeron 333

Using PHP Accelerator (freeware ZEND) and mod_gzip to increase speed for http/php traffic.

Running a very updated version of a 4.1.2 (Apache 1.3.27, current MYSQL, all RH errata bug-fixes applied, etc).

[Kelvin]

Hi Nathan,

Out of interest, when you say about 50 users, do you mean you have 50 LAN workstations connected and using the SME server or 50 user accounts of the 13 or more domains that you are hosting (which are not LAN users) ?

Kelvin

[Nathan Fowler]

About 50+ accounts, of those 50, 49 are WAN users not in the local LAN.

About a total of 50 user accounts with 13 distinct virtual hosts, with FQDN's and separate IBAYS.  Probably about 15 groups, and about 10 "custom" pseudonyms.

[Jason Judge]

I think the main limits come from the number of groups and users that Linux itself supports, since each network user is created as a Linux user. Some of the configuration files seem to increase in size exponentially with the number of users defined, so there may be some limits there too.

Can't help you any further than that, I'm afraid, but it may give you some leads as to where else you can look.

-- Jason

[Nathaniel Brown]

We'll here's out setup!

700 accounts with about 30 users on at anyone time.

Primary domain with roaming accounts.

This is currently all on a 700MHz with 3 Hard drives and 256MB ram.

It's starting to strain a little bit now so we're going to upgrade the server ie.
RAID, 1Gig ram, etc.

But it handeled fine upto about 50 users.

I'd still recommend RAID + RAM + duel CPU + backup for any reasonable(50+) number of users.

[Tim]

I have found that the limit on groups is my biggest problem. We're hosting a number of domains. Maybe 25 or so. But, I've found the limits on groups seems to be about 25. At that point you get a message that says no more.

Does anybody know of ways around these limits on groups??

Thanks,

Tim

[Nathaniel Brown]

We've run into a limit with groups as well.

When we have over 600 users the last users are cropped. We've narrowed it down to usermod. I'll give you move info when I have it.

Also there seems to be a limit on the number of groups a user can be in. From what I understand it's about 32 by default.

Nathaniel Brown

[Nathaniel Brown]

Found out what the bug was.

usermod has a bug in it that limits a signle line to 4096 characters + the username + the group information.

This bug is in the red hat database.

The work around we used was to add another script after e-smith added user then basically clober the last line of the group file an regenrate it using the e-smith database of active users.

For e-smith to scalle better I'd recomend that they move to a single LDAP datasource instead of maintaining three - one for unix, one for LDAP and one for E-Smith.

Instead create three schema's for LDAP that overlap and put all the user information into a single LDAP datasource and use PAM. It should also simplify a number of the scripts.

Nathaniel Brown