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

Websocketd

websocketd.com

Post reply on HN
Print view View original

211–220 of 233 posts

Re: Websocketd

#211

Post by laumars »

IgorPartola wrote: post #209
laumars wrote: post #207

Earlier quoted context omitted.

More than you’d assume, once you factor in search engine crawlers, miscellaneous bots and automated tools that bad actors run to probe websites looking for vulnerabilities. However if still expect CGI to stand up against that. Performance arguments aside and given the type of site you describe, wouldn’t it be more convenient for the developer to use Wordpress or one of those website builder as a service things instea…

Point taken on the bots but the static part shouldn’t go through the CGI anyways. The irony of decrying poor performance yet suggesting WordPress is pretty priceless :) I agree that most people would be better served with Squarespace/Wix but I run into the situation or static site + 1-2 bits of dynamic form processing frequently enough to warrant having a simple solution for it. When the site doesn’t warrant spending…

> Point taken on the bots but the static part shouldn’t go through the CGI anyways.

Event the non-static stuff will be hit by bad bots (and by "bad bots" I mean any crawler - malicious or otherwise - that doesn't obey robots).

> The irony of decrying poor performance yet suggesting WordPress is pretty priceless :)

It's not ironic at all. I've done extensive benchmarking on this in a previous job and discovered that even the out-of-the-box Wordpress experience would easily outperform the same equivalent in CGI - and that's without taking into account all the caching plugins available for Wordpress (sure you could optimize your CGI as well, but you'd have to write all that yourself where as with Wordpress it's a 2 minute install).

Even DB and page caching aside, you still have a problem with CGI forking for each web request where as with PHP you have mod_php (Apache) or php-fpm which do opcode caching and such like. This alone can make a dramatic difference once you start piling on the requests.

> When the site doesn’t warrant spending money on, sometimes a shared host + CGI is just right. But I think this is for some very rare cases. Most people should outsource these types of headaches.

Do shared hosts even allow CGI? I'd have thought that was a bit of a security faux pas for a shared host. In any case, almost all of them support PHP (and those that don't are special purpose ones for node or other frameworks) so there's no forced requirement to use CGI even on shared hosting. In fact I'd go further and argue that PHP is even easier to write than CGI so you're better off using that regardless of whether CGI is available.

Disclaimer: I pretty much hate PHP as a language and not too fond of Wordpress either. But I'm being pragmatic in this discussion and leaving out my own personal biases. Personally I wrote my blog in Go (which, as it happens, was originally written in CGI/Perl, then ported to Apache+mod_perl before being ported to Go about 9 years ago and where it's been running ever since)

Re: Websocketd

#213

Post by karl_p »

icebraining wrote: post #197
jasonhansel wrote: post #178

Earlier quoted context omitted.

Question: why doesn't Amazon just use the standard FCGI interface, then?

Maybe they are; as far as I know, the protocol they use to communicate with the worker isn't specified, all they say is "implement a function with this signature, then import our SDK, and it will call your function". This gives them the flexibility to switch protocols at will, at the cost of having to implement these SDKs. That said, building a FCGI "bridge" isn't hard, it's just that nobody cared enough to do it.

They have specified the lambda runtime. https://docs.aws.amazon.com/lambda/latest/dg/runtimes-api.ht...

Basically: your instance POSTS to an endpoint to get/reply to requests, one at a time.

I can't wait until you can specify that a lambda instance can handle a certain # of requests in parallel. Ex: things just blocked on IO/DB. That would make better use of your RAM.

Re: Websocketd

#214

Post by jasonhansel »

icebraining wrote: post #197
jasonhansel wrote: post #178

Earlier quoted context omitted.

Question: why doesn't Amazon just use the standard FCGI interface, then?

Maybe they are; as far as I know, the protocol they use to communicate with the worker isn't specified, all they say is "implement a function with this signature, then import our SDK, and it will call your function". This gives them the flexibility to switch protocols at will, at the cost of having to implement these SDKs. That said, building a FCGI "bridge" isn't hard, it's just that nobody cared enough to do it.

My new serverless-to-CGI bridge will be called "hipstercgid"

Re: Websocketd

#215

Post by rileytg »

hnarn wrote: post #100
rileytg wrote: post #28

