view · edit · sidebar · attach · print · history

< Niklaus.20161214-sbsm-without-drb | Index | Niklaus.20161212-davaz-load-test >>



  • must respond well with increased load
  • Keep in Mind


Index must respond well with increased load

I am beginning to ask myself whether using a Drb-Process for SBSM is the correct solution for making a SBSM based web application perform well.

As far as I know the following considerations led to use Drb as a solution on how to handle multiple concurrent HTTP-Request from Apache:

  • Apache called mod_ruby in several parallel Unix processes
  • The DRB-process itself was a single Unix process using ruby threads
  • DRB allowed a separtion of the DRB and the apache process
  • With old ruby version < 2.0 many often uses datastructures like Hash and Arrays were not thread safe, wrapping them into a DRB-session allowed a thread safe solution

When I look at Webrick or other younger web services for ruby I see that none of them uses DRB.

We found yesterday with wrk a good, nice and easily customizable tool to stress test our web applications. Failures (at least for some classes of errors) be signalled as soon as wrk reports "Non-2xx or 3xx responses: <x>", when there should no 404 error responses for the visited URL.

Looking at the problems we had yesterday it seems to me that somehow in bin/davazd app threads are not correctly bound to the session object in the rack process. Also the current thread is not visible in the logs, which makes debugging harder.

As SBSM is not running in non Apache2 process, I think it might be possible to simplify the design by geting rid of the DRB process. Maybe we could also get rid of our session handling by using a rack based server which offer session as specified in

I will invest some time (< 1 hour) into looking whether I can use wrk to show errors when running the sbsm/test app alone.

Added a test/, test/sbsmd and test/wrk_visit.lua. Now I am able to run wrk -t12 -c4000 -d30s --script=test/wrk_visit.lua http://localhost:6789/ after having started test/sbsmd with the following result

Running 30s test @ http://localhost:6789/
  12 threads and 4000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     3.16s   215.70ms   3.25s    92.91%
    Req/Sec     5.62      4.91    18.00     79.27%
  1115 requests in 30.05s, 328.37KB read
  Socket errors: connect 0, read 0, write 0, timeout 58052
Requests/sec:     37.10
Transfer/sec:     10.93KB

Nr request per seconds is similar to, but we do not get any non 2xx/3xx responses. But visiting manually http://localhost:6789/ I did see that after visiting http://localhost:6789/de/page/about, then http://localhost:6789 the page content did not change. Trying to convert this into a (failing) test case. This was easy. See new test test_session_about_then_root.

While looking at test/test_application.rb I found that my commit 3df112ee6deda3fb9cf17a600229a7f26f524c6f from 7.12.2016 "Fix handling http_headers, e.g. 303 for redirects" masked a very important test, whether variables are handled correctly in a session. Therefore test_session_id_is_maintained passed, even when it should signal an error.

Pushed commits Fixed unit tests for session-hanlding and Make testing simple sbsm via wrk possible

As my new unit test fails and I do not have a log file, changing test_application.rb to create a log file, too. Afterwards I will start to eliminate the DRBsession from sbsm and replace it by a rack.session compatible alternative.

Pushed commit Added test.log for test/test_application and Made wrk visit 3 pages


  • lib/cgi/drbsession.rb and
  • lib/sbsm/drbserver.rb (Keep in mind how this scale. It allowed us to get rid of old sessions. Maybe I must replace its functionality later). Also was setting the persistence_layer.

After a first refactoring all, but one unit tests pass again. has some working pages, but login does not work. Therefore I want to get rid of all occurences of drb_uri and make the SBSM::App class not a derived from the SBSM::Session class. Also the SBSM::App class shall not contain an session variable, as it must handle many concurrent sessions. I also must get rid off all occurences of proxy.

I migrated the drbsession to a session_store, but I keep asking myself whether I should replace it altogether with a Rack::Session An example is show in

Session and App are not clearly separated. Must think harder on howto seperate them.

view · edit · sidebar · attach · print · history
Page last modified on December 13, 2016, at 05:33 PM