Proper way of calling service in rospy

Question

I have designed a service and I am using it without any problem. However, I am having doubt about the client implementation in rospy. I am calling this service many times and hence, I am concerned about its implementation. Please see the code snippet below:

class MyServiceClient:
    def __init__(self):
        self.service_name = 'my_service'
        rospy.wait_for_service(self.service_name)

    def response(self):
        try:
            service = rospy.ServiceProxy(self.service_name, my_service)
            service_response = service(my_param)
            return service_response.data
        except rospy.ServiceException, e:
            print 'Service call failed: %s' % e
            return None

my_service_client = MyServiceClient()
for i in xrange(100):
    response = my_service_client.response()

I want to know if creating service proxy object everytime is a good choice or not? Or should it be a class variable declared inside __init__ constructor as self.service = rospy.ServiceProxy(self.service_name, my_service).

Please note that I am using Python 2.7 in ROS Indigo on Ubuntu 14.04 LTS PC. Thank you very much.

---

Originally posted by ravijoshi on ROS Answers with karma: 1744 on 2017-11-20

Post score: 1

Answer 1

The key here is persistence. Both of the object as well as the connection. Persistence impacts both performance as well as rosbustness.

I think this is pretty well covered by the documentation of ServiceProxy.

To avoid duplicating content I'm referring you to my answer to #q108256.

---

Originally posted by gvdhoorn with karma: 86574 on 2017-11-20

This answer was ACCEPTED on the original site

Post score: 2

---

Original comments

Comment by ravijoshi on 2017-11-20:
Thanks a lot. I learned something new. The service is running on the same computer with 8GB RAM and Intel i7 x64 processor. I think that the best way is to declare it inside __init__ constructor as self.service = rospy.ServiceProxy(self.service_name, my_service, persistent=True). Isn't it?

Comment by gvdhoorn on 2017-11-20:
I think you're implying with "on the same computer" that there should not be any problem in using persistent connections, but that would only consider network problems as a cause of failure. I'm not sure it can be assumed that locally running service servers will be less susceptible to crashes ..

Comment by gvdhoorn on 2017-11-20:
.. or other problems with might result in them becoming unreachable than remote ones.

Persistent services will be more performant as they avoid renegotiation of the connection, but at the cost of potential brittleness. I'm not sure I can tell you whether in your specific case one would be better ..

Comment by gvdhoorn on 2017-11-20:
.. than the other.

Btw: if you have a scenario where you find yourself calling a service periodically at a (relatively) high rate, it may be an indication that a topic (ie: dataflow, event-based) could be a more suitable design.

Comment by gvdhoorn on 2017-11-20:
Additionally: whether persistent services make sense from a performance perspective will also be dependent on the ratio of time spent for lookup & negotiation of the connection versus the time spent in the actual service implementation (ie: the part that does the actual work).

Comment by ravijoshi on 2017-11-20:
Thank you very much for the detailed explanation. I am thinking about it.