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

occwserv – The occam Web-Server 1/18 occwserv: An occam Web-Server (version 2) Fred Barnes ( frmb2@ukc.ac.uk ) Computing Laboratory, University of Kent, Canterbury, Kent. CT2 7NF

occwserv – 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

occwserv – 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

occwserv – The occam Web-Server 4/18 Design TCP TCP accept cache.control write and processes acceptor TCP TCP fe.farm static.farm cache.hash write read TCP cgi.farm write TCP ogi.farm write be.proc TCP close • New connections originate in the ‘acceptor’ • Requests read inside the ‘fe.farm’ • Responses generated in various places • Connections finish in ‘be.proc’

occwserv – The occam Web-Server 5/18 Front-End Farm fe.farm to cache from acceptor TCP fe.process fe.process read to to cgi’s be.proc to ogi’s • ‘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)

occwserv – The occam Web-Server 6/18 Page Caching from to cache.hash fe.farm static.farm TCP cache.process cache.process write data from cache.control static.farm to be.proc • ‘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

occwserv – The occam Web-Server 7/18 Static Pages static.farm from acceptor TCP get.page get.page write to be.proc to cache • 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

occwserv – The occam Web-Server 8/18 CGI Scripts cgi.farm from acceptor TCP cgi.page cgi.page read/write to be.proc conn. to cache • Follows the design of ‘static.farm’ • The ‘cgi.page’ process executes the spec- ified script, sending output directly to the client

occwserv – The occam Web-Server 9/18 Back-end Processing from to/from cache.hash cache.control to be.proc fe.farm stats.process stats.keeper TCP close • Primarily responsible for closing or recy- cling client connections • Also reports connection statistics to the ‘stats.keeper’ process

occwserv – The occam Web-Server 10/18 The occam Gateway Interface from ogi.farm fe.farm ogi.handler ogi.handler to be.proc to cache dynamically TCP ogimain loaded process 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

occwserv – 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

occwserv – The occam Web-Server 12/18 The occam Adventure out! in? TCP IRC TCP ogimain irc.interface read/write read/write irc.client irc.client event.filter game object object • 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 :-)

occwserv – The occam Web-Server 13/18 A New Adventure HTTP TCP out! in? read/write IRC TCP ogimain irc.interface read/write web.client web.client irc.client irc.client object object • Decentralised state, cleaner design • Channel-ends move around the network

occwserv – The occam Web-Server 14/18 1400 apache occwserv 1200 1000 responses/second 800 600 400 200 0 0 200 400 600 800 1000 1200 1400 1600 attempted requests/second 11000 apache 10000 occwserv 9000 8000 bandwidth (kb/s) 7000 6000 5000 4000 3000 2000 1000 0 0 200 400 600 800 1000 1200 1400 1600 attempted requests/second

occwserv – 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

occwserv – The occam Web-Server 16/18 Improving Performance to modified front−end farm from timed timed.buffer timed.buffer timed.buffer acceptor out TCP n.select.read n.select.read n.select.read read • Each ‘timed.buffer’ process holds a number of connections – inactive connections move left to right – active connections stay put • Reduces the number of blocking calls made • ... or get a faster PC..! :-(

occwserv – 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)

occwserv – 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.. :-)