3CX forum Topic "What are maximum contacts supported in 3CX". We did a series of experiments and here are the findings.
Purpose:
We want to know 3CX performance with a huge number of contacts (1 million contracts or phonebook entries), specifically when an incoming call comes in, how long does it take for PhoneSet (Yealink T42) to pick up right customer name?
Short Summary
- There is a limit for importing 3CX contacts: approximately 300,000 phonebook entries.
- Mapping Caller ID to real name has high performance regardless of phonebook size.
- 3CX's memory usage increases drastically together with the number of contacts.
- 3CX Web interface of listing Contacts tries to download all contacts at once, it's none-responsive with a huge number.
- 3CX Web interface Searching through a huge number of contacts have inaccurate results.
- 3CX pagination with contacts does not have 'jump to page', and its difficult to browse contacts in phonebooks.
- With a huge number of contacts in 3CX, never try to 'Delete ALL' , it freezes 3CX server.
- Searching through a huge phonebook size is fast, but not very accurate.
- Delete huge number of contacts has to be done step by step too, and deleting time decreases with phone-book-size.
We tested time from 'initiating a call' to Caller ID/Name display.
| Number of Contacts in 3CX | Cost of Action | Time measured |
| 0 | 1. Pull Data from CRM 2. Search PhoneBook | 2.01 Seconds |
| 1 (with matching contacts) | Search through PhoneBook | 1.99 Seconds |
| 100 (with matching contacts) | Search through PhoneBook | 2.03 Seconds |
| 1000 (with matching contacts) | Search through PhoneBook | 2.05 Seconds |
| 297,999 (with matching contacts) | search through phoneBook | 2.11 Seconds |
| 297,999 (without matching contacts) | 1. Pull Data from CRM 2. Search PhoneBook | 2.03 Seconds |
How do we measure time? We videotaped the mobile phone and Yealink T42G in the same view and then using video editing software to precisely cut between 'we press the call button on mobile phone' and T42G light up with Caller's Name.
We can safely say: Caller ID mapping to Name has little impact by phonebook-size.
But why 297999 contacts? did we say 1 million contacts?
Yes, we did mention 1 million records, we tried to import them, however, we found that 3CX cannot import more records, due to gateway 504 errors. Below is a detailed information on how we pump data into 3CX and how it behaves.
Detailed Information
Among the fake contacts, there is one real entry with the correct caller ID and information, which is 'pulled' from the CRM system.
import 0001.csv
import 0002.csv
import 0003.csv
....
Initial import action goes very quick (a few seconds only). However, as the phonebook-size grows, it takes longer and longer. When we imported 0295.csv, it cost 50+ seconds. When we try to import 0297.csv, 3CX breaks with errors, as shown below.
We inspected the DevTools of Chrome, and it shows 504 error, gateway timeout. Obviously, 3CX takes too long to respond.
We deleted all contacts and start all over again, it still stuck at 0297.csv. We started over 5 times, and they all stuck at a batch number between 280 and 300, where importing time breaks the threshold causing error-code 504.
We recorded each import time cost, we found initial import can be very fast. As the phone-book-size grows, each import, albeit 1000 contact always, take longer and longer.
It's not a resource issue, as we monitored 3CX resource usage in real-time, every 3 seconds. 3CX used only <50% CPU, and a small amount of memory. Plenty of disk spaces are available.
It freezes, but it will come back after 'fake-death'. The web interface tries to download all contacts to the browser, and it causes the browser to 'freeze', for up to 1 minute. Fortunately, it's within 1 minute. otherwise, it may cause another 504 gateway error.
Browsing a huge number of contacts is a pain, as the pagination is only 7, and there is no 'jump to page'. if you want to browse some contacts at the very end of your phone book in 3CX, you have to spend hours, trying click many times to reach the end.
Luckily 3CX provide a search box, and it can search through contacts, very fast, but not accurate.
During our test, we tried to empty fake records and get back to normal operation, and it kills the server. As deleting takes very long. It's not real death, but it hogs CPU to a crazy level. We tried to reboot gracefully, and it takes quite some time to respond console command.
But how did we delete all contacts? We delete 100 contacts each time. We choose 100, as each page has 100 contacts. We found that deleting contact is CPU intensive, and the time cost is reduced with the phonebook-size.
Delete Contacts 100 by 100
We may notice that in the beginning the deleting time was very short (2-4 seconds) , from #0 to #200. Then it jumped to 11 seconds, and gradually went down. Here is the reason why.
For 3CX each contact is associated with an ID, started from 1, and it is auto-increasing. When we deleting contacts, the id become non-exist. For example, we add 10 contacts to a newly installed system, those ID will be 1 ~ 10. Then we delete first 5. ID 1~5 becomes invalid, 6~10 still works. Then we add 3 more contacts, Contact ID will become 11 , 12 , and 13. the ID of 1~5 will never be reused.
We employed a production system, and deleted all existing contacts in it. So we have quite some invalid ID in the begining. When trying to delete them, 3CX responds very fast. That's why they only take 2 ~ 3 seconds in the begining. When it starts to delete 'existing' record, the times jump up to 12 seconds (with 300,000 contacts in the database).
With a huge number of contacts, 3CX cost a lot of memory, I'm guessing some sort of caching and searching is employed to make sure it searches fast. CPU does not have a lot of impacts, and disk increase is very little 300,000 contacts only cost 42MB disk space.
- There is a limit for importing 3CX contacts: approximately 300,000 phonebook entries.
- Mapping Caller ID to real name has high performance regardless of phonebook size.
- 3CX's memory usage increases drastically together with the number of contacts.
- 3CX Web interface of listing Contacts tries to download all contacts at once, it's none-responsive with a huge number.
- 3CX Web interface Searching through a huge number of contacts have inaccurate results.
- 3CX pagination with contacts does not have 'jump to page', and its difficult to browse contacts in phonebooks.
- With a huge number of contacts in 3CX, never try to 'Delete ALL' , it freezes 3CX server.
- Searching through a huge phonebook size is fast, but not very accurate.
- Delete huge number of contacts has to be done step by step too, and deleting time decreases with phone-book-size.