This has maintainability problems written all over it. I can't imagine a web page where you would actually gain something from this, that wouldn't be complex enough that you wouldn't need some language to deal with more complex selects/inserts. And that would mean that you would spread your logic (models?) across two totally different "platforms". One part in nginx conf file (brrr) and the other in your code. Add something like Sphinx into the mix, and you have your SQL all over the place.
Why is it only 3-4 times faster is what surprises me. No question that cutting out the PHP interpreter and VM is going to speed things up, but only ever so slightly?
The speed of MySQL is constant in both cases, and IO is always expensive, thus the CPU speedup via C vs PHP is not as dramatic as one hopes; remove MySQL from the equation and you'll see the gigantic difference.
Because it's taken out of the context. Original text says:
"We even observed that ngx_drizzle + ngx_rds_json achieved 128MB/sec (Yes, 1024Mbit/sec!) for a 380KB data-set query while connecting to a simple mysql server, about 3 ~ 4 times as fast as php + libmysql in this setting."
As you can imagine in such scenario (380KB result), MySQL engine is taking the most of the time.
The idea that you might not need the high-level language in the middle at all is interesting in itself. At least, it is to me. I've not seen it before.
This is working backwards. You do realize that before PHP and higher level languages this is how things generally worked to begin with (server modules) as opposed to now (higher level languages).
I still don't understand why this is on hacker news, let alone the top of the list.. seems to be about the most obvious item of all..
I can't really tell from the phc page, but HipHop at least doesn't "speed up PHP code". It converts the code from PHP to C++. That isn't speeding up PHP, that's unraveling the PHP and respinning it as C++.
You're kidding me right? I'm off to re-write my entire app as a stored proc ;)
You are right of course. But what would be nice would be to replace part of a static page with the result of a piece of SQL. To combine ESIs with MySql so that you can serve static files and still be able to add things like watermarks using a MySql lookup based on a session cookie.
This keeps reminding me to get off my butt and make some sort of passthrough between nginx and mongodb. Yes, I know there's GridFS development but it doesn't suit my needs.
Yes, title is definitely misleading. He's not even announcing new modules (both are available for about half year now), he just announced massive performance boost in them.
So, I get it and all that, what are some real world use cases of this and the postgresql equivalent? Who's actually using these things for something other than saying how fast they are?
I just hope they aren't being used as public-facing JSON API endpoints and the such, since none of them seem to even consider the case of SQL injection. From a quick glance it doesn't seem that any type of parameterized query or prepared statements are available to even begin helping with that, and the "documentation" examples wouldn't be setting people off on the right foot by even limiting the location paths with strict regex's.
> Who's actually using these things for something other than saying how fast they are?
Taobao.com (14th biggest site in the world, 3rd in China - according to Alexa) is using ngx_drizzle + ngx_rds_json in production. Qunar.com is using ngx_postgres + ngx_rds_json.
removing high level language in the middle is good, if you need performance, why not just use redis to server json directly, in the case you need scale up your db why not use crunchDB.
You specify a route in the nginx config, and when the route is requested, it serves up the result of the sql query that you specified. Even further, it looks like it will run different queries, depending on the type of request made (GET, PUT, DELETE).
This just makes it a little easier to put together a RESTful app. Alot of those apps are just thin wrappers around the request that check the request type, check authentication, and then perform a simple db statement. This is easier to define, and apparently alot faster.
