Forum Discussion

Calli-TK's avatar
Calli-TK
Level 2
11 years ago

Bad performance - Transvault with Enterprise Vault

Hi all,

currently we are migrating from Lotus Notes to Microsoft Exchange. We also have to migrate our existing EV Archive Domino to EV Archive Exchange. We are using the Transvault software for migrating the archives. Now when we are migrating some archives we have a very bad bad performance - it converts about 0,5 mails/second - this seems to be extremly slow. All needed server are virtualized with vmware.

When we trace these transactions, we find in the traces these entrys:
751 17:46:14.561  [3256] (StorageOnlineOpns) <3876> EV:M {CXMLIndexableItem::LoadProxies:#2236} Using global catalogue override GC://xy.kl.int
752 17:46:14.561  [3256] (StorageOnlineOpns) <3876> EV:M {CXMLIndexableItem::LoadProxies:#2246} Fetching proxy address for [SystemMbxName=SMTP:eve-sys1@xy.de]
753 17:46:14.561  [3256] (StorageOnlineOpns) <3876> EV:L {SanitizeUserName:#940} [SMTP:eve-sys1@xy.de] does not contain any chars that require encoding for LDAP or ADSI queries.
754 17:46:14.561  [3256] (StorageOnlineOpns) <3876> EV:M {FindUser:#391} Using searchbase [GC://xy.kl.int]
757 17:46:16.855  [3256] (StorageOnlineOpns) <3876> EV:M {FindUser:#393} Successfully bound to searchbase [GC://xy.kl.int]
758 17:46:16.855  [3256] (StorageOnlineOpns) <3876> EV:L {SanitizeUserName:#940} [SMTP:eve-sys1@xy.de] does not contain any chars that require encoding for LDAP or ADSI queries.

As you can see we have about 1.5sec. delay when the request is sent to the GC and the response comes back.

I already deactived all AV systems, firewalls etc - no change :-( So at the moment i am at the end of my knowledge - maybe somebody here in the forum has an idea?

We are using Enterprise Vault 10.0.4 and Transvault 6.4.10.24 with Exchange 2010.

Tnx in advance for your help! If you need more informations, i will post or send it!

Cheers
Torsten

Best Practice
Configuring
Enterprise Vault
Error messages
Information Governance
Monitoring
Performance
Recovering
Troubleshooting
Windows Server (2003-2008)
  • Paul_Honey's avatar
    Paul_Honey
    11 years ago

    Torsten,

    As we have discussed offline and with Support, this delay actually looks to be one that we have seen previously with various partner migration solutions that use the Content Management API. Whilst the root cause of such a slow bind to a Global Catalog should be diagnosed and resolved in the environment where it occurs as it seems unusually laboured, we have also refactored some code to include additional caching to significantly reduce the volume of calls to the GC to offset the impact of slow binding. This change was officially released in Enterprise Vault 11.0.0 CHF1, and referenced in the readme as follows:

    Ingestion using the Content Management API was slow in environments with many Exchange servers [3415538]

    Ingestion using the Enterprise Vault Content Management API was slow in environments with many Exchange servers.

    This has been fixed.

    Don't be put off by the reference to 'many Exchange servers' as whilst the original environment to report the issue observed delays due to volume of servers in the environment, the issue can similarly be observed with few servers but very slow GC lookups as per your scenario, with both situations being addressed by the same caching fix.

    Let us know how you go

    Paul

     

  • Paul_Honey's avatar
    Paul_Honey
    Level 5
    11 years ago

    Hi Torsten

    Can you log a case with support if you have not done so already and add the case number to this forum post.

    With the product as it currently works, the only solution / workaround is to resolve why the GC is taking such a long time to repsond. This 'delay' is beyond the realms of EV, we are simply making a standard MS call to bind to a GC here, but support will hopefully be able to provide some additional assistance in troubleshooitng the delay as I know it has been reported before by other customers performing migrations. Unfortunately, I don't know the answres to this as GC binding is not an area I have any expertise in.

    Beyond Support helping troubleshoot the root cause of the GC binding delay, I would also like to see them escalate the issue itself internally as long term Engineering need to review why the code is making so many repetitive binding calls and see if that behaviour can be improved.

    It all needs a case and a reference number to start with though, so that I can help the assigned support reps in the background progress the issue accordingly

     

    Regards

    Paul

  • AndrewB's avatar
    AndrewB
    Moderator
    11 years ago

    it looks like you are using the "API" connector from TransVault to migrate out of EV. since you're purely troubleshooting a performance issue, i would recommend you switch to the "direct" connector in TransVault which will bypass any GC calls or other functions of the EV API that are slowing down your process.

  • Calli-TK's avatar
    Calli-TK
    Level 2
    11 years ago

    Hi all,

    tnx a lot for your fast respones. As i know, our Migrationpartner already opened an case at the sysmantec support. As soon as i have more informations i will update it here.

    AndrewB - where can i set this "direct" connector switch in transvault?

    Tnx in advance!

    Cheers

    Torsten

  • Paul_Honey's avatar
    Paul_Honey
    Level 5
    11 years ago

    Torsten,

    As we have discussed offline and with Support, this delay actually looks to be one that we have seen previously with various partner migration solutions that use the Content Management API. Whilst the root cause of such a slow bind to a Global Catalog should be diagnosed and resolved in the environment where it occurs as it seems unusually laboured, we have also refactored some code to include additional caching to significantly reduce the volume of calls to the GC to offset the impact of slow binding. This change was officially released in Enterprise Vault 11.0.0 CHF1, and referenced in the readme as follows:

    Ingestion using the Content Management API was slow in environments with many Exchange servers [3415538]

    Ingestion using the Enterprise Vault Content Management API was slow in environments with many Exchange servers.

    This has been fixed.

    Don't be put off by the reference to 'many Exchange servers' as whilst the original environment to report the issue observed delays due to volume of servers in the environment, the issue can similarly be observed with few servers but very slow GC lookups as per your scenario, with both situations being addressed by the same caching fix.

    Let us know how you go

    Paul

     

  • AndrewB's avatar
    AndrewB
    Moderator
    11 years ago

    in TransVault 6.4 it's a change in the database, you can't do it via the TV client. it's different in later versions on TV now with their hybrid connector. you can have your migration partner open a case with TV support to get the script.

    http://blog.transvault.com/blog/2014/06/fast-enterprise-vault-migration.html

  • Calli-TK's avatar
    Calli-TK
    Level 2
    11 years ago

    Hi,

    yesterday we did the upgrade from 10.0.4 to 11 CHF1 - now it works like a charme :-) But we also had to update the Transvault Version to 6.5.8.2. - but now it runs as expected.

    Tnx a lot for your support here and the provided quick solution!

    Cheers

    Torsten