Huge Performance Difference for Small .EML File Between Local and Production Environment

Hi Team,

We are experiencing a major performance difference while opening .eml files between our local environment and production server.

Issue Details:

  • File type: .eml
  • File size: very small
  • Local environment opening time: few seconds
  • Production environment opening time: several minutes

Current EmailConfig:

config = new EmailConfig
{
    EmailEncoding = Encoding.UTF8,
    DefaultRender = true,
    RemoveLastWhitePage = true,
    TimeZoneOffset = new TimeSpan(-3, 0, 0)
};

Current DocOptions:

var documentOptions = new DocOptions
{
    ImageResolution = 110,
    TimeOut = 600,
    Watermark = watermark
};

can you help us resolving the issue ?

@Mohit_Tandel

Could you please share a sample .eml file that reproduces the issue, if possible? This would help us inspect the file metadata, encoding, embedded content, attachments, headers, and any other values that may affect rendering time.

The large difference between the local environment and production environment is important here. If the same small .eml file opens in a few seconds locally but takes several minutes in production, this may indicate an environment-specific issue.

Your current EmailConfig and DocOptions look acceptable for testing:

For the next test, we recommend temporarily disabling the watermark to isolate the rendering performance:

var documentOptions = new DocOptions
{
    ImageResolution = 110,
    TimeOut = 600,
    Watermark = "" // 
};

Also, please use the same JavaScript viewer configuration recommended for large or potentially slow documents:

objctlDoc = $("#div_viewer").docViewer(
{
    debugMode: false,

    // The viewer does not add all pages and thumbnails to the DOM at once.
    // It loads them in blocks, which is safer for large or slow-rendering documents.
    largeDoc: true,

    // cacheEnabled=true:
    // - smoother navigation for small/medium documents
    // - more anticipated requests to DocImage.axd
    // - more server load
    // - more browser memory usage
    //
    // cacheEnabled=false:
    // - loads only what the user is actually viewing
    // - less pressure on the server
    // - better when diagnosing performance issues
    cacheEnabled: false,

    // autoLoad=true:
    // - preloads/renders the whole document
    // - useful if you want everything ready for navigation/printing
    // - can be expensive if the document or environment is slow
    //
    // autoLoad=false:
    // - loads on demand
    // - recommended while diagnosing performance issues
    autoLoad: false
});

Please share the sample .eml file and, if possible, the opening-time logs from both environments using the same file and configuration. That will help us compare whether the delay is happening during file access, email parsing, rendering, or image/page generation.

Hi @gabriel.vega,

I would like to share additional findings related to the EML performance issue.

Since we could not share the original customer email due to confidential information, we created a sanitized version while trying to preserve the original MIME structure, Outlook HTML formatting, thread history, multipart sections, and overall rendering complexity as closely as possible.

Observed Behavior

Original EML File

  • Opens in localhost within a few seconds
  • Opens in Dev / QA / Production environments in approximately 4.8 minutes

Sanitized EML File

  • Opens in localhost within a few seconds
  • Opens in Dev / QA / Production environments in approximately 1.4 minutes

No intentional optimization was done to reduce file complexity.

Key Finding

Even after sanitization, reducing/removing some sensitive content decreased the opening time from:

~4.8 minutes → ~1.5 minutes

This suggests that certain content patterns inside the EML may significantly affect parsing/rendering/indexing performance.

We are sharing the sanitized EML file for analysis since it still reproduces the delayed opening behavior in server environments.
More_Sanitized_Working_EML.zip (10.1 KB)

Please let us know if there are:

  • recommended EML optimization settings
  • logging/tracing methods
  • ways to identify which EML section is causing the delay

Thanks & Regards,
Mohit Tandel

@Mohit_Tandel

Our development team is currently reviewing your case with the Doconut Mail Viewer. We will analyze the sanitized EML file to understand better which part of the email structure may be contributing to the delay in server environments.

Once we complete the analysis, we will get back to you with our findings and any recommended configuration changes, optimization options, or diagnostic steps.

@gabriel.vega

Is there any update regarding this topic ?

@Mohit_Tandel

Our development team has been reviewing the EML loading scenario and identified a few configuration and diagnostic options that may help improve performance. Please try the recommendations below:

Recommended EML optimization settings

For EML/MSG files, we recommend starting with a lighter EmailConfig:

var config = new EmailConfig
{
    DefaultRender = true,
    Resolution = 100,
    SkipExternalImages = true,
    RemoveLastWhitePage = false,
    ForcePageSize = false
};

If the delay happens after OpenDocument, also measure the first page render request, because EML processing may continue when the first page image is generated.

A slow EML is usually caused by one of these:

  • external images or linked resources;
  • large inline images;
  • many MIME parts / attachments;
  • very long reply chains;
  • malformed or unusual encoding.