일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- redis
- mysql
- vavr
- Docker
- ann
- Analyzer
- java crawler
- 아이온큐
- KNN
- java
- dbeaver
- 테슬라
- aqqle
- request cache
- Aggregation
- api cache
- JPA
- Elastic
- 양자컴퓨터
- Cache
- aggs
- elasticsearch cache
- file download
- Selenium
- API
- Query
- Elasticsearch
- NORI
- TSLA
- IONQ
- Today
- Total
목록request cache (2)
아빠는 개발자
API 를 만들고 응답시간을 측정해서 최적의 성능을 만들어 보자 일단 제물이 될 index 820만건의 location-index 일단 aqqle 의 shop API 를 응용해서 후다닥 만들어 보자. 복붙해서 이름만 바꾸니까 1분 미만 컷 지금은 bool > filter > term 쿼리로 조회하니 응답속도가 빠르다. 일단 이 상태에서 리소스 사용과 응답속도를 측정해보잣 캐싱이 안되고 있지만 너무 빠르다 일단 지난 캐시 테스트와 같은 구조로 multi_match 쿼리 와 count집계(aggs) 를 두번 추가 전체쿼리 더보기 { "size":100, "query":{ "bool":{ "must":[ { "multi_match":{ "query":"country_code", "fields":[ "CO^1...
검색 결과 리스팅은 Query Cache에, 검색 결과에 대한 집계 는 Request Cache 에 저장 된다 그렇다면 둘다 확인해서 multi_match + aggs 의 결과가 어디에 캐싱된건지 확인 GET /location-index/_stats/query_cache?human { "_shards": { "total": 2, "successful": 2, "failed": 0 }, "_all": { "primaries": { "query_cache": { "memory_size": "0b", "memory_size_in_bytes": 0, "total_count": 0, "hit_count": 0, "miss_count": 0, "cache_size": 0, "cache_count": 0, "evic..