"Sönke Ludwig" <slud...@outerproduct.org> wrote in message news:jndl9l$26eh$1...@digitalmars.com... > > We still have a more comprehensive benchmark on the table but it seemed to > get along happily with about 60MB of RAM usage during a C10k test. The > average request time went down to about 6s if I remember correctly. The > test was using a dual-core Atom server over a WiFI connection so the > results may have been skewed a litte. >
I guess I don't have much of a frame of reference, but that certainly sounds very impressive. Especially the RAM usage (you could probably kill lighttpd, from what I've heard about it) and also the fact that was all over WiFi. Have you looked at long-term memory usage? I wonder if D's imprecise GC could be a liability and would need to be ? > In terms of HTTP/1.1 implementation it is most importantly lacking > multipart form uploads (will be added shortly). Otherwise the protocol > supports most HTTP features. I'll put a more detailed comparison on my > TODO list. > Thanks, I'm anxious to take a look. I'm particulary curious how much of your intended scope does/doesn't overlap with Nginx's domain and it's (rather Apache-competetive) suite of modules: http://wiki.nginx.org/Modules Do you see this as eventually (or even currently) competing with Nginx in general? Or is it more focused on web framework and general async I/O? (Actually that's another thing, how general is the async I/O in it? Is it intended to be used for just...whatever general I/O uses...or is it more intended as a means-to-an-end for web?) The way it's designed, I suppose the features of many of Nginx's modules could simply be implemented using vibed, for example directory listings. I hope it doesn't sound like I'm trying to tear vibed apart. I'm genuinely impressed with it so far. Just trying to get a good feel for it and how best to use it effectively. >> >> - Why "static this"? Seems like a strange choice since it'll run before >> the >> main that (I assume) vibed automatically provides - and in an undefined >> order relative to all other module ctors. >> > > The order of module constructors should be defined to be a valid order > wrt. the import tree right? > Oops, yea. Not sure what I was thinking. > However, it is also possible to just implement a custom main() and start > from there - you just have to include vibe.vibe instead of vibe.d so that > the built-in main() is not compiled. I will put an example on the website > later. > Cool.
