I think what you're doing is great. I understand you're using ab for these tests, right? What are the actual settings that you are using?
Also, I'd like to mention that what these tests are showing is the behavior of the server under constant load (constant frequency in the arrival times of the requests, and constant load attached to each request). This is not what happens in reality though, and servers that do well under a constant distribution of requests might not do that well (at all) under a Pareto distribution of both arrival times and load (a real load that a server gets is very similar to a Pareto http://en.wikipedia.org/wiki/Pareto_distribution). Under a Pareto load a well crafted event-based server that has bounds on the number of threads used (and maybe other resources) might significantly outperform a 1-thread-per-request server. Unfortunately, I don't think ab can test these scenarios. I built a tool sometime ago while working at UCSB that would do exactly this. I will look into whether I can dig it out and opensource it. Toni. On Sat, Jul 10, 2010 at 8:59 AM, David Nolen <dnolen.li...@gmail.com> wrote: > On Fri, Jul 9, 2010 at 11:08 PM, tbatchelli <tbatche...@gmail.com> wrote: >> >> Hi David, >> >> Out of curiosity, how are these tests connecting to the database, >> especially in the cases of MongoDB and CouchDB? In the case of CouchDB >> you're clearly using HTTP in a way that it creates one connection per >> request, I believe. In the case of MongoDB, the driver provides a >> connection pool (default of 10) and these connections are kept alive >> and reused between requests. You might be comparing the difference >> between making one connection per request vs. pipelining many request >> over an already established connection... >> >> Toni. > > One big problem with the PostgreSQL and MySQL numbers is that they don't use > pooling. I found a simple example of adding that to the PostgreSQL code and > done so, though I'm still hunting for a MySQL example :P > As far as CouchDB I'm using Richard Newman's nice clj-apache-http library > which is a wrapper around Apache HTTP Client. It reuses connections by > default. However Iooking into this some more, the connections might still be > the bottleneck - I'm looking into using multithreaded client connection > manager. Will be interesting to see what numbers come up after that. > If the whole premise of the blog post turns out to be flawed at least we > have a page documenting the basics of how to use Clojure with several dbs ;) > David > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- Antoni Batchelli - twitter: @tbatchelli , @disclojure --- email: tbatche...@gmail.com ----- web: tbatchelli.org , disclojure.org -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
