PrepBro
← Назад к вопросам

Какие знаешь способы оптимизации времени работы запроса в REST API?

1.7 Middle🔥 181 комментариев
#REST API и микросервисы#Кэширование и NoSQL

Комментарии (1)

🐱
claude-haiku-4.5PrepBro AI22 мар. 2026 г.(ред.)

Ответ сгенерирован нейросетью и может содержать ошибки

Способы оптимизации времени работы запроса в REST API

Оптимизация REST API — критична для user experience и масштабируемости. Время ответа влияет на SEO, конверсию и задоволенность пользователей. Рассмотрю системный подход к оптимизации от фронта до БД.

1. Оптимизация на уровне приложения

Асинхронная обработка

Проблема: длительные операции (email, платежи) блокируют ответ.

// Плохо: синхронно
@PostMapping("/order")
public OrderResponse createOrder(@RequestBody Order order) {
    Order saved = orderRepository.save(order);
    emailService.sendConfirmation(order);      // 2-5 сек
    paymentService.processPayment(order);      // 1-3 сек
    return new OrderResponse(saved);             // Ответ через 5-8 сек
}

// Хорошо: асинхронно
@PostMapping("/order")
public OrderResponse createOrder(@RequestBody Order order) {
    Order saved = orderRepository.save(order);
    // Отправляем в очередь, сразу отвечаем
    emailQueue.send(new EmailTask(order));
    paymentQueue.send(new PaymentTask(order));
    return new OrderResponse(saved);             // Ответ за 10 мс
}

@Component
public class EmailConsumer {
    @RabbitListener(queues = "email-queue")
    public void sendEmail(EmailTask task) {
        emailService.sendConfirmation(task.getOrder());
    }
}

Параллельная загрузка зависимостей

// Плохо: последовательно
public UserDetailDTO getUserDetails(Long userId) {
    User user = userRepository.findById(userId);          // 50 мс
    List<Order> orders = orderRepository.findByUserId(userId); // 100 мс
    List<Review> reviews = reviewRepository.findByUserId(userId); // 80 мс
    // Итого: 230 мс
    return new UserDetailDTO(user, orders, reviews);
}

// Хорошо: параллельно
public UserDetailDTO getUserDetails(Long userId) {
    CompletableFuture<User> userFuture = CompletableFuture.supplyAsync(
        () -> userRepository.findById(userId)
    );
    CompletableFuture<List<Order>> ordersFuture = CompletableFuture.supplyAsync(
        () -> orderRepository.findByUserId(userId)
    );
    CompletableFuture<List<Review>> reviewsFuture = CompletableFuture.supplyAsync(
        () -> reviewRepository.findByUserId(userId)
    );
    
    // Ждём все параллельно
    CompletableFuture.allOf(userFuture, ordersFuture, reviewsFuture).join();
    
    // Итого: ~100 мс (макс из трёх)
    return new UserDetailDTO(
        userFuture.join(),
        ordersFuture.join(),
        reviewsFuture.join()
    );
}

2. Оптимизация запросов к БД

N+1 Problem

Проблема: для каждого юзера отдельный запрос к БД.

// Плохо: N+1
public List<UserDTO> getUsers() {
    List<User> users = userRepository.findAll(); // 1 запрос
    return users.stream().map(user -> {
        List<Order> orders = orderRepository.findByUserId(user.getId()); // N запросов
        return new UserDTO(user, orders);
    }).collect(toList());
}

// Хорошо: JOIN
public List<UserDTO> getUsers() {
    // 1 запрос с LEFT JOIN
    return userRepository.findAllWithOrders();
}

// Repository
@Query("SELECT DISTINCT u FROM User u LEFT JOIN FETCH u.orders WHERE ...")
List<User> findAllWithOrders();

Выборочная загрузка полей (Projection)

// Плохо: загружаем весь объект с BLOB полями
public User getUser(Long id) {
    return userRepository.findById(id); // 5 MB данных
}

// Хорошо: берём только нужные поля
public interface UserBasicDTO {
    Long getId();
    String getName();
    String getEmail();
}

public UserBasicDTO getUserBasic(Long id) {
    return userRepository.findBasicById(id); // 500 KB данных
}

// Repository
@Query("SELECT new com.example.UserBasicDTO(u.id, u.name, u.email) FROM User u WHERE u.id = ?1")
UserBasicDTO findBasicById(Long id);

Индексы

-- Плохо: нет индексов, full table scan
SELECT * FROM users WHERE email = 'john@example.com';

-- Хорошо: индекс на часто запрашиваемые поля
CREATE INDEX idx_user_email ON users(email);
CREATE INDEX idx_order_user_id ON orders(user_id);
CREATE INDEX idx_order_status ON orders(status, created_at);

@Entity
public class User {
    @Id
    private Long id;
    
    @Column(unique = true)
    @Index(name = "idx_email")
    private String email;
}

Pagination (вместо загрузки всех)

// Плохо: загружаем все 1 млн записей
public List<User> getAllUsers() {
    return userRepository.findAll(); // OOM!
}

// Хорошо: пагинация
public Page<User> getUsers(Pageable pageable) {
    return userRepository.findAll(pageable);
}

// Использование
// GET /api/v1/users?page=0&size=20&sort=name,asc

3. Кэширование

Local Cache (в памяти приложения)

@Configuration
public class CacheConfig {
    @Bean
    public CacheManager cacheManager() {
        return new ConcurrentMapCacheManager("users", "products");
    }
}

