Posted By: Sven Groot | Jul 6th @ 6:16 PM
page 1 of 1
Comments: 21 | Views: 648
Sven Groot
Sven Groot
You can't have everything; after all, where would you put it?
The new C9 seems to have two possible conditions: either it's lightning fast (pages open almost instantly) or it's dog slow (pages take 20 seconds or more to open).

Unfortunately it's still more often the latter than the former. It feels like you still may have an application reset bug.
littleguru
littleguru
allein, allein,... allein, allein!

What I have noticed and also reported to Erik is that C9 seems to be slower during the European day and faster in the night. I have noticed that behaviour although I can't really tell you if it can be generalized.

mVPstar
mVPstar
I'm white because I smelt an onion.

Well, it was slow during the time Sven posted.

harumscarum
harumscarum
out of memory
Get the same conditions here
figuerres
figuerres
???
TimeZone translations are a B*!  I have an app that has to do them and sometimes I have to go over the rules with the customer when they think my code was wrong... 

that aside I agree that C9 needs some kind of check-up / tune-up etc....


for example I click on an HREF  and sometimes all I see is the IE "throbber" in the tab to tell me that anything has happened.
the page needs to have some kind of change -- a large throbber or a style effect or , classic http -- clear the page!

the more I see this kind of thing (and not just on C9) the less I like AJAX.

in some ways classic HTTP page loads are better, you generaly get a clear UX on click-on-href actions that users know and have some idea what is happening, you get feedback that your request did something.
HumanCompiler
HumanCompiler
Compiling humans...and code
The throbber and opaque overlay isn't enough of an indication that something is happening?  Not sure what to say to that.  You use client software, right?  What do they do there?

Once we have the entire site working without javascript (only a few places work without javascript right now), we can add a setting in your profile that lets you force the site not use javascript (if enough people are interested).
figuerres
figuerres
???

the overlay does not always happen.

when the site is running "spot on" then it looks just fine.

but when it get's "hosed"  for what ever reason then the "visual cues" like the overlay do not seem to happen at all.

sometimes when I am clicking for example the link at the top of of the page, the "bread crumb" to take me from the thread back to the list of threads for example...  sometimes that click happens in say 0-3 seconds (guess at time, idea is "Fast")  other times that same action seems to take say 10 seconds to... ?? not sure cause I give up and close my browser window.

that's where it's bad/ugly  when clicking on the link leaves the page untouched visualy but the page icon/ IE throbber is doing the "throb"  so I know that my click left my browser but the browser has not got a reply from the server .... and I sit there and wait...

when that happens it's almost like IE is hung, the AJAX client script is (I Guess) looking for the reply to come back and has the UI kind of locked up till it gets a reply.

I generaly will try and wait ... but sometimes it just seems like it's forever...

often if I just close IE and start over then things run better... not sure if this means that the new session is hitting a different server in the farm, or if some server side blocking process has clearned, or a worker re-cyled or....

whatever it is from the user end of things it really sucks when that happens.

 

also replys to a thread /post that I add, sometimes the page updates and I see my new post, but not always...

this makes it seem like the site is not reliable, I know that if I re-load the thread with a full page load it is there, but with AJAX I am not supossed to need to do that...  the thing is for a non-tech user this kind of stuff looks bad and makes the user unsure about the system.

I have been doing some AJAX on my own sites and I am not sure if I will keep using it or stop.

when it works right it's great.

but when it's not.... not so great.

 

HumanCompiler
HumanCompiler
Compiling humans...and code
Ok, so what it really comes down to is...when the site is slow the experience is bad.  When the site is fast, the experience is good.  Even going the non-Ajax route the experience wouldn't be very good.  If the browser has contacted the server for the new page but hasn't heard anything back yet then nothing will happen other than the IE throbber telling you it's trying to bring up the page.  The page won't usually "go white" until it's started to hear something back from the server.  So I'm not sure that's a very good experience either.

That said, we're working to fix the root problem.  The site is blowing 10 to 20 exceptions every minute and about every 40 minutes, giving up and restarting.  Unfortunately, we can't see what the exception is (HttpUnhandledException).  We're working on fixing the other exceptions we can see in hopes that will fix the problem.  Needless to say (and back to the original post of this thread), we've got some issues and we're working through them.  Once we get those fixed, the site should be back to fast and hopefully most of your usuability issues will be gone.

