It would be better to figure out why setting off Keep-Alive has such
drastic performances problems. Might be an issue with some proxy / nat /
router at the server side.
En l'instant précis du 01/02/08 12:59, caped crusader s'exprimait en ces
termes:
I appreciate everyone's input and help, and this may well just be an
IE issue.
I've found an obvious difference in the headers. In IE the connection
header is set to 'close', in FF it's 'keep-alive'.
As a test in FF I turned off the keep-alive setting in 'about:config'
and this slowed down Firefox's performance considerably. Now need to
figure out where/why this is getting set for IE
Thanks
JM
On Thu, Jan 31, 2008 at 7:37 PM, David Delbecq <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Sniff both transactions, compare, find correct solution and post it
here, am really curious to know where this comes from?
caped crusader a écrit :
> Good idea. Tried it but it had no effect.
>
> On Thu, Jan 31, 2008 at 4:24 PM, Andrew Robinson
> <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
<mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>>
> wrote:
>
> Have you tried changing your IE cache settings to never
check for
> updates instead of "automatically" or "every time"? Worth a
try as
> a test to see if it has an effect.
>
>
> On Jan 31, 2008 5:42 AM, caped crusader
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>> wrote:
>
> Thanks for the suggestions everyone.
>
> Our pages are very simple, very few images, very little
> javascript, and we're not using any extra javascript
libraries.
>
> There is nothing obviously different in the server logs in
> terms of the files being fetched. I'm going to try the
> suggestions here and see if what turns up.
>
> The puzzling aspect is the very large difference in time
(by a
> factor of 4) between IE and Firefox. This makes me wonder is
> there a difference in how IE is handling either caching
or if
> it is waiting for everything in the page to load before
> rendering it to the screen, whereas FF is perhaps rendering
> the page, but allowing non-visible elements to download
in the
> background. Mind you, in FF, the browser progress bar, which
> presumably the download status of all elements on the page,
> completes in 6-7 seconds, compared to the 23 or so of IE.
>
> JM
>
> On Thu, Jan 31, 2008 at 8:46 AM, David Delbecq
> <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
<mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> wrote:
>
> Using ctrl-I on firefox , in the medias tab you will get
> an idea what is
> loaded by pages. If you see tons of javascript, css and
> picture, that
> might be the source of your problem. Note that we had a
> similar problem
> here once, JSF was slow to render (same time for IE /
> firefox), we
> discovered we had a filter in our config that was, for
> database
> transaction reasons, limiting request to one request
at a
> time per
> session (use of synchronized block on user session).
As a
> result, all
> queries for JS/CSS/pictures coming from JSF component
> where queued and
> serve one at a time instead of in parallel.
>
> Even complex JSF pages shouldn't take 23 seconds to be
> returned to
> client. Also note that complex css layout can sometimes
> takes time to
> get rendered client side, but 23 seconds.... ? Even 6
> seconds is far too
> much for average users :)
>
>
> En l'instant précis du 31/01/08 09:15, Christopher
> Cudennec s'exprimait
> en ces termes:
> > You should try a tool like ProxySniffer or a
plugin for
> FF or IE to
> > see why your page performance is that bad. We had some
> problems in our
> > project concerning included css and js-files. You
should
> be able to
> > see who's "responsible".
> >
> > Cheers,
> >
> > Christopher
> >
> > Martin Marinschek schrieb:
> >> Are you using any javascript libraries? Dojo?
> >>
> >>
> >>
> >> regards,
> >>
> >> Martin
> >>
> >> On 1/30/08, Simon Kitching
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>> wrote:
> >>
> >>> ---- caped crusader <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>> schrieb:
> >>>
> >>>> Hi
> >>>>
> >>>> I have a JSF application with some quite unusual
> performance problems.
> >>>> Loading pages in IE7 takes 4 times as long as in
> Firefox (v2.0.0.11).
> >>>>
> >>>> When I test the application locally, response times
> are good, and
> >>>> pretty
> >>>> similar for IE and FF. When I test our actual
> deployment, pages
> >>>> take on
> >>>> average 6 seconds to load in Firefox, and about 23
> seconds in IE7. The
> >>>>
> >>> pages
> >>>
> >>>> that are being rendered are very simple, with
perhaps
> 10-12 links
> >>>> and a
> >>>> handful of form fields. Much as I'd love to
tell our
> users to just
> >>>> use FF,
> >>>> most of them use IE and making them switch is
not an
> option.
> >>>> I've already looked at the performance page on the
> MyFaces wiki, and
> >>>> implemented the server-side tips there.
> >>>>
> >>>> I'm using
> >>>>
> >>>> MyFaces 1.14
> >>>> Tomahawk 1.1.3
> >>>> Firefox 2.0.0.11 <http://2.0.0.11/>
<http://2.0.0.11/>
> >>>> Internet Explorer 7.0.5730.11
> >>>>
> >>>> Are there any other obvious areas anyone can
think of
> to target?
> >>>>
> >>> One thing that comes to mind is that Firefox
might be
> caching some
> >>> resources
> >>> while IE is not caching them, and so repeatedly
> fetching something.
> >>> This
> >>> difference might not show up when the server is
local,
> but be much more
> >>> significant when the server is remote and more
heavily
> loaded.
> >>>
> >>> I suggest you enable logging of all requests on your
> server and then
> >>> compare
> >>> the list of URLs fetched by firefox with the list of
> URLs fetched by
> >>> IE for
> >>> the same page. This can be done on your "local"
> server, not the
> >>> remote one.
> >>>
> >>> I would also enable the "live headers" plugin in
> firefox and have a
> >>> look at
> >>> the http headers for pages, making sure that
they have
> the appropriate
> >>> caching headers set.
> >>>
> >>> Regards,
> >>> Simon
> >>>
> >>>
> >>
> >>
> >>
>
>
> --
> http://www.devlog.be <http://www.devlog.be/>
<http://www.devlog.be/> (a belgian
> developer's logs)
>
>
>
>
>
--
http://www.devlog.be (a belgian developer's logs)
