pre_delete and post_delete signals in Django - Performance & Optimization

Performance: pre_delete and post_delete signals

MEDIUM IMPACT

These signals affect the server-side processing time before and after deleting database records, impacting backend response time and user experience.

Performing cleanup tasks when deleting a database record

Django

from django.db.models.signals import pre_delete
from django.dispatch import receiver
import threading

@receiver(pre_delete, sender=MyModel)
def async_cleanup(sender, instance, **kwargs):
    # Run cleanup asynchronously
    threading.Thread(target=lambda: instance.related_set.all().delete()).start()

Runs cleanup asynchronously, so delete request returns quickly without waiting for cleanup to finish.

📈 Performance GainReduces blocking time to near zero, improving backend response speed

Performing cleanup tasks when deleting a database record

Django

from django.db.models.signals import pre_delete
from django.dispatch import receiver
import time

@receiver(pre_delete, sender=MyModel)
def heavy_cleanup(sender, instance, **kwargs):
    # Blocking long-running task
    time.sleep(5)  # Simulate slow operation
    instance.related_set.all().delete()

Blocking or slow operations in pre_delete delay the delete request, increasing server response time and user wait time.

📉 Performance CostBlocks request processing for 5+ seconds, increasing backend latency

Performance Comparison

Pattern	Server Blocking	Database Load	User Wait Time	Verdict
Synchronous heavy work in pre_delete	High (blocks request)	High (multiple deletes)	High (slow response)	[X] Bad
Asynchronous cleanup in pre_delete	Low (non-blocking)	High (same deletes)	Low (fast response)	[OK] Good

Rendering Pipeline

Although these signals run on the server, their execution time affects how fast the server responds to delete requests, indirectly impacting user experience.

→Server Processing

→Database Operations

⚠️ BottleneckBlocking synchronous operations in signal handlers

Optimization Tips

1Avoid long blocking operations in pre_delete and post_delete signals.

2Use asynchronous tasks for heavy cleanup triggered by delete signals.

3Monitor server response times to detect slow signal handlers.

Performance Quiz - 3 Questions

What is the main performance risk of running heavy synchronous code in a pre_delete signal?

A It blocks the delete request, increasing server response time.

B It causes the browser to re-render the page multiple times.

C It increases the size of the JavaScript bundle.

D It causes layout shifts on the client side.

DevTools: Network

How to check: Open DevTools Network tab, perform a delete request, and observe the request duration time.

What to look for: Long server response times indicate blocking operations in signals; faster responses indicate optimized signal handling.

Practice

1. What is the main difference between Django's pre_delete and post_delete signals?

easy

A. pre_delete runs after a record is deleted, post_delete runs before.

B. pre_delete runs before a record is deleted, post_delete runs after.

C. Both signals run at the same time during deletion.

D. pre_delete only works with models, post_delete only with forms.

Solution

1. Step 1: Understand signal timing

   pre_delete is triggered just before a model instance is deleted from the database.

2. Step 2: Understand post_delete timing

   post_delete is triggered immediately after the instance has been deleted.

3. Final Answer:

   pre_delete runs before a record is deleted, post_delete runs after. -> Option B

4. Quick Check:

   Signal timing difference = pre_delete runs before a record is deleted, post_delete runs after. [OK]

Hint: Remember: pre_delete before removal, post_delete after removal [OK]

Common Mistakes:

• Confusing the order of signal execution
• Thinking both signals run simultaneously
• Assuming signals work only with forms

2. Which of the following is the correct way to connect a pre_delete signal to a model named Book?

easy

A. Book.pre_delete.connect(my_handler)

B. post_delete.connect(my_handler, sender=Book)

C. pre_delete.connect(my_handler, sender=Book)

D. connect(pre_delete, my_handler, Book)

Solution

1. Step 1: Recall signal connection syntax

   In Django, signals are connected using signal.connect(handler, sender=Model).

2. Step 2: Apply to pre_delete and Book

   Use pre_delete.connect(my_handler, sender=Book) to connect the handler to the Book model.

