B4J Question How to define HttpSession.Id in jRDC2 client?

Discussion in 'B4J Questions' started by Diceman, Aug 14, 2019.

  1. Diceman

    Diceman Active Member Licensed User

    I am using jRDC2 and it is working fine. I am trying to write a stress test program in a single B4J client that simulates 100 different users accessing the jRDC2 server. The only problem is the server gets the 100 different requests and they all have the same HTTPSession.Id.

    Is there a way for the client to override the builtin session id like "node01s01isq9met0v1xc6zb51r2njy9" so it sends requests to the server using different session ids?

    This would only be done for this stress testing app. I could assign simple session id's like "001", "002" etc, or generate them with the proper syntax "node ....". It doesn't really matter.

    Is this possible?

  2. OliverA

    OliverA Expert Licensed User

    I wrote a test client for some jRDC2 testing in B4J non-gui mode. I then had a batch file start as many sessions of that client for me. I'm attaching source for both the client and the batch file and hopefully it gives some inspiration. Please note that this client was adapted for a heavily modified jRDC2 server that I was using to test various SQL pooling options (H2, HSQLDB, Hikari, Tomcat, Vibur, and 3CP0) and pooling/JDBC properties. I was also testing various DB engines (H2, Apachy Derby, SQLite, HSQLDB, and MySQL). I'll throw in the config.properties file so you can find the SQL statement that was used for testing. It's not a canned project for you, but it may help you (hopefully) in your endeavors.

    Attached Files:

    José J. Aguilar and Diceman like this.
  3. Diceman

    Diceman Active Member Licensed User

    Thanks for the files. I will dissect it tomorrow to see what I can scavenge. :rolleyes:
    BTW, have you published the results of your benchmark? Like which pooling option was superior and which was the worst? I noticed you did not test PostgreSQL which I am using on the server.
  4. OliverA

    OliverA Expert Licensed User

    One of the things I was curious about when I build this jRDC2 server is to see if SQLite is really that bad when it comes to concurrency. Well, it's not and it actually beat the pants of all the other solutions. When it came to pooling, I really did not see huge differences in the various pooling options. The pool size seemed to be optimal between 8-10. Anything above that did not improve anything (in my limited testing). The nice thing about H2, Apache Derby, SQLite and HSQLDB is that they are embedded DB's that really need no administrating. SQLite is fast, memory efficient, but type (SQL types) poor. H2 (successor to HSQLDB?) is very type rich, is not much slower, but is a memory hog compared to SQLite. MySQL requires a separate server daemon (locally or remote) but is actually relatively memory efficient (in comparison to H2). Pooling is definitely required when using MySQL on a remote server (with pool sizes between 8-10 being optimal). I'll dig for some data tomorrow and post some of it. Please note that the data is very specific to my testing and your test environment may discover something else. I could post the jRDC2 server, but it's a tad rough. It's functional, but not 100% finished. You can see the options that were allowed to be tweaked in the config file that I posted above.
    Diceman likes this.
  5. Diceman

    Diceman Active Member Licensed User

    If the database (Sqlite, PostgreSQL, etc.) is on the same machine as the web server, I doubt you will see much speed difference between Sqlite and the client server database. (BTW, putting the db on the same machine as the web server is a security risk if you are storing sensitive data.) If the transaction duration is kept at a minimum and there are very few writes to the db, then SQLite will be faster because it has much less overhead than a C/S db. The problem with Sqlite is it uses database locking so if you have 10 or more clients updating any table in the database that takes longer than 100 ms each, you will have locking contention. The clients will be sitting and waiting for the db lock to be released because one slow client is writing to the db. If the database is on a separate computer, then C/S databases will be more efficient at returning only a subset of data over the network. C/S databases also have stored procedures & triggers so a lot of the "intelligence" can be offloaded to the C/S db where it runs faster instead of running it on the client. I would use Sqlite on a web server if 95% of the operations are Reads, and there are less than 100 queries/second. Anything more than that and I would use a C/S database from the outset because I don't want to be rewriting my app for C/S after it has gone live. Just my 2 cents.

    Thanks for the testlauncher. I ran it today and it has given me a few ideas on how I can implement it on my existing benchmark pgm. :D
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice