Congratulations to Bernie who finally tied the knot! I re-read his post from yesterday and the penny dropped !
Segala’s WP optimisation article is useless apart from the one tip on disabling unwanted / unncessary plugins. A lot of the other supposed “tips” have very little to do with WordPress or are simply technically incorrect. My optimisation tip is simple – move to something saner.
Pavarotti has passed away. The knockon effect being that his official site has fallen over. Loads of media coverage.
Google reader now has a search function. I hadn’t noticed that it was missing one! I suppose it depends on how you interact with things. If an article interests me I’ll bookmark it.
The iPhone pricecut has upset a lot of early adopters (nah nah nah nah nah – told you so!) but Nokia’s marketing department have taken advantage (according to Techcrunch)
And which blogging platform would you recommend? Movable Type is it?
How nice of you to look down at every one.
I’ve asked Kamrul to check his blog tips to see where he could have made mistakes. It would have been helpful to us and your readers had you actually pointed to specific examples, rather than make a blanket statement. I noticed Donncha referenced the post in one of his own and didn’t point to any technical inaccuracies (but that’s not to say they’re weren’t any of course).
Paul
Sorry – it was a quick post at lunchtime covering several topics – none of them in depth:
A lot of the tips had nothing to do with WordPress eg. external Javascript etc.,
If you were using flat html and included an external file from a slow server it would slow down the load time, but would have absolutely nothing to do with the backend.
The php modules comment is inaccurate and even if you wanted to remove php modules you wouldn’t be able to unless you ran a dedicated server.
The comments on MySQL and the hosting environment were misleading. If your blog is causing a severe load on a shared hosts DB you are obviously running something that is using bad sql queries ie. not closing connections properly or running insane queries.
The Apache log rotation is irrelevant. If your logs aren’t rotating properly you’ve got serious issues that have nothing to do with WordPress.
The broken template issue is valid if you accept that the cms can allow bad code to hit the backend. One of the more recent security issues was, if I recall, due to an issue in a template. That a template can cause those kind of security issues is madness.
The excessive plugins is a very valid point. I’ve seen it happen far too often 🙂
The dashboard only affects the author. It has no effect on the reader.
The pingbacks should have been resolved a few versions back, unless the WP coders managed to “unfix” it. They were meant to have moved to asynchronous pings to do away with that and in my experience the change to asynchronous made all the difference. If you’re still using a version of WP with synchronous pings you need to upgrade.
Regards
Michele
Hi Michele,
If you are going to do a “quick post at lunchtime covering several topics – none of them in depth” then you shouldn’t be so dismissive and make statements such “simply technically incorrect” without reading the full post. Might also serve you well to use a above as a future disclaimer so your audience knows your in a hurry
Had you read the post you would have noticed I said a WordPress site problem caused by non-wp issues (PHP, Mysql etc.). Which means this argument don’t have any value-
“A lot of the tips had nothing to do with WordPress eg. external Javascript etc.,If you were using flat html and included an external file from a slow server it would slow down the load time, but would have absolutely nothing to do with the backend.”
PHP module – There is nothing wrong with my statement, remember I was giving tips to resolve a problem not whether the user has access or not.
“The comments on MySQL and the hosting environment were misleading. If your blog is causing a severe load on a shared hosts DB you are obviously running something that is using bad sql queries ie. Not closing connections properly or running insane queries.”
Again you missed what I mentioned in “MySQL server or connection issues”. In fact, you are saying the same thing 🙂 Even if you are running one line PHP code if your host is having a problem with SQL server, you will have problem. The wrong code issue is covered in other section, as you can see.
“The Apache log rotation is irrelevant. If your logs aren’t rotating properly you’ve got serious issues that have nothing to do with WordPress.”
Once again this demonstrates you didn’t read the post more carefully. I clearly mentioned that WP site problem might be caused by something other than Wp-core itself. Mind you the broken log rotation doesn’t cause a serious issue if the log files are small.
Lastly the admin interface(dashboard), I never said this tips are reader specific did I? Technical tips are always for blog writers, so how can you say that is incorrect?
So, I think you could rephrase “simply technically incorrect” to something else.
Caveat lector: I’m employed by Blacknight as their senior developer, so I know a thing or two about this. I’m also posting this as a private individual because, not an employee, and regardless, if Michele is full of crap, I’ll tell him he is, and publicly too. I’m not one to tow a company line.
Kamrul, he was dismissive because a lot of the stuff was poorly thought out and researched. Mind you, “inaccurate” would have been a better word to use than “incorrect”. I’m going to go through the post and comment on the parts I believe warrant the most attention.
Let’s start with your MySQL comments: “Actually very little you can do about this, since your host can only resolve this.”
No, you can enable wp-cache. The more of a site that’s baked rather than fried, the better.
“Too many connections to your DBhost can also trigger sluggishness.”
If this is the case, you’re either hitting the database too much or with a hosting company who’s doing some serious overselling. If you’re running bare-bones WP with wp-cache enabled and your site is *still* sluggish, you need to think of getting your own server.
“Make sure your WP database isn’t shared with your other sites.”
This is just plain crap. All a database is is a collection of related tables with a shared set of permissions. Partitioning a database into two databases, both handled by the same DBMS on the same machine won’t give you a single jot of extra performance. If the apps you’re running all share the same database, they won’t affect each other’s performance simply by virtue of all of them keeping their tables in the one database. What will affect them is if the apps you’re running are using the same tables and the table access patterns of the apps interfere with one another.
Here’s an example. WordPress sites are typically mostly read-only, with a certain amount of writing when comments and posts are posted or edited, let’s say 80% the former and 20% the latter (these numbers are more for example’s sake rather than an actual estimate). Now, let’s say that you’re using your WordPress site as a planet and have a separate RSS aggregation app running on the server that periodically polls a list of feeds and turns the feed items into posts on the WordPress blog.
The way the typical RDBMS is designed, you have basically two kinds of locking: shared and exclusive. Shared locks are acquired by readers, and exclusive locks are acquired by writers. If two or more readers attempt to read something, they can do so concurrently without interfering with one another, but while any of them still have a shared lock, no writers can write to the database. If a writer gets an exclusive lock, that writer is the only one able to access that table, and any other readers or writers must wait until the writer that has the lock finishes what they’re doing. It’s a little more complex than that (think page locks, row locks, multiversion concurrency control, &c.), but that’s the jist.
In the example above, the aggregator side of your planet will be 100% write, which will have a knock-on effect for your frontend. This is a general problem with database-backed database, and the only real way to identify it is by checking where you’re getting access bottlenecks and work around them using caching mechanisms, deferred writes, and so on.
But having all your apps use the same database isn’t a problem. If your apps are giving you that much difficultly, again, think dedicated server, whether it’s for all your stuff, or just the app that’s putting the most load on the DBMS.
“Check with your hosting company regarding your DB statistics, if needed do an upgrade or change host. No use sticking to a host just because they are nice but can’t meet your technical demand.”
…and if you’re still on shared hosting, you’ll end up running into the same problems, regardless of hosting company. If you’re site is really getting that much activity, and you’ve exhausted all other options, it needs to go on its own dedicated box, whether it’s hosted with your current hosting provider, or another one.
“The heartbeat of WP is PHP, so obviously when something goes wrong with that you will have issues.”
This is a given, a tautology, even.
“By default PHP is a beast with all kinds of nasty modules it thinks it needs to load.”
Uh, no. Have you ever actually looked at the size of the various PHP modules? They’re not all that big, and mostly wrappers around existing libraries that are already on your server. To top it off, they’re shared objects (on *nix, DLLs on Windows), and there’s only ever one copy of the shared object in memory.
“So the more it’s loading, the more memory you need.”
Really, take a look at the size of them. Most of them are around around 60kB or so, and and never much bigger than 120kB. The biggest one on my machine (aside from xdebug, which is 614kB, but would never be deployed on a production server) is the gnugp one, which weighs in at 110kB. Given the amount of memory the typical server has, this is removing lint.
“Why not control what to load? Disable as many extensions you are not using to save memory.”
What’s more, most modules don’t consume any additional resources aside from the memory to store their code unless you’re actually using them. If you *really* want to save memory, it’s better to release the resources you get as soon as possible.
“Optimize your PHP configuration, avoid loading unused modules.”
To do this, you need your own machine. However, doing so is a good idea, but only for security reasons: the less you run on a machine, the fewer vectors for exploits.
However, a better recommendation would be to get rid of your swap and throw as much memory into the machine as possible. Memory is cheap, and, if while profiling the app you notice a lot of page swapping, which is very bad for performance, doing this will give you a big win.
“Apache log rotator problem (for Apache server)”
As Michele said, if you’re having problems with this, your host (or whoever you’re paying to manage your box if you’re not on shared hosting) has screwed up and should be hit about the back of the head for not doing their job.
“Broken/Degraded PHP code in template/theme files.”
eAccelerator is a fine project, but it only really helps is the code is well-written in the first place. The problem with most poorly written PHP code is that they do things like running multiple join-less queries where a single query would do, repeatedly load files into memory rather than loading them once, processing them, and passing the processed data to be rendered, recalculating stuff repeatedly within a loop that only really needs to be calculated once before the loop, &c. Code caches won’t help this kind of code all that much (though admittedly, they will help a little), and it’s more important to fix the code itself.
“Third switch your themes to some standard theme (for example-WordPress default theme) with all the plugins active and test the performances. If the performance remains sluggish, your problem isn’t in theme/template codes.”
This, on the other hand, is actually a decent tip.
“Excessive plugin uses/ use of plugin(s) with broken codes”
Again, a decent tip. However…
“best still, remove the non active plugins”
This won’t boost performance by more than 1ms or so, and only in the backend when WP is listing the plugins. WP doesn’t load any disabled plugins into memory. However, you should remove them, but only because they’re clutter you don’t need.
BTW, what are “slow/degraded MySQL querries”? I’ve never heard of an SQL query being described as “degraded” before. But on that topic, let’s talk indexes. A good tip for improving DBMS performance is to regularly (say, once every few days) to run ANALYZE TABLE on frequently updated tables such as the posts and comments tables, particularly the comments table. This will get MySQL to recalculate the table’s indexes, which will make lookups on it more efficient.
“Some particular third party widgets/ JavaScript codes”
This isn’t really a WordPress issue, and frankly, sluggishness is the least of your problems when it comes to stuff in the browser: most of those widgets are annoying and drive readers away.
“WordPress Dashboard’s display of RSS feeds”
Lack of caching in the WP core is the problem here.
“Pingback attempts when posting”
Michele covered this.
Unfortunately I can’t agree with you. The argument can go foever but In short here is why-
MySQL comments: Wp-cache saves your query for future use (reuse and recycle). So in case your MYsql server down that don’t make any difference does it?
“If this is the case, you’re either hitting the database too much or with a hosting company who’s doing some serious overselling.”
So what was my solution for that again? Hosting related right? No matter how you say, the summary is, problem is in hosting side.
“Make sure your WP database isn’t shared with your other sites.”
Your argument is wrong or should I say crap, try using a cms with few hundred pages (not posts) and share it with a forum or something. Theory is good but reality is always sweeter.
Your example has nothing to do with the shared database. You are comparing load time for readers and writers perspective, where the tips were intended for the designer not for readers.
Your whole discussion regarding memory usage, swapping and database, you just end up promoting dedicated server/own server. My tips were not why they should go for dedicated server. You should also consider your idea regarding eAccelerator.
Broken/Degraded PHP code in template/theme files.””
You did all the argument but at the end you did agree to fix the code
“This isn’t really a WordPress issue, and frankly, sluggishness is the least of your problems when it comes to stuff in the browser: most of those widgets are annoying and drive readers away.”
Once again same problem, you just ignored the audience. And third party widget code you put is not in the broser, rather within your template.
So at the end “poorly thought out and researched” would be not from my end.
Check your facts. wp-cache is a page cache, not a query cache: http://mnm.uib.es/gallir/wp-cache-2/
“So what was my solution for that again? Hosting related right? No matter how you say, the summary is, problem is in hosting side.”
Not unless you’re with a bad hosting company providing some very nasty shared hosting, which was my point. If you’re with a decent hosting provider, you’ve a shared hosting account, and you’re having performance problems, you probably need to think about dedicated hosting.
“Your argument is wrong or should I say crap, try using a cms with few hundred pages (not posts) and share it with a forum or something. Theory is good but reality is always sweeter.”
Please explain to me *why* it’s crap. A CMS with a few hundred pages isn’t particularly big, and I’ve dealt with much bigger sites than that in my time (example from a former employer: Best Process Chemistry is a rather widely and heavily used application within Pfizer, with several thousands of page; it hever has performance problems), and most of the time, the performance problems they’ve had have been down to poorly coded SQL queries (where the programmers didn’t understand joins or didn’t feel they were needed) or poor table indexing. So yes, what I said comes from actually *knowing* how MySQL and RDBMS in general work internally. Here’s a cold hard fact: if your tables are all MyISAM (as is typical for a WordPress install, the only thing that they have in common is that .frm, .myi, and .myd files for each of the MyISAM tables are stored in the same directory: there is no other interaction between the files.
“Your example has nothing to do with the shared database. You are comparing load time for readers and writers perspective, where the tips were intended for the designer not for readers.
I think you misunderstand. “Reader” and “writer” are technical words used to refer to threads of execution within a DBMS which are accessing some kind of store (such as a block of memory or a database table) concurrently. They don’t refer to actual real-world readers or writers. An understanding of concurrency is critical to understanding how to write performant database-backed applications, and the fact that you didn’t understand what I meant when I used those words makes me doubt your credentials in this regard.
“Your whole discussion regarding memory usage, swapping and database, you just end up promoting dedicated server/own server.”
No, if you’re on shared hosting, the “tip” you gave titled “PHP Memory Limit” doesn’t and can’t apply. It requires you to do things that you can only do with dedicated or colo, and that’s the context I mentioned them in. The same goes for eAccelerator.
“You did all the argument but at the end you did agree to fix the code”
Because the code is the problem. A code cache is only effective on well written code, because at that point, the bottleneck move from the code to the PHP bytecode compiler. When code’s poorly written, the bytecode compiler isn’t the optimisation hotspot, the code itself is, and that is what you fix first.