Hello Tobias (and others),
I've got board and decided to check up on this probject. I was looking at the feature request page on the sourceforge project and decided to whip this out as I have just done a similar upgrade on my own web site and have seen enourmous speed increase from the site.
I wouldn't recommend using it if the site is heavily loaded (imagine 50+ gzips running on your websever) but if it is only a single machine and only the admin is accessing this, it should be fine.
It would be nice to know how much gzip increases the load on a heavily loaded server, but I have no such server.
cioa, Jeremy
Hi,
Well I use zlib compression in my PHP forum script, and increase in load is really low. I tested it on a heavily loaded server (Hardware.fr which uses my forum, with more than 200 connections at the same time - PIII-600 / 512 Mo RAM), and there is no problems so far. So I don't think gzip should be a problem.
Jocelyn Presence-PC
----- Original Message ----- From: "jeremy brand" jeremy@nirvani.net To: phpmyadmin-devel@lists.sourceforge.net Sent: Friday, July 20, 2001 8:38 AM Subject: [Phpmyadmin-devel] Gzip HTTP Content-Encoding patch
Hello Tobias (and others),
I've got board and decided to check up on this probject. I was looking at the feature request page on the sourceforge project and decided to whip this out as I have just done a similar upgrade on my own web site and have seen enourmous speed increase from the site.
I wouldn't recommend using it if the site is heavily loaded (imagine 50+ gzips running on your websever) but if it is only a single machine and only the admin is accessing this, it should be fine.
It would be nice to know how much gzip increases the load on a heavily loaded server, but I have no such server.
cioa, Jeremy
-- Jeremy Brand :: Sr. Software Engineer :: +393485323988 ::
jeremy@nirvani.net
http://www.JeremyBrand.com/Jeremy/Brand/Jeremy_Brand.html for more
"LINUX is obsolete" -- Andy Tanenbaum, January 29th, 1992
Get your own Free, Private email at http://www.smackdown.com/
Ok thanks Jeremy,
I am testing your patches.
Marc
jeremy brand a écrit :
Hello Tobias (and others),
I've got board and decided to check up on this probject. I was looking at the feature request page on the sourceforge project and decided to whip this out as I have just done a similar upgrade on my own web site and have seen enourmous speed increase from the site.
When I try to dump a 5 MB table to screen (I know, not very efficient...), with the Content-Encoding patch, it eventually times out with "document contains no data".
This is with NN4. Without the patch, I get the dump on screen.
Apart from this glitch, the patch looks great and is a real speed improvement!
Should I commit it in cvs, with maybe an additional entry in the FAQ about this dump problem?
Marc Delisle a écrit :
Ok thanks Jeremy,
I am testing your patches.
Marc
jeremy brand a écrit :
Hello Tobias (and others),
I've got board and decided to check up on this probject. I was looking at the feature request page on the sourceforge project and decided to whip this out as I have just done a similar upgrade on my own web site and have seen enourmous speed increase from the site.
Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Howdy all,
I wonder if the timeout is (since the gziping takes time -- presumably more time) that maybe we have reached our set_time_limit() (default in php.ini of 30 seconds).
I thought about this when I was writing it, but it didn't seem to be an issue specifically of doing gzip compression. I think this may be a separate issue that this patch has discovered.
Anyone know if set_time_limit() is set anywhere in phpMyAdmin? If so, on big dumps it should be set to set_time_limit(0) [indefinate] because you never know how long it will take to send the data.
Jeremy
There are some set_time_limit() in phpMyAdmin, but I don't think this is my problem, because I get an error after 3 seconds.
Without the patch, I get my dump at the screen in 7 seconds.
Maybe I hit a memory limit in my PHP configuration.
BTW, set_time_limit() does not work when PHP is in safe mode, a user suggests in the PHP manual to do this:
if (! get_cfg_var('safe_mode')) { set_time_limit(180); }
Marc
jeremy brand a écrit :
Howdy all,
I wonder if the timeout is (since the gziping takes time -- presumably more time) that maybe we have reached our set_time_limit() (default in php.ini of 30 seconds).
I thought about this when I was writing it, but it didn't seem to be an issue specifically of doing gzip compression. I think this may be a separate issue that this patch has discovered.
Anyone know if set_time_limit() is set anywhere in phpMyAdmin? If so, on big dumps it should be set to set_time_limit(0) [indefinate] because you never know how long it will take to send the data.
Jeremy
On Fri, 20 Jul 2001, the following spilled from the mind of Marc Delisle:
Date: Fri, 20 Jul 2001 09:41:34 -0400 From: Marc Delisle DelislMa@CollegeSherbrooke.qc.ca Reply-To: phpmyadmin-devel@lists.sourceforge.net To: phpmyadmin-devel@lists.sourceforge.net Subject: Re: [Phpmyadmin-devel] Gzip HTTP Content-Encoding patch
When I try to dump a 5 MB table to screen (I know, not very efficient...), with the Content-Encoding patch, it eventually times out with "document contains no data".
This is with NN4. Without the patch, I get the dump on screen.
Apart from this glitch, the patch looks great and is a real speed improvement!
Should I commit it in cvs, with maybe an additional entry in the FAQ about this dump problem?
Marc Delisle a écrit :
Ok thanks Jeremy,
I am testing your patches.
Marc
jeremy brand a écrit :
Hello Tobias (and others),
I've got board and decided to check up on this probject. I was looking at the feature request page on the sourceforge project and decided to whip this out as I have just done a similar upgrade on my own web site and have seen enourmous speed increase from the site.
Hi
BTW, set_time_limit() does not work when PHP is in safe mode, a user suggests in the PHP manual to do this:
if (! get_cfg_var('safe_mode')) { set_time_limit(180); } <<<<<<<
Just put an @ in front of the set_time_limit function to suppress the warning in then works in safemode, of course if the script is to long it will still timeout though.
@set_time_limit(180);
Pete
----- Original Message ----- From: "Marc Delisle" DelislMa@CollegeSherbrooke.qc.ca To: phpmyadmin-devel@lists.sourceforge.net Sent: Friday, July 20, 2001 5:22 PM Subject: Re: [Phpmyadmin-devel] Gzip HTTP Content-Encoding patch
There are some set_time_limit() in phpMyAdmin, but I don't think this is my problem, because I get an error after 3 seconds.
Without the patch, I get my dump at the screen in 7 seconds.
Maybe I hit a memory limit in my PHP configuration.
BTW, set_time_limit() does not work when PHP is in safe mode, a user suggests in the PHP manual to do this:
if (! get_cfg_var('safe_mode')) { set_time_limit(180); }
Marc
jeremy brand a écrit :
Howdy all,
I wonder if the timeout is (since the gziping takes time -- presumably more time) that maybe we have reached our set_time_limit() (default in php.ini of 30 seconds).
I thought about this when I was writing it, but it didn't seem to be an issue specifically of doing gzip compression. I think this may be a separate issue that this patch has discovered.
Anyone know if set_time_limit() is set anywhere in phpMyAdmin? If so, on big dumps it should be set to set_time_limit(0) [indefinate] because you never know how long it will take to send the data.
Jeremy
On Fri, 20 Jul 2001, the following spilled from the mind of Marc Delisle:
Date: Fri, 20 Jul 2001 09:41:34 -0400 From: Marc Delisle DelislMa@CollegeSherbrooke.qc.ca Reply-To: phpmyadmin-devel@lists.sourceforge.net To: phpmyadmin-devel@lists.sourceforge.net Subject: Re: [Phpmyadmin-devel] Gzip HTTP Content-Encoding patch
When I try to dump a 5 MB table to screen (I know, not very
efficient...), with the Content-Encoding
patch, it eventually times out with "document contains no data".
This is with NN4. Without the patch, I get the dump on screen.
Apart from this glitch, the patch looks great and is a real speed
improvement!
Should I commit it in cvs, with maybe an additional entry in the FAQ
about this dump problem?
Marc Delisle a écrit :
Ok thanks Jeremy,
I am testing your patches.
Marc
jeremy brand a écrit :
Hello Tobias (and others),
I've got board and decided to check up on this probject. I was
looking at
the feature request page on the sourceforge project and decided to
whip
this out as I have just done a similar upgrade on my own web site
and have
seen enourmous speed increase from the site.
_______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Hi all
When I try to dump a 5 MB table to screen (I know, not very efficient...),
with the Content-Encoding patch, it eventually times out with "document contains no data".<<
I use a cache system called jpcache, it is an excellent cache system, I think it is better than pear.
You can check it out at
http://sourceforge.net/projects/jpcache
To use jpcache all you do is add lines to the top of each file. here is an example <? $cachetimeout=-1; include "jpcache.inc" ?>
I have served around 2 million pages from my server using this cache system and never had a single problem.
Pete
----- Original Message ----- From: "Marc Delisle" DelislMa@CollegeSherbrooke.qc.ca To: phpmyadmin-devel@lists.sourceforge.net Sent: Friday, July 20, 2001 2:41 PM Subject: Re: [Phpmyadmin-devel] Gzip HTTP Content-Encoding patch
When I try to dump a 5 MB table to screen (I know, not very efficient...), with the Content-Encoding patch, it eventually times out with "document contains no data".
This is with NN4. Without the patch, I get the dump on screen.
Apart from this glitch, the patch looks great and is a real speed improvement!
Should I commit it in cvs, with maybe an additional entry in the FAQ about this dump problem?
Marc Delisle a écrit :
Ok thanks Jeremy,
I am testing your patches.
Marc
jeremy brand a écrit :
Hello Tobias (and others),
I've got board and decided to check up on this probject. I was looking
at
the feature request page on the sourceforge project and decided to whip this out as I have just done a similar upgrade on my own web site and
have
seen enourmous speed increase from the site.
Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
-- Marc Delisle Service de l'informatique Collège de Sherbrooke, Québec
_______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Does jpcache use ob_gzhandler? If yes, it may be useful to know that:
"Transient SID-mechanism (which adds ?PHPSID=abc to every local url, for people without cookies) does NOT work when you use ob_gzhandler"
webmaster@trafficg.com a écrit :
Hi all
When I try to dump a 5 MB table to screen (I know, not very efficient...),
with the Content-Encoding patch, it eventually times out with "document contains no data".<<
I use a cache system called jpcache, it is an excellent cache system, I think it is better than pear.
You can check it out at
http://sourceforge.net/projects/jpcache
To use jpcache all you do is add lines to the top of each file. here is an example
<? $cachetimeout=-1; include "jpcache.inc" ?>
I have served around 2 million pages from my server using this cache system and never had a single problem.
Pete
----- Original Message ----- From: "Marc Delisle" DelislMa@CollegeSherbrooke.qc.ca To: phpmyadmin-devel@lists.sourceforge.net Sent: Friday, July 20, 2001 2:41 PM Subject: Re: [Phpmyadmin-devel] Gzip HTTP Content-Encoding patch
When I try to dump a 5 MB table to screen (I know, not very efficient...), with the Content-Encoding patch, it eventually times out with "document contains no data".
This is with NN4. Without the patch, I get the dump on screen.
Apart from this glitch, the patch looks great and is a real speed improvement!
Should I commit it in cvs, with maybe an additional entry in the FAQ about this dump problem?
Marc Delisle a écrit :
Ok thanks Jeremy,
I am testing your patches.
Marc
jeremy brand a écrit :
Hello Tobias (and others),
I've got board and decided to check up on this probject. I was looking
at
the feature request page on the sourceforge project and decided to whip this out as I have just done a similar upgrade on my own web site and
have
seen enourmous speed increase from the site.
Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
-- Marc Delisle Service de l'informatique Collège de Sherbrooke, Québec
Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Hi
Does jpcache use ob_gzhandler?<<
It uses ob_start and a call-back function.
Jpcache does not just do content encoding it does a lot more, here is the information from the jpcache homepage http://www.weirdpier.com/jpcache/
jpcache is a lightweight, full page caching system for PHP, thus reducing server-load, as pages are generated less often. It also uses gzip content-encoding and ETag-headers, which results in around 80% in traffic-saving for php-pages. You can choose to store your files in a local dir or in a database
Features: - Caches full php pages for <X> seconds - When not modified since last visit, sends 304 response - When modified or first visit, sends gzipped content if possible, else uncompressed content - You can choose between file or MySQL based storage - Takes GET and POST data into account when caching
Quick usage: * Edit jpcache.inc and change the configurationsettings * Start your file with <? $cachetimeout=<X>; include "jpcache.inc" ?> * Setting <X> to -1 will disable caching and will only do content encoding. Use this for pages that are not cacheable due to user-specific content (polls, personalization etc.)
Pete
----- Original Message ----- From: "Marc Delisle" DelislMa@CollegeSherbrooke.qc.ca To: phpmyadmin-devel@lists.sourceforge.net Sent: Friday, July 20, 2001 5:41 PM Subject: Re: [Phpmyadmin-devel] Gzip HTTP Content-Encoding patch
Does jpcache use ob_gzhandler? If yes, it may be useful to know that:
"Transient SID-mechanism (which adds ?PHPSID=abc to every local url, for people without cookies) does NOT work when you use ob_gzhandler"
webmaster@trafficg.com a écrit :
Hi all
When I try to dump a 5 MB table to screen (I know, not very
efficient...),
with the Content-Encoding patch, it eventually times out with "document contains no data".<<
I use a cache system called jpcache, it is an excellent cache system, I think it is better than pear.
You can check it out at
http://sourceforge.net/projects/jpcache
To use jpcache all you do is add lines to the top of each file. here is an example
<? $cachetimeout=-1; include "jpcache.inc" ?>
I have served around 2 million pages from my server using this cache
system
and never had a single problem.
Pete
----- Original Message ----- From: "Marc Delisle" DelislMa@CollegeSherbrooke.qc.ca To: phpmyadmin-devel@lists.sourceforge.net Sent: Friday, July 20, 2001 2:41 PM Subject: Re: [Phpmyadmin-devel] Gzip HTTP Content-Encoding patch
When I try to dump a 5 MB table to screen (I know, not very efficient...), with the Content-Encoding patch, it eventually times out with "document contains no data".
This is with NN4. Without the patch, I get the dump on screen.
Apart from this glitch, the patch looks great and is a real speed improvement!
Should I commit it in cvs, with maybe an additional entry in the FAQ about this dump problem?
Marc Delisle a écrit :
Ok thanks Jeremy,
I am testing your patches.
Marc
jeremy brand a écrit :
Hello Tobias (and others),
I've got board and decided to check up on this probject. I was
looking
at
the feature request page on the sourceforge project and decided to
whip
this out as I have just done a similar upgrade on my own web site and
have
seen enourmous speed increase from the site.
Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
-- Marc Delisle Service de l'informatique Collège de Sherbrooke, Québec
Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
-- Marc Delisle Service de l'informatique Collège de Sherbrooke, Québec
_______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
Anyway I committed the patch to cvs, please give it a try!
Marc
Marc Delisle a écrit :
When I try to dump a 5 MB table to screen (I know, not very efficient...), with the Content-Encoding patch, it eventually times out with "document contains no data".
This is with NN4. Without the patch, I get the dump on screen.
Apart from this glitch, the patch looks great and is a real speed improvement!
Should I commit it in cvs, with maybe an additional entry in the FAQ about this dump problem?
Oops: Warning: Undefined variable: ob_mode in /usr/local/etc/www/si/php/phpMyAdmin/footer.inc.php3 on line 7
this is triggered when an ALTER TABLE does something wrong, for example setting a default value to a BLOB field.
Marc Delisle a écrit :
Anyway I committed the patch to cvs, please give it a try!
Marc
Howdy :)
I don't know what to do about this that makes sense. This must be occuring if the footer is included, but the header is not. (should this scenerio even be happening?)
I've added a $cfgOBGzip (boolean) to the config file. The header and footer also check to see if this is true or false before doing the check for true or false on the $ob_mode. This should _hopefully_ ellimitate this from happening.
Jeremy
Jeremy Brand :: Sr. Software Engineer :: +393485323988 :: jeremy@nirvani.net http://www.JeremyBrand.com/Jeremy/Brand/Jeremy_Brand.html for more - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - "LINUX is obsolete" -- Andy Tanenbaum, January 29th, 1992 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Get your own Free, Private email at http://www.smackdown.com/
Oops: Warning: Undefined variable: ob_mode in /usr/local/etc/www/si/php/phpMyAdmin/footer.inc.php3 on line 7
this is triggered when an ALTER TABLE does something wrong, for example setting a default value to a BLOB field.
Marc Delisle a �crit :
Anyway I committed the patch to cvs, please give it a try!
Marc
Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
the patch.
Jeremy
Jeremy Brand :: Sr. Software Engineer :: +393485323988 :: jeremy@nirvani.net http://www.JeremyBrand.com/Jeremy/Brand/Jeremy_Brand.html for more - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - "LINUX is obsolete" -- Andy Tanenbaum, January 29th, 1992 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Get your own Free, Private email at http://www.smackdown.com/
On Mon, 23 Jul 2001, the following spilled from the mind of jeremy brand:
Date: Mon, 23 Jul 2001 00:41:17 +0200 (WEDT) From: jeremy brand jeremy@nirvani.net To: phpmyadmin-devel@lists.sourceforge.net Subject: Re: [Phpmyadmin-devel] Gzip HTTP Content-Encoding patch
Howdy :)
I don't know what to do about this that makes sense. This must be occuring if the footer is included, but the header is not. (should this scenerio even be happening?)
I've added a $cfgOBGzip (boolean) to the config file. The header and footer also check to see if this is true or false before doing the check for true or false on the $ob_mode. This should _hopefully_ ellimitate this from happening.
Jeremy
Jeremy Brand :: Sr. Software Engineer :: +393485323988 :: jeremy@nirvani.net http://www.JeremyBrand.com/Jeremy/Brand/Jeremy_Brand.html for more
"LINUX is obsolete" -- Andy Tanenbaum, January 29th, 1992
Get your own Free, Private email at http://www.smackdown.com/
Oops: Warning: Undefined variable: ob_mode in /usr/local/etc/www/si/php/phpMyAdmin/footer.inc.php3 on line 7
this is triggered when an ALTER TABLE does something wrong, for example setting a default value to a BLOB field.
Marc Delisle a �crit :
Anyway I committed the patch to cvs, please give it a try!
Marc
Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
-
Fournier Jocelyn [Presence-PC] -
jeremy brand -
Marc Delisle -
webmaster＠trafficg.com