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?