51–60 of 60 posts
Gzipping is especially important for large JavaScript heavy apps. 280slides loads about 5x faster gzipped than not. If you're really worried about the performance hit of gzipping, you can cache gzipped versions of static resources.
For AJAX-based web applications, following is what I'd suggest in making things very zippy for the user: 1. Concatenate your JS and CSS files. Don't send out several files over the wire to the browser - the browser can only make 2 connections at a time. Be careful about JS dependencies - order is imp. in JS. 2. Minify and then compress the JS and CSS. Use Dojo's Shrinksafe or the YUI Compressor to do this. It will st…
While it's true that IE6 and IE7 can only handle 2 concurrent persistent connections per server, IE8 can handle 6. Firefox 3 by default handles max 8 persistent connections per server, and max 15 connections per server in total (persistent and non-persistent). This goes against RFC2616, but I guess the capacity of both servers and clients have increased enough the last 10 years to warrant such changes in default beha…
Earlier quoted context omitted.
Out of curiosity what was the reason for using a custom webserver?
Scalability, full control over everything, it's not rocket science... Mibbit uses some cool Comet like stuff, and I'm 99% confident the Mibbit webserver is better than anything else at doing this.
I'm constantly amazed by the people who think writing HTTP servers is really hard.
Earlier quoted context omitted.
Scalability, full control over everything, it's not rocket science... Mibbit uses some cool Comet like stuff, and I'm 99% confident the Mibbit webserver is better than anything else at doing this.
Wow, better than anything else ? That's a pretty tall claim! What leads you to believe that? I'm constantly amazed by the people who think writing HTTP servers is really hard.
Writing an HTTP server is easy. But making one that handles long lived connections (10s of thousands), and scales well, doesn't eat memory, doesn't eat CPU, etc etc is harder.
Having said that, it's easy enough that I think it's often worth doing if the webserver is integral to your success (It is with Mibbit).
Gzipping is especially important for large JavaScript heavy apps. 280slides loads about 5x faster gzipped than not. If you're really worried about the performance hit of gzipping, you can cache gzipped versions of static resources.
How do you deal with the time it takes to parse a large Javascript file? Past 500KB or so it can take several seconds.
500KB is pretty huge. Does every user need that? Perhaps you can use a smaller bootstrap script to pull down only what's needed when it's needed.
Earlier quoted context omitted.
How do you deal with the time it takes to parse a large Javascript file? Past 500KB or so it can take several seconds.
Are you minifying your javascript? 500KB is pretty huge. Does every user need that? Perhaps you can use a smaller bootstrap script to pull down only what's needed when it's needed.
a2enmod deflate /etc/init.d/apache2 restart
I don't use apache, but apparently it may be a little more complicated than that if you really want it to work: http://www.nerdblog.com/2009/04/my-modgzip-settings-deflatec...
Earlier quoted context omitted.
Wow, better than anything else ? That's a pretty tall claim! What leads you to believe that? I'm constantly amazed by the people who think writing HTTP servers is really hard.
It handles 2,000 HTTP requests a second on a single 1.4GB VPS server, which I think is good. It'll likely go to 10k/s or more... probably until the bandwidth is saturated. Writing an HTTP server is easy. But making one that handles long lived connections (10s of thousands), and scales well, doesn't eat memory, doesn't eat CPU, etc etc is harder. Having said that, it's easy enough that I think it's often worth doing i…
My main point was that it would be hard to tell if someone somewhere had an HTTP implementation that could handle 250 000 concurrent HTTP connections per 64MB of RAM while yours only handled, say, 5000 per 64MB. (I suspect the former number is achievable; I know the latter is.)
I can confirm from experience that writing an HTTP server that scales well without eating memory or CPU is dramatically harder than just writing an HTTP server. However, it's very easy to do better than apache-mpm-prefork. (No need, though; lighttpd and nginx should both do better at that, I have heard that perlbal does too, and I suspect from experience that twisted.web does as well, although I haven't measured it.)
Nobody has mentioned the latency issue when gzipping. If you have to construct the whole file before gzipping, in situations where the file is large or dribbles out as the server processes the data, this could mean a significant slowdown. In virtually all situations, I agree gzipping is good, just like I always leave write-caching on my hard drive turned on so that the slowest part of my system can run at the fastest…
Incorrect. Gzip streams just fine, so there is no latency issue. Google search, for example, writes the top of the page before the search is complete. (and I assure you, they use gzip)