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:
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 http://www.rubydoc.info/github/rack/rack/master/file/SPEC
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/config.ru, 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 davaz.com, 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
Removed
After a first refactoring all, but one unit tests pass again. Davaz.com 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 http://rack.rubyforge.org/doc/classes/Rack/Session/Cookie.html. An example is show in http://chneukirchen.org/repos/rack/lib/rack/session/cookie.rb.
Session and App are not clearly separated. Must think harder on howto seperate them.