Power and capacity

From regify WIKI
Revision as of 09:27, 19 March 2012 by Regify (talk | contribs)
Jump to navigation Jump to search

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:

  1. registering and creation of the rgf file
  2. 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 loadbalancing)
    • Database speed (using internal or external database or maybe a cluster)
    • Load of the system (other mass-sendings, many users on webinterface)


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).