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 often results in a network message 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, and this caching generally works well, so you don't need to be too concerned about it.
Furthermore, 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.
Having said that, we should add that not all methods are batched or 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++, GBModel.getRow in Java, GRBModel.GetRow in .NET, and Model.getRow in Python).
- Retrieving individual string-valued attributes.
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.