Web application framework stacks

Tuesday 13 June 2006 — This is over 18 years old. Be careful.

Peter Thomas gives us the full picture of a Java web application call stack. It’s very impressive. It shows about 100 call frames, annotated with the different layers of the architecture. The comments there debate the question of whether this is a good thing or a bad thing.

I was curious about the equivalent stack for our current mod_python/Django/MySQL architecture. I won’t paste the actual stack trace here (opinions differ about the extent to which work details can be discussed in a blog), but here’s the breakdown by layer:

  • mod_python: 1 stack frame
  • Django’s mod_python support: 3 stack frames
  • Our view infrastructure: 3 stack frames
  • Our business logic: 3 stack frames
  • Django’s ORM: 4 stack frames
  • Django’s MySQL support: 2 stack frames
  • MySQL’s Python layer: 3 stack frames

for a grand total of 19 Python stack frames between Apache and MySQL, six of which are our code. I won’t claim to know whether this is better or worse, just comparing.

Comments

[gravatar]
Jay P. 11:22 AM on 13 Jun 2006
Interesting, the Django stack frame count matches up with my own guesses.

I've been learning Django recently, and I keep noting how it does so much, but feels so nice and light. It's even easy to jump in and inspect the core Django code.
[gravatar]
Jacob Kaplan-Moss 11:39 AM on 13 Jun 2006
Wow, that Java call stack almost made me spit coffee all over my keyboard.

Another important thing to point out is that *every single level* in the Django call stack is free and open source. We have the right to fix any problem at any layer. The fact that there aren't that many of those layers means that finding and fixing bugs actually is a possibility, too.

*There's* your business case for open source :)

By the way -- what tool did you use to see Django's call stack? I've been fooling with trace.py but I can't get it to do the right thing...
[gravatar]
Ned Batchelder 1:43 PM on 13 Jun 2006
Jacob: I used a very low-tech approach. I edited the file nearest to MySQL to have a traceback.print_stack() call right where it dives into the C extension!
[gravatar]
Manuzhai 2:17 PM on 13 Jun 2006
The number of layers HAS to affect performance, doesn't it? It would seem to me that every layer would come at a cost (although this cost varies wildly --some layers will be doing lots of processing, others will just pass on the call to the next layer).
[gravatar]
Ian Phillips 3:07 PM on 13 Jun 2006
This difference is about what I'd expect really. People (well, mainly RoR fans of late...) often claim that dynamic languages are 10x more expressive/productive than Java/static languages. If we use stack depth as a measure that still gives us an approximately 5x productivity increase (function point counting, anyone?), this is about what I'd expect.

Of course you can argue that each call is also more productive as well, but since it's only a single data point it's probably best not to worry too much about exact numbers!
[gravatar]
AdSR 5:58 PM on 13 Jun 2006
This reminds me of something once said on c.l.py by Giovanni Bajo:

Also Python code is pretty bare-metal, so that file.write or socket.write go to the syscall immediately. Try that in Java and you'll find 30 layers of complex abstractions for doubtful benefits and obvious slowness.
[gravatar]
Fredrik 9:39 AM on 16 Jun 2006
"Also Python code is pretty bare-metal"

Sure, but they'll fix that in Python 3000 ;-)

Add a comment:

Ignore this:
Leave this empty:
Name is required. Either email or web are required. Email won't be displayed and I won't spam you. Your web site won't be indexed by search engines.
Don't put anything here:
Leave this empty:
Comment text is Markdown.