Closed Bug 550582 Opened 14 years ago Closed 14 years ago

MDC (developer.mozilla.org) is very slow

Categories

(developer.mozilla.org Graveyard :: General, defect)

Product:
developer.mozilla.org Graveyard
Component:
General
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: BenB, Unassigned)

Details

MDC (https://developer.mozilla.org) is very slow. Very often, it takes 20s to respond. I expect 200ms, maximum 1s. This slows down work.

Sometimes, I even get "service unavailable" for some pages, reload fixes it.

The "service unavailable" shows is that it's not the pure web server which is the problem. Please upgrade/add server(s) *and* (much more importantly) check out the software layers, how you can cut down unnecessary processing dramatically. Probably there's a huge amount of processing going on that could be removed, somehow - the response times can't be explained in another way.
I restarted the dekiwiki daemon on both webheads.  When this has become an issue in the past that usually fixes it.

I suspect you're absolutely right that there's software issues, but there's not much we can do about that ourselves.  Maybe Sheppy can pester the vendor again. :)
Assignee: server-ops → justdave
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Please keep open until the underlying issue is fixed.

Also, response time here is around 2s. As said, *maximum* should be 1s, esp. for a site that's integral in our work (and basically just displays webpages).
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Thanks for restarting, BTW. Definitely much better - for now.)
(In reply to comment #2)
> Please keep open until the underlying issue is fixed.

I think you're arguing for the sake of arguing here. I was just poking around at it before you reopened to make sure my restart actually got some speed back, and it seemed plenty responsive to me. We've been through this a dozen times already, there's not much else we can do on our end. If anything further needs to be done it's going to have to be done within the app.
Assignee: justdave → nobody
Component: Server Operations → Infrastructure
Product: mozilla.org → Mozilla Developer Center
QA Contact: mrz → infrastructure
Version: other → unspecified
> We've been through this a dozen times already

I know :-), I've seen it before, too. That's why I reopened it, because I don't want this to keep coming back.

>  it's going to have to be done within the app.

Yes, that's what the initial description said :).
Thanks for re-assigning, I didn't know the other Product.
Status: REOPENED → NEW
(In reply to comment #2)
> Also, response time here is around 2s. As said, *maximum* should be 1s, esp.
> for a site that's integral in our work (and basically just displays webpages).

To be far, basically displaying -dynamically- generated webpages in a C# app.  This is in no way a simple app or something that "just displays webpages" (the dream that would be if it were!).
> displaying -dynamically- generated webpages

Not necessarily. The content is basically static. The dynamic generation is just how we chose to do the content management.
You could just as well have them all as static webpages, and generate and update them every time somebody modifies the wiki page.
I.e. each time somebody clicks "save", a complete, static page is generated, written to /cached/, and the web server serves from there when somebody requests the wiki "page" (not "edit" mode, history or whatever). I think you could even implement that with little or no modification of the Wiki application.
It's very slow again
Filed bug 559337 about the static page idea (given that it was ignored here), and closing this.
Status: NEW → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Expected response time: 200ms.
Actual response time: 20000ms or no response at all.

Hello? Is somebody home? MDC is again extremely slow, with failure to respond for >50% of the requests, since about a week at least. I expect such problems to be fixed within the hour, not days or weeks, and not to come back every other week. The situation is unbearable.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
This is a known problem and is being worked on. Please see http://www.bitstampede.com/2010/04/23/stating-the-obvious/ for details.
That's good to know, but the problem is known since almost 2 months (when I filed this bug).

And I made a suggestion, which is fairly easy to implement, does not depend on proprietary software, and solves the problem for most cases (viewing page): bug 559337. So far, in all bugs I filed, you've only responded to tell me "can't do".
I understand your frustration (trust me, I guarantee I'm more frustrated than you are). But things have taken a recent turn for the worse in terms of performance and we're working to understand why.

It's not a matter of "can't do". It's a matter of "it doesn't make sense to do that right now."
> I guarantee I'm more frustrated than you are

OK, I will not add any frustration, then. Good luck!

I still do think that my caching suggestion is the fastest solution to your current problems, as that can be implemented in a matter of hours, without any dependence on MindSource vendor.
We are not dependent on the vendor unless we choose to be; it is an open source application, which we insisted on when we deployed it.

I don't think you could implement that solution in a matter of hours, but if you would like a contract to do so, I would be happy to pay 5 times your usual hourly rate for a fixed-price delivery of such a system.  You know how to contact me!
(In reply to comment #16)
> We are not dependent on the vendor unless we choose to be; it is an open source
> application, which we insisted on when we deployed it.

This is not true.  It's closed source, we have no access to the source code, it's a huge black box (which is why IT can't fix it ourselves).  It's all precompiled C# code running in Mono.
What happens if two Deki templates reference each other? Can this eat up CPU time?
(In reply to comment #17)
> This is not true.  It's closed source, we have no access to the source code,
> it's a huge black box (which is why IT can't fix it ourselves).

The Mindtouch Core is GPL-v2, and the Mindtouch Pro is Shared Source.  Both of them have source available.  I will ensure that we get our hands on the source that matches what we have deployed, so that IT can fix it ourselves!  I look forward to it!
Probably doesn't help that we don't have anyone on staff that knows C#
There's a pretty big difference between "it is a black box that we can't change, or we could fix it ourselves" and "the source doesn't help us, because we don't know how to use it".  Which is it?  I just mailed the developers demanding the source code...
Yeah, big difference indeed.  We can always learn. ;)  The fact that the source was available was news to me.  Quite welcome news, mind you. :)  From what I understand blizzard and morgamic are already working on poking at it since we made that discovery.
http://mdn.beonex.com/
Short-term workaround, in case you need to read the docs, but can't reach MDC. Limitations:
- DNS should get active within 24h, but will randomly fail ATM
- "dir.1" URLs
- Only English
- No edit, history etc.
Response time is currently about 3s for me, which is workable. But of course still not as fast as it could be. Please do implement bug 559337.
Closing this bug, will reopen in case it gets bad again.
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Component: Deki Infrastructure → Other
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.