Performance issues prompt "unplanned maintenance". Maybe.

[Conan]

Here's the latest version of the FA one:
http://greasefire.userscripts.org/scripts/review/125262

[Pi]

friend of mine is graphing FA's actual response time from two different hosts on the 'net.

[zed]

scrapers operating on the site to a degree that it's causing serious performance issues

Something I've tried to drill into yak's head is that the scrapers are not the problem - the scrapers are exposing a problem, and blocking scrapers is not going to fix the underlying issue. He's come out and told me that he blocks scrapers just because he "doesn't like them", and has no good technical reason for it.

Obviously, whatever script FA Rank was using to calculate user rank has sucked up all of FA's bandwidth. This is why we can't have nice things for FA, like an API.

[magus]

friend of mine is graphing FA's actual response time from two different hosts on the 'net.

This is pure page generation time, I assume? Just wondering, since the performance of their "CDN" can be pretty abysmal at random times too.

[Pi]

friend of mine is graphing FA's actual response time from two different hosts on the 'net.

This is pure page generation time, I assume? Just wondering, since the performance of their "CDN" can be pretty abysmal at random times too.

This is "time between opening the socket and seeing the end of response". I just suggested to _habnabit to parse the generation time out of the response, assuming the server even bothers to send us one. here's the source code (in python, and nobody knows python) if you're curious/want to send patches.

ETA: Hey, look:

[Jim Demintia]

scrapers operating on the site to a degree that it's causing serious performance issues

Something I've tried to drill into yak's head is that the scrapers are not the problem - the scrapers are exposing a problem, and blocking scrapers is not going to fix the underlying issue. He's come out and told me that he blocks scrapers just because he "doesn't like them", and has no good technical reason for it.

If it's not some kind of systemic scraping operation, and it's just random/regular users, then scrapers are neither the problem nor exposing any problems. I mean, how can single users scraping affect the site so severely, all the freaking time?

It's gotta be a goddamn robot. Either that, or Yak has no fucking clue what's going on and scrapers are a convenient place to put the blame.

[SlowFag]

Actually, if it is regular users, you'd think there'd be example code floating around. Anyone seen any?

I saw an FA scraper on lulz a bit back called 'Anti-Bawleted' or something similar.  It wasn't too long ago, so it might not have been bumped off the board yet, but I can't be arsed to dig through 15 pages of shitposting.

[loki]

The pagination for user favorites is interesting. If you do something like this:

http://www.furaffinity.net/favorites/[user name]/9999999999999999999999999999999999999999/

It will actually cause the DB to throw an error on the backend. Gut feeling tells me... SQL injection vulnerability. So I try this:

http://www.furaffinity.net/favorites/[user name]/2' or 1 = 1 or 1 =/

That still returns but most likely it's just picking up the first number it sees in the URL. Still, this isn't very safe. Especially if I can error the DB out by putting a number larger than the backend can handle.

[Ketsuban]

The pagination for user favorites is interesting. If you do something like this:

http://www.furaffinity.net/favorites/[user name]/9999999999999999999999999999999999999999/

It will actually cause the DB to throw an error on the backend.

I probed this further because I can't sleep.
256204778801521551 (0x38E38E38E38E38F) - okay
256204778801521552 (0x38E38E38E38E390) - db error

What the fuck.

e: I asked a couple of friends to doublecheck, and while an Opera user got the same results I did, a Safari user got a database error for both. It's not connected to the username, we tried each others' choice of username. What the double fuck.

[GreenReaper]

The value is likely causing an overflow in code attempting to obtain an alphanumeric string from the page number (perhaps as a key for caching or DB purposes).

Code like 'base_convert( 0x38E38E38E38E38F, 10, 36);' can be used to obtain a string of characters in '0123456789abcdefghijklmnopqrstuvwxyz'.

On a 64-bit system, PHP_INT_MAX == 2^63 == 9223372036854775807
9223372036854775807 / 36 = 256204778801521550 (0x38E38E38E38E38E)
Take one off because pages start at one, and you have your limit.

[Pi]

The value is likely causing an overflow in code attempting to obtain an alphanumeric string from the page number

This absolutely reeks of cargo-culted shit design; php encourages this kind of fragile garbage, and this is why it is to be avoided.

[Jim Demintia]

"design"? hah.

[ColeTrain]

http://forums.furaffinity.net/threads/115269-2-23-2012-504-errors

Currently the site's having some MySQL trouble, we're aware of what's causing the issue and rebooting MySQL.
The site should be online again shortly.

Correct me if I'm wrong, but wasn't the maintenance done few days ago supposed to "fix" MySQL among other things? And now we have it borking the site?

[Jim Demintia]

Uh, if they're rebooting MySQL to fix it, then that strongly suggests that, no, they don't know what's causing the issue.

[ProvincialTwit]

The time-tested method of "Have you tried turning it off and on again?"

[Pi]

<Pi> yak[away]: "Currently the site's having some MySQL trouble, we're aware of what's causing the issue and rebooting MySQL"
<Pi> yak[away]: what was the *actual issue* here, because "we kicked the database over" does not really scream 'we understand what's going on"
<yak[away]> Pi: ran out of memory. percona uses slightly more of it with the same config file. reduced the size of the innodb_buffer_pool to compensate
<Pi> okay, so that should be communicated to users
<Pi> "the database server ran out of memory due to a misconfiguration"
<Pi> not "we restarted the database server to fix it"