from Hacker News

Faster MySQL with HTTP/3

by mattrobenolt on 1/4/23, 4:40 PM with 47 comments

  • by kamikaz1k on 1/4/23, 8:48 PM

    Love love love planetscale.

    When I found it (you can thank Theo), shocked this isn't what AWS' serverless DB offering already was.

    I agree with what the author mentioned in another comment, not dropping performance for non-serverless use cases is a decided win. I deeply appreciate the work being done to enable serverless applications, so thank you for the work and thank you for sharing your findings OP.

  • by erulabs on 1/4/23, 7:26 PM

    Awesome work! I'm loving planetscale for lighting a new fire under the butt of MySQL again. Have been demoing Vitess (Planetscale's underlying software) and have only positive things to say so far - the Kubernetes operator is wonderful.

    I'm also curious about the comparison to the MySQL Classic protocol - would be interesting have an "as-close-as-possible" benchmark between Aurora MySQL "Serverless V2" and Planetscale. Even if it was as naive as "Given 100$ of credits, how many reads can you do at what average latency".

  • by dveeden2 on 1/4/23, 5:15 PM

    Would be nice to see a comparison with MySQL's X Protocol (protobuf based) as well as the "Classic" protocol. I don't think I've seen any MySQL compatible databases implement this protocol yet, so that's probably why it wasn't included.

    https://dev.mysql.com/doc/dev/mysql-server/latest/page_mysql...

  • by muhammadusman on 1/4/23, 10:53 PM

    I'm a huge fan of using PlanetScale, I've been using it for a few projects recently and can't wait to try out the "Boost" feature when it becomes available. I think it will reduce one more thing from my stack (caching/redis)!

    The developer experience with PlanetScale has been my favorite so far, I use it with a few Next.js apps and the "scaling" part has been the easiest as I haven't had to think about a burst of traffic b/c PlanetScale handles it without me lifting a finger.

  • by uluyol on 1/5/23, 3:35 AM

    I can see how you might want HTTP/3 across data centers, but you may want to stick to HTTP/2 for intra-DC workloads.

    There's a ton of work to optimize TCP including hardware offloads that help push higher throughput. Basically we're talking library + kernel + hardware changes. It might be possible to get some of these into QUIC, but since QUIC is most compelling for WAN traffic, there's probably not much incentive for that.

  • by alberth on 1/4/23, 10:00 PM

    What's so great about PlanetScale?

    I feel like I live under a rock because I just don't get what's so great.

  • by avargas on 1/4/23, 7:37 PM

    One of the best ways I've managed latency with MySQL is basically this:

    1) use persistent connections, let the OS handle them and tweak it to allow (both connecting server and mysql server). And never close the connection on the application side. (This could lead to potential deadlocks, but there are ways around it, like closing bad connections to clear thread info on mysql).

    2) run the whole thing in a transaction, simply begin transaction or autocommit if allowed (same thing)

    Doing so, when you are done rendering the content, flush it and send the correct signal to say nginx or apache to say it's done (like PHP's fastcgi_finish_request when working with FPM), and then run your commit. Obviously used when you can safely disregard failed inserts.

  • by YarickR2 on 1/4/23, 6:16 PM

    This is optimizing edge cases. Handshake is done once per execution , and it's constant time , so "connect + select 1" should be measured as "connect", then "select 1". Other than that, 5ms latency is too high anyway for modules doing hundreds of small requests, so you better have read replicas real close to your code, and shard your masters.

  • by mgaunard on 1/4/23, 7:40 PM

    Most likely the parallel requests are done using a single connection.

    So of course HTTP/2 will outperform, that's what it's designed to do.

    Now try again, but use one connection per thread, and connect it before you start benchmarking, i.e. use it the way it's meant to be used.

  • by exabrial on 1/4/23, 11:33 PM

    This may be a stupid question, but wouldn't connection pooling offer the same benefit?

  • by kurtextrem on 1/4/23, 5:07 PM

    Crazy results, really interesting experiment!