diff --git a/project0/index.html b/project0/index.html
index ea1d69b..b8f86a4 100644
--- a/project0/index.html
+++ b/project0/index.html
@@ -250,7 +250,7 @@ <h2 id="questions-to-answer">Questions To Answer</h2>
   <li>Why are there diminishing returns at higher concurrency levels?</li>
   <li>What’s the performance difference when requesting HTTP and HTTPS?</li>
   <li>How can github respond so quickly?</li>
-  <li>What is your site’s “Time to Interactive” according to PageSpeed Insights?</li>
+  <li>What is your site’s “Total Blocking Time” (TBT) according to PageSpeed Insights?</li>
 </ul>
 
 <h2 id="required-tools">Required Tools</h2>
diff --git a/project2/index.html b/project2/index.html
index e0a7dff..fe726a6 100644
--- a/project2/index.html
+++ b/project2/index.html
@@ -212,7 +212,7 @@ <h2 id="overview-video">Overview Video</h2>
 
 <h2 id="project-submission">Project Submission</h2>
 
-<p>&lt;&gt;</p>
+<p><a href="https://forms.gle/RhsrS5CQHR4NY5oV8">https://forms.gle/RhsrS5CQHR4NY5oV8</a></p>
 
 <h2 id="api-specification">API Specification</h2>
 
diff --git a/schedule/index.html b/schedule/index.html
index c7df16d..dbc5780 100644
--- a/schedule/index.html
+++ b/schedule/index.html
@@ -214,8 +214,8 @@ <h2 id="week-2-october-9-11">Week 2 (October 9-11)</h2>
   <h3 id="topics-1">Topics</h3>
 
   <ul>
-    <li>HTTP Servers</li>
-    <li>Application Servers</li>
+    <li>HTTP Servers (<a href="/slides/2023/03_http_servers">slides</a>)</li>
+    <li>Application Servers (<a href="/slides/2023/04_application_servers">slides</a>)</li>
   </ul>
 
   <h3 id="tasks-1">Tasks</h3>
@@ -241,7 +241,6 @@ <h3 id="topics-2">Topics</h3>
   <ul>
     <li>Scaling Web Applications</li>
     <li>Architecting for High Availability</li>
-    <li>Frontend Deep Dive: React</li>
     <li>Read <a href="http://nms.lcs.mit.edu/~kandula/projects/killbots/killbots_files/seda-sosp01.pdf">SEDA: An architecture for well-conditioned, scalable internet services</a> by M Welsh, D Culler, E Brewer</li>
     <li>Read <a href="https://matt-welsh.blogspot.com/2010/07/retrospective-on-seda.html">A Retrospective on SEDA</a></li>
   </ul>
@@ -270,6 +269,7 @@ <h3 id="topics-3">Topics</h3>
       </ul>
     </li>
     <li>Client-side Caching &amp; Content Delivery Networks</li>
+    <li>Frontend Deep Dive: React</li>
     <li>Deep Dive: Ruby on Rails</li>
   </ul>
 
diff --git a/sitemap.xml b/sitemap.xml
index 3d26ed6..fda214a 100644
--- a/sitemap.xml
+++ b/sitemap.xml
@@ -313,6 +313,12 @@
 <loc>https://cs291.com/slides/2023/02_http/</loc>
 </url>
 <url>
+<loc>https://cs291.com/slides/2023/04_application_servers/</loc>
+</url>
+<url>
+<loc>https://cs291.com/slides/2023/03_http_servers/</loc>
+</url>
+<url>
 <loc>https://cs291.com/slides/2023/01_course_introduction/</loc>
 </url>
 <url>
@@ -413,34 +419,34 @@
 </url>
 <url>
 <loc>https://cs291.com/project3/chat/</loc>
-<lastmod>2023-10-03T22:26:36+00:00</lastmod>
+<lastmod>2023-10-11T21:26:51+00:00</lastmod>
 </url>
 <url>
 <loc>https://cs291.com/report_samples/gaucho_book.pdf</loc>
-<lastmod>2023-10-03T22:26:36+00:00</lastmod>
+<lastmod>2023-10-11T21:26:51+00:00</lastmod>
 </url>
 <url>
 <loc>https://cs291.com/report_samples/whatever_chat.pdf</loc>
