Sönke Ludwig wrote:

> During the last few months, we have been working on a new framework for general I/O and especially for building extremely fast web apps. It combines asynchronous I/O with core.thread's great fibers to build a convenient, blocking API which can handle insane amounts of connections due to the low memory and computational overhead.
> 
> Some of its key fatures are:
> 
>   - Very fast but no endless callback chains as in node.js
>     and similar frameworks
>   - Concise API that tries to be as efficient and intuitive
>     as possible
>   - Built-in HTTP server and client with support for HTTPS,
>     chunked and compressed transfers, keep-alive connections,
>     Apache-style logging, a reverse-proxy, url routing and
>     more
>   - Jade based HTML/XML template system with compile-time
>     code generation for the fastest dynamic page generation
>     times possible
>   - Built-in support for MongoDB and Redis databases
>   - WebSocket support
>   - Natural Json and Bson handling
>   - A package manager for seemless use of extension libraries
> 
> See http://vibed.org/ for more information and some example applications (there are some things in the works such as an etherpad clone and an NNTP server).
> 
> vibe.d is in a working state and enters its first beta-phase now to stabilize the current feature set. After that, a small list of additional features is planned before the 1.0 release.
> 
> The framework can be downloaded or GIT cloned from http://vibed.org/ and is distributed under the terms of the MIT license.
> 
> Note that the website including the blog is fully written in vibe and provides the first stress test for the implementation.
> 
> Regards,
> Sönke

Sönke, vibed is truly amazing! I am interested in the web server's internal architecture. I always wanted to do an implementation of a web server using a form of asymmetric, multi-process event-driven architecture. A web server which utilises fibers. It would be nice if you explain the web-server architecture of vibed in more details.

Keep up with good work!

Regards

On 27.04.2012 0:46, Sönke Ludwig wrote:
> During the last few months, we have been working on a new
> framework for general I/O and especially for building
> extremely fast web apps. It combines asynchronous I/O with
> core.thread's great fibers to build a convenient, blocking
> API which can handle insane amounts of connections due to
> the low memory and computational overhead.
>
> Some of its key fatures are:

In short: meet the new boss of the web development :)

Few things I think worth looking at.
1. Add cool auto-magic API generator in Adam's style:
route.wrapModule!(module_name)("/url");
The effect is that it "binds" /url/function_name for each function found in module, automatically gets parameters from post (or get) using arguments names of function. Last but not least it issues necessary calls to std.conv.to as needed.
Ah and the result is again converted to string (if needed) and packed into response body.

Example:
module factorial;

long fact(int k)
{
	return k > 1 ? k*fact(k-1) : 1;
}

Wrapped via wrapModule!(factorial)("/"); will work as
/fact?k=10 will out the result in plain-text. MIME type and conversion should be configurable of course.

2. By the very nature of your framework you should be well prepared to small-scale DDoS attacks.  But there is much more in DoS assortment these days. It would be shame if your framework doesn't handle e.g. slow-writer attack. Imagine attacker spoon-feeds HTTP request to your server by 1 byte per 10msec. Bump simultaneous request count to few thousands and your nice event loop freezes to a crawl. You gotta check upload rates ;)

-- 
Dmitry Olshansky

On Thursday, 26 April 2012 at 22:25:33 UTC, Vladimir Panteleev wrote:
> On Thursday, 26 April 2012 at 20:46:41 UTC, Sönke Ludwig wrote:
>> During the last few months, we have been working on a new
>> framework for general I/O and especially for building
>> extremely fast web apps.
>
> Very nice, amazing job! This is like my personal plans and hopes coming to life.

+1, although I didn't have the chance to look at it in detail yet. How should we submit »bug reports« for the website?

David

On 4/27/12, Sönke Ludwig <sludwig@outerproduct.org> wrote:
> Now I changed the line "SET LIBDIR=..\lib\win-i386" in run_example.cmd from quoted to non-quoted and for me it seems to work.

Maybe try:
SET "LIBDIR=..\lib\win-i386"

IOW quotes after SET.

Am 27.04.2012 10:01, schrieb Nick Sabalausky:
> Sounds great! And the site's very speedy :)  I'm especially excited about
> this:
>
> "(Work-in-progress) An integrated load balancer is able to dynamically
> compile, run and test new processes before switching them live after the
> code has been modified."
>

