Comments on: Blog Performance Improvements http://blog.scotsnewsletter.com/2007/12/15/blog-performance-improvements/ Operating systems. Broadband. Issues. Reviews ... tech info you can use. Sat, 06 Sep 2008 16:55:53 +0000 http://wordpress.org/?v=2.6 By: Scot http://blog.scotsnewsletter.com/2007/12/15/blog-performance-improvements/#comment-386 Scot Mon, 18 Feb 2008 00:37:15 +0000 http://blog.scotsnewsletter.com/2007/12/15/blog-performance-improvements/#comment-386 Glad to be of service. Not sure whether it was the cache tool or the webhost solution you were referring to, but I added a link to WP-Cache in the post in case that helps. It's not clear to me that the concurrent user limitation will be something that will be universally helped by separate user names for the databases. But if that's what you're doing, I hope you'll come back and let us know whether it worked. -- Scot Glad to be of service. Not sure whether it was the cache tool or the webhost solution you were referring to, but I added a link to WP-Cache in the post in case that helps.

It’s not clear to me that the concurrent user limitation will be something that will be universally helped by separate user names for the databases. But if that’s what you’re doing, I hope you’ll come back and let us know whether it worked.

– Scot

]]> By: cgilkison http://blog.scotsnewsletter.com/2007/12/15/blog-performance-improvements/#comment-382 cgilkison Sun, 17 Feb 2008 23:43:45 +0000 http://blog.scotsnewsletter.com/2007/12/15/blog-performance-improvements/#comment-382 I can't tell you how much time this post just saved me. With five wordpress databases under one user, I was constantly running under this problem, but no one at Dreamhost seemed to be able to tell me why. Now I actually look forward to the monday surge to see if this fix works. Thanks! I can’t tell you how much time this post just saved me. With five wordpress databases under one user, I was constantly running under this problem, but no one at Dreamhost seemed to be able to tell me why. Now I actually look forward to the monday surge to see if this fix works. Thanks!

]]> By: Scot http://blog.scotsnewsletter.com/2007/12/15/blog-performance-improvements/#comment-192 Scot Sat, 15 Dec 2007 22:59:39 +0000 http://blog.scotsnewsletter.com/2007/12/15/blog-performance-improvements/#comment-192 The last four hosts I've had have all had simultaneous-MySQL-database-call limits. They don't put this spec on their site details pages, but they have them. One of those hosts kicked me off its service because I was exceeding the unpublished limit too frequently. It said it couldn't handle the demand of the forums. Now, *that* was ridiculous. I disagree with you a bit, ruirib. I can tell you that at my day job, where among other things I'm editorially responsible for a large, high-volume website, we have heavy duty caching software in place to cut down on the number of simultaneous calls to our Oracle database. Because, otherwise, service would eventually crawl to a halt. You can't just run everything real-time out of a database -- especially during peak demand times. Where I agree with you is that 50 concurrent calls is a pathetically low number. By the way, my webhost doesn't have a more expensive service or offer an upgrade for a few dollars a month. I just got rid of a webhost (Hostway.net) that played those games. So I'm not saying you're wrong. Many hosts do do that kind of stuff. But IX does not. Of course, IX ain't perfect either. ;-) -- Scot The last four hosts I’ve had have all had simultaneous-MySQL-database-call limits. They don’t put this spec on their site details pages, but they have them. One of those hosts kicked me off its service because I was exceeding the unpublished limit too frequently. It said it couldn’t handle the demand of the forums. Now, *that* was ridiculous.

I disagree with you a bit, ruirib. I can tell you that at my day job, where among other things I’m editorially responsible for a large, high-volume website, we have heavy duty caching software in place to cut down on the number of simultaneous calls to our Oracle database. Because, otherwise, service would eventually crawl to a halt. You can’t just run everything real-time out of a database — especially during peak demand times.

Where I agree with you is that 50 concurrent calls is a pathetically low number.

By the way, my webhost doesn’t have a more expensive service or offer an upgrade for a few dollars a month. I just got rid of a webhost (Hostway.net) that played those games. So I’m not saying you’re wrong. Many hosts do do that kind of stuff. But IX does not. Of course, IX ain’t perfect either. ;-)

– Scot

]]> By: ruirib http://blog.scotsnewsletter.com/2007/12/15/blog-performance-improvements/#comment-191 ruirib Sat, 15 Dec 2007 22:45:24 +0000 http://blog.scotsnewsletter.com/2007/12/15/blog-performance-improvements/#comment-191 IMHO, the 50 cuncurrent connection limit is imposed by the host but it's not that common. I find that there are no reasons for that, specially with a database system that costs... well nothing. There is no justification for that limit, pure and simple, except to force you to pay a few more bucks per month... It's ridiculous. IMHO, the 50 cuncurrent connection limit is imposed by the host but it’s not that common. I find that there are no reasons for that, specially with a database system that costs… well nothing. There is no justification for that limit, pure and simple, except to force you to pay a few more bucks per month… It’s ridiculous.

]]>