[sr-dev] git:master: modules_k/presence Fixed DB Storage Modes

[Klaus Darilion]

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