Ask Your Question

Revision history [back]

Keyset Fetch Performance?

Once a day, we're fetching a full RETS keyset for the purposes of detecting and pruning records that have been deleted. It looks like it takes almost 3 hours to pull a full keyset from the system, even when selecting only the listing key, status field, and modification timestamp field.

This is more or less the case for all MLSs in Michigan, but we're generally able to grab the equivalent in other (even of this size) markets in a few seconds or minutes, rarely ~30 minutes. Is there something wrong with our query, or is this in line with the servers' usual performance? We're issuing a (L_Type_=|0,1,2,3,6,7),(L_ListingID=0+) DMQL2 query since we only include a few property types on our site. While we're pulling this keyset, we temporarily pause our incremental data pulls, and so service is degraded for our customers during this operation.

Account UfxJsWDk at http://mimls.rets.fnismls.com/rets/fnisrets.aspx/MIMLS/login?rets-version=rets/1.7.

Keyset Fetch Performance?

Once a day, we're fetching a full RETS keyset for the purposes of detecting and pruning records that have been deleted. It looks like it takes almost 3 hours to pull a full keyset from the system, even when selecting only the listing key, status field, and modification timestamp field.

This is more or less the case for all MLSs in Michigan, but we're generally able to grab the equivalent in other (even of this size) markets in a few seconds or minutes, rarely ~30 minutes. Is there something wrong with our query, or is this in line with the servers' usual performance? We're issuing a (L_Type_=|0,1,2,3,6,7),(L_ListingID=0+) DMQL2 query since we only include a few property types on our site. While we're pulling this keyset, we temporarily pause our incremental data pulls, and so service is degraded for our customers during this operation.

Account UfxJsWDk at http://mimls.rets.fnismls.com/rets/fnisrets.aspx/MIMLS/login?rets-version=rets/1.7.