Me too, me too, it would have saved my ass last night when the server went down ;)

> A few questions:
>
> - Does the web framework work with other web servers, or is it tied to the
> built-in server?

You can put it behind an nginx reverse proxy (beginning with the new v1.2 that supports HTTP/1.1).

You could also just use everything except the HTTP server component and use classic CGI/FastCGI to communicate to the Web server. However, there is currently no FastCGI server built in, so something like libfcgi would have to do.

>
> - I don't suppose you have a feature comparison between the built-in server
> and Nginx? Is it one o' them fancy C10k servers? (Not that I'm likely to
> ever get that kind of traffic outside of a DDoS attack ;) )

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'm also planning to implement a core driver based on libuv in addition to the current libevent based one, which should gain a little more performance.

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.

>
> - 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?

The main reason is to have a lean and mean way to write small applications. A default main() is compiled in which handles command line parsing, connection to a load-balancer/reverse proxy etc.

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.

On 04/27/2012 10:01 AM, Nick Sabalausky wrote:
> ...
> - 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.
>

This is not true. The order is defined as far it matters for static initialisation. I think this is perfectly fine.

Am 27.04.2012 10:10, schrieb Dmitry Olshansky:
> On 27.04.2012 0:46, Sönke Ludwig wrote:
>> During the last few months, we have been working on a new
>> framework for general I/O and especially for building
>> extremely fast web apps. It combines asynchronous I/O with
>> core.thread's great fibers to build a convenient, blocking
>> API which can handle insane amounts of connections due to
>> the low memory and computational overhead.
>>
>> Some of its key fatures are:
>
> In short: meet the new boss of the web development :)
>
> Few things I think worth looking at.
> 1. Add cool auto-magic API generator in Adam's style:
> route.wrapModule!(module_name)("/url");
> The effect is that it "binds" /url/function_name for each function found
> in module, automatically gets parameters from post (or get) using
> arguments names of function. Last but not least it issues necessary
> calls to std.conv.to as needed.
> Ah and the result is again converted to string (if needed) and packed
> into response body.
>
> Example:
> module factorial;
>
> long fact(int k)
> {
> return k > 1 ? k*fact(k-1) : 1;
> }
>
> Wrapped via wrapModule!(factorial)("/"); will work as
> /fact?k=10 will out the result in plain-text. MIME type and conversion
> should be configurable of course.

Now on the TODO list!

>
> 2. By the very nature of your framework you should be well prepared to
> small-scale DDoS attacks. But there is much more in DoS assortment these
> days. It would be shame if your framework doesn't handle e.g.
> slow-writer attack. Imagine attacker spoon-feeds HTTP request to your
> server by 1 byte per 10msec. Bump simultaneous request count to few
> thousands and your nice event loop freezes to a crawl. You gotta check
> upload rates ;)
>

There is already a HttpServerOptions.maxRequestTime that would help - but this is currently still ignored. Also, keep-alive connections are kept open too long right now. But both is on the list.

Maybe something like a LRU limiter that closes old connections in case of too many open connections would also be a good alternative barrier...

My plan is also to switch all modules to @safe as soon as Phobos and Druntime have a bit better support. I guess this is type of application can be considered the prototype for which SafeD is useful.

Am 27.04.2012 10:16, schrieb David Nadlinger:
> On Thursday, 26 April 2012 at 22:25:33 UTC, Vladimir Panteleev wrote:
>> On Thursday, 26 April 2012 at 20:46:41 UTC, Sönke Ludwig wrote:
>>> During the last few months, we have been working on a new
>>> framework for general I/O and especially for building
>>> extremely fast web apps.
>>
>> Very nice, amazing job! This is like my personal plans and hopes
>> coming to life.
>
> +1, although I didn't have the chance to look at it in detail yet. How
> should we submit »bug reports« for the website?
>
> David

Initially I wanted to have a page-comment feature ready as on dlang.org. But for now I guess the github issue tracker should do the job: https://github.com/rejectedsoftware/vibe.d/issues

Sönke

"Sönke Ludwig" <sludwig@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.

"Nick Sabalausky" <SeeWebsiteToContactMe@semitwist.com> wrote in message news:jndnic$2b5u$1@digitalmars.com...
>
> Have you looked at long-term memory usage? I wonder if D's imprecise GC could be a liability and would need to be ?
>

...would need to be managed carefully?