Comments on: Put the web server on a diet and increase scalability http://gojko.net/2008/05/05/put-the-web-server-on-a-diet-and-increase-scalability/ The Quest for Software++ Sat, 30 Aug 2008 11:19:13 +0000 http://wordpress.org/?v=2.6.1 By: Curt Sampson http://gojko.net/2008/05/05/put-the-web-server-on-a-diet-and-increase-scalability/#comment-27654 Curt Sampson Thu, 15 May 2008 03:22:19 +0000 http://gojko.net/?p=123#comment-27654 This all seems incredibly specific to some particular software; my first thought on reading this was that most of it doesn't apply to my particular web server and framework. This all seems incredibly specific to some particular software; my first thought on reading this was that most of it doesn’t apply to my particular web server and framework.

]]> By: Gil http://gojko.net/2008/05/05/put-the-web-server-on-a-diet-and-increase-scalability/#comment-27356 Gil Mon, 05 May 2008 20:08:02 +0000 http://gojko.net/?p=123#comment-27356 You make some good points here, but the best ones seem to revolve around sound programming tactics as opposed to scaling strategy (I'm speaking primarily about the encapsulation section here). Your third paragraph begins "Consider using cookies as an alternative to store simple information that is not security-sensitive." Well, most session systems I'm familiar with already do this, and it's important to note that more cookies = more overhead because they must get passed along with every HTTP request to the server. Most of my experience with sessions revolves around PHP, which by default uses flat file storage. Combined with OS-level hard disk caching, this can scale remarkably well on a single machine. When you reach the point of needing multiple front end servers that method goes out the window, and for those cases a distributed object cache like memcache works remarkably well. Regardless of which server side session storage method you choose (flat file, object cache, etc), I'd say that session size is a nominal consideration. Memory is insanely cheap these days, and I'd much rather dump lots of info into a cache than require a database query for every page request. You make some good points here, but the best ones seem to revolve around sound programming tactics as opposed to scaling strategy (I’m speaking primarily about the encapsulation section here).

Your third paragraph begins “Consider using cookies as an alternative to store simple information that is not security-sensitive.” Well, most session systems I’m familiar with already do this, and it’s important to note that more cookies = more overhead because they must get passed along with every HTTP request to the server.

Most of my experience with sessions revolves around PHP, which by default uses flat file storage. Combined with OS-level hard disk caching, this can scale remarkably well on a single machine. When you reach the point of needing multiple front end servers that method goes out the window, and for those cases a distributed object cache like memcache works remarkably well.

Regardless of which server side session storage method you choose (flat file, object cache, etc), I’d say that session size is a nominal consideration. Memory is insanely cheap these days, and I’d much rather dump lots of info into a cache than require a database query for every page request.

]]> By: Kyrre http://gojko.net/2008/05/05/put-the-web-server-on-a-diet-and-increase-scalability/#comment-27355 Kyrre Mon, 05 May 2008 19:57:03 +0000 http://gojko.net/?p=123#comment-27355 I'm not sure I understand your point about security sensitive identifiers. Using a user ID in a URL is not really a bad things, at least not in the REST way of thinking about things. You only have to make sure that people can't guess that there's a resource at the end of the URL until they have logged in with the right credentials. At the end of the day a user's ID may be communicated, for example for a discussion list, etc. But I fully agree with your arguments against using cookies. In every project I do these days, I turn off all cookie handling in the beginning, and turn it on only of someone has a use and a good argument for using it. Surprisingly often, we find much better and more scalable solutions to the problem. I’m not sure I understand your point about security sensitive identifiers. Using a user ID in a URL is not really a bad things, at least not in the REST way of thinking about things. You only have to make sure that people can’t guess that there’s a resource at the end of the URL until they have logged in with the right credentials. At the end of the day a user’s ID may be communicated, for example for a discussion list, etc.

But I fully agree with your arguments against using cookies. In every project I do these days, I turn off all cookie handling in the beginning, and turn it on only of someone has a use and a good argument for using it. Surprisingly often, we find much better and more scalable solutions to the problem.

]]> By: Gavin Terrill http://gojko.net/2008/05/05/put-the-web-server-on-a-diet-and-increase-scalability/#comment-27347 Gavin Terrill Mon, 05 May 2008 18:14:41 +0000 http://gojko.net/?p=123#comment-27347 > Shopping cart contents are a good example I've forgotten where I read it, but I think it was Amazon who actually found that users like it when the system remembers what was in their cart previously. > Shopping cart contents are a good example
I’ve forgotten where I read it, but I think it was Amazon who actually found that users like it when the system remembers what was in their cart previously.

]]>