Same data works flawlessly on localhost. Crashes browser on production. Exporting to excel.

saurabhj@gmail.com

I am facing a very weird problem. Have thrown everything at it and finally I feel I have hit the wall.

We use DataTables to render a report on our application.
It is 1700 rows with about 18 columns.

We fetch the data separately in an AJAX call and then load up the Datatable separately (not using Datatable's AJAX calls).
Once data is loaded, there are no more server calls.

So far, so good.

However, when I hit the Export to Excel button online, my browser tab freezes and eventually the browser crashes.
I can see memory increase till about 1200 Megs on the Windows Task Manager before this happens.

If I have fewer rows - for example, 500 - 600 rows, this works correctly. No issues.

Locally, I fetch the data and hit the Export to Excel button for 1700 rows (18 columns).
The file is saved in under 5 - 6 seconds (we are doing some pre-processing on the excel export).
And memory goes from 200 Megs -> 300 Megs because of this operation.

What could be going wrong?
We have tried to mimic the local environment and setup to reflect the production server exactly but no cigar.

Any pointers would help. Pulling out my remaining few strands of hair here

colin

Hi @saurabhj@gmail.com ,

It does seem odd to have different behaviour when the systems are the same. Are the versions of DataTables and the extensions identical in both cases? Are you able to link to your page so we can take a look?

Cheers,

Colin

saurabhj@gmail.com

Hi Colin, thank you for checking.
Both the systems are identical.

Over the past few days, I have meticulously checked everything to ensure that the system locally is identical to the production server. (The same branch on git is deployed both places with the same build pipeline -- though we don't touch the datatables & extension files in our build pipeline).

Unfortunately, the data is quite sensitive (all our client + billing info) and as such, I am unable to share any info on that front.

What is baffling is that the production system works perfectly fine for upto 800-900 records. It is only when we go over 1000, does it have problems.

The same issue occurs for PDF, CSV and excel.

Locally, no matter what you throw at it, it works (I have a clone of the prod DB running on my machine).

Thanks again for looking into this for me.

colin

It would be worth looking at the performance tab on Chrome's developer tools, and profiling to see where the speed delay is. It might be on the network transfer perhaps, or something else external to the libraries...

C

saurabhj@gmail.com

Ok. Just to update this thread for people who come after me - incase I forget later.
I "think" I managed to solve the issue - we still have to deploy to production - so unless I come back and update this thread, please assume that the issue has been solved.

As it turns out, what was happening was that the data returned to us by the API had a few columns missing for a few rows.

When we were testing locally, we would get one pop up which would then go away.
On production, the act of raising this pop up itself was getting taxing for datatables which was crashing the browser.

One of our devs had written code:

      render: function (data, type, row) {
        if (data == null) { return ' ' }
        return data;
      }

In anticipation of this column being empty which worked while displaying.
However, when trying to export to excel, we would get an alert box locally and this would crash the browser tab on production.

I added the:

defaultContent: '',

property to the column which removed the alert box for us and I am hoping will not crash this on production as well.

(In my tests, just having 5 corrupt rows as output instead of the 1,500 rows also crashed the browser. But if I had 1400 rows (without the corrupt rows) worked fine)

So with that hypothesis, I am assuming this would fix our issue.
Thanks @colin for all your help on this. I appreciate it.

allan

That interesting - thanks for posting your findings. Buttons should be using the display rendered data for the export unless told to do otherwise. It would be worth checking what version of Buttons you are using as I think older versions did use the raw data.

But beyond that, we'd need a test case showing the issue to be able to say for certain.

Regards,
Allan