Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this presentation? Why not share!

Presentation

on

  • 1,137 views

 

Statistics

Views

Total Views
1,137
Views on SlideShare
1,137
Embed Views
0

Actions

Likes
0
Downloads
3
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 지금부터 석사 논문 발표를 시작하겠습니다 . 제목을 디자인 ~ 입니다 . 발표자는 조양환 입니당 .
  • 발표할 내용을 간략히 말씀 드리겠습니다 . 웹 서버가 처리할 수 있는 용량을 넘어서는 요청을 들어왔을 때 성능이 감소하는 단점이 있습니다 . 이같은 문제를 해결하기 위해 본 논문에서는 웹 서버 디렉터를 제안하였습니다 . 여기서는 이 웹 서버 디렉터의 설계와 구현에 대해 말씀드리고 성능을 평가해 보도록 하겠습니다 .
  • 웹 서버는 동시 연결 숫자가 증가하게 되면 다음 그림과 같은 성능 곡선을 가지게 됩니다 . 여기서 가로축은 웹 서버에 연결되는 클라이언트의 숫자입니다 . 세로축의 경우 빨간색은 쓰루풋 , 녹색의 경우는 레이턴시입니다 . 그림에서 보는 것처럼 클라이언트가 증가되면 , 쓰루풋은 떨어지고 , 레이턴시는 급격히 증가하게 됩니다 . 이 문제는 다음의 분석을 보면 문제가 더 심각한데 ,
  • 다음의 분석된 그래프처럼 , 웹 서버의 씨피유 작업은 계속 증가되지만 , 성공적으로 처리되는 웹 서버 오퍼레이션은 계속적으로 떨어지고 있습니다 . 또한 , 초당 처리량이 일정하지 못하고 변화량도 증가하게 됩니다 . 결과적으로 과부하 때의 웹 서버는 자체 성능을 최대로 발휘하지 못한다는 것입니다 .
  • 그럼 이 같은 성능감소의 원인은 무엇인지 분석해 보면 두가지로 크게 나누워 집니다 . 먼저 운영체제와 프로토콜적인 문제를 살펴보면 성능에 직접적으로 영향을 미치지 않는 씬 상태나 타임 웨잇 상태의 소켓이 증가 때문입니다 . 또한 웹 서버는 단일 포트를 리스닝 포트로 사용하므로 아이오 멀티플렉싱이 필요한데 , 이 기능의 스켈러빌러티 문제때문입니다 . 이 멀티 플렉싱의 문제에 대해 좀더 살펴보면
  • 셀렉트는 입출력을 기다리는 파일 디스크립터중에서 준비된 셋을 찾아내는 시스템 콜입니다 . 여기서 입출력 멀티플렉싱의 스켈러빌러티의 문제는 커널 상에서 읽기나 , 쓰기가 준비된 파일 디스크립터를 찾아낼때 리니어서치를 하기 때문입니다 . 이런 경우 파일 디스크립터가 적을때는 문제가 되지 않지만 수천개까지 파일이 열려지는 웹 서버의 경우 서치 타임이 급격히 증가하게 됩니다 .
  • 웹 서버의 컨커런시를 높이는데 두번째 문제 웹 서버의 아키텍처의 모델의 문제입니다 . 아파치 같은 웹 서버의 경우 컨커런시를 높이기 위해 멀티 프로세스 모델을 사용하는데 , 멜티프로세스 모델의 경우 필연적으로 각 연결마다 프로세스 포크를 해야 하고 포크된 프로세스는 메모리 자원을 사용하게 됩니다 . 또한 수백개의 프로세스가 떠 있을 경우 프로세스들 사이를 콘텍스트 스위치은 많은 상당히 비용이 큰 작업입니다 . 또한 웹 서버의 경우 리슨 포트가 동일하므로 그것을 공유하여 사용하므로 이것을 락 언락하는 과정에서 스케쥴링하는데 많은 시간을 소비하게 됩니다 . 이 싱크로나이제이션 문제를 아파치 서버에 한정하여 더 깊게 살펴보면
  • 싱크로나이제이션 문제를 더 자세히 설명하면 다음과 같습니다 . 아파치 웹 서버의 경우 각 웍킹 차일드는 크게 네가지 상태로 변화되면서 서비스를 하게 됩니다 . 1,2,3,4 서버 레디는 보통 포크된 차일드가 보통 이 상태입니다 . 이 과정에서 스케쥴링이 되면 락 과정을 거쳐 리슨 포트에서 연결을 어셉트하게 되고 다시 락을 풀고 비지 리드 상태가 됩니다 . 이 과정에서는 클라이언트로 부터 온 요청을 읽고 , 비지 라이트로 바뀌어 클라이언트로 응답을 보내게 됩니다 . 문제는 이 세이프 어셉트 상태인데 , 이 과정이 모든 워킹 차일드들이 공유하여 실행되는 부분이므로 이 과정을 처리할때 운영체제는 상당한 비용이 들게 됩니다 . 콘커런시를 높이기 위한 제한점으로 지적된 두가지 큰 문제를 해결하기 위해 연구자들은 다음과 같은 방식을 제안하였습니다 . semaphore, flock, uconfig newulock
  • 오버로드 상황에 좀더 로버스트한 웹 서버를 만들기 위해 가장 이상적은 모델로 싱글쓰레드 프로세스 모델로 , 이벤트 드리븐 방식으로 논블로킹 아이오를 사용하는 것입니다 . 이 모델은 많은 논문에서 가장 이상적인 네트웍 서버 모델로 검증되었습니다 . 그러나 이런 이상적인 모델을 사용하기에는 다양한 측면에서 한계를 가지고 있습니다 . 실재적으로 디스크 오퍼레이션은 아직까지 블로킹이고 , 이벤트 드리븐 방식의 웹 서버를 구현하기는 상당히 어렵습니다 . 또한 계속 증가하고 있는 복잡한 방식의 요청 , 데이터 베이스와 관련되거나 , 서버사이드 스크립트 , 씨지아이로 요청을 만들어내는 등 . 이런 복잡한 요청들을 모두 처리하면서 이런 복잡한 방식의 웹 서버에 는 적용하기가 힘들어집니다 . 이런 제한점들을 해결하기 위해 본 논문에서는 새로운 방식의 웹 서버 디렉터를 제안하였습니다 .
  • 웹 서버의 경우 블로킹 아이오와 넌 블로킹 아이오로 혼재되어 있고 , 또한 웹 서비스를 할 뿐만 아니라 연결을 관리까지 하게 됩니다 . 이런 과정에서 운영체제내의 프로토콜을 처리하는 비용까지 떠맡게 됩니다 . 여기서 웹 서버 디렉터는 빠른 속도를 낼 수 있는 부분과 , 웹 서비스 이외의 입출력에 관계된 비용을 좀더 특화된 머신으로서 담당하는 것입니다 . 이렇게 한다면 웹 서버는 웹 서비스에 맡도록 특화시킬 수 있어 좀더 양질의 서비스를 할 수 있게 됩니다 . 이런 아이디어를 실현하기 위해 웹 서버 디렉터는 단일 프로세스에 이벤트 드리븐 방식의 논블라킹 아이오로 구현하여 과부하때에도 좀더 로버스트하게 하였습니다 . Network elements are no longer layer 3 processors For performance, security, and service differentiation reasons there is increasing need to inspect higher layer information
  • 웹서버가 최상의 성능을 낼 수 있도록 하기 위해 웹 서버 디렉터는 연결 관리를 하게 됩니다 . 갑자기 증가한 요청일 겨우 펜딩하는 방식으로 일정하게 유지시키고 , 잘못되고 , 과부하되어 웹 서버가 처리하지 못할 경우에는 리젝트하여 서버 비지 페이지를 응답하게 됩니다 .
  • 그렇다면 연결관리를 하기 위해 과부하 상태를 어떻게 알아내는지 알아보겠습니다 . 앞에서의 일반 아파치 서버의 분석을 통해 다음과 같은 관계를 도출할 수 있습니다 . 오버로드 상태인경우 일정 씨피유 로드 이상에서 씬 상태의 소켓이 증가하게 됩니다 . 최고 성능을 내는 때의 약 두배의 커넥션 숫자인 것을 알 수 있습니다 . 또한 100% 씨피유 로드일 경우 최고 성능을 내는 경우의 동시 커넥션 숫자가 겨우 25% 이상입니다 . 이것을 기반으로 커넥션 콘트롤 방법을 알아보면 다음과 같습니다 .
  • 이런 커넥션을 관리하는 방식은 웹 서버의 상태를 모니터링 하여 웹 서버가 최상의 성능을 내도록 도와주게 됩니다 . 정상적으로 백퍼센트 연결을 받아들이는 상태에서 웹 서버의 프로토콜 상태의 씬 상태가 증가하게 되면 연결을 50% 까지 줄이게 됩니다 . 이렇게 줄어든 연결 비율은 씬 상태가 감소추세가 되면 75% 리커버리과정으로 변하고 , 다시 씨피유 로드가 줄어들면 90% 를 거쳐 정상적인 서비스 상태로 떨어지게 됩니다 . 또한 갑자기 씨퓨유로드가 증가하면 일시적으로 75% 까지 연결비율을 낮추어서 웹 서버가 과부하 상태로 빠지는 것을 막게 됩니다 .
  • 이런 작용을 하는 웹 서버 디렉터의 내부 이벤트는 크게 4 가지입니다 . 첫번째로 프롬클라이언트 , 이것은 클라이언트로 부터 웹 서비스 요청을 읽어들이는 과정입니다 . 다음으로 투리얼서버 , 이것은 웹 서버 상태를 점검하고 정상적일 경우 커넥션 풀에서 사용하지 않는 연결을 사용하여 클라이언트로부터 온 요청을 웹 서버로 전달하는 이벤트 입니다 . 다음으로 프롬리얼서버는 웹 서버에서 오는 응답을 받는 과정이고 , 그 과정을 거쳐 투클라이언트 클라이언트에게 요청을 전달하게 됩니다 . 이 기본적인 과정에서 투리얼서버는 웹 요청 헤더를 웹 서버의 서비스 가능 리스트나 , 서비스 정책등을 설정하여 그것을 바탕으로 정확성을 테스트하게 됩니다 . 이것은 악의적인 요청이나 , 잘못된 요청으로 인한 웹 서버의 성능 저하를 막을 수 있게 됩니다 . 각 연결들은 커넥션 오브젝트라는 데이터 구조로서 관리되며 각 이벤트 별로 상태를 바꾸며 서비스를 진행하게 됩니다 .
  • 간략히 정리를 하면 연결 관리에 최적화되고 특화된 웹 서버 디렉터는 아파치 웹 서버를 과부하때 좀 더 로버스트할수 있도록 했습니다 . 기본적인 기능으로서 웹 서버로 분시시켜 , 웹 서버와 관계없이 연결을 관리할 수 있으며 장기적으로는 클러스터로 확장이 가능하다는 장점을 가지게 됩니다 . 또한 펜딩이나 , 리젝트를 통해 웹 서버가 최상의 성능을 내도록 연결관리를 하고 . 과부하때 로버스한 구조로서 싱글 프로세스 , 이벤트 드리븐 , 논 블라킹 아이오를 사용합니다 . 이렇게 구현된 웹 서버 디렉터를 시험하고 성능의 검증을 위해 다음과 같은 벤치마크 환경을 사용하였습니다 .
  • SPECweb 99 file_set : class0: 35% class1: 50% class2 : 14% class3 : 1% SPECweb, webstone are based on a process-based concurrency model and utilize multiple machines to simulate heavy loads.
  • 다음으로 웹 서버 디렉터가 웹 서버가 성능 향상을 이룰 수 있도록 하기 위해 어떤 오버헤드들을 흡수 했는지 알아보았습니다 . 크게 프로토콜의 상태에 대해 모니터링 했으며 유저 영역의 씨피유 사용 시간과 커널 영역의 씨피유 사용시간에 대해 비교해 보았습니다 .
  • 많은 연구자들이 밝힌데로 타임 웨잇 상태의 소켓은 웹 서버의 성능에 큰 영향을 줍니다 .
  • 유주 영역의 씨피유 타임의 경우 약 2 배가 넘는 오버헤드 감소를 얻을 수 있습니다 .
  • 커널 영역의 씨피유 사용시간도 절반으로 줄어들었습니다 . 이것의 대부분은 성능에 영향을 주지 않는 소켓들을 웹 서버 디렉터가 흡수하고 또한 리슨 포트에 대한 락 / 언락 오버헤드를 상당량 감소시켰기 때문입니다 .
  • 지금까지 , 웹 서버 디렉터가 웹 서버가 성능 향상을 이룰수도록 하기 위해 어떤 오버헤드들을 흡수 했는지 알아보았습니다 . 결과적으로 웹 서버의 성능을 저하시키는 웹 서버의 단점들을 웹 서버 디렉터가 흡수하여 웹 서버 성능향상을 도운 것을 알 수 있습니다 .
  • 다음으로 , 아키텍쳐적인 문제는 어떻게 해결했는지 보기 위해 아파치 웹 서버와 그냥 사용했을때와 웹 서버 디렉터를 사용했을때 아파치 웹 서버의 실행 영역에 대해 알아보겠습니다 . 아파치는 빨간색 , 웹 서버 디렉터를 사용했을 경우 커넥션 풀의 사용으로 파란색 영역만 실행되므로 싱크로나이제이션이나 , 스케쥴링 , 문제에서 벗어날 수 있으며 아파치를 사용했을때보다 더 적은 수의 프로세스만 띄워지게 됩니다 . 이것은 간접적으로 콘텍스트 스위칭 횟수로 확인할 수 있습니다 . semaphore, flock, uconfig newulock
  • 웹 서버 디렉터를 사용한 경우 큰 비용없이 콘텍스트 스위칭 되므로 리퀘스트가 많아져도 스위칭 횟수가 증가하지만 아파치의 경우 싱크로나이제이션 뿐만 아니라 , 각 워킹 프로세스를 스케쥴링 해주는데 많은 비용을 사용하므로 스위칭 횟수의 증가 비율이 떨어지는 것을 볼 수 있습니다 . 이것은 결과적으로 성능 감소 요인으로 나타났습니다 . 이렇게 웹 서버 디렉터는 기존 아파치 웹 서버의 운영체제의 오버헤드와 아파치 웹 서버의 단점을 보완할 수 있었고 , 스펙 웹 벤치마크를 통해 실험 결과로 확인하였습니다 .
  • 결과적으로 웹 서버 디렉터는 웹 서버의 단점을 보완할 수 있도록 연결 관리나 입출력에 최적화되고 특화된 서버이고 , 성능 감소를 막고 , 잘못된 요청을 막음으로서 웹 서버의 최적의 성능을 유지할 수 있습니다 . 또한 웹 서버와 분리된 단을 서버로서 추후 클러스터로 확장할 수 있는 장점을 가지고 있습니다 . 웹 서버와는 분리된 머신으로서 추후 클러스터로 확장시킬 수 있는 장점을 가지고 있습니다 . 한마디 : Full feature 인 apache 를 간단한 구조로서 Overload 에 robust 한 고성능의 웹 서버로 바꾸었으며 , separated 된 머신으로 구현하여 cluster 로서 확장할 수 있는 장점을 가지고 있다 . why? 많은 기능을 가지고 , 안정된 서비스를 하는 아파치를 좀더 잘 사용하기 위해서 . multi-processes model 이 나쁜 것만은 아니다 . 안정되고 다양한 서비스가 가능하며 . 프로그래밍 구조가 간단하다 .
  • 추후 연구 과제로서 웹 서버 디렉터의 입출력을 시그아이오로 바꿔서 더 좋은 성능을 낼 수 있는 시그날 드리븐 구조를 채택 해야 합니다 . 또한 유저레벨 버퍼 카피를 줄이기 위해 티씨피 퍼워딩 기법으로 쓰이는 스플라이스 메소드를 사용하여 더 좋은 쓰루풋과 향상된 레이턴시얻을 수 있습니다 . 또한 분리된 머신으로서의 특징을 강화하기 위해 웹 서버 클러스터로의 확장이 필요합니다 . sigio /dev/poll real time,
  • blocking non-blocking I/O multiplexing Asynchronous I/O
  • Concurrency 를 높이기 위한 노력은 크게 , 운영체제와 웹 서버를 바꿈으로서 해결 . 그러나 , 복잡해져 가는 웹 요청을 처리하는데는 문제가 많다 . Apache : 많은 기능 , 새로운 기능 추가가 쉽다 . module API 공개 phhttpd features a very slim I/O core. It does all its networking work using non-blocking system calls driven by whatever event model is most appropriate for the host operating system. This allows a single execution context to handle as many client connections as the event model dictates. phhttpd's job is to serve static content as quickly as it possibly can. To do this it maintains a cache of content in memory. When a request is serviced, phhttpd saves a reference to the on disk content and whatever HTTP headers are dependent on the content. Next time a request for this content is received, phhttpd can service it very quickly. This cache can be prepopulated-populated at run time, or can be built dynamically as requests come in. Its size may also be capped by the administrator so that it doesn't overwhelm a system.

