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:SBrett@e-mis.com] Sent: 14 March 2001 16:57 To: mckaym@illyana.com 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:mckaym@illyana.com] 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:SBrett@e-mis.com] Sent: 14 March 2001 16:19 To: Mark Newnham; php-db@lists.php.net 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:mnewnham@adacorp.com] Sent: 14 March 2001 16:11 To: php-db@lists.php.net 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:SBrett@e-mis.com] > Sent: Wednesday, March 14, 2001 4:02 PM > To: php-db@lists.php.net > 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: php-db-unsubscribe@lists.php.net > For additional commands, e-mail: php-db-help@lists.php.net > To contact the list administrators, e-mail: > php-list-admin@lists.php.net > -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, e-mail: php-db-unsubscribe@lists.php.net For additional commands, e-mail: php-db-help@lists.php.net To contact the list administrators, e-mail: php-list-admin@lists.php.net -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, e-mail: php-db-unsubscribe@lists.php.net For additional commands, e-mail: php-db-help@lists.php.net To contact the list administrators, e-mail: php-list-admin@lists.php.net