Justus Pendleton writes:
> Dan Melomedman writes:
>
>> IMHO piped I/O and CGI is not scalable, neither is multi-process model of
>> Sqwebmail and Apache, but this model provides for a lot of flexibility.
>
> sqwebmail has supported fastcgi for a very long time. Is this too slow
> for your purposes?
No, not for my purposes. Also I could never get dynamic FastCGI to work for
some reason.
We do not run busy servers, and actually Sqwebmail serves us fine. My
previous e-mail was merely stating that things could be designed a little
differently, (if, for example a design goal was "enterprise scalability")
not complaint. Again, I am not complaining about Sqwebmail quality as such.
> There are lots of webservers out there besides Apache. Try flask or
> xitami if you like the event-driven model.
I am aware of this.
>> The size on my system for an older version is around 300K stripped.
>
> The size on disk doesn't matter nearly as much as its size at runtime.
This will be noted from now on :).
> How much memory does sqwebmail take up under load on your machine?
Haven't measured yet.
>> fork() is very expensive
>
> Have you measured it? Under linux, for instance, forking and creating a
> thread are essentially the same thing.
Never measured it, and do not really care.
If you're using the Linux native threading library that is. Which wasn't
written to be scalable to start with AFAIK, but just to provide Posix
threads implementation. Has a one to one model, and the Linux kernel doesn't
distinguish between a thread or process. Though as I remember there are
separate tables for bookkeeping threads and processes. There is a project
in the works from IBM that improves on the old library with source base from
GNU Pth. GNU Pth is a portable user-space threading library (with I believe
pthreads API).
>
>> and the larger the executable the more IMHO expensive it is.
I could be wrong here, but running a process per connection is wasteful on
very busy servers in any case. In other words, correctly designed
multi-threaded (not necessarily on Linux, and not necessarily with pthreads)
servers conserve memory and require less kernel scheduling overhead if any.
And why are we talking about Linux here? What other Unices don't provide
threading libraries? Dan Kegel has great information here
http://www.kegel.com/c10k.html
> Since forking is copy-on-write I'm not sure I follow your logic here. Can
> you explain?
Running many processes is very hard on the kernel. In fact if you start
enough, most of your CPU time will be wasted scheduling your processes and
little will be left to run them. Linux 2.0.x and 2.2.x are especially famous
for this. Plus you can hit the system-wide file descriptor limit. In
threaded programs memory is shared, whereas in multi-process forking servers
it's allocated per process. This means higher memory overhead.
Also, why does apache prefork a number of servers for instance?
Also, here's an interesting unrelated blurb about copy-on-write:
http://www.netbsd.org/Documentation/kernel/vfork.html
Forking is multitudes more expensive than threading, memory and kernel-wise.
Scheduling between processes takes much longer time than between threads in
a well-implemented library. A library doesn't have to have hooks to the
kernel, and may or may not use POSIX API. In user-space libraries threads
are not seen by the kernel. In the case of state threads, they are
pseudothreads.
The contrast here is it was written specifically for writing scalable
internet servers, where other libraries are more generic and force a
programmer to deal with mutexes and thread safety.
>
>> What I'd love to see in the future is something like Sqwebmail, but with
>> a web server built-in and multi-threaded using an easy, scalable
>> threading library like http://oss.sgi.com/projects/state-threads or
>> pthrlib from annexia.org.
>
> From what I can tell the state-threads project aren't really threads. It
> looks like an event-driven library.
Exactly. And a very cool one indeed since it allowes good system and load
scalability, while at the same time allowing to avoid thread safety
concerns, and mutexes are not usually needed.
>
> It seems like most of your concerns have more to do with the web server
> than sqwebmail.
>
> Justus
Not really concerns. I was just dreaming about a stand-alone server that was
designed to scale from scratch. This could be useful for large ISPs.
--
Dan
Three days of testing can save 10
minutes reading manuals.