Presentation Presentation Presentation Transcript

  • Design of a Web Server Director to Prevent Performance Degradation 2000.12.20 조양환
  • Contents
    • Introduction
    • Web Server Problem Under Overload
    • Previous Work
    • Web Server Director Solution
    • Benchmark Environment
    • Benchmark
    • Conclusion
    • Further Work
  • Introduction : Web Server Problem
    • Apache Web Server : Performance Degradation Under Overloaded
      • decrease throughput
      • increase latency
    Web Server Apache 1.3.12 Linux 2.2.14 Pentium III 450 128M Clients SEPCWeb 99 # of clients: 7 client spec : Pentium III 450 128M Linux 2.2.14
  • Web Server Problem
    • Overloaded Web Server
    • CPU Load
    • Access/sec
    • Increase Web Server CPU Load
    • But performance degradation (throughput op/sec )
    • Web access log(hits/sec)
    • Throughput is not stable
  • Web Server Problem 1
    • Limitation to achieve High Concurrency
      • Protocol and OS
        • SYN Flood
        • TIME_WAIT
        • I/O multiplexing Scalability
  • I/O Multiplexing Scalability
    • Unix system call used to multiplex between a bunch of file descriptors
    • select() system call is not scalable
    • Linear search in FD set
  • Apache Web Server Problem 2
    • Limitation to achieve High Concurrency
      • Apache Web Server Architecture
        • Overhead to support multi-processes/threads model
          • process fork
          • waste stack and kernel table memory
          • context switching overhead
          • synchronizing overhead
          • scheduling
  • Multi-process Model Problem
    • Apache Web Server
    • Many working child processes under overload
    • Process synchronization problem
    • SAFE_ACCEPT state
      • Mutual exclusive I/O zone
      • Scheduling when connection is established
      • Lock/unlock overhead
    listen socket accept_mutex_on() ap_select() find_ready_listener(): obtain sd csd = ap_accpet(sd) accpet_mutex_off() current_conn = new_connection() r=ap_read_request(current_conn) ap_process_request(r) SERVER_READY SAFE_ACCEPT BUSY_READ BUSY_WRITE
  • Previous Work
    • Robust Web Server for Overload [Flash, JAWS ]
      • High Throughput and Concurrency
      • Low Latency
      • Single-Thread/Process
      • Event-Driven Process
      • Non-Blocking I/O
    • Limitation
      • In practice, disk read is still blocking
      • Event-Driven Web Server is complex software architecture
      • Complex web requests are introduced for enhanced service(occur process block)
        • Data Base Request
        • Server Side Script
        • CGI
  • Web Server Director Solution
    • Separate Overheads (Connection Management and TCP overhead) from Web Server
      • Specialized server undertake overhead
    • Web Server Director
      • Single Process
      • Event-Driven Model
      • Non-Blocking I/O
    • Robust for Overload Requests
    Non-Blocking I/O Connection Management TCP Overhead Blocking I/O Web Service Web Server Director Apache Web Server
  • WSD Connection Management
    • Appropriate number of connections to keep Web Server peak performance
    • Guard against Bursty Requests and Wrong Requests
    • Pend or Reject Web connection when overloaded
      • Response Server Busy Page On Web Server Director
  • Overload Detection
    • Throughput
    • CPU load
    • SYN
    SYN state increase CPU Load 100% down to 80% CPU Load Normal Service recovery
  • WSD: Connection Control
    • Connection Control
    • Connection Acceptance Rate
      • 50% : Overload
      • 75% : Recovery
      • 90% : Healthy
    50% Acceptance 75% Acceptance 90% Acceptance Normal Service State 100% Acceptance SYN state increase decrease SYN state CPU Load 100% increase EST state decrease CPU Load down to 80% CPU Load
  • WSD: Internal
    • Single Process Event
    • toRealServer
    • Verify Web Request Header
      • Server URL list
      • Service ability
    • Control number of Connections by Web Server Status
      • Pending
      • Rejection
  • Summary of WSD
    • Motivation
      • Specialized and optimized machine for Connection Management
      • Complement Apache Web server with robustness for overloaded requests
    • Feature
      • Separated Machine from Web Server
        • Specialized and optimized connection management
        • Expand to cluster
      • Connection Control
        • Pend / Reject
      • Connection Pool
        • Avoid worse latency
      • Robust Architecture
        • Single Process
        • Event Driven
        • Non-Blocking I/O
  • Benchmark Environment
    • Web Server Director
    • Real Service Web Server
      • Multi-processes Model
      • Apache 1.3.12 on Linux 2.2.14 128M Pentium III 450
    • Clients
      • Web Request Clients : SPECweb 99 clients
  • Benchmark: throughput
    • SPEC Web 99 result
    • Apache
    • Apache with WSD
    • Operation/sec
    • Improvement by connection pool
    • Robust for overloaded requests
  • Benchmark: latency
    • SPEC Web 99 result
    • Apache
    • Apache with WSD
    • Response time(msec)
    • Redundant connection (WSD to Web Server)
    • Improve latency
  • Solution of OS Problems
    • Increase needless states under overload condition
      • SYN
      • TIME_WAIT
      • ESTABLISHED over server capacity
    • Increase CPU load
      • User time
      • System time
  • Experiment: TCP State 1
    • Apache
    • Apache with WSD
    • SYN state
    • The principle factor of Overload
  • Experiment: TCP State 2
    • Apache
    • Apache with WSD
    • ESTABLISHED
  • Experiment: TCP State 3
    • Apache
    • Apache with WSD
    • TIME_WAIT
    • Waste Kernel TCP control block
    • Timer interrupt
  • Experiment: CPU Load
    • Apache
    • Apache with WSD
    • CPU load
  • Experiment: User Time
    • Apache
    • Apache with WSD
    • User time
  • Experiment: System Time
    • Apache
    • Apache with WSD
    • System Time
    • The rate of increase is about two times than WSD
  • Solution of OS Problems
    • Increase needless states under overload condition
      • SYN
      • TIME_WAIT
      • ESTABLISHED over server capacity
    • Increase CPU load
      • User time
      • System time
    • Result
    • WSD undertake Apache Web Server drawbacks
  • Solution of Architecture Problem
    • Multi-process model
    • The benefit of Connection Pool
    • Avoid synchronization overhead
    listen socket accept_mutex_on() ap_select() find_ready_listener(): obtain sd csd = ap_accpet(sd) accpet_mutex_off() current_conn = new_connection() r=ap_read_request(current_conn) ap_process_request(r) SERVER_READY SAFE_ACCEPT BUSY_READ BUSY_WRITE Apache Apache with WSD
  • Experiment: Context Switching
    • Apache
    • Apache with WSD
    • Scheduling cost
    • Working child process
    • Lock/unlock overhead
    • Increase scheduler time
  • Conclusion
    • WSD is the Specialized and Optimized Server to complement Web Server’s drawbacks
    • Prevent performance degradation and Defend malicious requests
    • Keep peak performance of Web Server
    • Separated machine
      • Expand to cluster
  • Further Works
    • SIGIO
      • Modify WSD with Signal Driven Architecture for better performance
    • TCP forwarding
      • Splice Method for low latency, high throughput
    • Expand WSD to Web Server Cluster or Farm
  • Concurrency Strategies
    • Synchronous Event Dispatching
    • Asynchronous Event Dispatching
    read() write() http protocol process accept() NET Completion Port http protocol process http protocol process http protocol process http protocol process http protocol process read() write() read() read() write() write() accept() Event http protocol process http protocol process http protocol process ready FD set wake up one occur ready event select() I/O System Buffer
  • Previous Work 2
    • Accelerator or Web Server Helper
    • phhttpd
      • Signal Driven (Real Time Method, /dev/poll)
      • A very slim I/O core
      • Operate with normal web server(use TUNNEL IPC)
      • Use sendfile() system call
      • Static-content caching front end for full-service web servers
    • thttpd
      • Static contents or minimum http 1.1 spec
      • Redirect to full-service web servers
    • khttpd
      • Use kernel threads
      • Kernel module
    • Limit
      • Service for only non-blocking I/O request
        • Static html, in memory contents
      • Performance degradation when overloaded
        • Only operate with normal web server on same machine
  • Previous Work 3
    • SYN Flood
      • Random drop in backlog queue
      • SYN cookie
      • Firewall
    • TIME_WAIT
      • Decrease time
      • Close connection on Client
    • Limitation
      • OS specific configuration
      • Client not support
      • Violate TCP protocol standard
  • WSD on the L7 Switch
    • Contents Based Web Server
    • Partitioned Contents
      • Congestion of connections
    • WSD manages L7 switch drawbacks
  • SYN Flood Benchmark Env.
    • Virtual Overload Benchmark
    • Use raw socket
    • Random client IP address
      • SYN
      • 5000 packets/sec
  • SYN Flood Benchmark 1
    • Apache
    • Apache with WSD
    • Under SYN Flood Attack
    • No flood
    • Flood
    120 concurrent connection 317.2 728.1 flood 313.5 566.6 no flood latency(msec) 369.5 161.8 flood 372.4 208.5 no flood throughput(op/sec) WSD Apache client result
  • SYN Flood Benchmark 2
    • Apache Web Server Vs. WSD
    • Under SYN Flood Attack
    • No flood
    • Flood
    Apache : CPU Apache with WSD : CPU
  • Fast Network Servers Paper
    • G. Banga, P. Drushel, Better operating system features for faster network server , SIGMETRICS
    • J. C. Hu, D. C. Schmidt, JAWS: A framework for High-Performance Web Servers
    • V. S.Pai, P. Druschel, Flash: An Efficient and portable Web server , USENIX
  • TCP Control Block
    • SYN state
      • create TCP Control Block
    • SYN-ACK state
      • respond ACK
    • Move Accept Queue