Difference between revisions of "Power and capacity"
(Created page with '== Power and capacity == In many cases, regify is asked about the power of regify, especially on sending. You need to know, that sending a regify-message consists of two jobs: …') |
|||
| (One intermediate revision by the same user not shown) | |||
| Line 16: | Line 16: | ||
* Number of recipients per transaction | * Number of recipients per transaction | ||
| − | ** The more recipients in a single rgf file, the faster (encryption and compression happens only once) < | + | ** The more recipients in a single rgf file, the faster (encryption and compression happens only once) <sup>1</sup> |
* Networking Conditions | * Networking Conditions | ||
| − | ** How is the sending hardware connected to the regify | + | ** How is the sending hardware connected to the regify provider (local, internet) |
| − | ** How is the regify | + | ** How is the regify provider connected to internet (for clients and clearing) |
* Calling Method | * Calling Method | ||
| Line 28: | Line 28: | ||
* Provider Speed | * Provider Speed | ||
**Hardware (number of cores, memory etc.) | **Hardware (number of cores, memory etc.) | ||
| − | **Redundancy (are there multiple systems with | + | **Redundancy (are there multiple systems with load-balancing) |
| − | **Database speed ( | + | **Database speed (amount of memory and file system speed) |
| − | **Load of the system (other mass-sendings, many users on | + | **Load of the system (other mass-sendings, many users on web interface) |
| − | |||
=== 2) Sending the rgf files === | === 2) Sending the rgf files === | ||
| Line 39: | Line 38: | ||
| − | + | ||
| + | ''1) In many cases, e-mails are containing the same content. If it is ok, that users know each others e-mail addresses, a message can have up to 200 recipients. Currently, there is no BCC like option possible for usability reasons (Feb 2012).'' | ||
Latest revision as of 08:29, 22 November 2018
Power and capacity
In many cases, regify is asked about the power of regify, especially on sending.
You need to know, that sending a regify-message consists of two jobs:
- registering and creation of the rgf file
- sending the message (for example using SMTP)
1) Registering and creation of rgf files
The following list shows you the parameters affecting the speed of regify file creation:
- Attachments
- Number and Size
- Format (will it be ZIP-compressed or not)
- Number of recipients per transaction
- The more recipients in a single rgf file, the faster (encryption and compression happens only once) 1
- Networking Conditions
- How is the sending hardware connected to the regify provider (local, internet)
- How is the regify provider connected to internet (for clients and clearing)
- Calling Method
- using commandline client (slow)
- using native DLL/SO (fast)
- Provider Speed
- Hardware (number of cores, memory etc.)
- Redundancy (are there multiple systems with load-balancing)
- Database speed (amount of memory and file system speed)
- Load of the system (other mass-sendings, many users on web interface)
2) Sending the rgf files
After creation of the rgf files, they need to get sent out to the recipients. regify is not aware of your sending methods. Most customers are sending using SMTP (using a Mail Transfer Agent/MTA). Others are transmitting using (S)FTP or copy the files to some web-portal.
If you are sending using the same system(s) than for creation, please note that network transfer of sending may slow down the registration of regify-messages (and vice versa).
1) In many cases, e-mails are containing the same content. If it is ok, that users know each others e-mail addresses, a message can have up to 200 recipients. Currently, there is no BCC like option possible for usability reasons (Feb 2012).
