I need a web service that provides elevation profile data between two coordinates with request rates at a minimum of 2000 requests per second but preferably at 5000 per second. The distance between the coordinates is on average 50 kilometers, and I need perhaps 10 or 20 elevation sample points between the two coordinates. What are the logistical and financial means to make this possible?

  • Anything is possible with enough investment. How many years of development and millions of dollars are you willing to spend? – Vince May 15 '15 at 17:41
  • 1
    0.125 years and $0.001 million – johnklawlor May 15 '15 at 17:42
  • 2
    Those are very specific and very demanding numbers without context. If those numbers are real, you're going have to satisfy the ultimate aim a different way, it's trying to buy the moon with a penny. Google's Elevation API limit is 10 requests per second for paying customers, developers.google.com/maps/documentation/elevation/#Limits. Also see api4dev.com – matt wilkie May 15 '15 at 18:37
  • 2
    What kind of hardware and web server setup you need for 5k/s is something out of my league, and very challenging. For instance the absolutely smallest likely web response, even if a static text file, is one Ethernet packet (~1,500 bytes) then 5k/s works out to 60 megabits per second in bandwidth alone (ref). What you're talking about is expensive -- in terms of money to run and time/intellectual effort to build. – matt wilkie May 15 '15 at 21:11
  • 1
    You have received numerous comments and your requirements seem to be shifting from seeking to building a service. Consequently, now before any answers have been offered, is the ideal time to edit your question to revise it heavily. – PolyGeo May 20 '15 at 4:14

Let's start with some assumptions:

  1. You really need 5000 web requests per second, and
  2. It would be possible to service those requests in only 5 seconds, and
  3. The queries could be serviced by exactly one CPU core, and
  4. Each core only needs 4GB of RAM, and
  5. The optimal core to CPU chassis distribution is 32, and
  6. Each CPU chasis has enough SSD disk to service all the RAM, and
  7. Each network switch contains a backplane which will support 48 network drops, and
  8. A perfect hashing algorithm exists to match perfectly distributed spatial queries to cores that become available a microsecond before they're needed, and
  9. A networking protocol exists that would permit each core with unfettered network access in the exact duration necessary to transmit a 1k packet containing the responses

Then, we'll need 25,000 cores utilizing 100,000 Gb of RAM (and 100,000 Gb of disk), distributed across 781 blade chasis (128Gb RAM each), connected to 17 network switches.

If we further assume 6.5 weeks and $1000 is your budget, and that these servers and network switches are equivalently priced, then you'll need to spend no more than $1.25 per hardware device, and will be able to configure each with software (which will need to be written -- you can budget the remaining $2.50) in only 1092 hours (1 hour 23 minutes per device).

Computing devices exist today that could handle this load, but I think you under-bid by about $50M and 8 years.

  • i would up vote your answer if i could. thanks for the thorough explanation. – johnklawlor May 16 '15 at 18:13
  • assumptions 1 and 2 are correct. 3 is not--i believe these requests could be serviced by many CPUs and many databases. i have no knowledge of assumptions 4-9. – johnklawlor May 16 '15 at 18:16
  • Assuming that one core can do the work reduces the cost. Assuming that worker processes are dependent on multiple support processes means they aren't really worker processes, and increases the cost by an order of magnitude. In reality, if the data was correctly configured, the worker process, after initialization, would be able to service requests in isolation, so this is one of the least speculative assumptions. – Vince May 16 '15 at 19:18

I've recently setup an elevation lookup service using https://github.com/perliedman/elevation-service. My use case is significantly different than yours, a few requests for lots of points vs lots of requests for a few points: the incoming requests a GeoJSON LineString features with a few thousand points. I currently have it deployed on a single t2.micro ec2 instance that is able to handle approximately 3000 lookups per second, reading 1arc second DEMs off an GP-SSD EBS volume. This setup costs $60/month, and $50 of that is for the data storage.

I would guess that it would take 1 day to modify https://github.com/perliedman/elevation-service to handle the type of requests you describe. After that it's a DevOps problem.

Given that this is dramatically different use case than your's it's hard to say exactly how much compute resources it would take. I'm all in on AWS, so the rest of my answer is based on that.

I use the elevation service with all the DEMs pre-loaded, but in an environment with multiple servers i would probably write a loader that downloads DEMs as needed from an S3 bucket, and stores them on local storage. That should only take a few hours.

I would setup a a load balancer, and an autoscaling group to provision EC2 instances as needed. It would be best to use one of the instance types with an instance store large enough to hold all of the DEMs, 450GB if your using 1arc second, I would start with i2.xlarge, those cost $614/month, my guess is that 2 of those would be able to handle 5000/requests per second. The Load balancer is $18/month plus data transfer. So thats $1246 + data transfer.


  • 1 weeks work to set it up
  • $1246/month for servers + data transfer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.