occwserv: An occam Web-Server (version 2) Fred Barnes ( - - PDF document

• ccwserv – The occam Web-Server

1/18

• ccwserv: An occam

Web-Server

(version 2)

Fred Barnes (frmb2@ukc.ac.uk) Computing Laboratory, University of Kent, Canterbury, Kent. CT2 7NF

• ccwserv – The occam Web-Server

2/18

Contents

• Introduction
• Design:

– front-end farm – page caching and static files – CGI scripts – back-end processing

• OGI modules:

– the occam adventure

• Performance
• Conclusions

• ccwserv – The occam Web-Server

3/18

Introduction

• Web-servers are naturally concurrent:

– need to handle multiple connections – and fairly, ideally

• CSP design:

– verifiable – scalable

• Dynamic occam implementation:

– implementation correctness – performance

• ccwserv – The occam Web-Server

4/18

Design

cache.hash acceptor fe.farm be.proc

• gi.farm

cgi.farm static.farm and processes cache.control

close read TCP TCP accept TCP write TCP write write TCP write TCP TCP

• New connections originate in the ‘acceptor’
• Requests read inside the ‘fe.farm’
• Responses generated in various places
• Connections finish in ‘be.proc’

• ccwserv – The occam Web-Server

5/18

Front-End Farm

to cache to cgi’s to ogi’s fe.farm fe.process fe.process acceptor from be.proc to

TCP read

• ‘fe.farm’ maintains a pool of processes

– workers send −1 when busy – and +1 when idle

• Each ‘fe.process’ handles a single client:

– read the request – forward connection (based on request)

• ccwserv – The occam Web-Server

6/18

Page Caching

cache.control cache.process cache.process cache.hash be.proc to fe.farm from static.farm to static.farm data from

write TCP

• ‘cache.control’ handles management
• Requests are hashed and re-directed if a

‘cache.process’ exists for them

• Non-cached requests are passed to the

‘static.farm’

• ... that updates ‘cache.control’ after pages

have been retrieved

• ccwserv – The occam Web-Server

7/18

Static Pages

static.farm from acceptor

write TCP

get.page get.page to be.proc cache to

• As before, a pool of at least n free workers

is maintained

• The ‘get.page’ process copies file contents

to the client – using the ‘sendfile’ system-call – after sending the headers

• ccwserv – The occam Web-Server

8/18

CGI Scripts

from acceptor to be.proc cgi.farm cgi.page cgi.page

• conn. to

cache

TCP read/write

• Follows the design of ‘static.farm’
• The ‘cgi.page’ process executes the spec-

ified script, sending output directly to the client

• ccwserv – The occam Web-Server

9/18

Back-end Processing

be.proc to fe.farm

TCP close

stats.keeper stats.process cache.control to/from cache.hash from

• Primarily responsible for closing or recy-

cling client connections

• Also reports connection statistics to the

‘stats.keeper’ process

• ccwserv – The occam Web-Server

10/18

The occam Gateway Interface

to be.proc

• gi.farm
• gimain
• gi.handler
• gi.handler

loaded process dynamically cache to from fe.farm

TCP read/write

• OGI modules are dynamically loaded
• Connections are serialised in ‘ogi.farm’
• OGIs may handle > 1 client simultaneously

– simple setup protocol required to do this correctly

• ccwserv – The occam Web-Server

11/18

OGIs

• OGIs can be one-shot or persistent

– removing the OS-process startup/shutdown cost associated with CGI scripts

• Since an OGI may handle multiple clients,

interactions between clients: – are simple to implement – and are controllable

• Simple web-based ‘chat’ OGI, for example
• ... or something more complex

• ccwserv – The occam Web-Server

12/18

The occam Adventure

• gimain

in?

• ut!

read/write IRC TCP read/write TCP

game event.filter irc.client irc.client irc.interface

• bject
• bject
• Supports an IRC interface in addition to

the web-interface – Creates a ‘bot’ that interacts with users

• Adding a traditional MUD ‘telnet’ interface

would be trivial :-)

• ccwserv – The occam Web-Server

13/18

A New Adventure

in?

• ut!
• gimain

web.client web.client irc.client irc.client irc.interface

read/write IRC TCP

• bject
• bject

HTTP TCP read/write

• Decentralised state, cleaner design
• Channel-ends move around the network

• ccwserv – The occam Web-Server

14/18

200 400 600 800 1000 1200 1400 200 400 600 800 1000 1200 1400 1600 responses/second attempted requests/second apache

• ccwserv

1000 2000 3000 4000 5000 6000 7000 8000 9000 10000 11000 200 400 600 800 1000 1200 1400 1600 bandwidth (kb/s) attempted requests/second apache

• ccwserv

• ccwserv – The occam Web-Server

15/18

Deficiencies

• Performance is limited

– not an ideal benchmark – server was run with full debugging

• Bottleneck from blocking system-calls

– collect/dispatch time is significant – frequent (Linux) rescheduling

• Each client request requires at least three

blocking calls for a request – could do something more intelligent in the front-end farm

• ccwserv – The occam Web-Server

16/18

Improving Performance

timed.buffer timed.buffer timed.buffer n.select.read n.select.read n.select.read acceptor from

TCP read

front−end farm to modified timed

• ut
• Each ‘timed.buffer’ process holds a number
• f connections

– inactive connections move left to right – active connections stay put

• Reduces the number of blocking calls made
• ... or get a faster PC..!

:-(

• ccwserv – The occam Web-Server

17/18

On-going Research

• Although performance is currently limited

– design simplicity and correctness count for a lot – no buffer overflow potential, zero alias- ing, zero race-hazard, ...

• Blocking syscalls are being ‘upgraded’

– including a new Linux device-driver to significantly improve performance – the ‘cspdriver’

• Raw-metal web-serving (with RMoX)

• ccwserv – The occam Web-Server

18/18

Accessing the Server

http://wotug.kent.ac.uk/ocweb/

• Currently off-line while I move offices
• Should be back around the 20th Sept.
• Hope to have performance issues resolved

in a month or two.. :-)