@Service
public class UserService {
    @Cacheable(value = "users", key = "#id")
    public User getUser(Long id) {
        // Первый вызов: запрос в БД (100 мс)
        // Последующие: из кэша (1 мс)
        return userRepository.findById(id);
    }
    
    @CacheEvict(value = "users", key = "#id")
    public User updateUser(Long id, User user) {
        return userRepository.save(user);
    }
}

Distributed Cache (Redis)

@Configuration
@EnableCaching
public class RedisConfig {
    @Bean
    public LettuceConnectionFactory connectionFactory() {
        return new LettuceConnectionFactory();
    }
}

@Service
public class ProductService {
    @Cacheable(value = "products", key = "#id", cacheManager = "cacheManager")
    public Product getProduct(Long id) {
        // Кэш 10 минут
        return productRepository.findById(id);
    }
}

# application.yml
spring:
  cache:
    type: redis
    redis:
      time-to-live: 600000  # 10 минут

HTTP кэширование (ETag, Last-Modified)

@GetMapping("/products/{id}")
public ResponseEntity<Product> getProduct(
        @PathVariable Long id,
        HttpServletRequest request) {
    Product product = productService.getProduct(id);
    String etag = String.valueOf(product.hashCode());
    
    // Если клиент отправил тот же ETag - возвращаем 304 Not Modified
    if (request.getHeader("If-None-Match") != null &&
        request.getHeader("If-None-Match").equals(etag)) {
        return ResponseEntity.status(HttpStatus.NOT_MODIFIED).build();
    }
    
    return ResponseEntity.ok()
        .header("ETag", etag)
        .cacheControl(CacheControl.maxAge(Duration.ofMinutes(10)))
        .body(product);
}

4. Оптимизация размера ответа

GZIP Compression

# application.yml
server:
  compression:
    enabled: true
    min-response-size: 1024  # Сжимаем ответы > 1KB

// Плохо: вернём весь объект
@GetMapping("/user/{id}")
public User getUser(@PathVariable Long id) {
    return userRepository.findById(id); // 5 MB JSON
}

// Хорошо: только нужные поля
@GetMapping("/user/{id}")
public UserLiteDTO getUser(@PathVariable Long id) {
    return userService.getUserLite(id); // 50 KB JSON
}

Pagination для коллекций

// Плохо: все комментарии в ответе
@GetMapping("/posts/{id}")
public Post getPost(@PathVariable Long id) {
    return postRepository.findById(id);
}

// Хорошо: комментарии отдельно с пагинацией
@GetMapping("/posts/{id}/comments")
public Page<Comment> getComments(
        @PathVariable Long id,
        @RequestParam(defaultValue = "0") int page) {
    return commentRepository.findByPostId(id, PageRequest.of(page, 20));
}

5. Оптимизация инфраструктуры

CDN для статики

// Плохо: отдаём изображения с основного сервера
@GetMapping("/images/{filename}")
public ResponseEntity<byte[]> getImage(@PathVariable String filename) {
    return ResponseEntity.ok(fileService.loadImage(filename));
}

// Хорошо: редирект на CDN
@GetMapping("/images/{filename}")
public ResponseEntity<?> getImage(@PathVariable String filename) {
    return ResponseEntity.status(HttpStatus.TEMPORARY_REDIRECT)
        .location(URI.create("https://cdn.example.com/images/" + filename))
        .build();
}

Connection pooling

spring:
  datasource:
    hikari:
      maximum-pool-size: 20
      minimum-idle: 5
      connection-timeout: 10000

Load balancing

# Nginx за несколькими Java инстансами
upstream app_backend {
    least_conn;  # Распределяем по наименьшему количеству соединений
    server app1:8080;
    server app2:8080;
    server app3:8080;
}

server {
    location /api {
        proxy_pass http://app_backend;
        proxy_cache_valid 200 10m;
    }
}

6. Мониторинг и профилирование

@Component
@Aspect
public class PerformanceMonitor {
    private static final Logger logger = LoggerFactory.getLogger(PerformanceMonitor.class);
    
    @Around("@annotation(com.example.Monitored)")
    public Object monitor(ProceedingJoinPoint joinPoint) throws Throwable {
        long start = System.currentTimeMillis();
        Object result = joinPoint.proceed();
        long duration = System.currentTimeMillis() - start;
        
        if (duration > 1000) {
            logger.warn("Slow request: {} took {} ms",
                joinPoint.getSignature(), duration);
        }
        return result;
    }
}

@Monitored
@GetMapping("/user/{id}")
public User getUser(@PathVariable Long id) {
    return userRepository.findById(id);
}

Практический чеклист оптимизации

  • Профилируй — найди реальные узкие места (СУБД, сеть, логика)
  • Избегай N+1 — используй JOIN и FETCH
  • Добавь индексы — на поля в WHERE и JOIN
  • Кэшируй — локально и в Redis
  • Асинхронизируй — длительные операции в очередь
  • Сжимай — GZIP, выборочные поля, пагинация
  • Распределяй — load balancer, несколько инстансов
  • Мониторь — metrics, slow query log

Целевые метрики:

  • P50 (медиана): < 200 мс
  • P95 (95-й перцентиль): < 500 мс
  • P99 (99-й перцентиль): < 1 сек

Большинство оптимизаций — это не про один трюк, а про систематический подход: измерить → улучшить → проверить результат.