Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stack Overflow Outage Postmortem

stackstatus.net

Post reply on HN
Print view View original

331–335 of 335 posts

Re: Stack Overflow Outage Postmortem

#331

Post by mamcx »

chubot wrote: post #198
mamcx wrote: post #74

Earlier quoted context omitted.

Sadly not much Thompson's libraries are implemented. I have tried to find one for F# but are just toy projects.

It doesn't actually take that many lines of code to implement a linear time NFA engine. Most of the code is actually in the regex compiler. That is, there are only a few actual "instructions" or node types in a regex engine (alternation, concatenation, etc.). The rest is just compiling the bizarre syntax to a those nodes/instructions. (And dealing with Unicode if you need that.) The whole awk implementation is 958 li…

if is that "simple" why then are few? Or is because I don't know where to look at?

Maybe regex are just enough and few bother to have something faster?

I have found some start code at https://t0yv0.blogspot.com/2011/02/home-made-regular-express.... The thing is that I don't know how much else is necessary to have a well made library...

Re: Stack Overflow Outage Postmortem

#332

Post by shdon »

undersuit wrote: post #172
shdon wrote: post #146

Earlier quoted context omitted.

Which also wouldn't have been caught by the regex, because it was designed to do the same as Trim. Given the input, all that whitespace was not actually supposed to be removed and the regex worked, it was just a degenerate case that slowed it down to a crawl. Trim would not slow down on this input.

Trim won't work, otherwise SO would be using trim. The regex did work in all cases, but it was slow under certain conditions. The slowness caused a separate system to shutdown the site. The regex worked fine, 100% within expectations.

No, the regex was an actual trim. And they have indeed switched to that. The edge case that caused the slow performance was a lot of whitespace that did not appear at the start or end of the string. The regex would not remove that, nor would trim, but trim is much more efficient in doing the exact same thing. The regex may have been correct, but I doubt the expectations of the developer were met and it most definitely was the wrong tool for the job.

Re: Stack Overflow Outage Postmortem

#333

Post by brokenmachine »

dingo_bat wrote: post #255
solipsism wrote: post #250

Earlier quoted context omitted.

You're misreading the regex. \u200c is a single whitespace character. http://www.fileformat.info/info/unicode/char/200c/index.htm

But that's a weird character to put in a comment line! I don't get how this would happen accidentally.

What difference does it make if it got in there accidentally or on purpose?

Stackoverflow is a programmers site, you must expect that a programmmer might go, "Hmm, they're trimming whitespace, wonder what happens if I put 20,000 unicode whitespace characters in there instead of normal whitespace"?

Re: Stack Overflow Outage Postmortem

#334

Post by brokenmachine »

rixed wrote: post #253

Regex was not the main issue. The main issues were: 1. Rendering a page fails/does not terminate if some non essential subtask (rendering a single code block) fails/does not terminate. 2. They do not try to detect bad data (the way they certainly try to detect bad code) 3. Load balancing based on the rendering time of a single page Code bugs triggered by bad data will happen again, with or without regular expressions…

> 2. They do not try to detect bad data (the way they certainly try to detect bad code)

It was actually the sanitization function regex that became unresponsive. So they killed the page by trying to stop bad data coming in.

Agreed on your other points though.

Post reply on HN