Comments on: Great Concurrency -> Better Webapps

By: Yariv

Yariv — Sat, 10 Nov 2007 19:55:41 +0000

I know it’s not an optimally efficient solution, but it’s good enough, at least for a site that doesn’t get thousands of requests/sec. Having a background process that listens for updates and executes queries only saves you 320 bytes or so of RAM (the size of an Erlang process) per request (Erlang processes are dirt-cheap). If the background process also batched updates, the efficiency would be greater because it would result in fewer queries. Instead of updating every N hits, I would make it update every N seconds. This way I would throttle the number of update queries while guaranteeing a time ceiling for persisting even low numbers of updates. However, this is an optimization that I don’t think Vimagi requires right now.

By: jherber

jherber — Sat, 10 Nov 2007 18:03:28 +0000

this is a bad approach.

it is terribly inefficient. why not launch a persistent process that does nothing listen for update request messages and write to the db. messaging in erlang is asynchronous, so the code doesn’t block.

*bonus* the other thing you are doing wrong is updating the db on every hit. you should update the database after say every N hits, where N is a small number who’s precision you are comfortable with losing if you have a catastrophic failure (10? 100?).

please keep updating your blog. erlang is looks very promising so there is building interest in your thoughts, prolbems, and solutions.

By: Yariv

Yariv — Thu, 11 Oct 2007 05:56:40 +0000

@Nathan, I’ve read of benchmarks where people ran 1-2 million Erlang processes on a single box. The 80,000 number came from Joe Armstrong’s benchmark of Yaws, which showed Yaws can support ~80,000 mostly idle processes with relatively stable total throughput. However, that doesn’t mean you can’t run more than 80,000 processes on a server.

By: bmert

bmert — Sat, 06 Oct 2007 18:59:22 +0000

@Bryan, how do you handle sessions while updating facebook user profiles. Do you need a permanent session for that?

By: Nathan Youngman

Nathan Youngman — Mon, 01 Oct 2007 03:13:23 +0000

@Yariv: But is it worth it to write a web application in a concurrent way? With a lot of traffic, it might be better to dedicate those 80,000 lightweight processes to individual requests, no?

I guess it depends on how much can be gained in response time. Perhaps on big reports with a lot of data fetching. If the queries can’t run any faster, it could be fairly trivial to run them asynchronously.

I’m curious about a few things… like how Yaws compares to light-weight web servers like Lighttpd or Nginx.

Also, has anyone considered working with Flex/Flash/AMF3? LiveCycle Data Services has the idea of users concurrently editing data-grids and such, but it’s pricey and from what I’ve heard, not the most stable yet. Erlang seems like a good fit for a server that handles the large number of connections… and could provide a full-stack from web server down to data store. Flash seems a little more well-suited for a lot of client-side concurrency, and open connections (Comet). Though perhaps that isn’t desirable, since concurrency in Flash isn’t as nice to work with as Erlang (mind you, neither is JavaScript).

- nathan.

By: Yariv

Yariv — Sun, 30 Sep 2007 01:38:30 +0000

The traffic numbers aren’t very high. I don’t know exactly why MySQL started timing out, but it may be because the VPS has little RAM and/or the MySQL server isn’t well tuned. There was definitely a gradual degradation of response time from MySQL when the site went live, though.

I know, this captcha plugin sucks. I tried finding a better one but couldn’t find one that worked well.

By: ajrw

ajrw — Fri, 28 Sep 2007 19:38:42 +0000

Out of curiosity, how much traffic are we talking about here?

Your spam prevention input box keeps sending me back to the comment box when I try to type in it, I had to copy and paste the captcha.

By: Yariv

Yariv — Fri, 28 Sep 2007 09:09:35 +0000

@Nathan: I think you’re on the right track. If your webpage has independent components that can be rendered in parallel, why not use concurrent processes to speed things up? It’s certainly doable.

@Robin: Mnesia is great for datasets that fit in RAM, but it’s not so great for high-volume data that should be stored on disc. The good thing about Erlang/ErlyWeb is that you can have the best of both worlds. Vimagi, for example, uses MySQL for persistent storage and Mnesia for storing session data.

By: Robin

Robin — Thu, 27 Sep 2007 01:11:12 +0000

Good point: Significant tasks that are not in the critical path should be executed concurrently, which is trivial in Erlang.

I am sure many ErlyWeb developers are facing a design decision: SQL or Mnesia.

If Great Concurrency -> Better Webapps, then why does Vimagi opt for SQL, when Mnesia is there at your fingertips?

By: Nathan Youngman

Nathan Youngman — Thu, 27 Sep 2007 00:16:03 +0000

Yariv,

I haven’t actually learned Erlang yet, just have been reading *about* it. I would be interested in your thoughts on implementing the above sort of things?

One could also spawn a task to load up the various templates (views). Could you then “block” until the model data was ready… do a quick variable substitution and return the response?

When a query finishes, it can message the main process, right? But how does it ensure that all tasks it sent off are done and ready?

- nathan.