Some information on the very common question of how many users OGo can support ...

Note: The whole text is just a starting point. OGo is just too complex to put all answers in a single place. Feel free to ask specific questions in the users@opengroupware.org mailing lists.
Important: If you really want to make a useful estimate, set up an evaluation system and perform proper testing and Profiling! SOPE collects a lot of statistics which can be used to detect bottlenecks.

Every now and then people ask the (annoying ;-) question:
Q: "What I would like to know is does anyone have a definitive answer to how many people OGo can support before it starts to suffer from general slow downs?".

A: The even more annoying answer is: There can't be a definitive answer to the question as it depends on a huge number of variables. I know that this is disappointing as it is a common request, but its nevertheless a matter of fact that there is no (can't be a) useful answer on that.

In general you should consider that OGo is a functionally rich server application targetted at workgroups and project teams. So it isn't really intended to provide a shared internet calendar to tens of thousands of users (though it has a lot of reusable technology to build application servers like that!).
On the other side at least the SKYRiX 5 snsd provides all the facilities to distribute sessions on a number of cheap compute nodes to achieve a pretty good scalability.

Differences due to client application?

Q: Also, does the upper limit change based on how OGo is being accessed (e.g. desktop client like Outlook versus a web browser)?

A: Yes, this is one of the variables ;-) Eg ZideStore is stateless and consumes much less RAM than the WebUI. It also can be load balanced using regular HTTP techniques like Pound.
Further, ZideStore needs to deal with much simpler clients and as a result can perform much better caching.
Completely useless estimate: I would guess that you can host about 3-5 times more users with ZideStore than with OGo WebUI.

Any numbers published by SKYRIX?

Q: I know that the supported version from SKYRIX (SKYRiX 5) can do a few things that OGo can't, but there isn't anything on the OGo site that specifically states how many users OGo can support on a particular hardware configuration.

A: Yes, because this can't be simplified in a single number but requires analysis of the actual requirements. Remember that OGo is a number of different (but integrated) applications which have very different performance characteristics. Then it depends what plugins you install (eg ACLs slow the system down, extended attributes slow the system down, etc). Etc.

BEWARE: THE COMPLETELY USELESS ESTIMATE

Q: OGo is a great project and works very, very well. I just want to be sure that when I tell potential clients or anyone else about OGo, I have my facts straight.

A: OK, a VERY simplified estimate. As mentioned above, this is a completely useless one:

Database Backend

First, in general there is a limitation due to the database backend. OGo has a pretty complex database schema as it focuses on functionality rather than on raw speed. A regular setup allows you to hosts hundreds of users. When you get near the thousand or exceed it, you will need to watch the database as it will contains tables with a very large number of rows. A fast database (like a fat Oracle server) will do, but will require planning and tuning.

Mail Backend

Well, you don't need to care about Cyrus, it can host tens of thousands of mailboxes even on slow machines (for todays standards).

Instances

Then you need to understand the concept of "instances". An OGo instance is one Unix process which contains WebUI sessions. A limiting factor on this front is that OGo instances are (by intention) not multithreaded, that is, you loose possible concurrency, especially - but not only - on multi CPU servers.

The good thing is that those instances do not block on the network HTTP IO, all this is handled in Apache. The bad thing is that if people do some long running action on the server (like opening a large IMAP4 attachment), the other users need to wait.

So the general useless estimate is that about 20-100 sessions can be hosted by a single instance. Marketing says "up to 100" per instance.
You also need to consider RAM constraints. Again the absolutely useless estimate is that a WebUI session (which includes a lot of caches) requires between 2MB and 20MB of RAM. It heavily depends on the application in practice.

Load Balancing

So, as mentioned above, if you use OGo a lot or have hundreds of users or more, you definitely need multiple instances to properly take advantage of the systems multitasking facilities.

The usual approach is to buy SKYRiX 5 for such setups, which includes the so called "snsd" (Session Name Service Daemon). It connects to both, the instances and to Apache, keeps track of which session is running on which instance and is able to load balance sessions on the instances. This is pretty easy, but currently implies SKYRiX 5.

On the other side you are not required to use snsd. You can load balance "manually" in various ways. Eg one approach is to start some instances (on different ports) and just redirect incoming connections based on the client IP.

Useless estimate: Given that you should be able to host some hundreds of users on a fast machine. For example SKYRIX AG has a customer which has ~850 (web) users on a single machine.

Clustering

This is basically the same like load balancing. Get a fast database server, put some cheap application server nodes in front, load balance to the instances running on the hosts.

If you use snsd, this is trivial, you can just plug in additional nodes and get immediate advantage of the speed increase (the node instances will announce themselve at snsd and it will forward sessions to it). Also in case of a hardware fault snsd will detect that and do not forward any sessions to that server until it is up again.

Like before, you can also do that with regular Apache techniques, but it is much more work and even more difficult if you want to have fault tolerance.

Useless estimate: Given that OGo itself in theory scales to thousands of users - the real limit here is the database backend. But this technique is usually used if you want to get fault tolerance or you have some hundreds of users which actually do a lot of OGo work or have some hundred users which do a LOT of OGo work.

ZideStore

As mentioned, a lot of that is completely different for ZideStore, which only deals with very simple functionality (but still has to map that to the pretty complex OGo database schema) ...

Conclusion

BEWARE: As mentioned those are just completely useless marketing estimates. In practice you really need proper testing and planning. At least if you use snsd and are not going over 1000 users, you are on a pretty safe side, as you can scale pretty well using really cheap application server nodes.

General Hints

Some hints not bound to actual numbers ...

Extended Attributes

Extended contact attributes are stored in one table (company_value) and are joined with the actual company record in fetches. This provides maximum flexibility at the price of ... performance.

In "usual" work- or projectgroups you won't notice, but if you have tens of thousands of contacts and a lot of extended attributes, the company_value table will grow. Simple calculation: 1000 users, each having 50 contacts, each having 20 extended attributes - makes: 1.000.000 records in the company_value table (and 50.000 in the company table).
And OGo will do the required joins between those

So, 1.000.000 records is still in the range of capability of a modern RDBMS like Oracle, but it is already an interesting number even for that. Now if you have 10.000 users instead of 1.000, numbers start to explode.

Summary: extended attributes hurt performance if you have a LOT of contacts.

ACLs

Similiar to extended attributes. If you place an ACL on each contact, you'll end up with n-ACL-records per contact. Multiply by number of contacts per users and "estimate" the capability of your RDBMS.

Summary: ACLs hurt performance. Do not use them unless you really, really need them. The "private" flag is stored directly in the company record and is therefore very fast and usually sufficient.

FileSystem Projects vs DB Projects

DB projects provide a lot of functionality like versioning, ACLs or extended attributes. You should be aware that this has a price ...

Summary: use FileSystem projects if you do not need the extended functionality. They are WAY faster.