Environment

ProjeQtOr version: 12.4.1
Browser: Chrome / Chromium
Database: PostgreSQL

Summary

A Ticket opens in approximately 0.7–1.0 second when it has no Planning Activity or references a small Planning Activity.

The same Ticket takes approximately 14–15 seconds to open when it references a long-running Planning Activity with approximately 2,500 History rows.

The problematic Activity generates approximately 1.86 MB of HTML, mostly because of its large History table.

Problem

Most Tickets and Activities open quickly, usually in less than 1 second. The slowdown is reproducible only when the Ticket references the problematic long-running Planning Activity.

• Without Planning Activity: less than 1 second
• With another small Planning Activity from the same project: less than 1 second
• With the problematic Planning Activity: approximately 14–15 seconds

Measurements

Ticket without Planning Activity:
Total: ≈0.765 s

Same Ticket with a small Planning Activity:
Total: ≈0.708–0.987 s

Same Ticket with the problematic Planning Activity:
Total: ≈14.57 s

Several control Tickets:
Total: ≈0.65–0.90 s

New objects

New Ticket:
TTFB: 0.554 s
Total: 1.015 s
Response size: 104 KB

New Activity:
TTFB: 0.545 s
Total: 0.928 s
Response size: 138 KB

Problematic existing Activity

TTFB: 0.708 s
Total: 4.669 s
Response size: ≈1.88 MB

HTML comparison

Small Activity:
HTML size: 293 KB
History rows: ≈200
Table rows: 302
Option elements: 124

Problematic Activity:
HTML size: 1.86 MB
History rows: ≈2,500
Table rows: 2,736
Option elements: 124

The number of option elements is identical, so the issue does not appear to be related to reference or dropdown lists.

Further inspection shows that the large table is the Activity History.

Typical History entries include:

• revised work
• real work
• left work
• progress

The Activity is used for long-running work tracking, so its History grows continuously.

Network checks

Static resources are fast:

TTFB: 0.042 s
Total: 0.607 s
Size: 976,740 bytes
Speed: ≈1.6 MB/s

Network bandwidth therefore does not appear to be the bottleneck.

For the slow Ticket:

objectDetail.php?refresh=1

TTFB: ≈14.97 s
Total: ≈15.05 s
Response size: ≈135 KB

Almost all of the request time is spent before the response is returned, which suggests server-side processing during object detail generation.

Reproduction

1. Create or use an Activity with a large History, approximately 2,500 rows.
2. Assign this Activity as Planning Activity to a Ticket.
3. Open the Ticket.
4. Observe approximately 14–15 seconds loading time.
5. Replace the Planning Activity with a small Activity from the same project.
6. Open the Ticket again.
7. Observe approximately 0.7–1 second loading time.
8. Remove Planning Activity.
9. Open the Ticket again.
10. Observe approximately 0.8 second loading time.

Expected behavior

A Ticket should not become significantly slower to open only because its Planning Activity has accumulated a large History.

A long-running Activity should also remain usable after thousands of History entries have accumulated.

Possible cause

It appears that a large amount of Activity History is rendered or processed synchronously during object detail generation.

The History section already appears to support a separate refresh request:

objectDetail.php?refreshHistory=true

This suggests that History may be a good candidate for lazy or asynchronous loading.

Suggested improvement

1. Do not render the complete History during the initial object detail request.
2. Load History asynchronously when the History section is opened.
3. Add pagination or a limit, for example the latest 100 entries.
4. Provide a “Load more” action for older History records.

This would prevent long-running Activities from generating thousands of table rows and megabytes of HTML during normal object rendering.

Impact

Normal Ticket:
≈0.7–1.0 s

Ticket referencing a large-History Planning Activity:
≈14–15 s

Problematic Activity:
≈1.86 MB HTML
≈2,500 History rows

The issue becomes increasingly visible as a long-running Planning Activity accumulates work and progress History.

Related performance cases

“saveObject is too long”
https://www.projeqtor.org/en/kunena-2/2-submit-issues/14011-saveobject-is-too-long

“ProjeQtOr performance issue: too slow”
https://www.projeqtor.org/en/kunena-2/2-submit-issues/13119-projeqtor-performance-issue-too-slow

Please let us know if additional traces, measurements, or comparisons are required.