-
Notifications
You must be signed in to change notification settings - Fork 239
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Korean] caching.md #49
Conversation
|
||
## 페이지 레벨 캐싱 | ||
|
||
서버에서 렌더링된 애플리케이션은 외부 데이터를 사용하므로 본질적으로 내용은 동적이어서 오래동안 캐시할 수 없습니다. 그러나 컨텐츠가 사용자별로 다르면(즉, 동일한 URL의 경우 항상 모든 사용자에게 동일한 컨텐츠가 렌더링 됨) [micro-caching](https://www.nginx.com/blog/benefits-of-microcaching-nginx/)이라고 부르는 방식을 활용하여 높은 트래픽을 처리하는 앱의 성능을 대폭 향상시킬 수 있습니다. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
이전에 작성된 문서와 같이 애플리케이션
→ 앱
으로 통일되면 좋을 것 같습니다.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
외부 데이터를 사용하므로 본질적인 내용은 동적이기 때문에 오래동안 캐시할 수 없습니다.
으로 작성되는게 문맥상 자연스러울 것 같은데 어떻게 생각하시나요?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
감사합니다 더 잘어울리는거 같아요
}) | ||
``` | ||
|
||
컨텐츠는 단 1초 동안만 캐시되므로 사용자는 이전 컨텐츠는 보지 못합니다. 그러나 이는 서버가 각 캐시된 페이지에 대해 초당 최대 하나의 렌더링만 수행하면 된다는 것만 의미합니다. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
이전 컨텐츠는
→ 이전 컨텐츠를
렌더링하는 동안 렌더러가 컴포넌트의 캐시에 도달하면 전체 하위 트리에 대해 캐시된 결과를 직접 다시 사용합니다. 다음과 같은 경우에 컴포넌트를 **캐시하지 않아야 합니다.** | ||
|
||
- 전역 상태에 의존하는 하위 컴포넌트를 가지고 있는 경우 | ||
- 렌더링 `context`에 사이드이펙트를 발생시키는 하위 컴포넌트가 있는 경우 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
이전 리뷰에도 언급했었지만 사이드이펙트
를 번역 하는게 좋은지, 안하는게 좋은지는 잘 모르겠습니다
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
애매해서 우선은 사이드이펙트로 두었습니다
- 전역 상태에 의존하는 하위 컴포넌트를 가지고 있는 경우 | ||
- 렌더링 `context`에 사이드이펙트를 발생시키는 하위 컴포넌트가 있는 경우 | ||
|
||
따라서 성능상의 병목을 해결하려면 컴포넌트 캐싱을 신중하게 적용해야합니다. 대부분의 경우 단일 인스턴스 컴포넌트를 캐시하지 않아도 됩니다. 캐싱에 적합한 가장 일반적인 유형의 컴포넌트는 큰`v-for` 목록에서 반복되는 컴포넌트입니다. 이러한 컴포넌트는 대개 데이터베이스 모음의 객체에 의해 구동되기 때문에 고유한 ID와 최종 업데이트된 타임스탬프를 사용하여 캐시키를 생성하는 간단한 캐싱 전략을 사용할 수 있습니다, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
큰'v-for'
→ 큰 'v-for'
사이에 공백이 필요해보입니다.
그리고 큰 'v-for'
이라고 표현하는게 효과적일지는 잘 모르겠습니다. (최상위에서 돌아가는 v-for을 뜻하는건가요?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
양이 많은
의 의미가 있어 "거대한 v-for
리스트" 로 변경했습니다
Check out a review request at GitLocalize 😄