FogBugz Technical Support

A forum for technical support discussion related to Fogbugz.
The current FogBugz Knowledge Base can be found at http://help.fogcreek.com/fogbugz.

Posts by Fog Creek Employees are marked:

Documentation
Release Notes
Network Status

FB6 Performance: Poor compared to FB4

(What I mean here is grunt UI responsiveness.)


This has happened to me all week, and it is time to bring it up:

The first time I access FB6 in the morning, it takes 10+ seconds to respond. It may well be 20 seconds.

This never happened with FB4.


Also, at times, simply fetching a case by case # is slow in FB6. In FB4 it was snappy snappy.


Also, when my PC CPU is busy, FB6 is a dog. For example, I do a couple of CPU intensive things for 1+ hours every day:
  -Running junit or nunit tests that run for 1 to 20 minutes each
  -Producing video avi's (software demos, some of which
  are 30-130 minutes long, and take 1+ hours to
  encode)

  These tasks peak my CPU for extended periods.

In FB4, this had no real effect on the responsiveness of FB in my browser. The browser itself was a tad slower due to system load, but FB4 did not suffer in any large way, it was usable.

FB6, however, is slow to the point of being almost unusable. The AJAX load on the local CPU is real, and if the CPU is encoding a two hour video, FB6 suffers hugely.


None of my hardware has changed. It is the same FB6 DB, the same web server, same SQL server. Same workstation.

Most of the time, FB6 is OK. But at times, FB6 suffers hugely where FB4 was always snappy snappy.
Sam Jones
Friday, December 21, 2007
 
 
Haven't used anything prior to FB6, and only use the online version, and performance is fine from my "New" machine, dire from my "Old" machine, but that's not limited to FB.

None of which helps you of course ...

However, my various thoughts are:

AJAX CPU effort cannot be much different to round-trip can it?  The CPU effort to render a whole page is (I would guess) more than the effort to do a "skinny" round-trip of just the changed data, and then do some sort of local HTML-mangling to re-render the page.

The Javascript is probably, comparatively, huge so may have a larger footprint.

Its also possible that the database is slower (so overall time slower), but I am hearing you say that the slow-down when your machine is busy is disproportionately longer [than with previous version], so that probably wouldn't be relevant;  personally I would look at the key DB queries in case adding an Index here & there helps.

I saw in another thread a suggestion to check that Caching was on; including optionally turning it on for httpS

Personally I think all the AJAX stuff I use is very "first generation", even if not exactly New Technology, and better things will come along as more experience is gained.

I've found Firefox/Firebug very helpful in diagnosing what's going on in such situations (and equally if that is your normal working state to DISABLE Firebug on sites where it isn't needed!)

Do your local-install use httpS for everything (as the Online version does?)

I'm just typing-out-loud in case I have any thoughts that you haven't had and are useful to you.  We are planning to upgrade our Web Apps to use AJAX shortly, so real-world issues are of particular interest to me at present ...
Krispy Send private email
Wednesday, December 26, 2007
 
 
A reference point:

I am the only one on the dev team in the office today. So FB has not been touched by any user for 20+ hrs.

I pressed my shortcut button in firefox to go into FB. It took a full 22 seconds (I counted this time) for the FB UI to even show up in the browser, and it was another 8 seconds before the hourglass cleared and I could touch FB.

A full 30 seconds.

That never ever happened on FB4. Nothing in the ballpark.
Sam Jones
Monday, December 31, 2007
 
 
I see 30second+ cold-start times too - on a 4GB Core2duo machine.

From playing around with Procmon, I think it's largely the compilation time of the ASP code - it seems that EVERYTHING gets compiled when an interactive user first goes to log-in, including things like localization files for languages you're not using.

Unfortunately, this mass-recompilation *isn't* triggered by the heartbeat process, which would at least mean that one would always get a 'warmer' performance.

I don't really know much about trad-ASP compilation/cacheing, and it's hard to research because no-one writes articles about ASP any more.  I don't know where the 'compiled ASP' is stored, or how long it's stored for, and if any of that is controllable.

I have half-heartedly fiddled with running a scheduled process on our FB server to open the FB logon page every hour or so in an attempt to get around this problem, but for some reason I haven't made it work properly yet.
Will Dean
Monday, December 31, 2007
 
 
There are "keep alive" tools to prevent code unloading, but I thought that was an ASP.NET problem, rather than Classic ASP.  Might be worth a Google though ...
Krispy Send private email
Tuesday, January 1, 2008
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz Bug Tracking and Evidence-Based Scheduling.