
Show HN: Really fast webserver for kdb - geocar
https://github.com/geocar/dash
======
geocar
I've also put together a writeup of how to make fast network servers[1].

[1]: [http://geocar.sdf1.org/fast-servers.html](http://geocar.sdf1.org/fast-
servers.html)

~~~
bob1122
Did you intentionally obfuscate your code?

~~~
phpnode
It's idiomatic style in the K community, e.g. here's a random source file from
kdb itself -
[http://code.kx.com/wsvn/code/kx/kdb%2B/c/c/odbc.c](http://code.kx.com/wsvn/code/kx/kdb%2B/c/c/odbc.c)

Some members of that community prefer this style because they find it _more_
readable.

~~~
the-tomster
Some people like to have big monitors so that they can fit more code on their
screen at once. Instead of getting a bigger screen why not shrink the code?

As a side project I implemented a small text editor in this style. I had a
working text editor with the ability to load a file, insert and delete text,
scroll around a large file, and save changes. It fit within about 100 lines of
concise (but I wouldn't say obfuscated) C.

In the end I decided to reformat it and use my usual style before implementing
more features. But it was a good experiment and I now understand the appeal of
the ultra-condensed style you see in J, K, some Forth, and some Perl code.

------
j42
Can you tell me where I may find more info on KDB or how this may compare to
more traditional serving options for static resources, HLLs or anything that
might fit well in a large tree.

I'm trying to understand exactly what its limitations are though, both in
terms of what it can do and when it may be a poor candidate (when lower req/s
is ok and greater flexibility is needed).

~~~
geocar
In kdb, GET requests are normally mapped to .z.ph[1] which synchronously
returns the HTTP response. dash supports this as well (sync mode) when it
doesn't understand the query string parameters, and then dash works just like
a faster .z.ph for KDB.

Async mode is designed when dash knows what the HTTP response _will be_ and
can send it immediately. It then relies on kernel queueing to send the same
message to kdb which allows for logging (or other processing, like HLL or
anything else). This gives a significant performance boost so it's worth
optimising.

[1]:
[http://code.kx.com/wiki/Reference/dotzdotph](http://code.kx.com/wiki/Reference/dotzdotph)

------
dkaigorodov
Is there comparison with, for example, nginx?

------
gaze
Haha. poop()

------
forgotmypassw
I'm sure that C code is maintainable.

