Although SP is starting to slow down for me, its still going at a alright pace. But the search query for some reason was going incredibly slow. A few minutes earlier it worked quite fast.
When working with the search it seems to be trying to load some kind of advertisement (displays the url from ad on bottom). Does this majorly effect the speed?

Whatever you did it sure helped on my end. I am now able to upload photos without getting the generic browser reply about trying to reconnect to your server. Good work man. I didn't mean to be a jerk but for months I was getting failed uploads and page updates at all times of the day and night and I was almost ready to pull the plug on this site and go build my own.


Thanks,

Bob

Yep, thanks Matt. I may start voting again!

Page load pretty good, Matt. Seems to work fine.
This afternoon, I've been trying to make changes to some pages I took over and submitting the changes
is taking quite a while. Maybe I'm just impatient but it seems to be taking upwards of 30 seconds to upload everything
from a sentence change to whole images with links. Is there a difference in the 'coding end of things' between uploading content vs.
clicking previously uploaded content?
Thanks, Matt!

Kiefer Thomas wrote:Page load pretty good, Matt. Seems to work fine.

OK good. I think so too.

Kiefer Thomas wrote:Is there a difference in the 'coding end of things' between uploading content vs. clicking previously uploaded content?

If I recall correctly, no, the code is essentially the same, but it may be worth looking at again. You're noticing longer times to edit existing content than simply creating new content? If it's repeatable, then it would be worth investigating.

The root of the problem is that in either case (modifying content or creating new content), the `objects` table in the database has to be written to. The `objects` table and the `users` table are the only two tables left in the database that use MyISAM storage engine. All of the rest of the tables in the database have been moved to the InnoDB storage engine. The key difference between the two storage engines that is causing the delays is that the MyISAM storage engine locks at a table level when doing writes, while the InnoDB locks at a row level.

That means that anytime someone is writing to either MyISAM table (objects or users), they must wait for all of the reads to complete before the table can be locked and the write is completed. And every time someone loads a page on SP, they're reading from the MyISAM `objects` and `users` tables. So writes are delayed until all pending reads are completed, which during high traffic times could be quite a wait.

The solution to the problem is to move the `objects` and `users` tables to a storage engine that allows simultaneous reads and writes (the InnoDB engine in MySQL). The problem with that is that the InnoDB engine doesn't support fulltext search, so if those tables were switched to using the InnoDB storage engine, end users couldn't search for users or objects by name which would be unacceptable. So to fix this problem gets very involved and complicated. There are ways around having tables with fulltext indices while maintaining a way to search the entries of the table, but it requires a significant change to site structure (database and code). I want to do it sometime in the near future, but I don't currently have the time to invest in such a large project. I'm hoping that I will sometime this winter though.

I got bored and decided to read part of this article:
http://tag1consulting.com/MySQL_Engines ... _vs_InnoDB

Lately I been working with databases myself. It gets a bit complicated (although yes, I'm not super experienced at it). Anyways, thanks for looking into it Matt, hope some day for a solution to this.

Has anyone else noticed this. It seems to be decent speed most of the time, then randomly it goes slow for a page load (while it's loading I open up a new tab for sp which is virtually instant, and then my other tab eventually works). But then again this mostly applies to changing pages. Well it's not a big deal so far. (this post took less than a second to be published. )

Josh Lewis wrote:Has anyone else noticed this. It seems to be decent speed most of the time, then randomly it goes slow for a page load (while it's loading I open up a new tab for sp which is virtually instant, and then my other tab eventually works). But then again this mostly applies to changing pages. Well it's not a big deal so far. (this post took less than a second to be published. )

Yep. Noticed that too. It had me scratching my head. In fact, it still scratches.
Thanks for the response, Matt. I actually had to look up a couple words in your response!
I'll keep plugging away at it. Today, page loads for edits to new content is taking upwards of 4 minutes. But at least there's
a reason for it. Thanks, Matt.

Now I'm becoming more hesitant to post my trip reports in pieces (with most of it done in the first posting). I try to post as much as possible before hitting the submit button because I know how long it will take for it to be published.

Really? I haven't seen any slowdown for the last couple of weeks

So do your submissions post fast when making a edit on a page? I just did a test which it seems as though it is faster to post a page than it is to edit a page. Try editing one of your mountain pages or trip reports and let me know if it posted at a decent speed. I posted a test page a few seconds ago (I deleted it) and it posted right away.

SP is dead slow again this evening. It's unusable if you're trying to upload images or work on pages.

Hmmmmm... Seems to be running fine on my end.

Well I guess than pretty soon I should launch what I call "Operation Clean up SummitPost". Basically it would encourage users to do some simple things that would help speed up SP. I'll have to make some screen shots so it might be a few days.

Aaaarg ... it's been moving like a SNAIL on my end ...!

Hope "Operation Clean-up Summitpost" gets started quickly ... my hands are getting tired holding up this sign ...