Forgot your password?
New user?
Document Actions
2.
Scalability Requirements (by Lupi)
Up one level
Scalability Requirements by Roberto Lupi.
Usage Scenario
Partecs plans to offer its basic product as a service. Organizations will be free to sign up for the basic service and will pay for additional services or to host the software on their own servers.
• we expect a high number of signups to try out our software.
• Some of these organizations may find our software unsuitable to their needs and abandon their accounts.
• Among those that continue to use our software, we expect users to divide into these classes:
• Active, high value users that use Partecs’ software as a key part of their work, they will probably sign up for additional services. These are high load, high return users and we must give them the best possible service.
• Low load, low value users that find Partecs’ software suitable for them, but do not consider it central to their work. Most probably these organizations won’t invest much in value-added services on our platform, but it’s important to keep them happy for marketing purposes. It is important to give them a good service.
• High load, low value users that find Partecs’ software useful but do not currently invest in value added services. These organizations have the potential to drain resources from other more profitable users, we must avoid it and try to steer them to become higher value users. It is important to minimize their load on the servers, while still giving them a passable service.
Requirements
Creation of new organizations should be fully automated
We cannot support a high number of signups unless the marginal cost to add a new organization is zero. It should be a fully automated process, initiated by the user:
1. The user signs up thru a web form on our site.
2. The software chooses a suitable server to host it.
3. The server creates the required environment to host the user’s organization.
Inactive accounts should not affect server performance
If many organization sign up for our service but decide not to use their account and abandon it, our software’s performance should not be affected.
An unused account must:
• Have no impact on CPU load.
• Have no impact on memory load.
Storage space is cheap, so it is fine to use it to store the unused account data for some time. An automated process should however be created to track account usage, so unused account can be removed after some time.[1]
Migration of organizations between servers should be easy
We want to partition users by their class.
• High load, High value users will have their own servers.
• Low load, High value users will be separated from other users so they always get a good service and are kept happy.
• Low value users will be put together. A mixture of high load and low load users will be put on each server in order to balance the load among our server farm.
We need an easy procedure to migrate an entire organization from a server or instance to another one. This procedure will be used to move users between our servers as they change their value for us and as we add new server to support the load over time.
Ideally, we want to use Zope built-in import/export tools to handle the migration:
1. export the whole organization from the Zope management interface (ZMI) to a file.
2. move the file to the new Zope instance, potentially on another server.
3. import the new organization thru the ZMI.
4. update any system-wide configuration file[2] to point to the new location.
The system should scale horizontally with servers
We will be adding more servers over time. It is important that the performance of our server farm scales linearly as we add more boxes.