Xing's Weekly Tech Reports

My primary focus during the past week is improve the performance of event handling system on the java server. Context: We use one thread for processing room transaction related user actions. For instance, user move from one room to another. I added instrumentation for profiling data a few weeks ago and noticed that user disconnect is taking a long time to process while other transactions on the thread is usually done with 5ms. I added timer for sections of code that processes such even and ran profiling on production this week, and the result is astonishing. The majority of the time was spent on a synchronized block. In short, we kick off a call to update database on a different thread and move on with the current thread, and the next thing current thread does is to synchronize on user object. Unfortunately the database updater job locks the user object as well so essentially we're doing the database update on the same thread. And the worst thing is, the lock in database upd...

Trying to back fill a few weeks of tech reports before I forgot what I did: Spend 2 weeks assessing 2 libraries:   - HikariCP: https://github.com/brettwooldridge/HikariCP  - MariaDB Connector/J: https://github.com/brettwooldridge/HikariCP Context: Moving our database from mysql to AWS aurora and MariaDB is the recommended driver library. HikariCP is the most popular jdbc connection pool library and I'm thinking about upgrading from BoneCP to HikariCP. HikariCP: Upgrade was fairly simple and configuration can be easily translated to the matching configuration in BoneCP.  The major blocker for me is performance: tested HikariCP integration production environment and compared result to BoneCP, queries using HikariCP is consistently slower than queries using BoneCP. A frequently used simple select (for auth) takes on avg 1ms with BoneCP, but 2ms on HikariCP, another frequently used update query takes 2ms with BoneCP but 3mc with HikariCP. ...

Spent the week re-writing memcached accessor & configuration for our java server to support clustering. Initiative of this project: Multiple memcached clusters are used in my project and some of them need to be accessed by multiple services written in different languages, one of which being PHP. The old accessor does not support clustering at all, not even to mention ketama consistent hashing (on the roadmap). While other services do utilize clustering for memcached, the java server accessor create one memcached client per host in the cluster and run a multi-write &/ multi-read. On top of that manual hashing was done to decide which cluster a particular key goes to (based on an additional parameter, for instance, user id) Old format: memcached.name=<cluster_name> memcached.hosts.0=<mc00, mc01> memcached.hosts.1=<mc02, mc03> To fully utilize clustering support from memcahed library, a new format was proposed: New format: accessor.<accessor_name...

Starting from today I'm going to write one blog post per week to keep track of what I've achieved over the week on tech. This will be helpful to me when I need to look at thing back in time and recollect my highlights(hopefully)