3. Final Answer:

   pre_delete.connect(my_handler, sender=Book) -> Option C

4. Quick Check:

   Correct connect syntax = pre_delete.connect(my_handler, sender=Book) [OK]

Hint: Use signal.connect(handler, sender=Model) to connect signals [OK]

Common Mistakes:

• Using post_delete instead of pre_delete
• Trying to call connect on the model itself
• Incorrect argument order in connect

3. Given this code snippet, what will be printed when a Book instance is deleted?

from django.db.models.signals import pre_delete, post_delete
from django.dispatch import receiver

@receiver(pre_delete, sender=Book)
def before_delete(sender, instance, **kwargs):
    print(f"Deleting book: {instance.title} (pre_delete)")

@receiver(post_delete, sender=Book)
def after_delete(sender, instance, **kwargs):
    print(f"Deleted book: {instance.title} (post_delete)")

book = Book(title='Django Basics')
book.delete()

medium

A. Deleting book: Django Basics (pre_delete)
Deleted book: Django Basics (post_delete)

B. Deleted book: Django Basics (post_delete)
Deleting book: Django Basics (pre_delete)

C. Only Deleting book: Django Basics (pre_delete) is printed

D. No output is printed

Solution

1. Step 1: Understand signal order on deletion

   pre_delete runs before the instance is deleted, so its print runs first.

2. Step 2: Understand post_delete runs after deletion

   After deletion, post_delete signal triggers, printing the second message.

3. Final Answer:

   Deleting book: Django Basics (pre_delete) Deleted book: Django Basics (post_delete) -> Option A

4. Quick Check:

   Signal print order = Deleting book: Django Basics (pre_delete) Deleted book: Django Basics (post_delete) [OK]

Hint: pre_delete prints before delete, post_delete prints after [OK]

Common Mistakes:

• Assuming post_delete prints before pre_delete
• Expecting only one signal to run
• Forgetting to call delete() on the instance

4. What is wrong with this code that tries to use pre_delete signal?

from django.db.models.signals import pre_delete

@pre_delete(sender=Author)
def cleanup(sender, instance, **kwargs):
    print('Cleaning up author data')

medium

A. Using @pre_delete decorator is incorrect; should use @receiver instead.

B. Missing import for Author model.

C. Signal handler must return a value.

D. The function name 'cleanup' is reserved and cannot be used.

Solution

1. Step 1: Check signal handler decoration

   Django signals use the @receiver(signal, sender=Model) decorator, not @pre_delete(sender=Model).

2. Step 2: Confirm correct decorator usage

   Replace @pre_delete(sender=Author) with @receiver(pre_delete, sender=Author) to fix the error.

3. Final Answer:

   Using @pre_delete decorator is incorrect; should use @receiver instead. -> Option A

4. Quick Check:

   Use @receiver for signals, not @pre_delete [OK]

Hint: Use @receiver(signal, sender=Model) to decorate signal handlers [OK]

Common Mistakes:

• Using signal name as decorator directly
• Forgetting to import @receiver
• Assuming signal handlers must return values

5. You want to automatically delete all Comment objects related to a Post before the Post itself is deleted. Which signal and approach is best?

hard

A. Use post_delete on Comment to delete the post after comments are removed.

B. Use post_delete on Post to delete related Comment objects after the post is removed.

C. Use pre_delete on Comment to delete the post before comments are removed.

D. Use pre_delete on Post to delete related Comment objects before the post is removed.

Solution

1. Step 1: Understand deletion order requirement

   Comments must be deleted before the post to avoid foreign key errors.

2. Step 2: Choose correct signal and model

   pre_delete on Post allows deleting related comments before the post is removed.

3. Final Answer:

   Use pre_delete on Post to delete related Comment objects before the post is removed. -> Option D

4. Quick Check:

   Delete related objects in pre_delete to avoid FK errors [OK]

Hint: Delete related objects in pre_delete to prevent FK constraint errors [OK]

Common Mistakes:

• Deleting related objects after post deletion causes errors
• Using signals on wrong model
• Trying to delete parent in comment signals