When using an SAP TM external GIS to determine distances and duration between locations (see here: http://scn.sap.com/community/scm/transportation-management/blog/2012/10/08/monday-knowledge-snippet-mks–01-can-i-use-different-distances-for-planning-and-charge-calculation). it is recommended to use the SAP TM internal buffering by adding the standard buffering methods to your distance determination strategy.
There are 2 interesting settings which can influence the performance of this function in the customizing under SAP Transportation Management -> SCM Basis -> Master Data -> Transportation Lane -> Distance and Duration Determination -> Maintain Global Settings for Buffering of DDD
IMG path to DDD buffer settings
DDD buffer settings
Direction Irrelevant: With this setting you can tell the system that the distance/duration from Location A to Location B equals the distance/duration from Location B to Location A. This might not always be the case (for example inner city transports can vary), but i guess for most of the TM scenarios it is fine. And it save a lot of external calls, buffer entries and runtime when checking the DDD buffer. Its not set by default, but I would recommend to use it.
Last Access Update: When you set this flag, the system enables the automatic deletion of out-dated buffer entries. For example you have a scenario, where you rely on really accurate data (which might be updated week by week), you can trigger this here. The system will use the buffered entries until they are out-dated. As soon as this happens, it will call the external GIS for an updated value when it is next requested. From my perspective this is really rarely the case and I would rather not set it. I requires a timestamp check each time the buffer is accessed and slows down the distance determination. As said in the beginning, it is in general recommended to keep the buffer up-to-date. So I would go for a weekly (maybe on Sunday) buffer update using the report /SCMB/DDD_BUFFER_MAINT. Here you can determine for example only missing buffer entries, or overwrite existing ones with quite a lot of options.
By the way, there are two other reports of interest in this area:
With report /SCMB/DDD_BUFFER_CLEANUP you can clear the buffer tables or check for inconsistencies. Be very careful when clearing the table: Depending on your scenario it can take quite a whle to fill it again completely.
You can use report /SCMB/DDD_BUFFER_TRANSFER to transfer the distance buffer your one system to the other. The distance buffer is based on coordinates, which are of course not system dependend. To enable a transfer, you need the same DDD strategy in both systems. The report is capable of creating the required speed profile (which matches the buffer entries to means of transports).