-<lastmod>2023-10-03T22:26:36+00:00</lastmod>
+<lastmod>2023-10-11T21:26:51+00:00</lastmod>
 </url>
 <url>
 <loc>https://cs291.com/slides/2016/helfand_talk.pdf</loc>
-<lastmod>2023-10-03T22:26:37+00:00</lastmod>
+<lastmod>2023-10-11T21:26:51+00:00</lastmod>
 </url>
 <url>
 <loc>https://cs291.com/slides/2016/maloney_lecture.pdf</loc>
-<lastmod>2023-10-03T22:26:37+00:00</lastmod>
+<lastmod>2023-10-11T21:26:51+00:00</lastmod>
 </url>
 <url>
 <loc>https://cs291.com/slides/2017/maloney_lecture.pdf</loc>
-<lastmod>2023-10-03T22:26:37+00:00</lastmod>
+<lastmod>2023-10-11T21:26:51+00:00</lastmod>
 </url>
 <url>
 <loc>https://cs291.com/slides/2017/mutz_lecture.pdf</loc>
-<lastmod>2023-10-03T22:26:37+00:00</lastmod>
+<lastmod>2023-10-11T21:26:51+00:00</lastmod>
 </url>
 <url>
 <loc>https://cs291.com/slides/2021f/sean_maloney.pdf</loc>
-<lastmod>2023-10-03T22:26:37+00:00</lastmod>
+<lastmod>2023-10-11T21:26:52+00:00</lastmod>
 </url>
 </urlset>
