01:40:02 <donri> stepcut: http://geekandpoke.typepad.com/.a/6a00d8341d3df553ef0148c80ac6ef970c-pi
01:49:44 <stepcut> heh
16:41:12 <stepkut> hmm. For some reason warp is only archieving 11587 requests/second in the PONG test on my laptop
16:42:40 <donri> maybe check your conduit version?
16:43:06 <donri> i think there was a performance bug in an earlier version
16:43:12 <stepkut> ah
16:43:17 <stepkut> I seem to have 0.2.2
16:44:11 <stepkut> purging and reinstalling
16:44:43 <stepkut> alas, it seems to have installed the same version
16:44:54 <luite> do you have benchmarks of both somewhere?
16:45:24 <stepkut> both what?
16:45:53 <stepkut> I seem to recall warp doing around 70,000 reqs/second on this machine before.. but now it is stuggling to do 11,000
16:46:22 <luite> uh both warp and acme-http of course
16:46:27 <stepkut> oh
16:46:57 <stepkut> the best I have gotten out of warp today was 11,000 and for acme-http it was 201,896
16:47:15 <stepkut> I expected around 70,000-80,000 from warp though
16:47:31 <luite> hehe impressive numbers
16:47:38 <luite> though not from warp
16:47:42 <stepkut> it's easy when you cheat !
16:48:12 <donri> how is acme-http implemented?
16:48:16 <luite> better call it selective optimization
16:49:01 <stepkut> I removed warp, wai, conduits, etc. and do a fresh reinstall from hackage. :-/
16:49:25 <luite> maybe try yackage
16:49:30 <donri> maybe try cabal-dev :P
16:49:35 <luite> it has the yesod 1.0 release candidate
16:49:58 <stepkut> donri: http://patch-tag.com/r/stepcut/acme-http/snapshot/current/content/pretty
16:50:48 <donri> no pipes eh
16:51:02 <stepkut> nope
16:51:10 <luite> hehe
16:51:13 <stepkut> no pipes, conduits, or lazy IO
16:51:26 <luite> is the pipes backend somwhere in the repository already?
16:52:05 <stepkut> ... and very little else that is not required for the PONG benchmark :)
16:53:03 <donri> http://src.seereason.com/pipes-http-2/ i think?
16:53:24 <stepkut> yeah
16:53:34 <stepkut> there are a few different versions in there trying out different approaches
16:53:44 <stepkut> built against pipes-core
16:53:55 <stepkut> nothing really usable of course
16:54:29 <luite> ah tnx. things like exception handling and connection timeouting not implemented yet?
16:54:43 <stepkut> yeah
16:55:35 <donri> i understood from reddit there are optimization opportunities for pipes [proper], so benchmarks might not be indicative at the moment
16:55:47 <donri> ...but did you benchmark any of those?
16:55:55 <stepkut> yes
16:56:08 <luite> hehe the roadmap said that performance would be competitive already
16:56:25 <stepkut> one of them got 120,000 reqs/second.. but that will drop when timeouts, etc, are added
17:01:10 <stepkut> found the binary I used last time i benchmarked warp
17:01:18 <luite> ah the tricky points all sound familiar :)
17:01:34 <parcs`> perhaps conduits are slowing warp down?
17:02:02 <luite> parcs`: that's possible, I think 0.1 or 0.2 did cause a slowdown
17:03:15 <donri> stepkut: is acme-http just for fun / reference or are you actually considering not using pipes or anything like it?
17:03:19 <luite> actually I don't think there has been a lot of serious performance testing recently... and earlier not much more than the pong benchmarks.
17:04:28 <luite> and I think that it's quite likely that there are some things that are far from optimal... the snap guys already found that out for heist, and are rewriting it now
17:04:30 <donri> hey is continuous benchmarking on the scoutess roadmap?
17:04:42 <stepkut> donri: reference and experimenting
17:04:49 <stepkut> donri: yes, CB is on the roadmap
17:06:05 <stepkut> donri: the aim for acme-http is to try to identify what the bottle necks are in a simplied environment
17:06:19 <stepkut> donri: and to establish what the upper boundary of performance is
17:06:19 <donri> yea
17:06:27 <alpounet> we'll also write a dedicated OS for scoutess to run on, and port ghc to that OS
17:06:33 <donri> what i meant by "for reference" :)
17:06:40 <stepkut> so.. adding more cores made warp perform worse
17:07:16 <luite> hm that's interesting
17:07:25 <donri> alpounet: meh, just port scoutess to emacs
17:07:35 <luite> maybe due to the timeout variables
17:09:48 <stepkut> ok, so 51346.6 req/s for warp, and 218818.6 req/s for acme-http
17:13:24 <donri> now write pong as an nginx module in C for comparison :)
17:14:12 <luite> ouch ;p
17:14:16 <stepkut> no thanks
17:14:27 <luite> donri: why not write your own tcp stack instead
17:14:40 <donri> there's a web server that runs as a kernel module i recall
17:14:57 <luite> yeah, tux
17:15:00 <donri> yea
17:15:01 <luite> dunno if it's used anymore
17:15:55 <parcs`> stepkut: what program do you use to benchmark?
17:16:04 <luite> I guess nginx can easily saturate a gigabit connection without being a kernel module
17:16:05 <stepkut> httperf
17:16:14 <stepkut> https://patch-tag.com/r/stepcut/acme-http/snapshot/current/content/pretty/README.md
17:42:38 <luite> not bad, what kind of system?
17:48:13 <donri> stepkut: you know people are going to take the acme-http announcement as an april's fools
17:48:25 <Entroacceptor> I did
17:48:31 <stepkut> Lenovo T420 laptop. quad-core i5.
17:48:40 <stepkut> 2.5GHz.
17:49:00 <Entroacceptor> haha, michael's comment is great
17:49:01 <Entroacceptor> That's awesome! I think you should pair this up with the /dev/null
17:49:05 <Entroacceptor> datastore and then you'll be truly webscale!
17:49:08 <Entroacceptor>                                                                                                                                                                          
17:56:00 <luite> hmm, I still have my reservations about the /dev/null datastore though, can we be sure that it has truly not stored any data when a commit action returns?
17:56:12 <stepkut> http://hackage.haskell.org/packages/archive/acid-state/0.6.3/doc/html/Data-Acid-Memory.html
17:58:39 <mightybyte> stepkut: Woo hoo!  Loving acme-http.
17:58:47 <stepkut> mightybyte: :)
17:59:25 <mightybyte> As the creator of the pong benchmark (at least for Haskell web frameworks) I give my whole-hearted approval. :P
17:59:27 <stepkut> mightybyte: silly *and* useful
17:59:30 <mightybyte> Yes
18:00:26 <stepkut> like the real frameworks, it seems to consume too much RAM under high load, and also seems to not perform well when you crank the --rate up to 9000
18:00:27 <mightybyte> Maybe all Haskell web server developers should be forced to swear that all benchmarks they publish will include acme-http in the results
18:01:34 <stepkut> with around 5 more lines of code, acme-http could return real Responses aside from just PONG
18:02:15 <stepkut> there is a constructor for that, it is just unused
18:02:26 <mightybyte> Oh, you actually have a Request data type?
18:02:29 <mightybyte> What were you thinking?
18:02:34 <stepkut> yes
18:02:40 <mightybyte> 1. Open socket
18:02:41 <stepkut> it actually does more more than it really needs to even now
18:02:44 <mightybyte> 2. Drop all bytes on the floor
18:02:46 <mightybyte> 3. Write pong
18:02:55 <stepkut> pipelining makes things trickier though
18:03:02 <mightybyte> Ahhhh, true.
18:03:02 <stepkut> you have to know how many times to write PONG
18:03:11 <mightybyte> Yeah
18:03:15 <stepkut> also, I started by modifying some code I already had
18:03:33 <luite> hmm, writing pong until the connection is closed doesn't work?
18:03:35 <stepkut> at the very least you need to count the number of lines that start with GET
18:04:20 <stepkut> but, that level of cheating is probably less useful
18:04:57 <stepkut> I actually do intend to use it for figuring out some of the low-level performance issues that have been bothering me
18:05:08 <mightybyte> This may be the only acme- package that is actually a positive contribution to society.
18:05:11 <stepkut> :p
18:05:41 <mightybyte> Oh yeah, it really is useful.
18:06:16 <mightybyte> If for nothing else than to help people know how little meaning pong has.
18:06:55 <stepkut> :)
18:07:15 <stepkut> gotta run, bbl.
18:57:59 <donri> I wonder if the memory backend is useful as a cache, as opposed to something like plain stm or whatever... any gains?
20:47:23 <stepcut> donri: when replication is available, that would been an advantage
20:48:07 <stepcut> donri: share session information across a cluster, but don't log transactions to disk
20:48:24 <stepcut> donri: assuming there is nothing in your sessions that you would care about losing
20:56:17 <donri> wouldn't replication be a separate backend, disk-backed?
20:56:37 <donri> more interesting would be a memory-backed sharding backend perhaps?
23:37:58 <donri> luite: http://pnyf.inf.elte.hu:8000/UsersGuide_en.xml is that anything like what you're doing?