i’ve been using this in production to stream logs to a web console (~2,000 sets of logs distributed across 4 server with about 350 active connections at a time) and have never had any issues

How do you know that you haven't had any issues?

we track errors both server and client side. only errors we routinely see are network issues.

Re: Websocketd

#216

Post by rileytg »

rileytg wrote: post #215
hnarn wrote: post #100

Earlier quoted context omitted.

How do you know that you haven't had any issues?

we track errors both server and client side. only errors we routinely see are network issues.

to be fair there could be silent failures, but after 4 years of daily use by people who are experts on these logs, we would have had at least a couple reports of missing lines.

we often download the files post viewing on streams also. mostly it’s exceptions so we’d easily notice missing lines in stacks

Re: Websocketd

#218

Post by kevingadd »

iforgotpassword wrote: post #118
geocar wrote: post #115

Earlier quoted context omitted.

The myth that fork is expensive is pervasive, and speaking to the ways that it is true†, well: performance is relative. fork() only takes around 8ms on my Linux machine and I can get 100,000 posix_spawn() per second there with 100MB RSS. That's "fast enough" for a large number of applications. †: fork() is a lot slower (over 20x) on Windows

Related: when I worked on a server (on linux) that would spawn threads for new connections that were mostly short lived, I tried to use a thread pool instead. Hand crafted, with push and pop both O(1). It was still mostly slower than just spawning a new thread every time.

It's generally considered the right move to just spawn your own thread for things like connections instead of pooling threads - people tend to think they should throw everything into a threadpool but it's not actually encouraged to do that for stuff like web server connections, compiles, etc unless the task is short-lived. I wish more people knew that going in :) Some threadpool APIs actually ask you whether the job is going to take a while and if it is, they function more as a job limiter - not 500 active threads all competing for CPU - than a thread reuser.

Re: Websocketd

#219

Post by geocar »

NathanKP wrote: post #183
geocar wrote: post #115

Earlier quoted context omitted.

The myth that fork is expensive is pervasive, and speaking to the ways that it is true†, well: performance is relative. fork() only takes around 8ms on my Linux machine and I can get 100,000 posix_spawn() per second there with 100MB RSS. That's "fast enough" for a large number of applications. †: fork() is a lot slower (over 20x) on Windows

I see this argument all the time but its not the fork() that is the most expensive anymore, its the actual program initialization after the fork(). If your app is non trivial (lets say a websocket based chat server that needs to persist messages to a DB and use pubsub to sync them to other processes) it probably needs a connection to a database, a connection to a cache server like Redis or Memcached, etc, or perhaps…

Then consider posix_spawn(), since it pays that cost, but then we have to pay IPC as well:

fasthttp(go) can do around 80k/sec on my laptop; dash(C) can do almost 88k/sec on my laptop†. As soon as dash does IPC, it drops to around 51k/sec, and as soon as it needs a reply, we're down to 25k/sec††. I see no reason to believe fasthttp would do any faster.

That means I'm spending around 70% of my time in IPC -- something posix_spawn() would let me avoid (if my application were designed to do so). My same laptop will do 100k/sec posix_spawn() so I'd find this difficult to believe (1-4 msec per call) fork() or exec() is the bottleneck for any application with this architecture. Do you think posix_spawn() represents 70% of your costs? If our goal is to beat 51k/sec requests, sure, but NodeJS on my laptop (btw) gets 10k/sec, so if it's a contender, I'd say posix_spawn() is as well.

† https://github.com/geocar/dash/blob/master/README.techempowe...

†† https://github.com/geocar/dash/blob/master/README.md

Re: Websocketd

#220

Post by geocar »

porpoisely wrote: post #189
geocar wrote: post #115

Earlier quoted context omitted.

The myth that fork is expensive is pervasive, and speaking to the ways that it is true†, well: performance is relative. fork() only takes around 8ms on my Linux machine and I can get 100,000 posix_spawn() per second there with 100MB RSS. That's "fast enough" for a large number of applications. †: fork() is a lot slower (over 20x) on Windows

Only 8 ms? That's slower than a ping. You were right about performance being relative. And of course the trade off between ease of development, use and performance. At the end of the day, practical considerations are going to determine what is "expensive".

> Only 8 ms? That's slower than a ping.

Also depends what you're pinging. I'm in the UK, so everything in America is 30-80msec away anyway.

Post reply on HN