There are several possible causes for why customers may experience longer startup times after deployment of MarvelClient.

Above all, if you're not yet on at least MarvelClient release 2.0.8: update!
MC 2.0.8 and up introduced significant startup time improvements - for details see release notes.

  • For administrators who often have links to UNC paths on the workspace/desktop and/or bookmarks, MarvelClient always scanned those (usually distant or disconnected) databases along with all other local databases. Because those databases are often far away or require the client "to find its way through the network to them", this significantly prolongued startup times for admins prior to MC 2.0.8 from 2.0.8 on, MarvelClient by default no longer scans UNC paths
  • For all users with standard Notes 8 clients (=Eclipse client installs), MarvelClient used to scan the entire data directory and everything underneath.
    An Eclipse client install typically consists of 3,000 files in the Notes Data\workspace directory in 2,400 directories (out of which 1,850 are empty) - from 2.0.8 on MarvelClient will no longer scan the following directories:
    Notes Data\Domino, Notes Data\workspace, and Notes Data\IBM_TECHNICAL_SUPPORT, thereby all in all scanning roughly 97% lesser files for a normal end user.

If you still experience long startup times after updating to >= MarvelClient 2.0.8, then you should look at log.xml of selected end users (it'll be easier if you add log.xml to the backup to analyze job to simply look at log.xml files from within the analyze database).
Looking at a log file, each line has a millisecond indicator at the beginning, showing the number of milliseconds that have elapsed since the log was started:

<le><t>273</t><l>2</l><m>before login done; duration: 63</m></le>                                  
<le><t>2283</t><l>2</l><f>LDR::MCAfterLogin</f><m>waiting for local replica scan to finish</m></le>
<le><t>2283</t><l>2</l><f>LDR::MCAfterLogin</f><m>thread done</m></le>                          

Also note that at the beginning of each log.xml file, you will find the following important lines:

<le><t>0</t><l>2</l><m>Version C:20110414T101124 B:20110414T102608</m></le> //MarvelClient release
<le><t>0</t><l>2</l><m>now: 20110425T131632Z</m></le> //when was the log file started in UTC time - a quick peek tells you whether this is a rather recent log or quite an outdated one
<le><t>0</t><l>2</l><m>client: Release 8.5.2FP1|November 30, 2010</m></le> //The exact notes release

Those three lines will tell us wether the user is running Notes 7 or 8, how recent the log is and what MarvelClient release the user is on.
Further details on e.g. standard vs. basic client are to be found in config.xml.

Continuing with log analysis, look at larger millisecond jumps (> 1,000 for example) - those are usually the ones that indicate performance issues.
If you happen to have a log file with no significant jumps but ongoing small jumps from line to line it's quite definitely a user who is starting Notes along with a cold windows boot and the disk is going berserk trying to make Windows, Notes, and lots of other apps/drivers etc.happy.
In a normal log.xml on a halfway decent machine, you should find that the ms-indicator does not jump for many lines in a row.

In the following example it took 799 ms to open the local mailfile replica - most presumably because it's a several GB mail file - more details to be found in databases.xml, then.

<le><t>2881</t><l>2</l><f>CO::Names::ReplacePlaceholders</f><m>reading user details</m></le>
<le><t>3680</t><l>2</l><f>ND::Database_Impl::Open</f><m>opening database: (C12572D7:005E2FC0) 'mail\aname.nsf'</m></le>

In the above three line example, note the jump from 272 to 2,283 ms - that is the ONLY valid jump in any log file as it is the time the user needed to enter his or her password.
(Note that if the user is using Single Sign On (SSO), that there should not be any noticeable jump)

In 99% of all cases you should be able to easily determine wether you have performance bottlenecks because of your Domino server performance (e.g. when the config and/or analyze database are being opened), or towards the Data directory (especially if the Notes Data directory is on a network drive).

Last but not least, when searching for "duration" in a log.xml file, you will find summaries of how long specific sections took to process:

<le><t>6</t><l>2</l><m>init done; duration: 6</m></le>
<le><t>52</t><l>2</l><m>before login pre done; duration: 41</m></le>
<le><t>273</t><l>2</l><m>before login done; duration: 63</m></le>
<le><t>5138</t><l>2</l><m>after login done; duration: 2855</m></le>
<le><t>46975</t><l>2</l><m>shutdown done; duration: 2769</m></le>

init should usually not take longer than 10-50 ms - otherwise it would indicate starting Notes along with an OS cold boot.
before login pre is for roaming only and would only take longer if data is roamed from a network drive on to the local machine.
before login is the remainder until the login dialog - this should usually also not take much longer than 100-500 ms.
after login is the time it takes MarvelClient to process all "after login" changes (including after login - before download, after login - before sync, after login - after write etc.) until the client takes over the rest of the normal client startup (=showing the progress bar in the splash screen).
shutdown is shutdown :-)


In case you experience 1-2 minute delays in client startup even though log.xml states that MarvelClient was finished much earlier, you might want to look at the following:

A customer experienced slow startup times with almost exactly one or two minute lags.
Analysis of the customers environment showed that they were running Notes releases >= 8.5 but still had the following notes.ini entry:


This entry was introduced by IBM in Lotus Notes 8.0.2. In an effort to improve performance by switching the startup sequence around, Notes 8.0.2 by default adds the following notes.ini entry:

Selected customers have disabled early authentication by setting this entry to 0.

While that INI variable is valid for clients below release 8.5, it actually creates performance issues with Lotus Notes 8.5 and above.
It is highly recommended that this notes.ini entry be removed which will allow Notes to startup "regularly" again.