Regarding replies not always showing up...yes, it sucks and we're aware of it.  This issue is unrelated to Ajax for the most part, but Ajax makes the problem more obvious.  Two things:

  1. For now, if instead of clicking the browser refresh button you click the Ajax refresh button (located to the left of the pager buttons), once the new comment becomes available (from the server you happened to hit) it will show up (and a lot less data will be sent down to you than an entire page refresh) and scroll down and be selected.
  2. The way we do caching right now is great for performance, but not for data consistency.  Since we're on a web farm we need a way to invalidate cache so when something is added or removed from cache on one server, the other servers in the farm know to re-get the data from the database.  We do it by setting something in a table and polling it periodically (every 10 seconds [on every web node]) at the moment.  We've met with the Velocity team and gone over our data and what kinda of caching we need.  We believe Velocity will work really well for us and once we have some time we will implement it to see how it works (in its current CTP state).  Since Velocity allows you to control your cache better and does all the sync'ing across nodes for you, this will become a non-issue.
In the postback world, users almost always hit the same web node in the farm (cache is invalidated instantly and users see their comments immediately).  In the Ajax world, there is no gaurantee a user will ever hit the same web node.  Chances are high they won't so the problem is much more obvious.

Not sure how fast (or slow) we'll get Velocity in there, but I'd say it's at least a couple months out (we're swamped with other stuff at the moment...PDC related at the moment).

We will continue to get incrementally better with all of this stuff.  Thanks for being patient.
figuerres
figuerres
???
"The site is blowing 10 to 20 exceptions every minute and about every 40 minutes, giving up and restarting.  Unfortunately, we can't see what the exception is (HttpUnhandledException). "

Now that's gotta be ugly / nasty .... that alone must throw chunks all over site performance....
heck if you can pin that down it might fix things a *LOT*  I am sure you know that ...

like I said, I have some Ajax stuff and I know it can be a tad touchy, and I am not running a farm with the cross server issues to sort out.
Bas
Bas
It finds lightbulbs.
I personally am perfectly happy with the AJAX stuff. When the site works, performance is great and AJAX goes a long way in boosting the perceived performance even more.

But when it doesn't work, and this is often, the experience is horrible. I'm currently waiting several minutes before the thread list in the forums shows up. Want to read a thread? Come back five minutes after clicking.

This is unusable now. I hope resolving those exceptions and restarts fixes it, because this is a nightmare.
Sampy
Sampy
"It's my timey-wimey detector. It beeps when there's stuff."
I deployed a bunch of performance related fixes today that should help with the fast-slow-fast nature of things recently.

Let me know what you think.
Bas
Bas
It finds lightbulbs.

So far it seems to be working well. Let's see what happens during the daytime.

Site's kicking ass today.  Great job, Sampy!
mVPstar
mVPstar
I'm white because I smelt an onion.
Yeah, much better.

Though, the editor box controls were loading slightly slow earlier...
Sampy
Sampy
"It's my timey-wimey detector. It beeps when there's stuff."

Unhandled exceptions are bad.

Bas
Bas
It finds lightbulbs.
Much better now, let's hope it lasts. Great job!
figuerres
figuerres
???

let me fix that for you:

was:  "Unhandled exceptions are bad."

should be: "Exceptions are bad when they happen more than one an hour."

I'd be going nuts till I found and halted the 10-20 a minute that HC posted as happening, at that rate I am amazed that it works at all Smiley

I guess in a way that's backward praise for the site and .Net and IIS that it's able to keep chugging along even with some horribe internal bug(s) thrashing it to death.

 

HumanCompiler
HumanCompiler
Compiling humans...and code
Yup, definitely cool that it was working at all.  Good that the site didn't go completely down.
TommyCarlier
TommyCarlier
Trust me, I'm from the Internets
Wow, it's much faster now. Thanks.
HumanCompiler
HumanCompiler
Compiling humans...and code
No problem.  Go team!  Smiley