Quote:
Originally Posted by loramin
[You must be logged in to view images. Log in or Register.]
I would imagine/hope the coder behind it has heard of caching ... in which case, you're mistaken.
EDIT: Oh, it's a tunnel quest site. If it literally has a "update from wiki" button then yes, hitting it hits the wiki ... but why would anyone spam that button? Wiki prices don't even change daily on most items, let alone hourly or sooner?
Regardless, there's a world of difference between hitting one page, even a few times ... and hitting every page in a short period. How is that not obvious to you?
|
Pretty sure it's you who's mistaken. I don't think you understand what PigParse is. It's not just a tunnelquest website, it's also a log-reading utility that does DPS parsing and mapping, and I guess loading all items the wiki lists as dropping from a mob every time you /con it.
Here's the ConHandler hitting the the WikiApi:
https://github.com/smasherprog/EqToo...Handler.cs#L46
Here's the WikiApi directly hitting the wiki:
https://github.com/smasherprog/EqToo...ikiApi.cs#L107
Sure don't see any caching happening.
If it's hitting the p99 wiki every time any player using pigparse /cons a mob, that's a lot more than "one page, even a few times". And sure, I'm aware of the difference between that and an non-rate-limited multithreaded crawler, but unless you have some special insight into wiki traffic from being an administrator, neither of us knows whether the wiki slowness is caused by crawlers or something else. In contrast, the issue pointed out by Mattson is a real source of a nontrivial amount of unnecessary traffic. So why bother responding dissmissively if you're not even going to put in the effort to understand what the issue is?
It seems like the maintainer is aware that this is... not a best practice, and I see some (unfinished) work today to begin to implement caching:
https://github.com/smasherprog/EqToo...0ae286a691d333