Email importing shenanigans

Hi,

I’m using Version 7.11.15

there is a strange thing going on, in the “emails” (IMAP) section :

2 emails from the same contact :
1 is auto-imported, the other isn’t …
when I look inside the emails I see the following :
the first one (auto-imported)
kdbegcnhbhnoibka
the second one (not auto-imported)
ffflpamcfcnddkha
here you can clearly see the difference, one has the “from” email address (but why is there a comma in front of it, by the way ?), the other one has just a name … why are they different ?

when I look in Thunderbird, both email headers are exactly the same …
dolnonkgkmjehiij
pajbbhmakdoppcgo
do you see any difference ? I don’t !

another thing, the auto-imported one gets imported but NOT linked to the correct contact … to nothing actually …


but when I manually select contact by copy pasting the email address in the search window, it finds it !

huh ?

so the auto-import isn’t actually importing, although it has a contact for this email address …

and the manual import isn’t an option as well because sometimes the “From” email address is miraculously replaced by just a name instead of the actual email address, which makes it almost impossible to manually lookup the contact to import it to …

huh ?

what am I doing wrong ?

bump …

… nobody has any idea what is wrong ?

another thing connected to this problem :

opening any module on my CRM, my server is lightning fast …

image

opening the “emails” module (1 Imap account, with 2220 emails), it’s rediculously slow …

image

I have no complaints about slow email in Thunderbird or anywhere else …

what’s going on ?

I reduced the IMAP to only 362 emails in “inbox” and still terribly slow …

image

what am I doing wrong ???

If you have that installation going for a few years, I would bet you have overgrown tables in your database. Run the first query in this post:

I will look into it, but I find it really weird that all the other modules are lightning fast, only the IMAP emails are terribly slow …

if my database were bloated, wouldn’t EVERYTHING be slow ?

that’s why I think there is something wrong with the Email module …

No, a bloated database can be a matter of only a few tables, queries that don’t use those tables won’t be affected.

Any way, I am not discarding that you might have a problem specific to email, in fact, it wouldn’t surprise me. I am just saying that, in my experience, in SuiteCRM it’s always worthwhile to start by checking the database when things are slow.

hi @pgr,

I checked the SQL …

118.951 emails in the “emails” table …
113.678 in “emails_beans” table …
116.703 in “emails_text” table …

… somebody told me this is the reason for the slow reaction of the email modules

these emails is 15 years of company/customers communication …

does this mean the CRM can’t handle these amounts of emails ?

strange …

how about companies who work with dozins of sales reps and several service managers ? don’t they have a shitload of customer communications (emails) in their systems … ? Isn’t that what a CRM system is just made for ?

what am I doing wrong ?

I would suggest getting rid of the older emails, they’re probably not adding much value and they will slow down your system.

SuiteCRM is not that optimized for large amounts of email. Some people do use it in larger installations but that requires paying closer attention to performance. Things like analyzing queries, improving database indexes, or simply adding hardware capabilities.

We easily get used to big cloud email platforms like Gmail and forget that they have large teams of engineers constantly working to optimize that. And huge hardware running all of it…

Is there a way to “archive” these older emails, so they are still in the system, but they don’t slow down the system anymore ?

for example moving them to another table or something ?

Note that you might have more data connected to the emails - relationships etc. Remember that, in case you decide to move things around, whether you want to keep anything, or purge everything…

You can, of course, just move a ton of rows into a different database table, but it will be a “dead” storage. Not really “in the system” except for the ability to retrieve it with SQL.