Ticket Creation via API is Slow (9–20s) — Zammad 6.5.0

[wagner.loch]

Hello Team!

I’m experiencing performance issues when creating tickets via the API.

• Used Zammad version: 6.5.0
• Used Zammad installation type: source
• Operating system: 22.04.1-Ubuntu

Expected behavior:

• Ticket creation via the API should be fast and responsive.

Actual behavior:

• Creating a ticket (via API or GUI) takes a long time — usually between 9 to 10 seconds, and sometimes even up to 20 seconds.

Steps to reproduce the behavior:

• Call the /api/v1/tickets endpoint to create a new ticket.
  

  

• Observe the response time and logs.

INFO -- : Started POST "/api/v1/tickets" for 104.28.207.233 at 2025-05-28 23:01:31 -0300
INFO -- : Processing by TicketsController#create as */*
INFO -- : Parameters: {"title"=>"Help me!", "group_id"=>45, "priority_id"=>2, bject"=>"My subject", "body"=>"[FILTERED]", "type"=>"note", "internal"=>false}}
INFO -- : Completed 201 Created in 9427ms (Views: 0.2ms | ActiveRecord: 9058.4ms (547 queries, 33 cached) | GC: 37.1ms)

• As shown, the request takes 9427ms to complete.
• It executes 547 queries — is that expected?

Environment

• The Postgres server has 32 CPUs, 64GB RAM and Disk Performance tier 750K IOPS
• The database contains over 500,000 tickets.
• The Zammad Server has 8 CPUs, 48GB RAM.
• I’ve tried to configure WEB_CONCURRENCY=5 but it does not make any effect.

Any ideas or guidance on optimizing performance would be greatly appreciated. Thank you!

Best Regards

[mantas]

Are there complex triggers which could go into semi-permanent loop?

[wagner.loch]

Hi @mantas, Thanks for helping!

There are both complex and simple triggers in our setup.

[7] pry(main)> Trigger.count
=> 171
[8] pry(main)> 

I’m not sure how they work internally.

Do you have any tips on how to debug trigger execution?

[mantas]

I’d try to disable them all and see if that helps. If it helps, then start enabling them in batches, finally narrowing down on the offending ones.

Obviously it may not work on production system. Cloning the system and running this on an isolated test box is a good idea

[wagner.loch]

@mantas, we ran some tests and confirmed that the issue was indeed related to the triggers.

We managed to reproduce the problem in a staging environment — with all triggers disabled, the ticket creation performance was excellent!

In the production environment, we’ve already fine-tuned several triggers, and the performance has improved significantly.

I had no idea that triggers could have such a big impact on ticket creation via the API.

Thank you very much for your help!