[asterisk-dev] scalability issue with realtime lastms update on qualify state change

[Damon Estep]

> If you really are averse to the effect that saving lastms in the
> database causes, why don't you just remove that column from your
> realtime tables?  We've had this ability to remove columns that you
> prefer not to save in dynamic realtime since 1.6.2, and it sounds like
> this is, in effect, precisely what you'd prefer.
> 
> -Tilghman
> 

Can you help me understand what removing the column would do? I did not see anything in the code that would stop the database update attempt if the column did not exists. Would it not try, or would it just fail gracefully?

The problem is not having the data in the database, the problem is the OPTIONS packet processing latency as the result of having a lot of peers changing state and TRYING to update the database for every one of them. 

If removing the column will stop the attempt to update the database that would work, but if it just causes it to fail it will not.

I also recall something in the code that indicates lastms is a REQUIRED column, but maybe I misinterpreted it. I guess I need to look at the ast_check_reatime code.

ast_realtime_require_field(ast_check_realtime("sipregs") ? "sipregs" : "sippeers",
		"name", RQ_CHAR, 10,
		"ipaddr", RQ_CHAR, INET6_ADDRSTRLEN - 1,
		"port", RQ_UINTEGER2, 5,
		"regseconds", RQ_INTEGER4, 11,
		"defaultuser", RQ_CHAR, 10,
		"fullcontact", RQ_CHAR, 35,
		"regserver", RQ_CHAR, 20,
		"useragent", RQ_CHAR, 20,
		"lastms", RQ_INTEGER4, 11,
		SENTINEL);

Damon