View mode: basic / threaded / horizontal-split · Log in · Help
April 27, 2012
Re: Introducing vibe.d!
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
April 27, 2012
Re: Introducing vibe.d!
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
April 27, 2012
Re: Introducing vibe.d!
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
April 27, 2012
Re: Introducing vibe.d!
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.
April 27, 2012
Re: Introducing vibe.d!
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.
April 27, 2012
Re: Introducing vibe.d!
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.
April 27, 2012
Re: Introducing vibe.d!
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.
April 27, 2012
Re: Introducing vibe.d!
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
April 27, 2012
Re: Introducing vibe.d!
"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.
April 27, 2012
Re: Introducing vibe.d!
"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?
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home