This document summarizes a talk comparing PHP and Rails web development frameworks. It discusses the evolution of web servers from Apache to more scalable options like Nginx. Nginx acts as a reverse proxy, passing requests to application servers like FastCGI that execute code and return responses. This represents a shift from simply serving static files to building full-featured web applications using the MVC pattern. Node.js is presented as the next step, allowing JavaScript to be used for server-side development in an event-driven, non-blocking way.

1. PHP vs
Rails

2. Which originally was called:

3. LAMP
vs
The World

4. and is probably a far more
appropriate title.

5. But first,

6. Some housekeeping

7. Giving not just one talk,
not two, but three talks
in December!

8. Already gave:
Git & Github at Web414
blog.mattgauger.com/git-github-a-beginners-guide

9. Just go to: blog.mattgauger.com

10. MKE Ruby User’s Group:
What’s new & great in Rails 3
Dec 20th 7PM

11. Slides from this talk will be
online at blog.mattgauger.com
tomorrow (probably)

12. Simple agenda for tonight:
Webservers:
where we came from,
where we are now, and
where we’re going

13. All web sites (web apps)
have a need.

14. A need for speed.

15. How do we get there?

16. Let’s start with some basics.

17. HTTP

18. Hypertext Transfer Protocol

19. Request, Response

20. Client, Server

21. A Request or Response is
made of 4 parts:

22. • Request line, such as GET /index.html
• Headers, such as Accept-Language: en
• An empty line
• An optional message body

23. REST

24. A system of Verbs and
Nouns

25. for interacting with a web
resource.

26. GET /index.html

27. POST /form.html

28. GET, POST, PUT, DELETE

29. Roy Fielding first defined REST
10 years ago in his dissertation
Architectural Styles and the
Design of Network-based
Software Architectures.

30. Since then, REST is often held as
the standard for usable, well-
designed, easy-to-integrate APIs.

31. A little history of
web servers

32. Mosiac,
NCSA

33. Where we are today

34. Apache

35. Created in February 1995
from the NCSA httpd 1.3
+ some patches

36. First official public release
of the Apache server
came in April 1995.

37. Apache has the legacy of
being one of the most
popular web servers.

38. You might also say that it is
limited by that legacy.

39. How does it work?

40. Serving filesystem paths

41. /var/www/index.html

42. mysite.com/index.html

43. Where is that
behavior defined?

44. /etc/apache2/sites-available/

45. Example /etc/apache2/sites-available/default
<VirtualHost *:80>
ServerAdmin webmaster@mattgauger.com
DocumentRoot /var/www/
<Directory /var/www/>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
</Directory>
ErrorLog /var/log/apache2/access.log combined
</VirtualHost>

46. Request comes in,
spin up a thread,
form a response,
send it back.

47. Apache’s method of
scaling:

48. Making lots of
threads

49. Threads wait for
incoming connection

50. They sit in a “pool”

51. OS-level threads
incur a penalty

52. Each one has an
execution stack
that uses memory.

53. Context switching
between threads isn't
free.

54. The result is:

55. Memory climbs and
climbs and the server
runs out

56. Swapping to disk
incurs a huge
penalty

57. This isn’t an ideal
way to scale

58. For massive
concurrency, we cannot
use an OS thread for
each connection.

59. You can throw more
CPUs, more RAM,
and more servers at it,
but it doesn’t solve it.

60. Sidenote: How does
PHP work on Apache?

61. PHP is a module to
Apache

62. It executes PHP
passed into it and
Apache sends a
response back

63. Execution stays within
Apache

64. The original idea for
PHP was to fill in some
spots in HTML.

65. It was a HTML
“Preprocessor”

66. For example,

67. <?php $name = “Matt”; ?>
<p>My name is
<?php print $name; ?>
.</p>

68. becomes

69. <p>My name is Matt.</p>

70. Before it is sent back to the
browser.

71. So how do we get past
Apache’s scaling issues?

72. Enter

73. NGINX

74. Or just nginx

75. nginx can serve
HTML pages back to
a browser

76. but that isn’t why
you’d want to use it.

77. nginx uses an
event loop

78. the event loop waits
and dispatches
events, or messages

79. the event causes an
event handler to be
called

80. event loops can be
highly concurrent

81. Its memory footprint
stays constant as #
of clients increases

82. nginx is intended to
be used as more of a
reverse proxy

83. What’s a ʎxoɹd
ǝsɹǝʌǝɹ?

84. Typically, reverse
proxies are used in front
of web servers.

85. Connections coming in
go to the reverse proxy
first.

86. The proxy may deal with
the request itself, or pass
it off to some other
service.

87. What does that all
mean?

88. nginx doesn’t handle
your PHP scripts for you

89. You have to tell it to give
PHP scripts to something
that can parse PHP

90. Like FastCGI

91. Here’s a default nginx
configuration

92. Example /etc/nginx/sites-available/default
server {
listen 80 default;
server_name mattgauger.com;
index index.html;
root /var/www;
access_log /var/log/nginx/localhost.access.log;
}

93. FastCGI version of the same config
server {
listen 80;
server_name mattgauger.com;
index index.php;
root /var/www;
location ~* .php$ {
if (!-f $request_filename) {
return 404;
}
fastcgi_pass 127.0.0.1:9000;
}
}

94. Anything matching the
pattern ~* .php$
gets passed to FastCGI

95. FastCGI is actually a
service running on the
webserver on port 9000

96. In this sense, we can say
that FastCGI is a lot like
an application server in
other languages.

97. Like Ruby, Python, etc.

98. What does the app
server do?

99. Request comes in from
the reverse proxy

100. Or from some other means
(another server, data
transfers, APIs, RPCs, etc)

101. App servers run scripts,
but not in response to
incoming requests

102. The code is always
running, and when it
sees a request come in

103. It decides what it has to
do with that request

104. And it puts together an
HTTP Response

105. HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Server: Etc.
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Etag: "3f80f-1b6-3e1cb03b"
Accept-Ranges: bytes
Content-Length: 438
Connection: close
Content-Type: text/html; charset=UTF-8
[blank line here!]
Response body.Neque porro quisquam est qui dolorem ipsum
quia dolor sit amet, consectetur, adipisci velit..."

106. Which is sent back as a
response to a browser,
or some JavaScript, or
whatever

107. Notice what’s going on
here.

108. We aren’t just serving
the contents of a file.

109. We aren’t just serving
the results of running a
PHP to fill in some parts
of HTML either.

110. We’re writing an
application

111. But instead of having a
commandline interface
or GUI

112. This application uses
HTTP and REST.

113. Web applications are
typically structured with
something called MVC.

114. MVC = Model, View,
Controller

115. A full discussion on MVC
will have to wait.

116. But the important part is
that we’re not just
writing index.php

117. And index.php isn’t just
some preprocessor
code, filling out values in
an HTML template.

118. At this point in the talk,
I talked a lot about
where we’re going here,
which I argue is

119. node.js

120. node.js is written on top
of the Google V8 engine

121. Which is cool, because
you’re writing JavaScript
on the server-side.

122. node uses JavaScript’s
callback concept to
define applications

123. not just webapps;
other things are possible,
like DNS servers.

124. See this great talk by
node.js’s creator:
http://yhoo.it/e4Jx7i

125. I plan to write more blog
posts about webapps, web
servers, and application
servers in the future.

126. Thank you!