pre_save and post_save signals in Django - Performance & Optimization

Performance: pre_save and post_save signals

MEDIUM IMPACT

These signals affect server-side processing time before and after saving data, impacting backend response time and perceived page load speed.

Running extra logic when saving a model instance

Django

from django.db.models.signals import post_save
from django.dispatch import receiver
from threading import Thread

@receiver(post_save, sender=MyModel)
def async_post_save(sender, instance, **kwargs):
    def background_task():
        expensive_calculation(instance)
    Thread(target=background_task).start()

Moves heavy logic to a background thread after save, so save completes quickly without blocking response.

📈 Performance GainSave operation returns immediately, reducing backend latency and improving user experience

Running extra logic when saving a model instance

Django

from django.db.models.signals import pre_save
from django.dispatch import receiver

@receiver(pre_save, sender=MyModel)
def heavy_pre_save(sender, instance, **kwargs):
    import time
    time.sleep(2)  # Simulate slow processing
    instance.computed_field = expensive_calculation(instance)

The pre_save signal blocks the save operation for 2 seconds, delaying the database write and response time.

📉 Performance CostBlocks backend response for 2 seconds per save, increasing server latency

Performance Comparison

Pattern	Server Processing	Database Delay	Response Time Impact	Verdict
Heavy pre_save blocking logic	High CPU and wait	Delayed until logic finishes	Blocks response by seconds	[X] Bad
Lightweight pre_save logic	Minimal CPU	Minimal delay	Fast response	[OK] Good
Heavy post_save async logic	Runs after save, non-blocking	No delay to save	Fast response	[OK] Good
Heavy post_save blocking logic	High CPU after save	No delay to save	Blocks response	[!] OK but risky

Rendering Pipeline

pre_save and post_save signals run on the server before and after database writes. Slow handlers delay the server response, which delays browser receiving data and rendering updates.

→Server Processing

→Database Write

→Response Time

⚠️ BottleneckServer Processing time during signal handler execution

Optimization Tips

1Avoid heavy or blocking logic in pre_save signals to keep saves fast.

2Use asynchronous processing for expensive tasks triggered by post_save signals.

3Monitor server response times to detect slow signal handlers affecting backend performance.

Performance Quiz - 3 Questions

What is the main performance risk of running heavy logic in a pre_save signal?

A It causes layout shifts in the browser.

B It increases client-side JavaScript execution time.

C It blocks the database save and delays server response.

D It reduces CSS selector performance.

DevTools: Network

How to check: Open DevTools, go to Network tab, reload page or trigger save, and check server response time in waterfall.

What to look for: Long server response times indicate slow backend processing, possibly due to blocking signal handlers.

Practice

1. What is the main purpose of the pre_save signal in Django?

easy

A. To run code after a model instance is deleted

B. To run code before a model instance is saved to the database

C. To run code after a model instance is saved to the database

D. To validate form data before submission

Solution

1. Step 1: Understand the timing of pre_save

   The pre_save signal triggers just before saving a model instance to the database.

2. Step 2: Compare with other signals

   post_save runs after saving, and deletion signals run on delete, so they don't match pre_save.

3. Final Answer:

   To run code before a model instance is saved to the database -> Option B

4. Quick Check:

   pre_save = before save [OK]

Hint: Remember: pre_save runs before saving data [OK]

Common Mistakes:

• Confusing pre_save with post_save
• Thinking pre_save runs after saving
• Mixing signals with form validation

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

easy

A. post_save.connect(my_handler, sender=Book)

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

C. Book.post_save.connect(my_handler)

D. connect.post_save(my_handler, Book)

Solution

1. Step 1: Recall the signal connection syntax

   The correct syntax is signal.connect(handler_function, sender=ModelClass).

2. Step 2: Match the syntax to options

   post_save.connect(my_handler, sender=Book) matches this pattern exactly, connecting my_handler to post_save for Book.

3. Final Answer:

   post_save.connect(my_handler, sender=Book) -> Option A

4. Quick Check:

   Signal.connect(handler, sender=Model) = correct [OK]

Hint: Signal.connect(handler, sender=Model) is the pattern [OK]

Common Mistakes:

• Swapping handler and sender arguments
• Trying to call connect on the model
• Using incorrect order of parameters

3. Given this code snippet, what will be printed when a new Author instance is saved?

from django.db.models.signals import pre_save, post_save
from django.dispatch import receiver

@receiver(pre_save, sender=Author)
def before_save(sender, instance, **kwargs):
    print('Before saving:', instance.name)

@receiver(post_save, sender=Author)
def after_save(sender, instance, created, **kwargs):
    if created:
        print('Created:', instance.name)
    else:
        print('Updated:', instance.name)

# Assume instance.name = 'Alice' and this is a new save

medium

A. Updated: Alice

B. Created: Alice
Before saving: Alice

C. Before saving: Alice
Created: Alice

D. Before saving: Alice
Updated: Alice

Solution

1. Step 1: Understand signal order on save

   pre_save runs before saving, so it prints 'Before saving: Alice' first.

2. Step 2: Check post_save behavior for new instance

   post_save runs after saving; since created=True, it prints 'Created: Alice'.

3. Final Answer:

   Before saving: Alice Created: Alice -> Option C

4. Quick Check:

   pre_save then post_save with created=True = Before saving: Alice Created: Alice [OK]

Hint: pre_save prints first, post_save with created=True prints second [OK]

Common Mistakes:

• Assuming post_save runs before pre_save
• Ignoring the created flag in post_save
• Mixing update and create messages

4. You wrote this signal handler but it runs whenever ANY model is saved (not specifically for Product). What is the likely problem?

from django.db.models.signals import post_save
from django.dispatch import receiver

@receiver(post_save)
def product_saved(sender, instance, **kwargs):
    print('Product saved:', instance.name)

medium

A. Missing sender argument in @receiver decorator

B. Signal handler must be named post_save_handler

C. post_save signal cannot be used with Product model

D. print statement should be inside a try-except block

Solution

1. Step 1: Check the @receiver decorator usage

   The @receiver(post_save) decorator needs a sender=ModelClass argument to connect specifically to Product.

2. Step 2: Understand why handler runs for all

   Without sender=Product, the handler listens to post_save for all models, causing it to run whenever any model is saved.

3. Final Answer:

   Missing sender argument in @receiver decorator -> Option A

4. Quick Check:

   @receiver(post_save, sender=Model) required [OK]

Hint: Always specify sender=Model in @receiver for signals [OK]

Common Mistakes:

• Omitting sender argument in @receiver
• Assuming handler name matters
• Thinking post_save can't be used with certain models

5. You want to automatically set a model's slug field based on its title before saving, but only if the slug is empty. Which signal and approach is best?

hard

A. Use a form validation method to set slug before saving

B. Use post_save signal to update slug after saving the instance

C. Override the model's save() method and set slug after calling super().save()

D. Use pre_save signal to check if slug is empty and set it from title

Solution

1. Step 1: Identify when to set slug

   The slug should be set before saving to ensure it is stored correctly in the database.

2. Step 2: Choose the right signal

   pre_save runs before saving, allowing modification of fields like slug before the database write.

3. Step 3: Why not post_save or save override

   post_save runs after saving, so changing slug then requires another save. Overriding save() is possible but pre_save keeps logic separate and clean.

4. Final Answer:

   Use pre_save signal to check if slug is empty and set it from title -> Option D

5. Quick Check:

   Set fields before save with pre_save [OK]

Hint: Modify fields before saving with pre_save signal [OK]

Common Mistakes:

• Setting slug after saving causing extra saves
• Overriding save() but setting slug too late
• Using form validation which may not cover all saves