How We Boosted a Classification Tree API 10× Faster with 5 Smart Optimizations

In this article we walk through five successive optimizations—adding Redis caching, scheduling asynchronous jobs, introducing local Caffeine cache, enabling Nginx GZip compression, and slimming Redis data—to dramatically improve the performance of a SpringBoot‑Thymeleaf classification‑tree query, reducing response size from 1 MB to 100 KB and raising QPS from 100 to over 500.

Su San Talks Tech
Su San Talks Tech
Su San Talks Tech
How We Boosted a Classification Tree API 10× Faster with 5 Smart Optimizations

Preface

The classification‑tree query is a common feature in many business systems, especially e‑commerce platforms.

Background

Our site is built with SpringBoot and uses the Thymeleaf template engine for dynamic rendering. The first version fetched the entire category tree directly from the database and returned it to the front‑end.

First Optimization

We introduced Redis caching to store the category tree as a JSON string.

When a client requests the category tree, first check Redis.

If the data exists, return it directly.

If not, query the database, assemble the tree, and return it.

Store the assembled tree in Redis with a 5‑minute expiration.

Return the tree to the client.

Second Optimization

We added a scheduled Job that periodically rebuilds the category tree from the database and updates Redis, while keeping the original on‑demand logic as a fallback.

Third Optimization

To eliminate the Redis bottleneck under high QPS, we introduced a local in‑memory cache using Caffeine.

Check the local cache first.

If present, return the data.

If absent, query Redis.

If Redis returns data, populate the local cache and return.

If Redis is unavailable, fall back to the database, update Redis and the local cache, then return.

Remember to set an expiration time (e.g., 5 minutes) for the local cache to keep data fresh.

Fourth Optimization

When the category tree grew to tens of thousands of entries, we enabled Nginx GZip compression, reducing the response size from about 1 MB to 100 KB.

Fifth Optimization

We slimmed down the JSON stored in Redis by keeping only essential fields and using short property names, then compressed the byte array with GZip before saving.

@AllArgsConstructor
@Data
public class Category {
    private Long id;
    private String name;
    private Long parentId;
    private Date inDate;
    private Long inUserId;
    private String inUserName;
    private List<Category> children;
}
@AllArgsConstructor
@Data
public class Category {
    @JsonProperty("i")
    private Long id;

    @JsonProperty("l")
    private Integer level;

    @JsonProperty("n")
    private String name;

    @JsonProperty("p")
    private Long parentId;

    @JsonProperty("c")
    private List<Category> children;
}

Compressing the JSON with GZip before storing it in Redis reduced the stored size by another tenfold, solving the large‑key issue.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

rediscachingCaffeineNginxSpringBootThymeleaf
Su San Talks Tech
Written by

Su San Talks Tech

Su San, former staff at several leading tech companies, is a top creator on Juejin and a premium creator on CSDN, and runs the free coding practice site www.susan.net.cn.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.