Connection Timeout after 2 minutes while generating a PDF-report

[omroepmuseum]

You are using DaDaBIK version 13.1-Levanto enterprise, installed on 08/10/2025 (installation code: 133315a7493334bfea), the latest version of DaDaBIK is 13.2-Levanto released on 29/10/2025

You are not running the last release of DaDaBIK, the release you are running might have bugs and security holes, see the official change log for further information. You can upgrade DaDaBIK here.

In case you want to upgrade to a more powerful edition (from Pro to Enterprise/Platinum, from Enterprise to Platinum) please contact us.

System info​

PHP Version: 8.2.29

mysql version: 10.6.23-MariaDB-cll-lve

Web server: LiteSpeed

Client: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Safari/537.36 Edg/142.0.0.0

URL installation:

Hello, I wanted to generate a PDF-report for a subset of 325 records out of a couple of thousand records. For each record, I show a picture (size 1280 x ...) plus some fields. But after 2 minutes I get a "Connection Timeout". Without the picture, I do NOT get the "Connection Timeout".
Is there a way to get rid of this "Connection Timeout" without sacrifying the display of the pictures?

Kind greetings,

Hendrik

 

[omroepmuseum]

I already increased the parameter "max_execution_time" to 600 seconds and more. No change!

 

[eugenio]

Hello,
max_execution_time is related to PHP, you probably have another max execution time related to LiteSpeed.

Best,

 

[omroepmuseum]

Our hosting platform changed the LiteSpeed max execution time also to 600 seconds.
In the config_custom.php I have "$pdf_creation_time_limt = 600;" (_limt OK?).
I inspected all - I think - htaccess-files to find any time limiting commands in it - I found nothing.
???

 

[omroepmuseum]

Do you have any idea where this 2 minutes can come from. Or is it some hard upper limit?

 

[eugenio]

On PHP, there is also this parameter

PHP: Runtime Configuration - Manual

Runtime Configuration

www.php.net

that by default is -1, meaning equal to max_execution_time. You can check the value you have for it.
If this is not the reason, I think there is another timeout set in your infrastructure, try to ask again to your hosting provider.

 

[omroepmuseum]

Hello Eugenio! max_input_time was also 600; I set it to -1, to 0 and to the default value of our hosting platform 60. No change.
Our hosting platform suggest to execute a pdf-generation "outside" of DaDaBIK. Using what they call a cron-function. I know how to do that (I use it) and I know how to call ddb_api-functions from within such a cron-function. BUT I do not know how I can start PDF-creation from "outside" DaDaBIK. Any idea?

Kind greetings,

Hendrik

 

[eugenio]

Hi Hendrik,
unfortunately you can't execute the export to PDF via cron-function.

There certainly must be another setting that is preventing you to execute scripts for longer than 120 seconds.

Best,

 

[omroepmuseum]

Eugenio, certainly indeed but our hosting platform is also unaware of such a limit!
By the way: the setting "$pdf_creation_time_limt" ends with "limt"! That end is OK?
As said before I have run the PDF with the picture-field declared as a text-field. Then the PDF is generated in 12 seconds! So clearly the fact that I add one picture to each of the 300+ records in the PDF causes this severe increase in execution-time (no surprise!). I already lowered the resolution and file size of the pictures. File size is now below 5 kByte. Are there any other tricks one can do to lower the processing time?

 

[eugenio]

I know there is a typo in the parameter but it doesn't affect its behaviour. Also, if you don't specify any $pdf_creation_time_limt, you won't have any limit.
Unfortunately, I don’t have any specific trick to reduce the processing time, except generating the PDFs in batches (e.g., records 1–100, then 101–200, and so on).

 

[omroepmuseum]

OK! The weird thing is that no-one can tell me where this timeout after exactly 120 seconds comes from. Nor you nor our hosting platform!

 

[omroepmuseum]

OK! After some searching, I was told that the TCPDF-"library" used by DaDaBIK to generate the PDF's is notoriously slow, certainly when one adds images. In my case, one thumbnail image of max 5 kByte is added to each record.
The timeout however is caused by our hosting platform. They already changed a number of parameters, however without any success.
My question: are there any plans to use a more powerful PDF-generating tool in the (near?) future.
In general I find DaDaBIK rather slow in displaying results in the grid-form. Our master table now has 79 fields. 39 of them are shown in the grid. Each record contains that one thumbnail-picture and our default number of records per page has - already quite a while - been set at 20.

Kind greetings, Hendrik

 

[omroepmuseum]

Meanwhile we ARE running the latest version of the software:
You are using DaDaBIK version 13.3-Levanto platinum, installed on 31/01/2026 (installation code: 133315a7493334bfea), the latest version of DaDaBIK is 13.3-Levanto released on 20/01/2026

You are running the latest release of DaDaBIK

 

[eugenio]

Hello,
there isn't any plan to change the library in the near future, if you feel the application is slow when displaying results in the grid, the reason is most probably the database, first thing I would check if if fields are correctly indexed, in particular the lookup fields. I would also check if the speed increase considerably if you temporarily remove all lookup fields from the grid.

Best,

 

[omroepmuseum]

Hello Eugenio. On the matter of PDF-generation, there the cause is clearly the presence of the (thumbnail-)images. Without them the PDF-generation is succesfull within the "allowed" 120 seconds.
In general, displaying result in the grid in general has also become rather slow. Again the display of the same (thumbnail-)images play a role that has slowed down the display since the very beginning. I don't think lookup fields play an important role because there are only a limited amount of them. All PK-fields are indexed. But I have many, many custom php-functions (format, required, operational hooks, ...) that probably slow things down. I have some JS-formatting but quite often I need some information from the database so I go to php. Any advice apart from you apart from buying more processing power from our hosting platform?

Kind greetings, Hendrik

 

[eugenio]

Hi Hendrik,
even if you don't think lookup fields is the reason, I would definitely test the speed difference after having temporarily removed all lookup fields from the grid. This is the first check I would do, if the speed does not change you can try, one by one, to remove the other features (individual custom functions etc) to see if you notice a difference.

Best,

 

[omroepmuseum]

Hello Eugenio,

my custom functions have grown so numerously that I hardly dare to remove them one by one, out of fear of not getting it right again afterwards. I assume it will make a difference, but for the PDF-generation the (thumbnail-)images definitely are the main cause.

Kind greetings,

Hendrik