5 ms·
This person doesn't even offer a solution? How is it that people who have blogs that take 30 seconds to load continue to give performance advice that gets upvo
by mscarborough 14y ago
This person doesn't even offer a solution?
How is it that people who have blogs that take 30 seconds to load continue to give performance advice that gets upvoted?
The funny thing is that this blog's performance is based on some cookie. If I reload in Chrome? 2 sec. If I reload in "Incognito Chrome", it's again really slow.
So seriously, just stop with these authoritative blog posts when you don't even know what you're talking about.
- fdr 14y agoWhen criticizing a piece of software as popular as MySQL, offering a solution is an exercise in futility: it only leads people to think that the author is wrong because the alternative posited is wrong for them. See the endless MySQL vs. PostgreSQL discussions (which are not entirely without merit: the two system do have overlap in targeted users). Instead, this author his simply focused on numerous detailed aspects of MySQL that he/she seems to think would be seen by most people as particularly insane, without need for comparison. I think there's a place for that.
- mscarborough 14y agoYou're right, offering a solution to MySQL problems in a thread is generally useless. I don't really get what point the author is trying to make. I also don't take detailed performance advice from people who can't keep a blog up. Yeah, must be the wrong backend.
- willlll 14y agoHow could you possibly not get the point? It's the first two (2) sentences "Considering MySQL? Use something else."
- mscarborough 14y agoI use MySQL and Postgres, depending on the project. What other option is so obvious that you can't even name it?
- ansgri 14y agoSQLite is so obvious, and in many cases it's just enough. Or, hsqldb if you're into Java.
- stef25 14y agoI used Postgres on a project and my main concern with it is that whatever GUIs were available were seriously lacking. Phppgadmin is awful. If you're really pushing its capabilities then there may be better solutions than MySQL but for bog standard applications and websites there is no alternative as far as I'm concerned.
- zorlem 14y agoYou should've used pgAdmin [1], it's much better than PhpPgAdmin [1]. I have not used the MySQL GUI (MySQL Workbench [2])that Oracle/Sun/MySQL sells with the Enterprise license but by its feature list I suspect that it provides comparable functionality to pgAdmin (which is FOSS). I would not put any of Php{Pg,My}Admin interfaces in the same category - they're too lacking IMO. [1] http://www.pgadmin.org/ http://www.pgadmin.org/ [2] http://www.mysql.com/products/workbench/ http://www.mysql.com/products/workbench/
- deleted 14y ago[deleted]
- robertfw 14y agoI'll second pgadmin. I finally woke up to the fact that I should start using Postgres a few months ago, and pgadmin made my initial foray into postgres very straight forward
- mdellabitta 14y agoThis is an ad hominem argument. His statements about MySQL should be judged on their own merits, regardless of the load times of his blog.
- mscarborough 14y agoNo, it's not. If you're going to be a performance authority about web technology, you should know how to configure the open-source and very well-documented code you are using.
- jacques_chester 14y agoI don't see how using Apache, with what I guess are the default settings, has any bearing on remarks about MySQL.
- mscarborough 14y agodidn't say anything about apache, so not sure what you're complaining about.
- jacques_chester 14y agoSee my other reply for why I brought Apache into the discussion.
- mdellabitta 14y agoAnd so you assume that the author of the article doesn't know how to optimize his or her blog, ignoring the possibility that he or she does, but didn't do it for intervening reasons. Still has no bearing on the veracity of statements made in the article.
- zorlem 14y agoThe OP is not trying to be "a performance authority about web technology", in fact the article's main focus in not on performance, but on peculiarities in the RDBMS engine that force the developers to constantly seek workarounds and be very careful about silent (and unexpected) behavior. There is no "web technologies" in the article, the term "web" is found only once (!) in the whole text.
- jacques_chester 14y agoIt's not performance advice, though. It's a list of known problems with MySQL, most of which violate the "Principle of Least Surprise". Some of the problems have performance implications. The query planner stuff, for example. > The funny thing is that this blog's performance is based on some cookie. If I reload in Chrome? 2 sec ... just stop ... when you don't even know what you're talking about. It may interest you to learn that web browsers have local caches. Incognito Mode does not have such a cache, and so must refetch pages from scratch on each view.
- mscarborough 14y agoIf you have to be a jerk about it, it may interest you that relatively static blog content can be cached on the server. I'm genuinely interested to learn which use cases are more dependent on query planning than caching methodologies.
- jacques_chester 14y ago> relatively static blog content can be cached on the server. If you poke around, you'll find that this isn't a Wordpress installation. (Or any other dynamic blog engine, for that matter.) It's Markdoc[1], a static site generator: > Markdoc converts wikis into raw HTML files and media ... Markdoc need not be installed on the hosting site, since the resultant HTML is completely independent. I believe the program at fault here is Apache, which in the default configuration loves nothing better than to choke on child processes. [1] http://markdoc.org/ http://markdoc.org/
- jacques_chester 14y ago> I'm genuinely interested to learn which use cases are more dependent on query planning than caching methodologies. I'll reply to this separately, it's a good discussion to have. My basic problem is that caching comes with a coordination cost and I prefer the originating data source to be as performant as possible. My own use case is a small Wordpress multisite installation. Even with a relatively trivial amount of traffic and site data, it behaves abysmally on some simple requests. The linked article seems to explain why -- the query planner ignores indexes on certain kinds of joins. The same sort of joins as the Wordpress Recent Comments Widget. Now, I can and have worked around this by using multiple layers of caching. There's the MySQL query cache, some memcache (PHP opcode caches would in theory be quicker but I've never been satisfied with their stability) and of course pumping gzipped HTML to disk for nginx to serve directly without hitting PHP or MySQL. But like I said, caching comes with a coordination cost. One of my sites is used less like a blog and more like a chat room. Hundreds of comments per hour, every single one of which causes the query cache to be pruned of the exact query I most need to cache in the first place. That is: I need to cache this query because they talk so much. But they talk so much that the cache is not that helpful. What would be helpful is if MySQL was a bit smarter about using the indexes I put there in an apparently useless bit of chicken-waving.
- saosebastiao 14y agoIt took less than a second for it to load on my browser. And why should he offer a solution? The point of his rant isn't that you should use a particular solution, but rather that you should avoid MySQL at all costs.
- elchief 14y agothe solution is Postgres
- lucian1900 14y agoGiven such a detailed article, the solution is obviously another DB. Postgres lacks most of the MySQL flaws described.