On 20.02.2012 13:31, Anca Vamanu wrote:
On 02/20/2012 01:47 PM, Klaus Darilion wrote:
I see now an opportunity to improve the performance because of this behavior - having a mode in which to read from memory for Subscribes, but always read from DB for Publishes.
What if publ_cache=1. What really happens on incoming PUBLISH?
I have not read the code but I suspect with subs_db_mode=3 and publ_cache=0 the module does (without permissions checking):
incoming PUBLISH without e-tag: INSERT INTO presentity .....
incoming PUBLISH with e-tag:
add here query to verify if the publish record exists: SELECT * FROM presentity WHERE etag=..
UPDATE presentity ... WHERE etag='..' AND ......
Is the SELECT really necessary? If only UPDATE is done, and UPDATE returns '0 rows' affected then respond with 412.
incoming SUBSCRIBE without to-tag: INSERT INTO active-watchers ... SELECT * FROM presentity WHERE ....
incoming SUBSCRIBE with to-tag:
add there the query to verify if the subscribe dialog exists: SELECT * FROM active_watchers WHERE ..
UPDATE active-watchers ... SELECT * FROM presentity WHERE ....
same here. If the subs_db_mode=3 the SELECT could be avoided and send back 481 in case of 0 affected rows.
Thus, during normal operation the SELECT query could be avoided - which safes at least 1 RTT between PS and DB. On the other hand, during "abnormal" operation (lots of 481 responses), the UPDATE query may take longer than the SELECT query.
Maybe this is an area where noSQL DBs could speed up look-ups and updates.
And you have all the operations that are performed with with subs_db_mode=3 and publ_cache=0;
So what changes if publ_cache=1?
If publ_cache=1 the performance improvement happens when a Subscribe comes. Before doing the query in the presentity table, a check in the publish cache is made to see if there are any known active publications for that presentity. This way the query in presentity table is made only when there is something to retrieve from there.
This could be extended to help with the read query when a Publish with e-tag comes. Now the etag is not stored in cache, only the presentity uri.
OK, I understand it now.
Thanks Klaus