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.