web development in D

[Adam D. Ruppe]

I wrote:
> That said, an embedded webserver /is/ even faster

I measured this using one of my in-development apps recompiled
to use the built in server I have, picking a page with moderate
processing requirements.

CGI:
Time per request:       17.375 [ms] (mean)

built in webserver:
Time per request:       8.727 [ms] (mean)

I wonder why the difference is bigger than the startup I measured
when isolated? I think I/O contributes to slowdown a little too.
My startup cost was based on hello world, no significant output.
This outputs several kilobytes of data.

That's without any optimization. Let's try that again, making the
mysql and reflection objects static so they needn't be recreated
on every request when embedded....

Cgi:
Time per request:       17.178 [ms] (mean)

Built-in:
Time per request:       5.079 [ms] (mean)


Very nice.


Those are all pretty small numbers, but we do see a clear speedup
with the built in webserver.


Since my webserver is single threaded, I don't think this is
really fit for production use. If one user's request went too
long - which it shouldn't, but could - it'd slow everyone down.
It also can't serve up staticish files while waiting on something
else to process.

Another worry I have with a long lived process is what if it dies?
With CGI, you can trust Apache to start a fresh copy for you.

That's why I call the cgi one easier to use. You just drop it in
there, no need to worry about it dying, no need to start or restart
the process for updates, etc.


For fun, let's run it on some simpler pages too

Serving the auto-generated Javascript api file:

CGI:
Time per request:       13.678 [ms] (mean)

Built in:
Time per request:       1.070 [ms] (mean)


Big multiplier, but since it's a trivial program, we can see it's
about the same difference as we saw above - a constant ~10-13 ms
savings.

I also serve the stylesheet through it, because then it's
deployed all as one file. This is done before the database and
reflection objects are created anyway, so that optimization
shouldn't have an effect here.

CGI:
Time per request:       10.493 [ms] (mean)

Built in:
Time per request:       0.774 [ms] (mean)

And indeed, it didn't - the 10 ms constant cost is all we see.

I wonder if I can do anything to improve the I/O
performance.... nope, changing to the syscall from stdio made
no significant difference.

Doing
 time PATH_INFO=/style.css ./cgi-app > /dev/null

averages to ~10 ms too, so I can't blame Apache either.


So startup + object construction + I/O overhead for a real
world page gives CGI about a 10ms penalty. This ranges from a
small to a very big multiplier of total time, depending on
what the program is.

Next to real world network conditions, this is consistently
a small number in the big picture - the end user is unlikely to
notice it.