Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

KORE – A fast SPDY-capable webserver for web development in C

kore.io

Post reply on HN
Print view View original

21–30 of 60 posts

Re: KORE – A fast SPDY-capable webserver for web development in C

#21

Post by FooBarWidget »

codex wrote: post #18
a-priori wrote: post #13

Okay here's a peeve of mine: just because something is in C ("no overhead!") doesn't mean it's faster than something in another language in all situations. As an example, this server uses a thread pool architecture. This architecture will perform poorly with slow clients (common on the public Internet), servers which have to interact with slow disks or external services, and is useless for long-polling. It's only use…

Threaded servers are not necessarily slower than asynchronous architectures, though they can be. In fact, threaded models are coming back into fashion these days, and can (sometimes) be faster than asynchronous models when each thread is affine to a particular physical CPU. This is due to cache effects and the substitution of fast stack allocation for slow heap allocation. Bazillions of threads using too much stack s…

Modern threading implementations are pretty good. Plus, a lot of the memory threads use is just virtual address space, not real memory. On 32-bit systems you ran into the problem of running out of virtual address space with a few hundred threads. With the popularity of 64-bit platforms this problem has gone away. Plus, because this is C, it's trivial to reduce the stack size to, say, 512 KB without too many problems.

Re: KORE – A fast SPDY-capable webserver for web development in C

#22

Post by weland »

betterunix wrote: post #9

Why web development in C? Seems like a headache.

It's quite a gift for embedded systems. It's very convenient to have a self-contained solution for a web interface, rather than drag an interpreter and a web server on an already crowded rootfs. Plus, you can get the benefit of static analysis and the like, which is extra useful on such systems.

Re: KORE – A fast SPDY-capable webserver for web development in C

#23

Post by fcambus »

eric_bullington wrote: post #20
antihero wrote: post #15

Would it be an interesting idea to create a framework for making webapps as nginx modules? Sure, it's a pain in the ass, but nginx is evented as opposed to thread pooled, and tried and tested. Because nginx takes up hardly any memory, you could run a single nginx instance and proxy to other nginx instances that are compiled purely to run the app. Though the scope for creating critical vulnerabilities is huge .

There is such a framework: openresty http://openresty.org/ It uses a wide range of 3rd-party nginx modules, and Lua as a scripting language, to form a nice little framework. Extraordinarily fast by any standards.

Lapis is also worth mentioning : http://leafo.net/lapis/

Lapis is a framework for building web applications using MoonScript (or Lua) that runs inside of a customized version of Nginx called OpenResty.

Re: KORE – A fast SPDY-capable webserver for web development in C

#24

Post by mpweiher »

a-priori wrote: post #13

Okay here's a peeve of mine: just because something is in C ("no overhead!") doesn't mean it's faster than something in another language in all situations. As an example, this server uses a thread pool architecture. This architecture will perform poorly with slow clients (common on the public Internet), servers which have to interact with slow disks or external services, and is useless for long-polling. It's only use…

> this server uses a thread pool architecture.

Is the README wrong? It says:

"Event driven architecture and worker processes for throughput"

To me this indicates using events for the external interface (slow clients), and threads for taking advantage of multiple cores.

Re: KORE – A fast SPDY-capable webserver for web development in C

#25

Post by drdaeman »

weland wrote: post #22
betterunix wrote: post #9

Why web development in C? Seems like a headache.

It's quite a gift for embedded systems. It's very convenient to have a self-contained solution for a web interface, rather than drag an interpreter and a web server on an already crowded rootfs. Plus, you can get the benefit of static analysis and the like, which is extra useful on such systems.

I believe there are relatively many AOT-compiled-to-native-code languages other than C.

Re: KORE – A fast SPDY-capable webserver for web development in C

#26

Post by papsosouid »

a-priori wrote: post #13

Okay here's a peeve of mine: just because something is in C ("no overhead!") doesn't mean it's faster than something in another language in all situations. As an example, this server uses a thread pool architecture. This architecture will perform poorly with slow clients (common on the public Internet), servers which have to interact with slow disks or external services, and is useless for long-polling. It's only use…

That's a terrible example, both because it has nothing to do with speed (your complaint is about scalability, not speed) and because it is wrong. Having a pool of workers to handle requests while using event driven interfaces is normal now, and gives you the best of both worlds. Your theoretical attack works the same as it would on nginx: you'd need to run it out of file handles.

Re: KORE – A fast SPDY-capable webserver for web development in C

#27

Post by readme »

eric_bullington wrote: post #20
antihero wrote: post #15

Would it be an interesting idea to create a framework for making webapps as nginx modules? Sure, it's a pain in the ass, but nginx is evented as opposed to thread pooled, and tried and tested. Because nginx takes up hardly any memory, you could run a single nginx instance and proxy to other nginx instances that are compiled purely to run the app. Though the scope for creating critical vulnerabilities is huge .

There is such a framework: openresty http://openresty.org/ It uses a wide range of 3rd-party nginx modules, and Lua as a scripting language, to form a nice little framework. Extraordinarily fast by any standards.

Trying that out now myself. It's OK but has a long way to go if it is to compete with the current platforms dujour.

Re: KORE – A fast SPDY-capable webserver for web development in C

#29

Post by aray »

Why the ISC license? The site just says "Kore is licensed under the ISC license allowing it to be used in both free and commercial products." but don't Apache 2, BSD, and MIT all satisfy this as well.

IANAL, but here's a quick summary of ISC vs MIT: http://www.tldrlegal.com/compare?a=MIT+License&b=ISC+License

Re: KORE – A fast SPDY-capable webserver for web development in C

#30

Post by osth »

richo wrote: post #28

> Secure by default > SPDY Choose one, SPDY mandates gzip, and gzip in SSL/TLS is vulnerable to leaking repeated plaintext, eg cookies in nearly every implementation. http://en.wikipedia.org/wiki/CRIME_(security_exploit)

I choose HTTP/1.1 pipelining. Uncompressed headers are useful. Ordered records are returned (unlike SPDY), where "HTTP/1.1 200 OK" is the record separator. Been using this for a decade. Can't see the benefit of SPDY.

Anyway pipelining is only useful where numerous resources are coming from the same host. But the way the www has evolved, so much (unneeded) crap gets served from ad servers and CDN's. Pipelining isn't going to speed that up.

HTTP/1.1 pipelining was never broken. It was usually just turned off (e.g. in Firefox), while most web servers have their max keep alive set around 100. In plain English, what does that mean? It means "Dear User, You have permission to download 100 files at a time from http://stupidwebsite.com. That is you can make one request for 100 files, instead of 100 separate requests, each for a single file." And what do Firefox and other braindead web browsers do? They make a separate request for each file. But heay, never mind all those numerous connections to ad servers to retrieve marketing garbage (i.e. not the content you are after), lets concentrate on compressing HTTP headers instead. Brilliant.

It's trivial to use pipelining: 1. Feed your HTTP requests through netcat or some equivalent to retrieve the files and save them to a concatenated file, 2. split the concatenated file into separate files if desired, 3. view in your favorite browser.

No ad server BS.

Now that's "SPEEDY".

Post reply on HN