Puakma: Under the hood

I'm Brendon Upson, jack-of-all-trades, master of one or two. I'm talking about life running a small ISV tackling business issues and leaping technology hurdles in a single bound.

webWise Network Consultants is based in Sydney, Australia and develops the groundbreaking Tornado Server technology.

Browser timeouts

Filed under: by Brendon Upson on 2008-07-16

Some of the code we write here, particularly reports, can take a long time to process due to the report's inherent complexity. One recent project took over 3 minutes to generate a customer designed-on-the-fly report andspit out the pdf. Since the customer has complete control over the data and report contents, the time it takes to produce the report expands in a linear fashion. You can optimize the hell out of the code, but soon there will be a point where it's spitting out 10,000 pages instead of 1,000 and you're back to square one.

So what can you do?

The obvious choice is to batch process the report and send it to the user by some other means, eg email. This has some serious drawbacks. The user doesn't know if the report has run but the email failed, they can click the generate button 30 times and grind the server to a halt because all the processing is happening in the background. Plus it's not very intuitive: generate a report then check your email. It works, but could be better.

With HTTP 1.0, you don't need to send a content-length so you can "stream" the report to the browser as it is put together. Until, of course, the customer asks for page numbers "Page X of Y". You don't know what Y is until the report is complete and if you've already sent it to the browser...

Then I thought up a trick to fool the browser into not timing out. 

With HTTP 1.1, the server sends a "Content-Length: 999" to the browser, which means the server must process the report completely to get its size in bytes, then tell the browser how many bytes to expect. From the time the report is started to the time the browser gets its first reply from the server can be several minutes and the browser may disconnect because it thinks the web server is not responding.

In order to stop the connection timing out, the web server needs to send some data to the browser. Enter dummy http headers. As we process the request the report code sends dummy http headers to the browser, eg "X-PageNumber-1: ok" etc. This trick requires responding completely to the http request yourself rather than relying on the web server so you have to craft your own HTTP/1.1 200 OK etc and set the other mandatory headers. The basic process is:

1. Send the standard headers
2. send an extra dummy header for each report page
3. Send the content-length:
4. Send the data payload





Multi-Threading apps

Filed under: by Brendon Upson on 2008-07-07

Last week we upgraded the office VMware server. It's now running an Intel Core2 quad CPU with 8GB RAM. I can't believe how much the price of hardware has fallen. This replaces a 5 year old dual CPU Athlon 2100. The performance leap is HUGE.

Which then got me thinking. The trend is to add more and more cores to CPUs, which is great so long as the software that runs on it is multithreaded. Sure you'll get a good boost by running multiple applications, but what about web applications? Yes, two incoming web requests run in their own threads and there is a certain amount of parallelization (is that a word?) within that request, but at some point the web server will run your custom code which does the actual work. How well does that cater for a parallel approach. My guess is in most cases, not at all. Here we have a bottle neck. Add 100 more cores and your code will go no faster. 

Ok, so just make it multithreaded?

Well, not so fast. This is a difficult LOGICAL problem. Consider you are writing a lump of code to dress a person. Can you put shoes and socks on at the same time? Do trousers come before or after shoes? For most tasks there is a sequential order. It is a difficult task to determine which tasks can be run in parallel and which are sequential and usually there is a combination of both task types.

As programmers we are on the cusp of having to change the way we think about problems and probably use some new tools to get that work done.

Apple, Google, MS and things to come

Filed under: by Brendon Upson on 2008-07-04

Here's a few random thoughts.

1. I managed to snap my right arrow key on my macbook pro (my fault completely....). I though I could get a replacement KEY. No. I have to buy an entire KEYBOARD. Thats $95 plus $75 for a half hour labour. Robbery. Apple will never make it in the server market until they change their hardware support (which is notoriously bad) and pricing.

2. iPhone 3g - big deal?

Sure, it's "just a phone". The device itself is not entirely a market changer, but the way we will use it will be. More and more we will use this (and devices like it) more than we use our PC. Why? Because it's convenient, it's always with us and always connected. This is why the blackberry has been so popular. The difference with the iphone is that for the first time we have a decent size screen and an intuitive way of interacting with it. IMHO microsoft have totally lost the plot. The Windows franchise is dying quickly as worthy competitors in Mac OS X and Linux are hammering at the gates and their online strategy is seemingly non-existant. Devices like the iphone and later Andriod from Google will serve to completely bypass the traditional PC business, meaning Windows and desktop operating systems will become redundant. The phone IS the PC.

Feed, change, sleep, repeat

Filed under: by Brendon Upson on 2008-07-01

Last week saw the arrival of Brooke Ada Upson. Life as we know it will never be the same again. It's amazing how such a small life form can completely transform your world! It's the small things that have changed - like sleeping at night.

 Needless to say we're completely overjoyed at our new arrival but still trying to understand how she works. If I disappear for long periods - now you know why.