diff --git a/slides/2023/03_http_servers/callback_hell.png b/slides/2023/03_http_servers/callback_hell.png
new file mode 100644
index 0000000..193f73a
Binary files /dev/null and b/slides/2023/03_http_servers/callback_hell.png differ
diff --git a/slides/2023/03_http_servers/index.html b/slides/2023/03_http_servers/index.html
new file mode 100644
index 0000000..95289db
--- /dev/null
+++ b/slides/2023/03_http_servers/index.html
@@ -0,0 +1,679 @@
+<html>
+  <head>
+    <meta charset="utf-8" />
+    <title>HTTP Servers</title>
+    <style>
+      @import url(https://fonts.googleapis.com/css?family=Droid+Serif);
+      @import url(https://fonts.googleapis.com/css?family=Yanone+Kaffeesatz);
+      @import url(https://fonts.googleapis.com/css?family=Ubuntu+Mono:400,700,400italic);
+
+      body { font-family: 'Droid Serif'; }
+      h1, h2, h3 {
+        font-family: 'Yanone Kaffeesatz';
+        font-weight: 400;
+        margin-bottom: 0;
+      }
+      .remark-slide-content h1 { font-size: 2.5em; }
+      .remark-slide-content h2 { font-size: 2em; }
+      .remark-slide-content h3 { font-size: 1.6em; }
+      .footnote {
+        position: absolute;
+        bottom: 3em;
+      }
+      li p { line-height: 1.25em; }
+      .red { color: #fa0000; }
+      .large { font-size: 2em; }
+      a, a > code {
+        color: rgb(249, 38, 114);
+        text-decoration: none;
+      }
+      blockquote {
+        border-left: 0.3em solid rgba(0,0,0,0.5);
+        padding: 0 15px;
+        font-style: italic;
+      }
+      code {
+        background: #e7e8e2;
+        border-radius: 5px;
+      }
+      img {
+        max-height: 100%;
+        max-width: 100%;
+      }
+      .remark-code, .remark-inline-code { font-family: 'Ubuntu Mono'; }
+      .remark-code-line-highlighted     { background-color: #373832; }
+      .clear { clear: both; }
+      #slideshow .slide .content code { font-size: 0.8em; }
+      #slideshow .slide .content pre code {
+        font-size: 0.9em;
+        padding: 15px;
+      }
+      .inverse {
+        background: #272822;
+        color: #777872;
+        text-shadow: 0 0 20px #333;
+      }
+      .inverse h1, .inverse h2 {
+        color: #f3f3f3;
+        line-height: 1em;
+      }
+      .background-blue {
+        background-color: deepskyblue;
+      }
+      .background-green {
+        background-color: springgreen;
+      }
+      .background-pink {
+        background-color: deeppink;
+      }
+
+      /* Two-column layout */
+      .left-column {
+        width: 49%;
+        float: left;
+      }
+      .right-column {
+        width: 49%;
+        float: right;
+      }
+      .left-column20 {
+        width: 20%;
+        float: left;
+      }
+      .right-column80 {
+        width: 79%;
+        float: right;
+      }
+      .left-column30 {
+        width: 30%;
+        float: left;
+      }
+      .right-column70 {
+        width: 69%;
+        float: right;
+      }
+      .left-column40 {
+        width: 40%;
+        float: left;
+      }
+      .right-column60 {
+        width: 59%;
+        float: right;
+      }
+
+      /* Table layout */
+      table {
+        background: #f5f5f5;
+        margin: 30px auto;
+        text-align: left;
+        width: 100%;
+      }
+      th {
+        background: linear-gradient(#777, #444);
+        color: #fff;
+        font-weight: bold;
+        padding: 10px 15px;
+      }
+      td {
+        border-right: 1px solid #fff;
+        border-left: 1px solid #e8e8e8;
+        border-top: 1px solid #fff;
+        border-bottom: 1px solid #e8e8e8;
+        padding: 10px 15px;
+      }
+
+    </style>
+    <link rel="icon" href="data:;base64,iVBORw0KGgo=">
+  </head>
+  <body>
+    <textarea id="source">
+class: center, middle
+
+# HTTP Servers
+
+## CS291A: Scalable Internet Services
+
+---
+
+# End to End HTTP
+
+By now, we all should have a reasonable understanding of the HTTP.
+
+--
+
+Many browsers and clients exist that are able to:
+
+* Open a TCP socket
+
+* Send an HTTP request
+
+* Have the request processed
+
+* Receive the data in a response
+
+* Reuse the socket for multiple requests
+
+--
+
+The software systems that handle the requests are generally divided into two
+parts:
+
+* HTTP Servers (these slides)
+
+* Application Servers (the next set of slides)
+
+---
+
+# HTTP Servers
+
+![Netcraft survey of HTTP servers](netcraft_web_servers_2022_aug.png)
+
+Latest:
+https://news.netcraft.com/archives/2022/08/26/august-2022-web-server-survey.html
+
+---
+
+# HTTP Server Responsibilities
+
+* Parse HTTP requests and craft HTTP responses _very_ fast
+
+* Dispatch to the appropriate handler and return response
+
+* Be stable and secure (lots of string parsing)
+
+* Provide clean abstraction for application servers
+
+>  How do HTTP servers provide concurrency?
+
+---
+
+class: center inverse middle
+# Server Architectures
+
+---
+
+# TCP Server Concurrency Approaches
+
+* Sequential (no concurrency)
+
+* Process per request
+
+* Process pool
+
+* Thread per request
+
+* Process/thread worker pool
+
+* Event-driven
+
+For select examples see:
+[https://gist.github.com/bboe/6a7b03fcd110c4c6bbe5ec412f523428](https://gist.github.com/bboe/6a7b03fcd110c4c6bbe5ec412f523428)
+
+---
+
+# Sequential Servers
+
+```python
+bind() to port 80 and listen()
+loop forever
+    accept() a socket connection
+    while we can read from the socket
+        read() a request
+        process that request
+        write() its response
+    close() the socket connection
+```
+
+--
+
+> What happens if another request comes in while we're within the loop?
+
+---
+
+# Sequential Server Issues
+
+If a sequential HTTP server does not process the request quickly, other clients
+end up waiting or dropping their connections (**head of line blocking**).
+
+We are building complex web applications not simple web sites. As a result:
+
+--
+
+* The requests are usually more complicated than serving a file from disk.
+
+--
+
+* It is common to have a web request doing a significant amount of computation
+  and business logic.
+
+--
+
+* It is common to have a web request result in connections to multiple external
+  services, e.g., databases, and caching stores.
+
+--
+
+* These requests can be anything: lightweight or heavyweight, IO intensive or
+  CPU intensive.
+
+--
+
+We can solve these problems if the thread of control that processes the request
+is separate from the thread that `listen()`s and `accept()`s new connections.
+
+---
+
+# Process per Request Servers
+
+Handle each request as a subprocess:
+
+.left-column40[![forking server](server_forking.png)]
+.right-column60[
+```python
+bind() to port 80 and listen()
+loop forever
+    accept() a socket connection
+*   if fork() == 0  # child process
+        while we can read from the socket
+            read() a request
+            process that request
+            write() its response
+        close() the socket connection
+*       exit()
+```
+]
+
+---
+
+# Process per Request Servers
+
+## Strengths
+
+* Simple
+
+* Provides significant isolation between requests
+
+--
+
+## Weaknesses
+
+* How much memory is required?
+
+* What happens as more parallel requests come in?
+
+* How efficient is it to start a process on each request?
+
+  * How much setup and teardown work is necessary?
+
+---
+
+# Process Pool Servers
+
+.left-column[![process pool server](server_process_pool.png)]
+.right-column[
+Instead of spawning a process for each request, create a pool of N processes at
+start-up and have them handle incoming requests when available.
+
+The children processes `accept()` the incoming connections and use shared
+memory to coordinate.
+
+The parent process watches the load on its children and can adjust the pool
+size as needed.
+]
+
+---
+
+# Process Pool Servers
+
+## Strengths
+
+* Provides isolation between concurrent requests
+
+* Children can die after _M_ requests to minimize memory leakage issues
+
+* Process setup and teardown costs are minimized
+
+* More predictable behavior under high load
+
+--
+
+## Weaknesses
+
+* More complex than process per request
+
+* Many processes can still mean a large amount of memory consumption
+
+This HTTP server architecture is provided by the Apache 2.x MPM "Prefork" module.
+
+---
+
+# Thread per Request Servers
+
+Why use multiple processes at all? Instead we can use a single process and
+spawn new threads for each request.
+
+.left-column40[![http server thread per request](server_threaded.png)]
+.right-column60[
+```python
+bind() to port 80 and listen()
+loop forever
+    accept() a socket connection
+*   pthread_create()
+        while we can read from the socket
+            read() a request
+            process that request
+            write() its response
+        close() the socket connection
+        pthread_exit()
+```
+]
+
+---
+
+# Thread per Request Servers
+
+## Strengths
+
+* Relatively simple
+
+* Reduced memory footprint compared to multi-processed
+
+
+--
+
+## Weaknesses
+
+* Worker (request handling code)  must be thread-safe
+
+* Setup and teardown needs to occur for each thread (or shared data
+  needs to be thread-safe)
+
+* What about memory leaks?
+
+---
+
+# Process/Thread Worker Pool Servers
+
+.left-column[![http process/thread worker pool](server_worker_pool.png)]
+.right-column[
+Combination of the two techniques.
+
+Parent process spawns worker processes, each with many threads. Parent maintains
+process pool.
+
+Processes coordinate through shared memory to `accept()` requests.
+
+Fixed threads per request, scaling is done at the process level.
+]
+
+---
+
+# Process/Thread Worker Pool Servers
+
+## Strengths
+
+* Faults isolated between processes, but not threads
+
+* Threads reduce memory footprint
+
+* Tunable level of isolation
+
+* Controlling the number of processes and threads allows for predictable
+  behavior under load
+
+--
+
+## Weaknesses
+
+* Requires thread-safe code
+
+* Uses more memory than an all-thread based approach
+
+This HTTP server architecture is provided by the Apache 2.x MPM "Worker" module.
+
+---
+
+class: center inverse middle
+
+# Digression: C10K Problem
+
+---
+
+# C10K Problem
+
+> Given a 1 GHz machine with 2GB of RAM, and a gigabit Ethernet card, can we
+> support 10,000 simultaneous connections?
+
+--
+
+## 20,000 clients means each client gets:
+
+* 50 KHz of CPU
+
+* 100 KB of RAM
+
+* 50 Kb/second of network
+
+--
+
+> It shouldn't take any more horsepower than that to take four kilobytes from
+> the disk and send them to the network once a second for each of twenty thousand
+> clients.
+
+--
+
+Originally posed in 1999 by Dan Kegel.
+
+Source: [http://www.kegel.com/c10k.html](http://www.kegel.com/c10k.html)
+
+2015: [C10M](https://migratorydata.com/2015/05/20/how-migratorydata-solved-the-c10m-problem-10-million-concurrent-connections-on-a-single-commodity-server/)
+
+---
+
+class: center middle
+
+# What makes managing concurrent connections difficult?
+
+---
+
+# For each client the server is...
+
+* Reading from the network socket
+
+* Parsing its request
+
+* Opening a file on disk
+
+* Reading the file into memory
+
+* Writing the memory to network
+
+---
+
+# For each client the server is... __blocking on I/O__
+
+* Reading from the network socket (__blocking__)
+
+* Parsing its request
+
+* Opening a file on disk  (__blocking__)
+
+* Reading the file into memory  (__blocking__)
+
+* Writing the memory to network  (__blocking__)
+
+---
+
+# Waiting on I/O
+
+Every time a process/thread is waiting on I/O it is not runnable, and it is not
+cost-free:
+
+* Each process/thread is considered every time the scheduler makes a decision
+
+* Memory is occupied by the process, and its last load may have evicted other
+  processes' memory from the cache
+
+Massive concurrency slows down all processes/threads.
+
+---
+
+# How can we not wait on I/O?
+
+Blocking system calls cause this problem.
+
+> Can we accomplish our desired tasks without blocking?
+
+--
+
+## Yes! Using Asynchronous I/O
+
+Use a non-blocking version of I/O system calls in combination with:
+
+* `select()`: Provided a list of file descriptors, block only until at least
+  one is ready for I/O (only usable up to file descriptor number 1023 on Linux).
+
+* `epoll_*()`: (Linux) Register to listen for events on file descriptors. Again
+  block only until at least one of the registered descriptors is ready for I/O
+
+---
+
+# Select example
+
+Assume we have a list of sockets called fd_list.
+
+```python
+loop forever:
+    select(fd_list, ...) // block until something has I/O to handle
+    for fd in fd_list
+        if fd is ready for IO
+            handle_io(fd)
+        else do nothing
+```
+
+--
+
+## handle_io
+
+* can include socket acceptance
+
+* shouldn't make any blocking calls (use non-blocking variants)
+
+* should avoid excessive computation
+    * Use a separate thread, process, or worker pool for such purposes
+
+---
+
+# Event Driven Systems
+
+Systems that operate in such a manner are called event driven systems.
+
+Often such systems can accomplish everything using only a single process and
+thread, of course more may be needed for CPU-bound segments.
+
+Well used examples:
+
+* NGINX
+
+* lighttpd
+
+* netty (java)
+
+* node.js (JavaScript)
+
+* eventmachine (ruby)
+
+* twisted (python)
+
+---
+
+# Event Driven Servers
+
+## Strengths
+
+* High performance under high load
+
+* Predictable performance under high load
+
+* No need to be thread-proof (unless specifically adding thread-concurrency)
+
+--
+
+## Weaknesses
+
+* Poor isolation
+
+    * What happens if a bug causes an infinite loop?
+
+* Extensions are hard to implement since they cannot use blocking syscalls
+
+* Very complex
+
+---
+
+# Event Machine (Ruby) Example
+
+Event driven code is dominated by callbacks:
+
+```ruby
+EM.run {
+  test = EM::HttpRequest.new('http://google.com/').get
+  test.errback { puts "Google is down! terminate?" }
+  test.callback {
+    search = EM::HttpRequest.new('http://google.com/search?q=em').get
+    search.callback { # callback nesting, ad infinitum }
+    search.errback  { # error-handling code }
+  }
+}
+```
+
+---
+
+# Callback Hell
+
+.center[![Yo dawg, I heard you like JavaScript](callback_hell.png)]
+
+With all these callbacks, event-drived programming _can_ very easily become
+complicated.
+
+---
+
+# Server Architectures Review
+
+.left-column[
+* Sequential (single process and thread)
+    * Easy
+    * No concurrency
+
+* Process per request
+    * Greatest isolation
+    * Largest memory footprint
+
+* Thread per request
+    * Less isolation
+    * Smaller memory footprint
+]
+.right-column[
+* Process/thread worker pool
+    * Tunable compromise between processes and threads
+
+* Event-driven
+    * Great performance under high load
+    * Difficult to extend
+    * Reduced isolation
+]
+
+    </textarea>
+    <script src="https://remarkjs.com/downloads/remark-latest.min.js"
+            type="text/javascript"></script>
+    <script type="text/javascript">
+      var hljs = remark.highlighter.engine;
+      var slideshow = remark.create({
+          highlightLanguage: 'ruby',
+          highlightLines: true,
+          hightlightSpans: true,
+          highlightStyle: 'monokai'
+        }) ;
+    </script>
+  </body>
+</html>
diff --git a/slides/2023/03_http_servers/netcraft_web_servers_2022_aug.png b/slides/2023/03_http_servers/netcraft_web_servers_2022_aug.png
new file mode 100644
index 0000000..def3077
Binary files /dev/null and b/slides/2023/03_http_servers/netcraft_web_servers_2022_aug.png differ
diff --git a/slides/2023/03_http_servers/server_forking.png b/slides/2023/03_http_servers/server_forking.png
new file mode 100644
index 0000000..a6eb4a0
Binary files /dev/null and b/slides/2023/03_http_servers/server_forking.png differ
diff --git a/slides/2023/03_http_servers/server_process_pool.png b/slides/2023/03_http_servers/server_process_pool.png
new file mode 100644
index 0000000..4213ede
Binary files /dev/null and b/slides/2023/03_http_servers/server_process_pool.png differ
diff --git a/slides/2023/03_http_servers/server_threaded.png b/slides/2023/03_http_servers/server_threaded.png
new file mode 100644
index 0000000..e80458b
Binary files /dev/null and b/slides/2023/03_http_servers/server_threaded.png differ
diff --git a/slides/2023/03_http_servers/server_worker_pool.png b/slides/2023/03_http_servers/server_worker_pool.png
new file mode 100644
index 0000000..629f477
Binary files /dev/null and b/slides/2023/03_http_servers/server_worker_pool.png differ
diff --git a/slides/2023/04_application_servers/index.html b/slides/2023/04_application_servers/index.html
new file mode 100644
index 0000000..dfdb554
--- /dev/null
+++ b/slides/2023/04_application_servers/index.html
@@ -0,0 +1,240 @@
+<html>
+  <head>
+    <meta charset="utf-8" />
+    <title>Application Servers</title>
+    <style>
+      @import url(https://fonts.googleapis.com/css?family=Droid+Serif);
+      @import url(https://fonts.googleapis.com/css?family=Yanone+Kaffeesatz);
+      @import url(https://fonts.googleapis.com/css?family=Ubuntu+Mono:400,700,400italic);
+
+      body { font-family: 'Droid Serif'; }
+      h1, h2, h3 {
+        font-family: 'Yanone Kaffeesatz';
+        font-weight: 400;
+        margin-bottom: 0;
+      }
+      .remark-slide-content h1 { font-size: 2.5em; }
+      .remark-slide-content h2 { font-size: 2em; }
+      .remark-slide-content h3 { font-size: 1.6em; }
+      .footnote {
+        position: absolute;
+        bottom: 3em;
+      }
+      li p { line-height: 1.25em; }
+      .red { color: #fa0000; }
+      .large { font-size: 2em; }
+      a, a > code {
+        color: rgb(249, 38, 114);
+        text-decoration: none;
+      }
+      blockquote {
+        border-left: 0.3em solid rgba(0,0,0,0.5);
+        padding: 0 15px;
+        font-style: italic;
+      }
+      code {
+        background: #e7e8e2;
+        border-radius: 5px;
+      }
+      img {
+        max-height: 100%;
+        max-width: 100%;
+      }
+      .remark-code, .remark-inline-code { font-family: 'Ubuntu Mono'; }
+      .remark-code-line-highlighted     { background-color: #373832; }
+      .clear { clear: both; }
+      #slideshow .slide .content code { font-size: 0.8em; }
+      #slideshow .slide .content pre code {
+        font-size: 0.9em;
+        padding: 15px;
+      }
+      .inverse {
+        background: #272822;
+        color: #777872;
+        text-shadow: 0 0 20px #333;
+      }
+      .inverse h1, .inverse h2 {
+        color: #f3f3f3;
+        line-height: 1em;
+      }
+      .background-blue {
+        background-color: deepskyblue;
+      }
+      .background-green {
+        background-color: springgreen;
+      }
+      .background-pink {
+        background-color: deeppink;
+      }
+
+      /* Two-column layout */
+      .left-column {
+        width: 49%;
+        float: left;
+      }
+      .right-column {
+        width: 49%;
+        float: right;
+      }
+      .left-column20 {
+        width: 20%;
+        float: left;
+      }
+      .right-column80 {
+        width: 79%;
+        float: right;
+      }
+      .left-column30 {
+        width: 30%;
+        float: left;
+      }
+      .right-column70 {
+        width: 69%;
+        float: right;
+      }
+      .left-column40 {
+        width: 40%;
+        float: left;
+      }
+      .right-column60 {
+        width: 59%;
+        float: right;
+      }
+
+      /* Table layout */
+      table {
+        background: #f5f5f5;
+        margin: 30px auto;
+        text-align: left;
+        width: 100%;
+      }
+      th {
+        background: linear-gradient(#777, #444);
+        color: #fff;
+        font-weight: bold;
+        padding: 10px 15px;
+      }
+      td {
+        border-right: 1px solid #fff;
+        border-left: 1px solid #e8e8e8;
+        border-top: 1px solid #fff;
+        border-bottom: 1px solid #e8e8e8;
+        padding: 10px 15px;
+      }
+
+    </style>
+    <link rel="icon" href="data:;base64,iVBORw0KGgo=">
+  </head>
+  <body>
+    <textarea id="source">
+class: center, middle
+
+# Application Servers
+
+## CS291A: Scalable Internet Services
+
+---
+
+# Separation of Responsibilities
+
+> Why not use a single process to handle both the HTTP request and the
+> application logic?
+
+--
+
+The concerns and design goals of HTTP servers are different from those of
+application servers.
+
+---
+
+# Server Design Goals
+
+## HTTP Server
+
+* Provide a high performance HTTP implementation (handles concurrency)
+
+* Be extremely stable, and relatively static
+
+* Be very configurable and language/framework agnostic
+
+--
+
+## Application Server
+
+* Support a specific language (e.g., Ruby), many of which are not optimized for
+  performance
+
+* Run _business logic_ which is extremely dynamic
+
+---
+
+# Application Servers
+
+We are building web applications, so we will require complex server-side logic.
+
+We _can_ extend our HTTP servers to provide this logic through modules, but
+there are benefits to separating application servers into one ore more distinct
+processes. Because:
+
+--
+
+* Application logic will be dynamic
+
+* Application logic regularly uses high level (slow) languages
+
+* Security concerns are easier (HTTP server can shield app server from
+  malformed requests)
+
+* Setup costs can be amortized if the app server is running continuously
+
+---
+
+# Application Server Architectures
+
+> What architecture should we use for our application server?
+
+--
+
+We have the same trade-offs to consider as with HTTP servers (e.g. threads,
+processes, and/or workers), so we needn't revisit them again.
+
+---
+
+class: center middle
+# How does an HTTP Server communicate with the application server(s)?
+
+---
+
+# Inter-server Communication
+
+
+## [CGI](https://en.wikipedia.org/wiki/Common_Gateway_Interface)
+
+Spawn a process, pass HTTP headers as ENV variables and utilize STDOUT as the
+response.
+
+--
+
+## [FastCGI](https://en.wikipedia.org/wiki/FastCGI), [SCGI](https://en.wikipedia.org/wiki/Simple_Common_Gateway_Interface)
+
+Modifications to CGI to allow for persistent application server processes
+(amortizes setup time).
+
+--
+
+
+
+    </textarea>
+    <script src="https://remarkjs.com/downloads/remark-latest.min.js"
+            type="text/javascript"></script>
+    <script type="text/javascript">
+      var hljs = remark.highlighter.engine;
+      var slideshow = remark.create({
+          highlightLanguage: 'ruby',
+          highlightLines: true,
+          hightlightSpans: true,
+          highlightStyle: 'monokai'
+        }) ;
+    </script>
+  </body>
+</html>