Tag: performance

Bufferbloat

very detailed and troubling discussion about the scalability problems of the internet.

You see various behavior going on as TCP tries to find out how much bandwidth is available, and (maybe) different kinds of packet drop (e.g. head drop, or tail drop; you can choose which end of the queue to drop from when it fills). Note that any packet drop, whether due to congestion or random packet loss (e.g. to wireless interference) is interpreted as possible congestion, and TCP will then back off how fast to will transmit data.

Digging Deeper with htracr

visualizing the binding between http and tcp

There’s a lot of current activity on the binding between HTTP and TCP; from pipelining to SPDY, the frontier of Web performance lives between these layers. To get more visibility in exactly what’s happening down there, I decided to throw together a little tool to show how HTTP uses TCP: htracr.

LHC 1PB / s

one of the most data-intensive apps in the world today. from 1 PB / s to a mere 1 GB / s.

Overclocking SSL

ssl is now fast enough for general use if you are careful.

HTTP Proxy Considerations

very good summary. performance, features etc

3x faster iPhone JS

you mean no longer 10ms to parse 1kb of JS? current js performance on iphone is atrocious.

Wine beats Linux FF

all the desktop linux apologists in the comments. you guys are a disgrace.

Saxon Performance

In this paper I have presented 10 characteristics of the Saxon XQuery implementation that contribute to its performance, and for most of these, I have attempted to quantify the size of that contribution for some selected queries. Few of these mechanisms are unique to Saxon; what makes Saxon distinctive is the deployment of a balanced portfolio of techniques to deliver efficient query execution over a variety of user workloads, coupled with a determination to place other qualities of the product (standards conformance, reliability, usability) ahead of raw performance. In a crowded marketplace with over 50 XQuery implementations competing for user attention, I believe it is this balanced approach that has led many users to make Saxon their preferred choice.

memcached scaling

we have been able to scale memcached to handle 200k UDP requests/s with an avg latency of 173us. This is from 50k UDP requests/s using the stock version of Linux and memcached.

VE to Google Maps

In IE6, we saw a speedup of ~10 seconds