EVE Technology Lab

Is 150r/s for public CREST accurate? I'm getting a lot of "server temporary unavailable" errors with 150, but everything works fine with 100. Other than that, it's extremely slow

It would be very nice if some dev actually responded, and even nicer if someone takes a look at the problem. Today even 100r/s limit is too much for CREST and the server closes connections all the time.

Traceroute:

Tracing route to public-crest.eveonline.com [87.237.38.221]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.0.1
  2    14 ms     9 ms    11 ms  84-10-168-1.static.chello.pl [84.10.168.1]
  3    12 ms    14 ms     9 ms  89-75-13-65.infra.chello.pl [89.75.13.65]
  4    10 ms    14 ms    11 ms  pl-waw04a-rc1-ae17-2114.aorta.net [84.116.252.57
]
  5     9 ms    11 ms    14 ms  pl-waw02a-ri1-ae1-0.aorta.net [84.116.138.90]
  6     9 ms    13 ms    11 ms  pni-pl-waw05a-as1299-telia.aorta.net [213.46.178
.50]
  7    37 ms    38 ms    35 ms  hbg-bb1-link.telia.net [80.91.251.35]
  8    40 ms    38 ms    41 ms  ldn-bb3-link.telia.net [62.115.142.125]
  9    37 ms    38 ms    39 ms  ldn-b3-link.telia.net [80.91.251.165]
 10  eveonline-ic-138015-ldn-b3.c.telia.net [213.248.83.198]  reports: Destinati
on net unreachable.

Trace complete.

Seems like one of the nodes is down atm, but the problem persists pretty much all the time I started testing public CREST about a week ago.

User agent: Evernus 1.36

I'm experimenting with different r/s limits and 100 seems to work most of the time. 150 in 100% cases causes closed connections by remote host. Everything in between is a lottery.

I also found it might be linked to the number of requests sent. < 1k requests seem to be handled properly most of the time, but making ~30k requests (even with <150r/s limit) causes errors.

Check out the logs for that user agent from today and last few days. The requests were getting through (looks like something died now), yet 150r/s was not attainable.

Yup, 1.36. I just made ~150 requests right now.

No worries, my requests are getting through.

Thanks for looking at it. If you need any more info, let me know.

Hi FoxFour,

I WAS having the same issues as both Iam and Pete and I have to wonder if it was my testing against public-crest that contributed to the constant problems.

My experimentation is very similar to that of Pete’s in that very fast polling (rate limits of 150 per second) was causing random closes in connections by the remote host. And similarly to Pete I found it linked with the number of requests sent. In my case it seemed to always crap out at around 1.5k requests. Additionally, waiting a minute or two and starting the polling again would almost always obtain the same results.

Using netstat revealed that almost all of my sockets were staying open with TIME_WAIT and that I was creating an insane amount of new sockets. I have to wonder if it is the amount of open sockets and concurrent connections that was causing the crest server to bork?

At first I thought that you all had some code to disconnect clients that were making an excessive amount of concurrent connections (which would explain my disconnects after n amount of requests). However, if others are having disconnects (which seem to correspond to my testing) I have to assume that these events are related.

Is it possible that whatever server you are using was using up all of its socket pool and not able to send out any more connections? I only suggest this because after my TIME_WAIT eventually was removed by the timeout, another connection was eventually established.

The problem that I had with excessive amount of concurrent connections and TIME_WAIT has been fixed in my code. I found that the problem was in how my software, nodejs in this case, was not properly using http keep-alive. If anyone out there is using Nodejs to make requests using https.request() and doing a lot of fast concurrent requests against crest I highly suggest using agentkeepalive , otherwise you will have the same issue.

Anyway, this keep-alive fix works for me now and allows me to regularly obtain rate limits of 150ms with way more than 1.5k requests

If Pete and Iam stop having problems, I think it might be safe to assume that the amount of socket connections might be an issue.

In my case, I can say I make max 6 sockets for parallel connections. Used to be much more before the limit - ironically it worked then more often than now.

Iam,

Today I was able to pull in ALL of the market data for all applicable market type, buy/sell, in all regions, in just about 4 hours. I have to imagine this is probably fast enough for most applications. This is using rate limits of 100 req/sec.

Unfortunately, I am still receiving a lot of errors (dropped connections, socket hang ups, and the random missing data). Over the course of the 2 million requests I had about 150k errors of which I simply did a re request. I should note that if I go above 100 req/sec I see ALOT more disconnects, so I'm staying away from the suggested max of 150 req/sec.

Not having these errors would probably save about 15 minutes or so in the grand scheme of things and if they can fix up to 150 req/sec it would probably save an hour+ of time.

Most of the regions however have 0 market data, but unfortunately there is no way to tell, which could save us a lot of additional time.

@FoxFour - It would be nice if there was some way to quickly tell if a region has no orders, so we do not have to traverse the region. Like maybe add that as a property to the /regions/ emdpoint. Better yet, maybe give us a way to grab all the market data from the region in one area instead of having to traverse all the types. I'm sure that would be better than the 2 million+ req per app per day scenario for those of us that want to analyze all the market data.