When you say "real-time," you need to define precisely what that is. Assuming your app tracks multiple users on a map, if the information is delayed for a few seconds (or a few minutes), is that a problem? And what is the movement profile of users - are they usually moving fast, or slower? The answer to these questions will tell you what approach you should take.
Note that an approach that collects GPS information every second (or less) and sends information to the server will give you the best "real-time" degree (assuming you have some logic on the server to normalize the variations of the GPS signal), but it will probably consume so much user battery that the trend is that he / she uninstall the application.
Starting with the second question (user move profile). If most users are moving "slowly" (which is also a relative term - small position changes are increased if the zoom level of the map you are using is high), you can wait more than 10 seconds to collect the GPS position. If you know that the drive is fast, or that it is possible that the user may not be moving in a straight line, making several curves (for example, a running application, type the RunKeeper), where then the range should be reduced (also taking into account that the GPS signal has an error that should be incorporated).
Regarding the first question (how "real time" is information), if your application does not need precision in seconds, you can take longer to update the user's position in the web service. Note that this is orthogonal to GPS data capture - you may even be capturing the position every second (if necessary), but only transmit to the server every minute, for example.
Finally, like several questions, the answer is "it depends." You should collect GPS data as often as necessary, but not more than that. The same with updating data in the service - as frequent as I need, but nothing else.