with only two layers, because additional time is required for cloning the application into an instance and *rsync*ing the third layer (see Figure \[fig:lxcMigrationTimesforApps\]). However, the service downtime (which is usually the more critical factor for MEC applications) remains the same no matter whether the application is found at the destination or not, because the service is suspended only after the application layer (containing an idle application) has been transferred.

Therefore, it is apparent that the benefits of the three-layer model need to be balanced with any trade-offs incurred. Factors such as how frequently the application is used and how much service downtime impacts the user experience should be taken into account when deciding whether to use two or three layers. Such decisions have to be made based on application characteristics. For example, it may be better for applications with small installation sizes and intensive RAM utilization to use only two layers for quicker migration.

A practical implementation of an MEC system can support both two-layer and three-layer models, since their underlying mechanisms are similar. The system can perform some simple profiling of applications and historical migration performance, and it can decide whether to use two or three layers on 