You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This will require some more brainstorming and discussion so I'm assigning a version that will enable us to revisit it in the future. The general idea is that users could shard their database and split the load for a single instance of MC onto as many servers as they'd like.
1.With MC 3.0, each channel now has their own message tables that are basically standalone from the rest of the database. Most instances are IO bound, so with enough sharding users could more fully utilize the CPUs for a single server.
Users are ALWAYS running out of disk space. This would allow longer message history and fewer pruning sessions.
This will require some more brainstorming and discussion so I'm assigning a version that will enable us to revisit it in the future. The general idea is that users could shard their database and split the load for a single instance of MC onto as many servers as they'd like.
1.With MC 3.0, each channel now has their own message tables that are basically standalone from the rest of the database. Most instances are IO bound, so with enough sharding users could more fully utilize the CPUs for a single server.
Imported Issue. Original Details:
Jira Issue Key: MIRTH-3464
Reporter: wayneh
Created: 2014-09-24T13:19:16.000-0700
The text was updated successfully, but these errors were encountered: