RE: [PHP-DB] File Optimisation

2001-03-15 Thread Steve Brett

Hi,

Thanks for the comments, we do use IE but for the future we have to keep an
open mind as there is a fair chance the network may go linux.

There are plans for a windows type app in the pipeline already, with the web
front end being the test-bed so I guess things ewill improve. Gonna do some
load testing today and see if the gzip thing is as promising as it looks.

As for splitting the page we do this already for one department and they
love it. However, another department refuse to change or compromise so i
think i'm in for a bit of 'change management' over the next few weeks.

:-)


-Original Message-
From: Mal McKay [mailto:[EMAIL PROTECTED]]
Sent: 14 March 2001 17:12
To: Steve Brett
Cc: [EMAIL PROTECTED]
Subject: RE: [PHP-DB] File Optimisation


I wouldn't know about flushing the buffer.
Another approach would be changing to ADO. This being an intranet, i'd
assume that you could force users to use IE on windows (or provide a IE
specific page but keep the current page for other brwosers).
This way you either connect direct to the database or send down an CSV file
to the browser.
Speed should be improved with this approach, and it should reduce the memory
load on the user's browser, useful for those low memeory machines lying
around.

Try and compare the speed you get to the speed with Access over ODBC or even
with a random mailbox or contact address book of apropriate length to get an
idea of how slow the page _really_ is. I'd say you'll be happy with the
speed once you've seen that everything else is similar at those sizes.

And to bring this email's total value up to 6 cents, try putting a few drop
down menus to filter the page and see how the boss likes it. He should
appreciate the difference. Any page that loads up fast is impressive, even
if he wants more (ie all the info on the page instead of 2 weeks say). they
always want more



-Original Message-
From: Steve Brett [mailto:[EMAIL PROTECTED]]
Sent: 14 March 2001 16:57
To: [EMAIL PROTECTED]
Subject: RE: [PHP-DB] File Optimisation


it does work.

i've tested it using ie5 and the network traffic is reduced dramatically.

not much of an imporvement on speed though 

would have to test it some more - do i need to manaully flush the buffer or
is this done automatically ?

Steve

-Original Message-
From: Mal McKay [mailto:[EMAIL PROTECTED]]
Sent: 14 March 2001 16:39
To: Steve Brett
Subject: RE: [PHP-DB] File Optimisation


Most modern browsers can decode gzip format and display the expanded file.
I don't actually know any more details, so you'll have to experiment, or
maybe someone else can help.
A company did try to commercialise on this fact, provide a server that

automatically sent zipped files and a plug-in that handled them seamlessly,
but I've long since forgotten them.

It may be a case of users having the "save to disk/Open from remote
location" dialog coming up and having to pick "Open from...";

-Original Message-
From: Steve Brett [mailto:[EMAIL PROTECTED]]
Sent: 14 March 2001 16:19
To: Mark Newnham; [EMAIL PROTECTED]
Subject: RE: [PHP-DB] File Optimisation


i've used both already. not so ruthless with the css and there is no java at
all in there. just html.

the db produces 15 sessions per working week for 100 users for 12 weeks so
there is a fair chunk of data there ...

-Original Message-
From: Mark Newnham [mailto:[EMAIL PROTECTED]]
Sent: 14 March 2001 16:11
To: [EMAIL PROTECTED]
Subject: RE: [PHP-DB] File Optimisation


The first thing I would look at ( having had the same issue ) is whats
actually in the document. I managed to reduce the size of data delivered by
60% by 2 methods.

1. Ruthless use of css in table formatting.
2. Creating javascript functions for even the smallest inline feature such
as mouseovers.

Regards


