[Haskell-cafe] Haskell and concurrency
S. Alexander Jacobson
haskell at alexjacobson.com
Fri Jun 25 16:03:28 EDT 2004
On Fri, 25 Jun 2004, Simon Marlow wrote:
> Concurrent Haskell is designed to provide exactly the kind of
> lightweight concurrency you're after. It won't be as quick as a custom
> application-specific threading model in the way you describe, but it's a
> *lot* faster than using one OS-thread for each thread in your system.
> And if you find it to be still too slow for your application, we know of
> several ways to speed it up...
That's exciting. I am currently working on a
web-appserver framework that relies on concurent
Haskell (hence all my postings to the list about
concurrent haskell issues).
My theory is, given that you were able to achieve
~1000 requests/second in 2000, I should be able to
serve 10k HTTP requests per second on a regular
modern beige box. (~5m unique users at 1 visit/day
10 clicks per visit 10 request per click). If I
need less than 5k of server state per visitor then
I can operate a fairly substantial web site on
e.g. a 32GB Dell PowerEdge for under $50k ($.01/user)!
I currently have working:
* ACID semantics on an abstract serializable state
* each request must encapsulate the entire transaction
* requests and state must be instances of Read/Show
* state must fit in memory (though this is looser than it appears)
* in order execution of all sideeffects
* multiple sideeffect queues
* at least once execution of all sideeffects
* very basic HTTP serving framework for these apps
(SMTP framework coming soon)
* a basic relational database (not yet serializable)
that will eventually be used as a concrete state
I am now working on an application to run on the
framework and use these features. I'll post
when the design is more proven and its time to
reach those performance levels.
S. Alexander Jacobson mailto:me at alexjacobson.com
More information about the Haskell-Cafe