pphaneuf: (Default)
Saturday, I attended BarCampMontreal3, which was quite fun. I figured that I should really practice my presentation skills, so Thursday, when I found out it was this Saturday (not the next one as I has thought!), I had to find something to talk about.

I figured there would be a lot of web developers in the audience, and having noticed that a lot of web application platforms tend to disable many HTTP features that helped the web scale to the level it has today, I thought I could share a few tips on how to avoid busting bandwidth caps, deliver a better user experience and overall try to avoid getting featured on uncov.

It was well received, mostly (see the slides), although it felt a bit like a university lecture for some (maybe the blackboard Keynote theme didn't help, and I was also one of the few with a strictly educational presentation that was also technical). Marc-André Cournoyer writes that just one simple trick visibly improved his loading time, so it's not just for those who get millions of visitors! Since at least one person thought that, I guess I should clarify or expand on a few things...

Read more... )
pphaneuf: (Angry Tongue)
Related to my previous post, I would like to use MySQL++ as an counter-example: it's "result set" object does not have a "no more rows" method, it simply throws an exception when it is at the end.

See, this is a good example of something that is not exceptional at all.
pphaneuf: (Spikes)
I was checking out a review of new Xeon hardware, which was using MySQL 4, MySQL 5 and PostgreSQL 8.2 beta. The test is mostly realistic, consisting of PHP pages doing queries, taken from their own website, with an exception, that the dataset is restrained to something like 2 gigabytes, so that it doesn't hit the disks too much (this can make it either unrealistic, or is a strategy to stay sane).

The article mostly talks about the hardware, but the results put MySQL in, uh, a "bad light". MySQL 4.1.20, going from a one single-core processor to two dual-core processors (that's between twice to four times the horsepower), goes 56% faster. MySQL 5.0.20a goes 40% faster. PostgreSQL 8.2-dev (okay, dev, whatever, have you looked at MySQL recently?) puts in a 224% increase in performance, meaning that it actually gets the "slightly more than three times as fast" you'd expect from having "between two and four times the horsepower".

They also show graphs of how they behave dealing with concurrent requests, where you see MySQL peak at about 520 requests per second, then goes down as the number of concurrent requests. PostgreSQL, on the other hand, slowly goes up to about 640 requests per second, then pretty much stays there, being clearly limited by the hardware to that level, a textbook example of nice scaling. At a concurrency of 100, PostgreSQL pulls in nearly twice as many requests per second than MySQL.

So much for MySQL being "the fast one" (PostgreSQL was traditionally the "safe and correct one", which was already nothing to sneeze at, as long as it managed to be "fast enough").

February 2016

7891011 1213


RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 27th, 2017 06:36 am
Powered by Dreamwidth Studios