ahlight
개발 저장소
ahlight
전체 방문자
오늘
어제
  • 분류 전체보기 (197)
    • Java (7)
    • Spring (5)
    • JPA (2)
    • JavaScript (0)
    • Computer Science (12)
      • 디자인패턴, 프로그래밍 패러다임 (1)
      • 네트워크 (4)
      • 운영체제 (4)
      • 데이터베이스 (3)
      • 자료구조 (0)
    • 알고리즘 (1)
    • 프로그래머스 (13)
    • 백준 (94)
    • 서평 (3)
    • 회고 (1)
    • TIL (58)
    • 기타 (1)

블로그 메뉴

  • 홈

공지사항

인기 글

태그

  • 라즈베리파이4 #홈서버 #포트포워딩 #dhcp
  • 넥스트스텝
  • TDD
  • 클린코드
  • Java

최근 댓글

최근 글

티스토리

hELLO · Designed By 정상우.
ahlight

개발 저장소

TIL

TIL - 0602

2023. 6. 3. 18:14

1. 알고리즘

  • SQL 알고리즘
  • CASE WHEN 문법 활용
SELECT ANIMAL_ID, NAME, 
    CASE WHEN 
        (SEX_UPON_INTAKE LIKE 'Intact%')
    THEN 'X' ELSE 'O' 
    END AS 중성화
FROM ANIMAL_INS
ORDER BY ANIMAL_ID ASC;

 

2. 운영체제(공룡책)

*챕터5 - CPU 스케줄링 (CPU Scheduling)

5.6.3 Rate-Monotonic Scheduling(비율 단조 스케줄링)

  • 정적 우선순위 정책을 활요해 주기 태스크들을 스케줄하는 선점형 방식
  • 주기에 따라 우선순위가 정해진다 - 짧을 수록 높은 우선순위, 프로세스가 CPU를 차지한 시간이 각각의 CPU버스트 시간과 같음
  • https://ko.wikipedia.org/wiki/%EB%B9%84%EC%9C%A8_%EB%8B%A8%EC%A1%B0_%EC%8A%A4%EC%BC%80%EC%A4%84%EB%A7%81
 

비율 단조 스케줄링 - 위키백과, 우리 모두의 백과사전

위키백과, 우리 모두의 백과사전. 전산학에서 비율 단조 스케줄링(rate-monotonic scheduling, 줄여서 RMS)은 1973년 리우(Liu)와 래일랜드(Layland)가 제안한 실시간 시스템을 위한 스케줄링 정책이다. 비율

ko.wikipedia.org

  • 프로세스의 수가 증가함에 따라 CPU이용률이 69.xx%에 수렴한다.

 

5.6.4 Earliest-Deadline-First Scheduling(최단 마감 우선 스케줄링)

  • 마감시간에 따라서 우선순위를 동적으로 부여하는 방식
  • 프로세스는 실행 가능해질 때 자신의 마감시간을 스케줄러에게 전달해야 한다.
  • 이론적으로 최적화된 기법이지만 문맥교환 비용 때문에 CPU이용률이 100%가 되긴 어렵다.
  • 또한 현실적으로 마감시간을 예측하기 어렵기 때문에 실제론 RM스케줄링을 주로 사용

5.6.5 Proportionate Share Scheduling(일정 비율의 몫 스케줄링)

  • 모든 응용들에게 T개의 시간 몫을 할당하여 동작
  • 응용이 시간 몫을 할당받는 것을 보장하는 승인 제어 정책과 함께 동작해야한다.

 


3. 후니의 쉽게 쓴 시스코 네트워킹

* Part 8


4. HTTP 웹 기본 지식

Chapter 7 HTTP-header

  • 검증 헤더 - ETag(버전 별 고유한 버전이름), Last-Modified(최종 수정일)
  • 조건부 요청 헤더 - If-Match, If-None-Match(ETag 활용), If-Modified-Since, If-UnModified-Since(Last-Modified 활용)
  • Last-Modified, If-Modified-Since의 한계 - 1초 미만 단위의 캐시 조정이 불가능, 날짜 기반 로직, 서버에서 로직 관리 불가, 같은 데이터 수정시에도 변경이 적용(최종 수정일이 기준이기 때문에)
  • ETag, If-Match - 단순하게 ETag 값만 비교하고, 서버에서 캐시제어 로직을 관리

 

  • 캐시 제어 헤더 - Cache-Control, Pragma, Expires(오른쪽 두개는 Cache-Control의 하위 호환,왼쪽이 우선순위 높음)
  • Cache-Control - max-age(유효시간), no-cache(데이터는 캐시해도 되지만 origin 서버에 검증 후 가능), no-store(민감 정보 저장x)

 

  • 프록시 캐시 - origin서버까지의 거리가 멀 경우 데이터 통신이 오래걸리기 때문에 중간에서 origin서버의 대리역할을 함
  • 서버-클라이언트 간 간접적 접근, 중계 역할 덕분에 트래픽 분산, 보안등의 장점이 존재
  • Cache-Control(public) - 응답이 public 캐시에 저장
  • Cache-Control(private) - 응답이 해당 사용자만을 위한 private 캐시에 저장

 

  • 캐시 무효화
  • cache-control - no-cache, no-store, must-revalidate를 조합해 캐시 무효화 구현
  • must-revalidate의 경우 캐시 만료 후 최초 조회시 origin서버에 무조건 검증해야한다. origin 서버 접근 실패 시 504에러를 반드시 발생시켜야한다.(no-cache의 경우 캐시 서버 설정에 따라 200코드도 가능

 

'TIL' 카테고리의 다른 글

TIL - 0608  (0) 2023.06.08
TIL - 0607  (1) 2023.06.07
TIL - 0531  (0) 2023.06.01
TIL - 0529  (0) 2023.05.29
TIL - 0522  (0) 2023.05.22
    'TIL' 카테고리의 다른 글
    • TIL - 0608
    • TIL - 0607
    • TIL - 0531
    • TIL - 0529
    ahlight
    ahlight

    티스토리툴바