Try our new documentation site (beta).
Performance Considerations on a Wide-Area Network (WAN)
While using Gurobi Compute Server doesn't typically require you to make any modifications to your code, performance considerations can sometimes force you to do some tuning when your client and server are connected by a slow network (e.g., the internet). We'll briefly talk about the source of the issue, and the changes required to work around it.
In a Gurobi Compute Server, a call to a Gurobi routine typically results in network messages between the client and the server. While each individual message is not that expensive, sending hundreds or thousands of messages can be quite time-consuming. Compute Server makes heavy use of caching to reduce the number of such messages. However, not all methods are cached. As a result, we suggest that you avoid doing the following things:
- Retrieving the non-zero values for individual rows and columns of the constraint matrix (using, for example, GRBgetconstrs in C, GRBModel::getRow in C++, GRBModel.getRow in Java, GRBModel.GetRow in .NET, and Model.getRow in Python).
- Retrieving individual string-valued attributes.
Please note that you don't need to be too concerned about this issue. Caching generally works well. In particular, when building a model, our lazy update approach avoids the issue entirely. You should feel free to build your model one constraint at a time, for example. Your changes are communicated to the server in one large message when you request a model update.
Of course, network overhead depends on both the number of messages that are sent and the sizes of these messages. We automatically perform data compression to reduce the time spent transfering very large messages. However, as you may expect, you will notice some lag when solving very large models over slow networks.
