Thread: RE: [Phplib-users] How to disable browser caching
Brought to you by:
nhruby,
richardarcher
Menu
▾
▴
phplib-users
|
From: Carl Y. <cyo...@le...> - 2002-03-28 17:02:28
|
I have seen this behavior in IE all the time. And I'm using IE version 6.0. There must be an official way to disable page caching because I've seen a lot of high profile sites, like financial sites, that show this "page has expired" message when clicking the back button. > -----Original Message----- > From: Lars Heuer [mailto:ph...@qu...] > Sent: Thursday, March 28, 2002 9:47 AM > To: php...@li...; Carl Youngblood > Cc: 'php...@li...' > Subject: Re: [Phplib-users] How to disable browser caching > > > Hi, > > > I have been to sites where, when you click on the browser's back > > button, you are given a message that says "this page has > expired" and > > you are thereby > > This is just a Netscape Bug if you send data via POST. > > > but that doesn't seem to do any good. Does anybody know how to > > accomplish this? > > Use NN 4.x :-)) > > Regards, > Lars > > -- > quiXS! | http://www.quixs.com > |
|
From: Layne W. <la...@if...> - 2002-03-28 18:45:15
|
> I have seen this behavior in IE all the time. And I'm using > IE version 6.0. > There must be an official way to disable page caching because > I've seen a > lot of high profile sites, like financial sites, that show > this "page has > expired" message when clicking the back button. Yes, but why would you ever _want_ that to happen on your site? If a visitor sees a stupid browser message while on my site, then I'm not earning my paycheck. Instead, I use the no-cache feature of PHPLib's sessions to rebuild the page. Of course some browsers, like Opera, may cache the pages anyway (and I think Opera is right to keep a true history of pages seen). Any problems caused by actions taken from an obsolete page will be caught by basic data checking. Layne Weathers Ifworld Inc. |
|
From: Carl Y. <cyo...@le...> - 2002-03-28 18:50:04
|
There are cases where the url perhaps indicates a database record that has already been deleted, or some other change in data state has occurred, so it is not possible to recreate the page or else it would be venturing into undefined territory to do so. Rather than worry about all these possiblities it would be easier just to keep them from going back to stale pages. > -----Original Message----- > From: Layne Weathers [mailto:la...@if...] > Sent: Thursday, March 28, 2002 11:48 AM > To: 'Carl Youngblood'; php...@li... > Subject: RE: [Phplib-users] How to disable browser caching > > > > I have seen this behavior in IE all the time. And I'm using IE > > version 6.0. There must be an official way to disable page caching > > because I've seen a > > lot of high profile sites, like financial sites, that show > > this "page has > > expired" message when clicking the back button. > > > Yes, but why would you ever _want_ that to happen on your > site? If a visitor sees a stupid browser message while on my > site, then I'm not earning my paycheck. Instead, I use the > no-cache feature of PHPLib's sessions to rebuild the page. Of > course some browsers, like Opera, may cache the pages anyway > (and I think Opera is right to keep a true history of pages > seen). Any problems caused by actions taken from an obsolete > page will be caught by basic data checking. > > Layne Weathers > Ifworld Inc. > |
|
From: <pis...@al...> - 2002-03-28 19:47:57
|
Hello, I've got a BIG problem, that the development team and I could not resolve. I'm using a RedHat Linux, Apache+PHP4+MySql on a P2/500 with 256 MB RAM. The website I talk about is a portal with many different services (search engine, webmail, news, on-line games, web-directories, ads etc, etc, etc.). Everything is hosted on a single server. The user system is entirely based on PhpLib. The database files used by MySQL are large, with about 60 tables (approx. 500 MB) The things were fine, until the last weeks, when the pageviews number was growing fast (today i had about 100000 pageviews, but it's not very relevant). The MySQL crashes very often, and i need to /etc/rc.d/init.d/mysqld stop-start about 5 times a day. Can anybody tell me, if this server is not strong enough, or it should face the situation ? Thank you for your time Regards ________________________________________________________________________ Singurul serviciu 100% confidential din Romania : http://mail.alabala.ro |
|
From: Paul W. <wol...@sf...> - 2002-03-28 19:59:44
|
Besides getting new hardware, you might consider caching some of your pages. We had a similar problem that was resolved by using something like SpiderCache. /Paul On 3/28/02 11:45 AM, "pis...@al..." <pis...@al...> wrote: > Hello, > > I've got a BIG problem, that the development team and I could not resolve. > > I'm using a RedHat Linux, Apache+PHP4+MySql on a P2/500 with 256 MB RAM. > > The website I talk about is a portal with many different services (search > engine, webmail, news, on-line games, web-directories, ads etc, etc, etc.). > Everything is hosted on a single server. The user system is entirely based on > PhpLib. > > The database files used by MySQL are large, with about 60 tables (approx. 500 > MB) > > The things were fine, until the last weeks, when the pageviews number was > growing fast (today i had about 100000 pageviews, but it's not very relevant). > The MySQL crashes very often, and i need to /etc/rc.d/init.d/mysqld stop-start > about 5 times a day. > > Can anybody tell me, if this server is not strong enough, or it should face > the situation ? > > Thank you for your time > > Regards > > > ________________________________________________________________________ > Singurul serviciu 100% confidential din Romania : http://mail.alabala.ro > > _______________________________________________ > Phplib-users mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phplib-users > -- Paul Wolstenholme Advanced Publishing Research Lab (APuRL) 604.291.5229 http://www.apurl.org/ Simon Fraser University |
|
From: Roberto M. <rm...@cc...> - 2002-03-28 20:13:52
|
On Thu, Mar 28, 2002 at 11:59:33AM -0800, Paul Wolstenholme wrote: <snip> > > > > The database files used by MySQL are large, with about 60 tables (approx. 500 > > MB) > > > > The things were fine, until the last weeks, when the pageviews number was > > growing fast (today i had about 100000 pageviews, but it's not very relevant). > > The MySQL crashes very often, and i need to /etc/rc.d/init.d/mysqld stop-start > > about 5 times a day. > > > > Can anybody tell me, if this server is not strong enough, or it should face > > the situation ? Even if your server was not "strong enough", MySQL should not be crashing. It should be getting slow, or giving you warnings, but not crashing. You should really think about migrating to a real RDBMS. One that withstands ACID requirements. -Roberto -- +----| http://fslc.usu.edu/ USU Free Software & GNU/Linux Club |------+ Roberto Mello - Computer Science, USU - http://www.brasileiro.net/ http://www.sdl.usu.edu/ - Space Dynamics Lab, Developer A poor excuse is better than no excuse! |
|
From: Richard A. <rh...@ju...> - 2002-03-28 21:36:27
|
At 9:45 PM +0200 28/3/02, <pis...@al...> wrote: >I'm using a RedHat Linux, Apache+PHP4+MySql on a P2/500 with 256 MB RAM. More RAM never hurts. Upgrade that machine to the max it can handle (probably only 768 MB). >The MySQL crashes very often, and i need to /etc/rc.d/init.d/mysqld >stop-start about 5 times a day. Sounds like you have a corrupt table there. Are you running the latest MySQL? Did you compile it yourself or install from a package? (hint: you almost always have to compile your MySQL, Apache, PHP and kernel yourself to get the options and optimizations you want) After you stop MySQL, do you run a verification/repair on all the databases? See the manual, section 4.4.6. This should do the trick (assuming all your tables are MyISAM format): myisamchk --silent --force --fast --update-state -O key_buffer=64M -O sort_buffer=64M -O read_buffer=1M -O write_buffer=1M /path/to/datadir/*/*.MYI ...R. |
|
From: nathan r. h. <na...@ds...> - 2002-03-29 14:45:25
|
On Fri, 29 Mar 2002, Richard Archer wrote: > At 9:45 PM +0200 28/3/02, <pis...@al...> wrote: > > >I'm using a RedHat Linux, Apache+PHP4+MySql on a P2/500 with 256 MB RAM. > > More RAM never hurts. Upgrade that machine to the max it can handle > (probably only 768 MB). > Word. This probably won't fix the crashing problem, but it certianly can *never* hurt. This would also help with something I mention below. Faster drives can also make a huge difference, sometimes (depending on usage) more than a faster processor. If you're using plain ol vanialla 33 or even 66 IDE drives, you need to step up to UltraATA 100 or SCSI 160. Even the SCSI-2 machines I have (max sustained rate 10 MB/sec) show better throughput and performance than my ATA 33 drives. (and my SCSI-160 RAID 5 array just pretty much screams :) Again, this is a performance suggestion and probably wouldn't help your crashing problem. > > >The MySQL crashes very often, and i need to /etc/rc.d/init.d/mysqld > >stop-start about 5 times a day. > > Sounds like you have a corrupt table there. > Could very well be. > Are you running the latest MySQL? > > Did you compile it yourself or install from a package? > (hint: you almost always have to compile your MySQL, Apache, PHP > and kernel yourself to get the options and optimizations you want) > Even without custom compiling apache or php, a tweaked kernel can be a world of help. Using one of the newer memory managemebnt patches floating out there would also be good (Ingo's o(2) scheduler, or the AA VM) At a minimum, don't run a SMP kernel if you have a single processor. It would also behoove you to update to 2.4.18 (or 2.4.19-pre1) which has been very stable and wonderful for me. (The -ac series has been looking a bit to rough for production use of late) Also, general system admin stuff... turn off services you don't need, make sure you have updates for everything, looks at top and ps, see what's eating the memory and cpu. Try turinging off pconnect() in phplib, tune your MinSpareServers and MaxSpareServers and other Apache tuning. Got a lot of .htaccess files? Put their directives in httpd.conf and save the extra disk I/O. You also mention this machine serves webmail. If you can, split mail (sendmail / imap / pop) onto another machine and repoint your webmail stuff to it. That should lessen the load a good bit (just make sure the two machines have a fast connection to each other - best if you can put an addtional 100MBs card in each and run a crossover cable twixt the two or buy a very very nice switch - or get the extra cards and a nice hub, yaddah yaddah) If you have the cash, space and brainshare to do it, you could also do some sort of cluster using LVS+mon+heartbeat, redhat's pirannah, or VA's ultraMonkey. Can be cheaper than you think as you don't need screamers behind the load balancers, that's why there are load balancers :) (Of course you could always shell out the bucks for a Cisco or Checkpoint LB.. but where's the fun in that?) > After you stop MySQL, do you run a verification/repair on all the > databases? > > See the manual, section 4.4.6. This should do the trick (assuming > all your tables are MyISAM format): > > myisamchk --silent --force --fast --update-state -O key_buffer=64M > -O sort_buffer=64M -O read_buffer=1M -O write_buffer=1M > /path/to/datadir/*/*.MYI > Yes, do that :) Also, someone mentioned caching, which can really save the day. I dunno what people are using, but I've been turned on to jpcache which is very nice and easy to implement. File and DB based storage, I'd say use the Files method and with all that extra memory you have, set the files cache to live on a ramdisk or shm segment (/dev/shm on 2.4 kernels) Whee.. that's fast. jpcache will also use gzip compression on the output so hopefully it'll not only cut down on the load, but possibly lessen your connection load. as well. http://www.weirdpier.com/jpcache/ To the troll about using a "real database" MySQL can by fully ACID if you want, more specficly, I doubt throwing Oracle at the situation would help matter any in terms of performance and ACIDity has nothing to do with the crashing issues the original poster is having. Before we all jump on the Great DB flamfest again, lets all take a breath and remember "to each their own." This isn't the forum for debating ACIDity issues or what DB rocks more. -n ------ nathan hruby na...@ds... ------ |
|
From: Chris J. <ch...@ch...> - 2002-03-29 17:12:35
|
Yeah, not only is this not the forum for debating ACID tests, but it's not even the forum for MySQL. There exists several good mailing lists for MySQL, and the original poster would get better answers by asking there. This is, after all, the PHPLIB mailing list. That said, after using MySQL on production servers for 3 years (although on FreeBSD, not Linux), I will say this: If MySQL is crashing, you either have a problem with your Linux software or your MySQL software. It is not a lack of power or memory on your system. If you think you have a MySQL bug or problem, be sure you have one of the most recent releases from MySQL (visit www.mysql.com). You should also report the bug to the MySQL people. See the "mysqlbug" command. ..chris ----- Original Message ----- From: "nathan r. hruby" <na...@ds...> Before we all jump on the Great DB flamfest again, lets all take a breath and remember "to each their own." This isn't the forum for debating ACIDity issues or what DB rocks more. -n ------ nathan hruby na...@ds... ------ |
|
From: Layne W. <la...@if...> - 2002-03-28 19:05:45
|
> There are cases where the url perhaps indicates a database > record that has already been deleted, or some other change > in data state has occurred, so it is not possible to > recreate the page or else it would be venturing into > undefined territory to do so. Rather than worry about all > these possiblities it would be easier just to keep them > from going back to stale pages. Easier, but never better. It might be okay if I was showing off pictures of my cat, but we charge for professional-level web apps, so they damn well better be checking every piece of data. I take validation and data integrity _very_ seriously; in some pages, the validation accounts for more than half of the code. Layne Weathers Ifworld Inc. |
|
From: Daniel B. <bo...@io...> - 2002-03-28 19:19:47
|
how do you avoid the browser messages for pages that that were created from form posts? every browser handles form posts and caching a bit differently, so there is no way to guarantee not getting the message. Setting PHPLIB to no-cache will still come up with error messages when going back to pages that were created from form posts (like the phplib login page). -----Original Message----- From: Layne Weathers [mailto:la...@if...] Sent: Thursday, March 28, 2002 10:48 AM To: 'Carl Youngblood'; php...@li... Subject: RE: [Phplib-users] How to disable browser caching > I have seen this behavior in IE all the time. And I'm using > IE version 6.0. > There must be an official way to disable page caching because > I've seen a > lot of high profile sites, like financial sites, that show > this "page has > expired" message when clicking the back button. Yes, but why would you ever _want_ that to happen on your site? If a visitor sees a stupid browser message while on my site, then I'm not earning my paycheck. Instead, I use the no-cache feature of PHPLib's sessions to rebuild the page. Of course some browsers, like Opera, may cache the pages anyway (and I think Opera is right to keep a true history of pages seen). Any problems caused by actions taken from an obsolete page will be caught by basic data checking. Layne Weathers Ifworld Inc. _______________________________________________ Phplib-users mailing list Php...@li... https://lists.sourceforge.net/lists/listinfo/phplib-users |
|
From: Carl Y. <cyo...@le...> - 2002-03-28 19:22:19
|
Point taken, though I think you'd be surprised at how many sites that do a lot more than show pictures of someone's cat don't do this level of error checking, which is probably why all sorts of cross-site scripting security holes are showing up these days. If you are this thorough with your error-checking, good for you. > -----Original Message----- > From: Layne Weathers [mailto:la...@if...] > Sent: Thursday, March 28, 2002 12:09 PM > To: 'Carl Youngblood'; php...@li... > Subject: RE: [Phplib-users] How to disable browser caching > > > > There are cases where the url perhaps indicates a database > record that > > has already been deleted, or some other change in data state has > > occurred, so it is not possible to recreate the page or > else it would > > be venturing into undefined territory to do so. Rather than worry > > about all these possiblities it would be easier just to keep them > > from going back to stale pages. > > > Easier, but never better. It might be okay if I was showing > off pictures of my cat, but we charge for professional-level > web apps, so they damn well better be checking every piece of > data. I take validation and data integrity _very_ seriously; > in some pages, the validation accounts for more than half of the code. > > Layne Weathers > Ifworld Inc. > |
|
From: Layne W. <la...@if...> - 2002-03-28 19:40:30
|
> how do you avoid the browser messages for pages that that were created > from form posts? > > every browser handles form posts and caching a bit > differently, so there > is no way to guarantee not getting the message. Setting PHPLIB to > no-cache will still come up with error messages when going > back to pages > that were created from form posts (like the phplib login page). The short answer - I can't prevent stupid browser behaviour so in this case I don't bother trying. The mainstream modern browsers (and many well-designed older ones, as well) do not have a problem. As was mentioned before, the problems do not exist in every browser. I don't remember the results of my tests anymore, but old Netscape browsers were the primary culprit in this bit of browser programming stupidity. (What flawed logic justified preventing me from viewing source of a post-created page?) Layne Weathers Ifworld Inc. |
Thanks for helping keep SourceForge clean.
X