Mark

 -Original Message-
 From: Steve Brett [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, March 14, 2001 4:02 PM
 To: [EMAIL PROTECTED]
 Subject: [PHP-DB] File Optimisation


 I have a calendar system that details the appointments for various
 departments in the company and am having problems with the
 sheers size of
 the html docs that are returned.

 One department insists that they nned to see all the users in
 one go (approx
 110) and the calendars for 3 months.

 This causes an html doc being returned frm the server that is 3.5 meg.
 Whilst is takes the server 4 seconds to build and deliver this I was
 wondering if there is any way to speed things up and reduce
 the amount of
 network traffic.

 Would zipping the file b4 it is sent be a good (and easy) way to go ?

 Thanks in advance,

 Steve Brett
 Internal Development
 EMIS Ltd.
 "Privileged and /or Confidential information may be contained in this
 message. If you are not the original addressee indicated in
 this message (or
 responsible for delivery of the message to such person), you
 may not copy or
 deliver this message to anyone. In such case, please delete
 thi

RE: [PHP-DB] File Optimisation

2001-03-14 Thread Mark Newnham

The first thing I would look at ( having had the same issue ) is whats
actually in the document. I managed to reduce the size of data delivered by
60% by 2 methods.

1. Ruthless use of css in table formatting. 
2. Creating javascript functions for even the smallest inline feature such
as mouseovers.

Regards 


Mark

 -Original Message-
 From: Steve Brett [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, March 14, 2001 4:02 PM
 To: [EMAIL PROTECTED]
 Subject: [PHP-DB] File Optimisation
 
 
 I have a calendar system that details the appointments for various
 departments in the company and am having problems with the 
 sheers size of
 the html docs that are returned.
 
 One department insists that they nned to see all the users in 
 one go (approx
 110) and the calendars for 3 months.
 
 This causes an html doc being returned frm the server that is 3.5 meg.
 Whilst is takes the server 4 seconds to build and deliver this I was
 wondering if there is any way to speed things up and reduce 
 the amount of
 network traffic.
 
 Would zipping the file b4 it is sent be a good (and easy) way to go ?
 
 Thanks in advance,
 
 Steve Brett 
 Internal Development 
 EMIS Ltd. 
 "Privileged and /or Confidential information may be contained in this
 message. If you are not the original addressee indicated in 
 this message (or
 responsible for delivery of the message to such person), you 
 may not copy or
 deliver this message to anyone. In such case, please delete 
 this message,
 and notify us immediately. Opinions, conclusions and other information
 expressed in this message are not given or endorsed by my 
 firm or employer
 unless otherwise indicated by an authorised representative 
 independently of
 this message."
 
 
 
 
 -- 
 PHP Database Mailing List (http://www.php.net/)
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 To contact the list administrators, e-mail: 
 [EMAIL PROTECTED]
 

-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




RE: [PHP-DB] File Optimisation

2001-03-14 Thread Michael Rudel

Hi Steve,

if your users have all JavaScript enabled, you could generate the HTML-Doc
clientside, using things like document.write or document.writeln.

Hope this helps.

Greetinx,
  Mike

Michael Rudel
- Web-Development, Systemadministration -
___

Suchtreffer AG
Bleicherstrae 20
D-78467 Konstanz
Germany
fon: +49-(0)7531-89207-17
fax: +49-(0)7531-89207-13
e-mail: mailto:[EMAIL PROTECTED]
internet: http://www.suchtreffer.de
___



-Original Message-
From: Steve Brett [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 14, 2001 5:02 PM
To: [EMAIL PROTECTED]
Subject: [PHP-DB] File Optimisation


I have a calendar system that details the appointments for various
departments in the company and am having problems with the sheers size of
the html docs that are returned.

One department insists that they nned to see all the users in one go (approx
110) and the calendars for 3 months.

This causes an html doc being returned frm the server that is 3.5 meg.
Whilst is takes the server 4 seconds to build and deliver this I was
wondering if there is any way to speed things up and reduce the amount of
network traffic.

Would zipping the file b4 it is sent be a good (and easy) way to go ?

Thanks in advance,

Steve Brett
Internal Development
EMIS Ltd.
"Privileged and /or Confidential information may be contained in this
message. If you are not the original addressee indicated in this message (or
responsible for delivery of the message to such person), you may not copy or
deliver this message to anyone. In such case, please delete this message,
and notify us immediately. Opinions, conclusions and other information
expressed in this message are not given or endorsed by my firm or employer
unless otherwise indicated by an authorised representative independently of
this message."




--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




RE: [PHP-DB] File Optimisation

2001-03-14 Thread Steve Brett

i've used both already. not so ruthless with the css and there is no java at
all in there. just html.

the db produces 15 sessions per working week for 100 users for 12 weeks so
there is a fair chunk of data there ...

-Original Message-
From: Mark Newnham [mailto:[EMAIL PROTECTED]]
Sent: 14 March 2001 16:11
To: [EMAIL PROTECTED]
Subject: RE: [PHP-DB] File Optimisation


The first thing I would look at ( having had the same issue ) is whats
actually in the document. I managed to reduce the size of data delivered by
60% by 2 methods.

1. Ruthless use of css in table formatting. 
2. Creating javascript functions for even the smallest inline feature such
as mouseovers.

Regards 


Mark

 -Original Message-
 From: Steve Brett [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, March 14, 2001 4:02 PM
 To: [EMAIL PROTECTED]
 Subject: [PHP-DB] File Optimisation
 
 
 I have a calendar system that details the appointments for various
 departments in the company and am having problems with the 
 sheers size of
 the html docs that are returned.
 
 One department insists that they nned to see all the users in 
 one go (approx
 110) and the calendars for 3 months.
 
 This causes an html doc being returned frm the server that is 3.5 meg.
 Whilst is takes the server 4 seconds to build and deliver this I was
 wondering if there is any way to speed things up and reduce 
 the amount of
 network traffic.
 
 Would zipping the file b4 it is sent be a good (and easy) way to go ?
 
 Thanks in advance,
 
 Steve Brett 
 Internal Development 
 EMIS Ltd. 
 "Privileged and /or Confidential information may be contained in this
 message. If you are not the original addressee indicated in 
 this message (or
 responsible for delivery of the message to such person), you 
 may not copy or
 deliver this message to anyone. In such case, please delete 
 this message,
 and notify us immediately. Opinions, conclusions and other information
 expressed in this message are not given or endorsed by my 
 firm or employer
 unless otherwise indicated by an authorised representative 
 independently of
 this message."
 
 
 
 
 -- 
 PHP Database Mailing List (http://www.php.net/)
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 To contact the list administrators, e-mail: 
 [EMAIL PROTECTED]
 

-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DB] File Optimisation

2001-03-14 Thread clayton collie

Steve,
   look at the output buffering/filtering methods in PHP (ob_) In
particular, you can enable the gzip filter to automatically zip your html
server side, assuming your user's browsers support auto gzip deflation,
which the newer browsers seem to 


"Steve Brett" [EMAIL PROTECTED] wrote in message
C05E7DA1218ED411BF8A00105AC95A8E01B1F3CF@SV-CNTRMAIL">news:C05E7DA1218ED411BF8A00105AC95A8E01B1F3CF@SV-CNTRMAIL...
 I have a calendar system that details the appointments for various
 departments in the company and am having problems with the sheers size of
 the html docs that are returned.

 One department insists that they nned to see all the users in one go
(approx
 110) and the calendars for 3 months.

 This causes an html doc being returned frm the server that is 3.5 meg.
 Whilst is takes the server 4 seconds to build and deliver this I was
 wondering if there is any way to speed things up and reduce the amount of
 network traffic.

 Would zipping the file b4 it is sent be a good (and easy) way to go ?

 Thanks in advance,

 Steve Brett
 Internal Development
 EMIS Ltd.
 "Privileged and /or Confidential information may be contained in this
 message. If you are not the original addressee indicated in this message
(or
 responsible for delivery of the message to such person), you may not copy
or
 deliver this message to anyone. In such case, please delete this message,
 and notify us immediately. Opinions, conclusions and other information
 expressed in this message are not given or endorsed by my firm or employer
 unless otherwise indicated by an authorised representative independently
of
 this message."




 --
 PHP Database Mailing List (http://www.php.net/)
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 To contact the list administrators, e-mail: [EMAIL PROTECTED]




-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]