> Right after you start a lot of processes, there's a bunch of
> optimization that takes place -- frequently used files are read into
> cache, database connections are set up, necessary parts of the
> operating system are paged into memory, perhaps your VM is setting
> itself up, maybe Rails is generating caches...
> All of this stuff takes time, and can make requests really slow.
> Fortunately, you almost never run Rails immediately after startup
> (unless you're using rmagick or something ;-) so throwing out the
> data with that startup hit will give you a better idea of how your
> site will perform in the real world.
> In your case, it looked to me like Mongrel's median times were faster
> -- your totals were longer because of a very large max time.

I understand the startup overhead, but was under the impression that
it only affected the first request, not the first thousand. I assume
you're under the impression that I'm running these immediately after
starting up the server without hitting the page once. While I'm pretty
sure I hit all the pages before testing, I'll run some more tests,
this time making sure that the page requested has been hit once in the
browser beforehand.

Looking back at the results, yeah, the median connection time for two
mongrels is indeed faster than for one FCGI, but two FCGIs still comes
in considerably faster than two mongrels. Is there any RAM advantage
gained by using two mongrels instead of two FCGI procs, or any other
compelling reason for me to use mongrel instead if my connection times
remain significantly faster for FCGI when the server is warmed up and

Mongrel-users mailing list

Reply via email to