Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.php > #5827 > unrolled thread
| Started by | Dominique Ottello <air.intakes@fra.fr.invalid> |
|---|---|
| First post | 2012-05-06 11:12 +0200 |
| Last post | 2012-05-08 09:49 +0200 |
| Articles | 20 on this page of 143 — 18 participants |
Back to article view | Back to comp.lang.php
Windows binaries 64bit for PHP Dominique Ottello <air.intakes@fra.fr.invalid> - 2012-05-06 11:12 +0200
Re: Windows binaries 64bit for PHP "J.O. Aho" <user@example.net> - 2012-05-06 11:51 +0200
Re: Windows binaries 64bit for PHP Dominique Ottello <air.intakes@fra.fr.invalid> - 2012-05-06 17:23 +0200
Re: Windows binaries 64bit for PHP Arno Welzel <usenet@arnowelzel.de> - 2012-05-06 18:11 +0200
Re: Windows binaries 64bit for PHP Dominique Ottello <air.intakes@fra.fr.invalid> - 2012-05-06 19:04 +0200
Re: Windows binaries 64bit for PHP Arno Welzel <usenet@arnowelzel.de> - 2012-05-07 20:05 +0200
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-07 20:23 +0100
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-07 17:16 -0400
Re: Windows binaries 64bit for PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2012-05-07 16:49 -0500
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-07 15:01 -0700
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-07 20:15 -0400
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-07 20:37 -0700
Re: Windows binaries 64bit for PHP Arno Welzel <usenet@arnowelzel.de> - 2012-05-08 09:11 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-08 08:21 -0400
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-08 11:17 -0700
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 09:14 -0400
Re: Windows binaries 64bit for PHP Gregor Kofler <usenet@gregorkofler.com> - 2012-05-09 17:05 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 12:21 -0400
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-09 19:36 +0100
Re: Windows binaries 64bit for PHP Gregor Kofler <usenet@gregorkofler.com> - 2012-05-09 21:31 +0200
Re: Windows binaries 64bit for PHP Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-05-12 11:12 +0200
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-12 22:56 +0100
Re: Windows binaries 64bit for PHP Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-05-14 10:51 +0200
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-14 10:17 +0100
Re: Windows binaries 64bit for PHP Gregor Kofler <usenet@gregorkofler.com> - 2012-05-14 19:26 +0200
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-10 00:23 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 23:52 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-10 08:50 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-10 08:01 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-10 21:01 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-10 15:12 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-11 11:56 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 06:50 -0400
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-11 13:57 +0100
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 10:29 -0400
Re: Windows binaries 64bit for PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2012-05-11 13:32 -0500
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-11 20:01 +0100
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-08 22:25 +0200
Re: Windows binaries 64bit for PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2012-05-08 21:29 -0500
Re: Windows binaries 64bit for PHP Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-05-09 09:56 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 09:17 -0400
Re: Windows binaries 64bit for PHP Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-05-09 16:23 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 10:38 -0400
Re: Windows binaries 64bit for PHP Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-05-09 16:54 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 12:23 -0400
Re: Windows binaries 64bit for PHP Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-05-11 13:23 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 07:38 -0400
Re: Windows binaries 64bit for PHP Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-05-11 15:44 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 10:30 -0400
Re: Windows binaries 64bit for PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2012-05-11 13:38 -0500
Re: Windows binaries 64bit for PHP Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-05-14 10:48 +0200
Re: Windows binaries 64bit for PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2012-05-09 11:34 -0500
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-09 11:30 -0700
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 15:52 -0400
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-09 13:46 -0700
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 09:10 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-10 00:19 +0200
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-09 15:28 -0700
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 23:53 -0400
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-10 13:15 -0700
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-10 21:48 +0100
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-10 17:05 -0400
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-10 14:29 -0700
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-10 19:35 -0400
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-10 18:50 -0700
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-10 22:22 -0400
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-11 10:03 -0700
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 13:56 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-11 11:58 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 06:51 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-11 21:11 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 15:29 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-11 21:53 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 18:11 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-12 01:00 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 20:44 -0400
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-12 00:38 +0100
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-12 00:36 +0100
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-11 14:01 +0100
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 10:34 -0400
Re: Windows binaries 64bit for PHP Shake <alex.estevezQUENO@QUENOfilnet.es> - 2012-05-11 20:58 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 15:30 -0400
Re: Windows binaries 64bit for PHP Shake <alex.estevezQUENO@QUENOfilnet.es> - 2012-05-11 21:46 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 18:14 -0400
Re: Windows binaries 64bit for PHP Shake <alex.estevezQUENO@QUENOfilnet.es> - 2012-05-12 14:42 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-12 11:04 -0400
Re: Windows binaries 64bit for PHP Shake <alex.estevezQUENO@QUENOfilnet.es> - 2012-05-12 18:40 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-12 15:49 -0400
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-12 22:59 +0100
Re: Windows binaries 64bit for PHP Shake <alex.estevezQUENO@QUENOfilnet.es> - 2012-05-13 13:46 +0200
Re: Windows binaries 64bit for PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2012-05-13 07:50 -0500
Re: Windows binaries 64bit for PHP Anders Wegge Keller <wegge@wegge.dk> - 2012-05-13 16:15 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-13 10:36 -0400
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-13 09:06 -0400
Re: Windows binaries 64bit for PHP Shake <alex.estevezQUENO@QUENOfilnet.es> - 2012-05-13 18:54 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-13 13:27 -0400
Re: Windows binaries 64bit for PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2012-05-13 22:26 -0500
Re: Windows binaries 64bit for PHP Shake <QUITAESTO@QUITAESTO.NOES> - 2012-05-14 09:51 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-14 08:04 -0400
Re: Windows binaries 64bit for PHP Shake <QUITAESTO@QUITAESTO.NOES> - 2012-05-14 14:25 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-14 09:37 -0400
Re: Windows binaries 64bit for PHP Shake <QUITAESTO@QUITAESTO.NOES> - 2012-05-14 16:22 +0200
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-14 16:45 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-14 14:07 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-14 22:37 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-14 17:47 -0400
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-14 16:53 +0100
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-14 14:06 -0400
Re: Windows binaries 64bit for PHP Shake <alex.estevezQUENO@QUENOfilnet.es> - 2012-05-14 20:36 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-14 14:53 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-14 23:04 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-14 17:48 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-14 23:00 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-14 17:57 -0400
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-12 00:38 +0100
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 20:46 -0400
Re: Windows binaries 64bit for PHP PlastiqueMAN <plastique@man.com> - 2012-05-23 22:45 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-24 00:18 -0400
Re: Windows binaries 64bit for PHP Stig Vestøl <stig@vestoldata.no> - 2012-05-24 11:40 +0200
Re: Windows binaries 64bit for PHP Shake <QUITAESTO@QUITAESTO.NOES> - 2012-05-24 12:00 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-24 09:12 -0400
Re: Windows binaries 64bit for PHP Shake <QUITAESTO@QUITAESTO.NOES> - 2012-05-24 16:29 +0200
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-24 20:41 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-24 15:17 -0400
Re: Windows binaries 64bit for PHP Luuk <luuk@invalid.lan> - 2012-05-11 21:53 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 18:15 -0400
Re: Windows binaries 64bit for PHP Luuk <luuk@invalid.lan> - 2012-05-12 10:00 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-12 07:29 -0400
Re: Windows binaries 64bit for PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2012-05-12 06:47 -0500
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-12 00:40 +0100
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-11 01:07 +0100
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 23:53 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-10 08:49 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-10 08:02 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-10 21:09 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-10 15:32 -0400
Re: Windows binaries 64bit for PHP Dominique Ottello <air.intakes@fra.fr.invalid> - 2012-05-16 17:56 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-16 12:35 -0400
Re: Windows binaries 64bit for PHP Dominique Ottello <air.intakes@fra.fr.invalid> - 2012-05-16 19:35 +0200
Re: Windows binaries 64bit for PHP Gregor Kofler <usenet@gregorkofler.com> - 2012-05-06 18:30 +0200
Re: Windows binaries 64bit for PHP Dominique Ottello <air.intakes@fra.fr.invalid> - 2012-05-06 19:04 +0200
Re: Windows binaries 64bit for PHP "J.O. Aho" <user@example.net> - 2012-05-12 16:45 +0200
Re: Windows binaries 64bit for PHP "Álvaro G. Vicario" <alvaro.NOSPAMTHANX@demogracia.com.invalid> - 2012-05-08 09:49 +0200
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2012-05-10 21:48 +0100 |
| Message-ID | <joh9ij$ffq$9@news.albasani.net> |
| In reply to | #5936 |
Daniel Pitts wrote: > On 5/9/12 8:53 PM, Jerry Stuckle wrote: >> On 5/9/2012 6:28 PM, Daniel Pitts wrote: >>> On 5/9/12 3:19 PM, Michael Fesser wrote: >>>> .oO(Jerry Stuckle) >>>> >>>>> On 5/8/2012 4:25 PM, Michael Fesser wrote: >>>>>> .oO(Jerry Stuckle) >>>>>> >>>>>>> On 5/7/2012 11:37 PM, Daniel Pitts wrote: >>>>>>>> Exactly true, but if you scale to sizes you don't need, you indeed >>>>>>>> use >>>>>>>> more processor time! Our disk space is definitely not the >>>>>>>> bottleneck. >>>>>>> >>>>>>> And if you repeatedly rescale the same image to the same size, >>>>>>> you're >>>>>>> using even more processor time! >>>>>> >>>>>> You missed the word 'caching'. You rescale when needed, and only >>>>>> once. >>>>> >>>>> No, I didn't. By definition, caching is temporary storage which can be >>>>> erased at any time. >>>> >>>> Correct. And then the rescaled images are created again when needed, so >>>> what's the problem? It all happens automatically. >>>> >>>> Micha >>>> >>> >>> Caching needn't be temporary, and you can ensure it isn't "erased at any >>> time" by just not erasing the "cache". There are many different types of >>> "cache". >> >> By definition a cache is temporary. >> > Whose definition? > According to <http://www.thefreedictionary.com/cache> > > 1. "A collection of items of the same type stored in a hidden or > inaccessible place." > 2. Computer Science: A fast storage buffer in the central processing > unit of a computer. Also called cache memory. > > That doesn't define it as temporary. Perhaps you're mistaking your > understanding of the concept with reality. Reality wins over your > understanding. > > Anyway, I've had enough fun arguing with an obvious "expert" in this > field. Enjoy being "right" on the internet. > a cache simply means a store. Usually with the implication its hidden. In CPU terms that means its in RAM which is limited, therefore its temporary. In disk terms its as temporary as you care to make it. IE caches browsing history going back YEARS. > Good day, > Daniel. -- To people who know nothing, anything is possible. To people who know too much, it is a sad fact that they know how little is really possible - and how hard it is to achieve it.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-10 17:05 -0400 |
| Message-ID | <johaj8$c90$1@dont-email.me> |
| In reply to | #5936 |
On 5/10/2012 4:15 PM, Daniel Pitts wrote: > On 5/9/12 8:53 PM, Jerry Stuckle wrote: >> On 5/9/2012 6:28 PM, Daniel Pitts wrote: >>> On 5/9/12 3:19 PM, Michael Fesser wrote: >>>> .oO(Jerry Stuckle) >>>> >>>>> On 5/8/2012 4:25 PM, Michael Fesser wrote: >>>>>> .oO(Jerry Stuckle) >>>>>> >>>>>>> On 5/7/2012 11:37 PM, Daniel Pitts wrote: >>>>>>>> Exactly true, but if you scale to sizes you don't need, you indeed >>>>>>>> use >>>>>>>> more processor time! Our disk space is definitely not the >>>>>>>> bottleneck. >>>>>>> >>>>>>> And if you repeatedly rescale the same image to the same size, >>>>>>> you're >>>>>>> using even more processor time! >>>>>> >>>>>> You missed the word 'caching'. You rescale when needed, and only >>>>>> once. >>>>> >>>>> No, I didn't. By definition, caching is temporary storage which can be >>>>> erased at any time. >>>> >>>> Correct. And then the rescaled images are created again when needed, so >>>> what's the problem? It all happens automatically. >>>> >>>> Micha >>>> >>> >>> Caching needn't be temporary, and you can ensure it isn't "erased at any >>> time" by just not erasing the "cache". There are many different types of >>> "cache". >> >> By definition a cache is temporary. >> > Whose definition? > According to <http://www.thefreedictionary.com/cache> > > 1. "A collection of items of the same type stored in a hidden or > inaccessible place." > 2. Computer Science: A fast storage buffer in the central processing > unit of a computer. Also called cache memory. > > That doesn't define it as temporary. Perhaps you're mistaking your > understanding of the concept with reality. Reality wins over your > understanding. > > Anyway, I've had enough fun arguing with an obvious "expert" in this > field. Enjoy being "right" on the internet. > > Good day, > Daniel. And you obviously don't understand what you're reading. Since when is "memory" permanent? I thought that's why we had hard drives. And I don't see any thing in your definition about hard drives. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Daniel Pitts <newsgroup.nospam@virtualinfinity.net> |
|---|---|
| Date | 2012-05-10 14:29 -0700 |
| Message-ID | <0rWqr.8806$br3.2203@newsfe10.iad> |
| In reply to | #5939 |
On 5/10/12 2:05 PM, Jerry Stuckle wrote: > On 5/10/2012 4:15 PM, Daniel Pitts wrote: >> On 5/9/12 8:53 PM, Jerry Stuckle wrote: >>> On 5/9/2012 6:28 PM, Daniel Pitts wrote: >>>> On 5/9/12 3:19 PM, Michael Fesser wrote: >>>>> .oO(Jerry Stuckle) >>>>> >>>>>> On 5/8/2012 4:25 PM, Michael Fesser wrote: >>>>>>> .oO(Jerry Stuckle) >>>>>>> >>>>>>>> On 5/7/2012 11:37 PM, Daniel Pitts wrote: >>>>>>>>> Exactly true, but if you scale to sizes you don't need, you indeed >>>>>>>>> use >>>>>>>>> more processor time! Our disk space is definitely not the >>>>>>>>> bottleneck. >>>>>>>> >>>>>>>> And if you repeatedly rescale the same image to the same size, >>>>>>>> you're >>>>>>>> using even more processor time! >>>>>>> >>>>>>> You missed the word 'caching'. You rescale when needed, and only >>>>>>> once. >>>>>> >>>>>> No, I didn't. By definition, caching is temporary storage which >>>>>> can be >>>>>> erased at any time. >>>>> >>>>> Correct. And then the rescaled images are created again when >>>>> needed, so >>>>> what's the problem? It all happens automatically. >>>>> >>>>> Micha >>>>> >>>> >>>> Caching needn't be temporary, and you can ensure it isn't "erased at >>>> any >>>> time" by just not erasing the "cache". There are many different >>>> types of >>>> "cache". >>> >>> By definition a cache is temporary. >>> >> Whose definition? >> According to <http://www.thefreedictionary.com/cache> >> >> 1. "A collection of items of the same type stored in a hidden or >> inaccessible place." >> 2. Computer Science: A fast storage buffer in the central processing >> unit of a computer. Also called cache memory. >> >> That doesn't define it as temporary. Perhaps you're mistaking your >> understanding of the concept with reality. Reality wins over your >> understanding. >> >> Anyway, I've had enough fun arguing with an obvious "expert" in this >> field. Enjoy being "right" on the internet. >> >> Good day, >> Daniel. > > And you obviously don't understand what you're reading. > > Since when is "memory" permanent? I thought that's why we had hard > drives. And I don't see any thing in your definition about hard drives. > So, lets take a step back here. Forget the word caching, and your misunderstanding of it altogether. A system which will resize an image on-demand, and store the resize image for later retrieval is more efficient than one that will create all known previous sizes and then reprocessing all old images as new requirements are introduced.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-10 19:35 -0400 |
| Message-ID | <johjbr$2qm$1@dont-email.me> |
| In reply to | #5941 |
On 5/10/2012 5:29 PM, Daniel Pitts wrote: > On 5/10/12 2:05 PM, Jerry Stuckle wrote: >> On 5/10/2012 4:15 PM, Daniel Pitts wrote: >>> On 5/9/12 8:53 PM, Jerry Stuckle wrote: >>>> On 5/9/2012 6:28 PM, Daniel Pitts wrote: >>>>> On 5/9/12 3:19 PM, Michael Fesser wrote: >>>>>> .oO(Jerry Stuckle) >>>>>> >>>>>>> On 5/8/2012 4:25 PM, Michael Fesser wrote: >>>>>>>> .oO(Jerry Stuckle) >>>>>>>> >>>>>>>>> On 5/7/2012 11:37 PM, Daniel Pitts wrote: >>>>>>>>>> Exactly true, but if you scale to sizes you don't need, you >>>>>>>>>> indeed >>>>>>>>>> use >>>>>>>>>> more processor time! Our disk space is definitely not the >>>>>>>>>> bottleneck. >>>>>>>>> >>>>>>>>> And if you repeatedly rescale the same image to the same size, >>>>>>>>> you're >>>>>>>>> using even more processor time! >>>>>>>> >>>>>>>> You missed the word 'caching'. You rescale when needed, and only >>>>>>>> once. >>>>>>> >>>>>>> No, I didn't. By definition, caching is temporary storage which >>>>>>> can be >>>>>>> erased at any time. >>>>>> >>>>>> Correct. And then the rescaled images are created again when >>>>>> needed, so >>>>>> what's the problem? It all happens automatically. >>>>>> >>>>>> Micha >>>>>> >>>>> >>>>> Caching needn't be temporary, and you can ensure it isn't "erased at >>>>> any >>>>> time" by just not erasing the "cache". There are many different >>>>> types of >>>>> "cache". >>>> >>>> By definition a cache is temporary. >>>> >>> Whose definition? >>> According to <http://www.thefreedictionary.com/cache> >>> >>> 1. "A collection of items of the same type stored in a hidden or >>> inaccessible place." >>> 2. Computer Science: A fast storage buffer in the central processing >>> unit of a computer. Also called cache memory. >>> >>> That doesn't define it as temporary. Perhaps you're mistaking your >>> understanding of the concept with reality. Reality wins over your >>> understanding. >>> >>> Anyway, I've had enough fun arguing with an obvious "expert" in this >>> field. Enjoy being "right" on the internet. >>> >>> Good day, >>> Daniel. >> >> And you obviously don't understand what you're reading. >> >> Since when is "memory" permanent? I thought that's why we had hard >> drives. And I don't see any thing in your definition about hard drives. >> > So, lets take a step back here. > > Forget the word caching, and your misunderstanding of it altogether. > > A system which will resize an image on-demand, and store the resize > image for later retrieval is more efficient than one that will create > all known previous sizes and then reprocessing all old images as new > requirements are introduced. > > I do not misunderstand caching. Just because YOU have no idea what you're talking about doesn't mean anyone else doesn't. And a system which creates all the images once so it doesn't have to keep needlessly checking to see if an image exists or not is more efficient than one which constantly has to see if something exists or not. Resizing is done ONCE. Checking has to be done on EVERY REQUEST. But then you're got your mind made up. After all, it would take "months" for you to resize your images. A good system can resize several hundred images a second. At most we're taking a few hours to do 7.5M images, even if they are high-res. But your TRS-80's may only be able to do one a second. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Daniel Pitts <newsgroup.nospam@virtualinfinity.net> |
|---|---|
| Date | 2012-05-10 18:50 -0700 |
| Message-ID | <wf_qr.11303$8L6.4806@newsfe07.iad> |
| In reply to | #5944 |
On 5/10/12 4:35 PM, Jerry Stuckle wrote: > On 5/10/2012 5:29 PM, Daniel Pitts wrote: >> On 5/10/12 2:05 PM, Jerry Stuckle wrote: >>> On 5/10/2012 4:15 PM, Daniel Pitts wrote: >>>> On 5/9/12 8:53 PM, Jerry Stuckle wrote: >>>>> On 5/9/2012 6:28 PM, Daniel Pitts wrote: >>>>>> On 5/9/12 3:19 PM, Michael Fesser wrote: >>>>>>> .oO(Jerry Stuckle) >>>>>>> >>>>>>>> On 5/8/2012 4:25 PM, Michael Fesser wrote: >>>>>>>>> .oO(Jerry Stuckle) >>>>>>>>> >>>>>>>>>> On 5/7/2012 11:37 PM, Daniel Pitts wrote: >>>>>>>>>>> Exactly true, but if you scale to sizes you don't need, you >>>>>>>>>>> indeed >>>>>>>>>>> use >>>>>>>>>>> more processor time! Our disk space is definitely not the >>>>>>>>>>> bottleneck. >>>>>>>>>> >>>>>>>>>> And if you repeatedly rescale the same image to the same size, >>>>>>>>>> you're >>>>>>>>>> using even more processor time! >>>>>>>>> >>>>>>>>> You missed the word 'caching'. You rescale when needed, and only >>>>>>>>> once. >>>>>>>> >>>>>>>> No, I didn't. By definition, caching is temporary storage which >>>>>>>> can be >>>>>>>> erased at any time. >>>>>>> >>>>>>> Correct. And then the rescaled images are created again when >>>>>>> needed, so >>>>>>> what's the problem? It all happens automatically. >>>>>>> >>>>>>> Micha >>>>>>> >>>>>> >>>>>> Caching needn't be temporary, and you can ensure it isn't "erased at >>>>>> any >>>>>> time" by just not erasing the "cache". There are many different >>>>>> types of >>>>>> "cache". >>>>> >>>>> By definition a cache is temporary. >>>>> >>>> Whose definition? >>>> According to <http://www.thefreedictionary.com/cache> >>>> >>>> 1. "A collection of items of the same type stored in a hidden or >>>> inaccessible place." >>>> 2. Computer Science: A fast storage buffer in the central processing >>>> unit of a computer. Also called cache memory. >>>> >>>> That doesn't define it as temporary. Perhaps you're mistaking your >>>> understanding of the concept with reality. Reality wins over your >>>> understanding. >>>> >>>> Anyway, I've had enough fun arguing with an obvious "expert" in this >>>> field. Enjoy being "right" on the internet. >>>> >>>> Good day, >>>> Daniel. >>> >>> And you obviously don't understand what you're reading. >>> >>> Since when is "memory" permanent? I thought that's why we had hard >>> drives. And I don't see any thing in your definition about hard drives. >>> >> So, lets take a step back here. >> >> Forget the word caching, and your misunderstanding of it altogether. >> >> A system which will resize an image on-demand, and store the resize >> image for later retrieval is more efficient than one that will create >> all known previous sizes and then reprocessing all old images as new >> requirements are introduced. >> >> > > I do not misunderstand caching. Just because YOU have no idea what > you're talking about doesn't mean anyone else doesn't. I have some idea, as I actually work on such a system. You seem to have little real-world experience, as you seem to think that one solution suits all. > > And a system which creates all the images once so it doesn't have to > keep needlessly checking to see if an image exists or not is more > efficient than one which constantly has to see if something exists or not. Whatever is serving your static content must check if it exists or not. You can hook into the "or-not" case, which happens only once per image per size that is *actually* used. > > Resizing is done ONCE. Checking has to be done on EVERY REQUEST. Checking has to be done on every request regardless. This is not an extra step. > But then you're got your mind made up. After all, it would take "months" > for you to resize your images. Months may have been a slight exaggeration, but it does take more than a few days to resize every possible image. > A good system can resize several hundred images a second. At most we're > taking a few hours to do 7.5M images, even if they are high-res. But > your TRS-80's may only be able to do one a second. It is still easier to set up this lazy-loading once, than to have to run a "few hours" of scripts every time requirements change. The site will perform well enough (storing the resized images permanently, plus having edge cache in front of them). Why waste an engineers time running such a script (which is more expensive than CPU time needed to handle the lazy resizing). The actual hardware in question is a "Compaq DL385 G6" CPU: 12 x 2200 MHz Six-Core AMD Opteron 2427, 512 KB cache Memory: 64461MB Granted, this machine is shared with many other tools.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-10 22:22 -0400 |
| Message-ID | <joht5u$f9a$1@dont-email.me> |
| In reply to | #5947 |
On 5/10/2012 9:50 PM, Daniel Pitts wrote: > On 5/10/12 4:35 PM, Jerry Stuckle wrote: >> On 5/10/2012 5:29 PM, Daniel Pitts wrote: >>> On 5/10/12 2:05 PM, Jerry Stuckle wrote: >>>> On 5/10/2012 4:15 PM, Daniel Pitts wrote: >>>>> On 5/9/12 8:53 PM, Jerry Stuckle wrote: >>>>>> On 5/9/2012 6:28 PM, Daniel Pitts wrote: >>>>>>> On 5/9/12 3:19 PM, Michael Fesser wrote: >>>>>>>> .oO(Jerry Stuckle) >>>>>>>> >>>>>>>>> On 5/8/2012 4:25 PM, Michael Fesser wrote: >>>>>>>>>> .oO(Jerry Stuckle) >>>>>>>>>> >>>>>>>>>>> On 5/7/2012 11:37 PM, Daniel Pitts wrote: >>>>>>>>>>>> Exactly true, but if you scale to sizes you don't need, you >>>>>>>>>>>> indeed >>>>>>>>>>>> use >>>>>>>>>>>> more processor time! Our disk space is definitely not the >>>>>>>>>>>> bottleneck. >>>>>>>>>>> >>>>>>>>>>> And if you repeatedly rescale the same image to the same size, >>>>>>>>>>> you're >>>>>>>>>>> using even more processor time! >>>>>>>>>> >>>>>>>>>> You missed the word 'caching'. You rescale when needed, and only >>>>>>>>>> once. >>>>>>>>> >>>>>>>>> No, I didn't. By definition, caching is temporary storage which >>>>>>>>> can be >>>>>>>>> erased at any time. >>>>>>>> >>>>>>>> Correct. And then the rescaled images are created again when >>>>>>>> needed, so >>>>>>>> what's the problem? It all happens automatically. >>>>>>>> >>>>>>>> Micha >>>>>>>> >>>>>>> >>>>>>> Caching needn't be temporary, and you can ensure it isn't "erased at >>>>>>> any >>>>>>> time" by just not erasing the "cache". There are many different >>>>>>> types of >>>>>>> "cache". >>>>>> >>>>>> By definition a cache is temporary. >>>>>> >>>>> Whose definition? >>>>> According to <http://www.thefreedictionary.com/cache> >>>>> >>>>> 1. "A collection of items of the same type stored in a hidden or >>>>> inaccessible place." >>>>> 2. Computer Science: A fast storage buffer in the central processing >>>>> unit of a computer. Also called cache memory. >>>>> >>>>> That doesn't define it as temporary. Perhaps you're mistaking your >>>>> understanding of the concept with reality. Reality wins over your >>>>> understanding. >>>>> >>>>> Anyway, I've had enough fun arguing with an obvious "expert" in this >>>>> field. Enjoy being "right" on the internet. >>>>> >>>>> Good day, >>>>> Daniel. >>>> >>>> And you obviously don't understand what you're reading. >>>> >>>> Since when is "memory" permanent? I thought that's why we had hard >>>> drives. And I don't see any thing in your definition about hard drives. >>>> >>> So, lets take a step back here. >>> >>> Forget the word caching, and your misunderstanding of it altogether. >>> >>> A system which will resize an image on-demand, and store the resize >>> image for later retrieval is more efficient than one that will create >>> all known previous sizes and then reprocessing all old images as new >>> requirements are introduced. >>> >>> >> >> I do not misunderstand caching. Just because YOU have no idea what >> you're talking about doesn't mean anyone else doesn't. > I have some idea, as I actually work on such a system. You seem to have > little real-world experience, as you seem to think that one solution > suits all I have over 40 years of "real world experience", including 13 with IBM and 22 as a consultant. I suspect I was programming before you were born. >> >> And a system which creates all the images once so it doesn't have to >> keep needlessly checking to see if an image exists or not is more >> efficient than one which constantly has to see if something exists or >> not. > Whatever is serving your static content must check if it exists or not. > You can hook into the "or-not" case, which happens only once per image > per size that is *actually* used. It's a simple file load from Apache. No additional application programming required. And, being a compiled program, it's quite fast. With your way, Apache has to load a PHP script (same process as I just referenced). But then it has to start call the PHP module to establish the PHP environment, interpret the script, execute the script, which then has to check to see if the file exists or not. Much more processing than above, and it has to be done on every request. Or, let Apache try to load the file. If the load fails, call the 404 error handler (more overhead) which then has to go through all the processing to load an execute a PHP file (as noted above) then resizing the image. Either way there is significantly more overhead than resizing once and forgetting it. But you don't seem to understand that. >> >> Resizing is done ONCE. Checking has to be done on EVERY REQUEST. > Checking has to be done on every request regardless. This is not an > extra step. > See above. If the file exists, Apache can handle it directly. >> But then you're got your mind made up. After all, it would take "months" >> for you to resize your images. > Months may have been a slight exaggeration, but it does take more than a > few days to resize every possible image. > Even days is an exaggeration if you get rid of your TRS-80. You obviously have NO IDEA how long anything would take. You're just guessing (again). >> A good system can resize several hundred images a second. At most we're >> taking a few hours to do 7.5M images, even if they are high-res. But >> your TRS-80's may only be able to do one a second. > It is still easier to set up this lazy-loading once, than to have to run > a "few hours" of scripts every time requirements change. The site will > perform well enough (storing the resized images permanently, plus having > edge cache in front of them). Why waste an engineers time running such a > script (which is more expensive than CPU time needed to handle the lazy > resizing). > You've got it. It's easier to set up the lazy-loading. It takes actual skill to be able to write a script which will resize all the images for you. > The actual hardware in question is a "Compaq DL385 G6" > > CPU: 12 x 2200 MHz Six-Core AMD Opteron 2427, 512 KB cache > Memory: 64461MB > > Granted, this machine is shared with many other tools. > If that actually were your system, then it should take nowhere near 12 days to process 7.5M images. But you don't know - you're still guessing because you don't have the skills to figure out how to resize the images from a script. But we know all you've got is your trusty TRS-80. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Daniel Pitts <newsgroup.nospam@virtualinfinity.net> |
|---|---|
| Date | 2012-05-11 10:03 -0700 |
| Message-ID | <%Dbrr.7541$ax3.697@newsfe05.iad> |
| In reply to | #5948 |
On 5/10/12 7:22 PM, Jerry Stuckle wrote: > On 5/10/2012 9:50 PM, Daniel Pitts wrote: >> On 5/10/12 4:35 PM, Jerry Stuckle wrote: >>> On 5/10/2012 5:29 PM, Daniel Pitts wrote: >>>> On 5/10/12 2:05 PM, Jerry Stuckle wrote: >>>>> On 5/10/2012 4:15 PM, Daniel Pitts wrote: >>>>>> On 5/9/12 8:53 PM, Jerry Stuckle wrote: >>>>>>> On 5/9/2012 6:28 PM, Daniel Pitts wrote: >>>>>>>> On 5/9/12 3:19 PM, Michael Fesser wrote: >>>>>>>>> .oO(Jerry Stuckle) >>>>>>>>> >>>>>>>>>> On 5/8/2012 4:25 PM, Michael Fesser wrote: >>>>>>>>>>> .oO(Jerry Stuckle) >>>>>>>>>>> >>>>>>>>>>>> On 5/7/2012 11:37 PM, Daniel Pitts wrote: >>>>>>>>>>>>> Exactly true, but if you scale to sizes you don't need, you >>>>>>>>>>>>> indeed >>>>>>>>>>>>> use >>>>>>>>>>>>> more processor time! Our disk space is definitely not the >>>>>>>>>>>>> bottleneck. >>>>>>>>>>>> >>>>>>>>>>>> And if you repeatedly rescale the same image to the same size, >>>>>>>>>>>> you're >>>>>>>>>>>> using even more processor time! >>>>>>>>>>> >>>>>>>>>>> You missed the word 'caching'. You rescale when needed, and only >>>>>>>>>>> once. >>>>>>>>>> >>>>>>>>>> No, I didn't. By definition, caching is temporary storage which >>>>>>>>>> can be >>>>>>>>>> erased at any time. >>>>>>>>> >>>>>>>>> Correct. And then the rescaled images are created again when >>>>>>>>> needed, so >>>>>>>>> what's the problem? It all happens automatically. >>>>>>>>> >>>>>>>>> Micha >>>>>>>>> >>>>>>>> >>>>>>>> Caching needn't be temporary, and you can ensure it isn't >>>>>>>> "erased at >>>>>>>> any >>>>>>>> time" by just not erasing the "cache". There are many different >>>>>>>> types of >>>>>>>> "cache". >>>>>>> >>>>>>> By definition a cache is temporary. >>>>>>> >>>>>> Whose definition? >>>>>> According to <http://www.thefreedictionary.com/cache> >>>>>> >>>>>> 1. "A collection of items of the same type stored in a hidden or >>>>>> inaccessible place." >>>>>> 2. Computer Science: A fast storage buffer in the central processing >>>>>> unit of a computer. Also called cache memory. >>>>>> >>>>>> That doesn't define it as temporary. Perhaps you're mistaking your >>>>>> understanding of the concept with reality. Reality wins over your >>>>>> understanding. >>>>>> >>>>>> Anyway, I've had enough fun arguing with an obvious "expert" in this >>>>>> field. Enjoy being "right" on the internet. >>>>>> >>>>>> Good day, >>>>>> Daniel. >>>>> >>>>> And you obviously don't understand what you're reading. >>>>> >>>>> Since when is "memory" permanent? I thought that's why we had hard >>>>> drives. And I don't see any thing in your definition about hard >>>>> drives. >>>>> >>>> So, lets take a step back here. >>>> >>>> Forget the word caching, and your misunderstanding of it altogether. >>>> >>>> A system which will resize an image on-demand, and store the resize >>>> image for later retrieval is more efficient than one that will create >>>> all known previous sizes and then reprocessing all old images as new >>>> requirements are introduced. >>>> >>>> >>> >>> I do not misunderstand caching. Just because YOU have no idea what >>> you're talking about doesn't mean anyone else doesn't. >> I have some idea, as I actually work on such a system. You seem to have >> little real-world experience, as you seem to think that one solution >> suits all > > I have over 40 years of "real world experience", including 13 with IBM > and 22 as a consultant. I suspect I was programming before you were born. > >>> >>> And a system which creates all the images once so it doesn't have to >>> keep needlessly checking to see if an image exists or not is more >>> efficient than one which constantly has to see if something exists or >>> not. >> Whatever is serving your static content must check if it exists or not. >> You can hook into the "or-not" case, which happens only once per image >> per size that is *actually* used. > > It's a simple file load from Apache. No additional application > programming required. And, being a compiled program, it's quite fast. > > With your way, Apache has to load a PHP script (same process as I just > referenced). But then it has to start call the PHP module to establish > the PHP environment, interpret the script, execute the script, which > then has to check to see if the file exists or not. Much more processing > than above, and it has to be done on every request. > > Or, let Apache try to load the file. If the load fails, call the 404 > error handler (more overhead) which then has to go through all the > processing to load an execute a PHP file (as noted above) then resizing > the image. > > Either way there is significantly more overhead than resizing once and > forgetting it. But you don't seem to understand that. > >>> >>> Resizing is done ONCE. Checking has to be done on EVERY REQUEST. >> Checking has to be done on every request regardless. This is not an >> extra step. >> > > See above. If the file exists, Apache can handle it directly. > >>> But then you're got your mind made up. After all, it would take "months" >>> for you to resize your images. >> Months may have been a slight exaggeration, but it does take more than a >> few days to resize every possible image. >> > > Even days is an exaggeration if you get rid of your TRS-80. You > obviously have NO IDEA how long anything would take. You're just > guessing (again). > >>> A good system can resize several hundred images a second. At most we're >>> taking a few hours to do 7.5M images, even if they are high-res. But >>> your TRS-80's may only be able to do one a second. >> It is still easier to set up this lazy-loading once, than to have to run >> a "few hours" of scripts every time requirements change. The site will >> perform well enough (storing the resized images permanently, plus having >> edge cache in front of them). Why waste an engineers time running such a >> script (which is more expensive than CPU time needed to handle the lazy >> resizing). >> > > You've got it. It's easier to set up the lazy-loading. It takes actual > skill to be able to write a script which will resize all the images for > you. Ad hominem attacks huh? You have no idea of my skill level, and have yet to prove yours. I did a little digging into the history of this newsgroup. I didn't realize you were the resident troll, and was trying to use reason with you. It's been fun sparing with you, but you have proven to me that you have no interest in facts and reason. *plonk*
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-11 13:56 -0400 |
| Message-ID | <jojjt3$kjn$1@dont-email.me> |
| In reply to | #5968 |
On 5/11/2012 1:03 PM, Daniel Pitts wrote: > On 5/10/12 7:22 PM, Jerry Stuckle wrote: >> On 5/10/2012 9:50 PM, Daniel Pitts wrote: >>> On 5/10/12 4:35 PM, Jerry Stuckle wrote: >>>> On 5/10/2012 5:29 PM, Daniel Pitts wrote: >>>>> On 5/10/12 2:05 PM, Jerry Stuckle wrote: >>>>>> On 5/10/2012 4:15 PM, Daniel Pitts wrote: >>>>>>> On 5/9/12 8:53 PM, Jerry Stuckle wrote: >>>>>>>> On 5/9/2012 6:28 PM, Daniel Pitts wrote: >>>>>>>>> On 5/9/12 3:19 PM, Michael Fesser wrote: >>>>>>>>>> .oO(Jerry Stuckle) >>>>>>>>>> >>>>>>>>>>> On 5/8/2012 4:25 PM, Michael Fesser wrote: >>>>>>>>>>>> .oO(Jerry Stuckle) >>>>>>>>>>>> >>>>>>>>>>>>> On 5/7/2012 11:37 PM, Daniel Pitts wrote: >>>>>>>>>>>>>> Exactly true, but if you scale to sizes you don't need, you >>>>>>>>>>>>>> indeed >>>>>>>>>>>>>> use >>>>>>>>>>>>>> more processor time! Our disk space is definitely not the >>>>>>>>>>>>>> bottleneck. >>>>>>>>>>>>> >>>>>>>>>>>>> And if you repeatedly rescale the same image to the same size, >>>>>>>>>>>>> you're >>>>>>>>>>>>> using even more processor time! >>>>>>>>>>>> >>>>>>>>>>>> You missed the word 'caching'. You rescale when needed, and >>>>>>>>>>>> only >>>>>>>>>>>> once. >>>>>>>>>>> >>>>>>>>>>> No, I didn't. By definition, caching is temporary storage which >>>>>>>>>>> can be >>>>>>>>>>> erased at any time. >>>>>>>>>> >>>>>>>>>> Correct. And then the rescaled images are created again when >>>>>>>>>> needed, so >>>>>>>>>> what's the problem? It all happens automatically. >>>>>>>>>> >>>>>>>>>> Micha >>>>>>>>>> >>>>>>>>> >>>>>>>>> Caching needn't be temporary, and you can ensure it isn't >>>>>>>>> "erased at >>>>>>>>> any >>>>>>>>> time" by just not erasing the "cache". There are many different >>>>>>>>> types of >>>>>>>>> "cache". >>>>>>>> >>>>>>>> By definition a cache is temporary. >>>>>>>> >>>>>>> Whose definition? >>>>>>> According to <http://www.thefreedictionary.com/cache> >>>>>>> >>>>>>> 1. "A collection of items of the same type stored in a hidden or >>>>>>> inaccessible place." >>>>>>> 2. Computer Science: A fast storage buffer in the central processing >>>>>>> unit of a computer. Also called cache memory. >>>>>>> >>>>>>> That doesn't define it as temporary. Perhaps you're mistaking your >>>>>>> understanding of the concept with reality. Reality wins over your >>>>>>> understanding. >>>>>>> >>>>>>> Anyway, I've had enough fun arguing with an obvious "expert" in this >>>>>>> field. Enjoy being "right" on the internet. >>>>>>> >>>>>>> Good day, >>>>>>> Daniel. >>>>>> >>>>>> And you obviously don't understand what you're reading. >>>>>> >>>>>> Since when is "memory" permanent? I thought that's why we had hard >>>>>> drives. And I don't see any thing in your definition about hard >>>>>> drives. >>>>>> >>>>> So, lets take a step back here. >>>>> >>>>> Forget the word caching, and your misunderstanding of it altogether. >>>>> >>>>> A system which will resize an image on-demand, and store the resize >>>>> image for later retrieval is more efficient than one that will create >>>>> all known previous sizes and then reprocessing all old images as new >>>>> requirements are introduced. >>>>> >>>>> >>>> >>>> I do not misunderstand caching. Just because YOU have no idea what >>>> you're talking about doesn't mean anyone else doesn't. >>> I have some idea, as I actually work on such a system. You seem to have >>> little real-world experience, as you seem to think that one solution >>> suits all >> >> I have over 40 years of "real world experience", including 13 with IBM >> and 22 as a consultant. I suspect I was programming before you were born. >> >>>> >>>> And a system which creates all the images once so it doesn't have to >>>> keep needlessly checking to see if an image exists or not is more >>>> efficient than one which constantly has to see if something exists or >>>> not. >>> Whatever is serving your static content must check if it exists or not. >>> You can hook into the "or-not" case, which happens only once per image >>> per size that is *actually* used. >> >> It's a simple file load from Apache. No additional application >> programming required. And, being a compiled program, it's quite fast. >> >> With your way, Apache has to load a PHP script (same process as I just >> referenced). But then it has to start call the PHP module to establish >> the PHP environment, interpret the script, execute the script, which >> then has to check to see if the file exists or not. Much more processing >> than above, and it has to be done on every request. >> >> Or, let Apache try to load the file. If the load fails, call the 404 >> error handler (more overhead) which then has to go through all the >> processing to load an execute a PHP file (as noted above) then resizing >> the image. >> >> Either way there is significantly more overhead than resizing once and >> forgetting it. But you don't seem to understand that. >> >>>> >>>> Resizing is done ONCE. Checking has to be done on EVERY REQUEST. >>> Checking has to be done on every request regardless. This is not an >>> extra step. >>> >> >> See above. If the file exists, Apache can handle it directly. >> >>>> But then you're got your mind made up. After all, it would take >>>> "months" >>>> for you to resize your images. >>> Months may have been a slight exaggeration, but it does take more than a >>> few days to resize every possible image. >>> >> >> Even days is an exaggeration if you get rid of your TRS-80. You >> obviously have NO IDEA how long anything would take. You're just >> guessing (again). >> >>>> A good system can resize several hundred images a second. At most we're >>>> taking a few hours to do 7.5M images, even if they are high-res. But >>>> your TRS-80's may only be able to do one a second. >>> It is still easier to set up this lazy-loading once, than to have to run >>> a "few hours" of scripts every time requirements change. The site will >>> perform well enough (storing the resized images permanently, plus having >>> edge cache in front of them). Why waste an engineers time running such a >>> script (which is more expensive than CPU time needed to handle the lazy >>> resizing). >>> >> >> You've got it. It's easier to set up the lazy-loading. It takes actual >> skill to be able to write a script which will resize all the images for >> you. > Ad hominem attacks huh? You have no idea of my skill level, and have yet > to prove yours. > > I did a little digging into the history of this newsgroup. I didn't > realize you were the resident troll, and was trying to use reason with > you. It's been fun sparing with you, but you have proven to me that you > have no interest in facts and reason. > > *plonk* > Just responding to your comment about my having no experience. But then like all trolls, you can dish it out - but you can't take it. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Michael Fesser <netizen@gmx.de> |
|---|---|
| Date | 2012-05-11 11:58 +0200 |
| Message-ID | <glopq7tv51j3blo0hr60h5gnb9h09vuvpd@mfesser.de> |
| In reply to | #5944 |
.oO(Jerry Stuckle) >And a system which creates all the images once so it doesn't have to >keep needlessly checking to see if an image exists or not is more >efficient than one which constantly has to see if something exists or not. > >Resizing is done ONCE. Right. >Checking has to be done on EVERY REQUEST. Wrong. Micha -- http://mfesser.de/blickwinkel
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-11 06:51 -0400 |
| Message-ID | <joiqvp$q7t$2@dont-email.me> |
| In reply to | #5955 |
On 5/11/2012 5:58 AM, Michael Fesser wrote: > .oO(Jerry Stuckle) > >> And a system which creates all the images once so it doesn't have to >> keep needlessly checking to see if an image exists or not is more >> efficient than one which constantly has to see if something exists or not. >> >> Resizing is done ONCE. > > Right. > >> Checking has to be done on EVERY REQUEST. > > Wrong. > > Micha > You really have no idea what you're talking about, do you? But you'll argue it anyway. After all - you think there's no overhead in 404 processing! -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Michael Fesser <netizen@gmx.de> |
|---|---|
| Date | 2012-05-11 21:11 +0200 |
| Message-ID | <7hnqq7h7f84025ddoi0g39323fccahbs9u@mfesser.de> |
| In reply to | #5957 |
.oO(Jerry Stuckle) >On 5/11/2012 5:58 AM, Michael Fesser wrote: >> .oO(Jerry Stuckle) >> >>> And a system which creates all the images once so it doesn't have to >>> keep needlessly checking to see if an image exists or not is more >>> efficient than one which constantly has to see if something exists or not. >>> >>> Resizing is done ONCE. >> >> Right. >> >>> Checking has to be done on EVERY REQUEST. >> >> Wrong. >> >> Micha >> > >You really have no idea what you're talking about, do you? But you'll >argue it anyway. You still miss the point (or just don't want to accept it, as usual). If there's a static image file, there is absolutely no additional checking for existance necessary (besides the one that has to be done for every resource the server wishes to deliver, but this doesn't matter here). If the file is there, it will be delivered as-is, if not, it triggers a 404 (which could then create the requested resource on demand). That's the same for every static HTML or CSS file, so your claim from above "Checking has to be done on EVERY REQUEST" is simply wrong. >After all - you think there's no overhead in 404 processing! A little maybe, but I don't think it really matters. What much has the server to do after it didn't find the requested resource? Deliver another page or call a script. I can't think of much more, except maybe a second log entry. The typical redirects from http://example.com/foo to http://example.com/foo/, which are still seen on many sites, are much more expensive. Micha -- http://mfesser.de/blickwinkel
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-11 15:29 -0400 |
| Message-ID | <jojpaj$n7f$1@dont-email.me> |
| In reply to | #5974 |
On 5/11/2012 3:11 PM, Michael Fesser wrote: > .oO(Jerry Stuckle) > >> On 5/11/2012 5:58 AM, Michael Fesser wrote: >>> .oO(Jerry Stuckle) >>> >>>> And a system which creates all the images once so it doesn't have to >>>> keep needlessly checking to see if an image exists or not is more >>>> efficient than one which constantly has to see if something exists or not. >>>> >>>> Resizing is done ONCE. >>> >>> Right. >>> >>>> Checking has to be done on EVERY REQUEST. >>> >>> Wrong. >>> >>> Micha >>> >> >> You really have no idea what you're talking about, do you? But you'll >> argue it anyway. > > You still miss the point (or just don't want to accept it, as usual). If > there's a static image file, there is absolutely no additional checking > for existance necessary (besides the one that has to be done for every > resource the server wishes to deliver, but this doesn't matter here). > > If the file is there, it will be delivered as-is, if not, it triggers a > 404 (which could then create the requested resource on demand). That's > the same for every static HTML or CSS file, so your claim from above > "Checking has to be done on EVERY REQUEST" is simply wrong. > >> After all - you think there's no overhead in 404 processing! > > A little maybe, but I don't think it really matters. What much has the > server to do after it didn't find the requested resource? Deliver > another page or call a script. I can't think of much more, except maybe > a second log entry. The typical redirects from http://example.com/foo to > http://example.com/foo/, which are still seen on many sites, are much > more expensive. > > Micha > No, you don't get it. A 404 causes even more overhead - Apache has to detect the 404, determine which is the correct error page to load, and load it. In this case it's a PHP file, so the PHP module has to be loaded and the environment initialized, etc. Then the PHP code needs to determine if it is even a request for an image, and if the image can be found and resized. If so, the code must resize the image and send it. Then the module cleanup has to be performed. Plus, depending on what the sysadmin has installed for Apache extensions, other modules may be called in the process. That's a lot of overhead, especially when you know the images and the sizes you need ahead of time. It's fine if you're running 200 hits/day, but not in a busy server. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Michael Fesser <netizen@gmx.de> |
|---|---|
| Date | 2012-05-11 21:53 +0200 |
| Message-ID | <5vqqq71iibo48dcmj0b03dgse9vi3jgm3r@mfesser.de> |
| In reply to | #5975 |
.oO(Jerry Stuckle) >On 5/11/2012 3:11 PM, Michael Fesser wrote: >> >> A little maybe, but I don't think it really matters. What much has the >> server to do after it didn't find the requested resource? Deliver >> another page or call a script. I can't think of much more, except maybe >> a second log entry. The typical redirects from http://example.com/foo to >> http://example.com/foo/, which are still seen on many sites, are much >> more expensive. > >No, you don't get it. A 404 causes even more overhead - Apache has to >detect the 404 Happens all the time for every single resource. >, determine which is the correct error page to load Which is defined in the server configuration. >and >load it. Happens all the time for every single resource. >In this case it's a PHP file, so the PHP module has to be >loaded and the environment initialized, etc. On a site using PHP the module is already there and ready to work. >Then the PHP code needs to determine if it is even a request for an >image, and if the image can be found and resized. If so, the code must >resize the image and send it. That's the only additional work, once per image. So what? >Then the module cleanup has to be performed. Nope, the module stays there. There's just the usual cleanup as for every other PHP page. >Plus, depending on what the sysadmin has installed for Apache >extensions, other modules may be called in the process. Possible, but rather unlikely and irrelevant. >That's a lot of overhead, especially when you know the images and the >sizes you need ahead of time. > >It's fine if you're running 200 hits/day, but not in a busy server. After a short period of time all most requested images are there. Creating another missing image every now and then won't bring a server to its knees. Micha -- http://mfesser.de/blickwinkel
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-11 18:11 -0400 |
| Message-ID | <jok2r8$hom$1@dont-email.me> |
| In reply to | #5978 |
On 5/11/2012 3:53 PM, Michael Fesser wrote: > .oO(Jerry Stuckle) > >> On 5/11/2012 3:11 PM, Michael Fesser wrote: >>> >>> A little maybe, but I don't think it really matters. What much has the >>> server to do after it didn't find the requested resource? Deliver >>> another page or call a script. I can't think of much more, except maybe >>> a second log entry. The typical redirects from http://example.com/foo to >>> http://example.com/foo/, which are still seen on many sites, are much >>> more expensive. >> >> No, you don't get it. A 404 causes even more overhead - Apache has to >> detect the 404 > > Happens all the time for every single resource. > Nope. A static page is served up immediately. No 404 processing required. Even a PHP page is served up with less overhead than a PHP page with 404 processing. 404 is not cheap, and can be quite expensive (relatively) if there are a number of optional modules loaded. >> , determine which is the correct error page to load > > Which is defined in the server configuration. > And has to be found in the configuration - not required when the resource is found. >> and >> load it. > > Happens all the time for every single resource. > Two loads - one failed attempt for the missing resource and a second successful attempt once it figures out which page has to be loaded. >> In this case it's a PHP file, so the PHP module has to be >> loaded and the environment initialized, etc. > > On a site using PHP the module is already there and ready to work. > Maybe, maybe not. It depends on the server. But even if it is loaded, it still has to be attached to the thread or process, the environment initialized. >> Then the PHP code needs to determine if it is even a request for an >> image, and if the image can be found and resized. If so, the code must >> resize the image and send it. > > That's the only additional work, once per image. So what? > Completely unnecessary work, but ok if your site only has 200 hits per day. >> Then the module cleanup has to be performed. > > Nope, the module stays there. There's just the usual cleanup as for > every other PHP page. > The module must still perform cleanup after the script terminates. >> Plus, depending on what the sysadmin has installed for Apache >> extensions, other modules may be called in the process. > > Possible, but rather unlikely and irrelevant. > Not at all unlikely nor irrelevant. >> That's a lot of overhead, especially when you know the images and the >> sizes you need ahead of time. >> >> It's fine if you're running 200 hits/day, but not in a busy server. > > After a short period of time all most requested images are there. > Creating another missing image every now and then won't bring a server > to its knees. > > Micha > Creating them once with a script means the images are there from the start. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Michael Fesser <netizen@gmx.de> |
|---|---|
| Date | 2012-05-12 01:00 +0200 |
| Message-ID | <bj4rq7ljtir5s63egl3jb5p73a8cniqibg@mfesser.de> |
| In reply to | #5980 |
.oO(Jerry Stuckle)
>On 5/11/2012 3:53 PM, Michael Fesser wrote:
>> .oO(Jerry Stuckle)
>>
>>> On 5/11/2012 3:11 PM, Michael Fesser wrote:
>>>>
>>>> A little maybe, but I don't think it really matters. What much has the
>>>> server to do after it didn't find the requested resource? Deliver
>>>> another page or call a script. I can't think of much more, except maybe
>>>> a second log entry. The typical redirects from http://example.com/foo to
>>>> http://example.com/foo/, which are still seen on many sites, are much
>>>> more expensive.
>>>
>>> No, you don't get it. A 404 causes even more overhead - Apache has to
>>> detect the 404
>>
>> Happens all the time for every single resource.
>>
>
>Nope. A static page is served up immediately.
But the server always has to check if it's there. How else could he
deliver it?
And if a previous 404 causes an image file to be created - from that
time on it will also be "served up immediately". The overhead for that
single image happens exactly one time. That's nothing to worry about.
>> Which is defined in the server configuration.
>
>And has to be found in the configuration - not required when the
>resource is found.
The configuration is loaded before and the handlers are defined.
It's just one function call or another (more or less):
if (resourceIsFound()) {
sendResource();
} else {
sendErrorDocument();
}
>>> In this case it's a PHP file, so the PHP module has to be
>>> loaded and the environment initialized, etc.
>>
>> On a site using PHP the module is already there and ready to work.
>
>Maybe, maybe not. It depends on the server. But even if it is loaded,
>it still has to be attached to the thread or process, the environment
>initialized.
Like on every other PHP page.
>>> Then the PHP code needs to determine if it is even a request for an
>>> image, and if the image can be found and resized. If so, the code must
>>> resize the image and send it.
>>
>> That's the only additional work, once per image. So what?
>
>Completely unnecessary work, but ok if your site only has 200 hits per day.
The work has to be done either way.
If you have 100.000 images and get 100.000 hits a day, each one for a
different image, all the images are created on that single day and can
be served directly from that time on. Only the first requester of a
particular image might notice a little delay.
>>> That's a lot of overhead, especially when you know the images and the
>>> sizes you need ahead of time.
>>>
>>> It's fine if you're running 200 hits/day, but not in a busy server.
>>
>> After a short period of time all most requested images are there.
>> Creating another missing image every now and then won't bring a server
>> to its knees.
>
>Creating them once with a script means the images are there from the start.
Which also takes a lot of time and creates images which might not be
used at all.
In short: These are two totally different approaches, but both have
their uses and are reasonable. Doing it the "all-before-way" is OK, but
so is the "on-demand-way". There's absolutely nothing wrong about the
latter: The server load is almost the same, just spread across time.
Micha
--
http://mfesser.de/blickwinkel
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-11 20:44 -0400 |
| Message-ID | <jokbp2$1ts$1@dont-email.me> |
| In reply to | #5983 |
On 5/11/2012 7:00 PM, Michael Fesser wrote:
> .oO(Jerry Stuckle)
>
>> On 5/11/2012 3:53 PM, Michael Fesser wrote:
>>> .oO(Jerry Stuckle)
>>>
>>>> On 5/11/2012 3:11 PM, Michael Fesser wrote:
>>>>>
>>>>> A little maybe, but I don't think it really matters. What much has the
>>>>> server to do after it didn't find the requested resource? Deliver
>>>>> another page or call a script. I can't think of much more, except maybe
>>>>> a second log entry. The typical redirects from http://example.com/foo to
>>>>> http://example.com/foo/, which are still seen on many sites, are much
>>>>> more expensive.
>>>>
>>>> No, you don't get it. A 404 causes even more overhead - Apache has to
>>>> detect the 404
>>>
>>> Happens all the time for every single resource.
>>>
>>
>> Nope. A static page is served up immediately.
>
> But the server always has to check if it's there. How else could he
> deliver it?
>
> And if a previous 404 causes an image file to be created - from that
> time on it will also be "served up immediately". The overhead for that
> single image happens exactly one time. That's nothing to worry about.
>
Not a problem when you're doing 200 hits/day.
>>> Which is defined in the server configuration.
>>
>> And has to be found in the configuration - not required when the
>> resource is found.
>
> The configuration is loaded before and the handlers are defined.
> It's just one function call or another (more or less):
>
> if (resourceIsFound()) {
> sendResource();
> } else {
> sendErrorDocument();
> }
>
You really think that's all there is to it? ROFLMAO!
What does resourceIsFound() do? What does sendErrorDocument() do? A
lot more than just a simple C function call!
>>>> In this case it's a PHP file, so the PHP module has to be
>>>> loaded and the environment initialized, etc.
>>>
>>> On a site using PHP the module is already there and ready to work.
>>
>> Maybe, maybe not. It depends on the server. But even if it is loaded,
>> it still has to be attached to the thread or process, the environment
>> initialized.
>
> Like on every other PHP page.
>
Yes, and if the resource is found, no PHP page is required.
>>>> Then the PHP code needs to determine if it is even a request for an
>>>> image, and if the image can be found and resized. If so, the code must
>>>> resize the image and send it.
>>>
>>> That's the only additional work, once per image. So what?
>>
>> Completely unnecessary work, but ok if your site only has 200 hits per day.
>
> The work has to be done either way.
>
Not at all. It can be done once offline, instead of on the web server.
And doing a bunch of images offline is far more efficient than trying
to handle a 404.
> If you have 100.000 images and get 100.000 hits a day, each one for a
> different image, all the images are created on that single day and can
> be served directly from that time on. Only the first requester of a
> particular image might notice a little delay.
>
You've obviously never had a site which had 100,000 hits a day. I
suspect your sites never exceed 200 hits/day.
>>>> That's a lot of overhead, especially when you know the images and the
>>>> sizes you need ahead of time.
>>>>
>>>> It's fine if you're running 200 hits/day, but not in a busy server.
>>>
>>> After a short period of time all most requested images are there.
>>> Creating another missing image every now and then won't bring a server
>>> to its knees.
>>
>> Creating them once with a script means the images are there from the start.
>
> Which also takes a lot of time and creates images which might not be
> used at all.
>
Less time than creating them on the fly. Plus it's done offline and not
taking web server time.
> In short: These are two totally different approaches, but both have
> their uses and are reasonable. Doing it the "all-before-way" is OK, but
> so is the "on-demand-way". There's absolutely nothing wrong about the
> latter: The server load is almost the same, just spread across time.
>
> Micha
>
In short, you have no idea how to optimize even a slightly busy site.
Your approach works fine for your sites which never have more than 200
hits/day. It does not scale to an even moderately busy site.
I'm not in favor of premature optimization. However, I AM in favor of
not putting an unnecessary load on the web server. But then the sites I
deal with are moderately busy, also.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2012-05-12 00:38 +0100 |
| Message-ID | <jok7uc$8im$4@news.albasani.net> |
| In reply to | #5978 |
Michael Fesser wrote: > .oO(Jerry Stuckle) > >> On 5/11/2012 3:11 PM, Michael Fesser wrote: >>> A little maybe, but I don't think it really matters. What much has the >>> server to do after it didn't find the requested resource? Deliver >>> another page or call a script. I can't think of much more, except maybe >>> a second log entry. The typical redirects from http://example.com/foo to >>> http://example.com/foo/, which are still seen on many sites, are much >>> more expensive. >> No, you don't get it. A 404 causes even more overhead - Apache has to >> detect the 404 > > Happens all the time for every single resource. > >> , determine which is the correct error page to load > > Which is defined in the server configuration. > >> and >> load it. > > Happens all the time for every single resource. > exactly: so a check is always done. not never done.
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2012-05-12 00:36 +0100 |
| Message-ID | <jok7pg$8im$2@news.albasani.net> |
| In reply to | #5974 |
Michael Fesser wrote: > .oO(Jerry Stuckle) > >> On 5/11/2012 5:58 AM, Michael Fesser wrote: >>> .oO(Jerry Stuckle) >>> >>>> And a system which creates all the images once so it doesn't have to >>>> keep needlessly checking to see if an image exists or not is more >>>> efficient than one which constantly has to see if something exists or not. >>>> >>>> Resizing is done ONCE. >>> Right. >>> >>>> Checking has to be done on EVERY REQUEST. >>> Wrong. >>> >>> Micha >>> >> You really have no idea what you're talking about, do you? But you'll >> argue it anyway. > > You still miss the point (or just don't want to accept it, as usual). If > there's a static image file, there is absolutely no additional checking > for existance necessary (besides the one that has to be done for every > resource the server wishes to deliver, but this doesn't matter here). > > If the file is there, it will be delivered as-is, if not, it triggers a > 404 (which could then create the requested resource on demand). That's > the same for every static HTML or CSS file, so your claim from above > "Checking has to be done on EVERY REQUEST" is simply wrong. > the 404 response is evidence that a check has been done. >> After all - you think there's no overhead in 404 processing! > > A little maybe, but I don't think it really matters. What much has the > server to do after it didn't find the requested resource? Deliver > another page or call a script. I can't think of much more, except maybe > a second log entry. The typical redirects from http://example.com/foo to > http://example.com/foo/, which are still seen on many sites, are much > more expensive. > *shrug* serve the file via a PHP script. The check is minimal compared top the actual serving of the data, and infinitely small compared with rescaling. > Micha > -- To people who know nothing, anything is possible. To people who know too much, it is a sad fact that they know how little is really possible - and how hard it is to achieve it.
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2012-05-11 14:01 +0100 |
| Message-ID | <joj2ih$pqq$6@news.albasani.net> |
| In reply to | #5955 |
Michael Fesser wrote: > .oO(Jerry Stuckle) > >> And a system which creates all the images once so it doesn't have to >> keep needlessly checking to see if an image exists or not is more >> efficient than one which constantly has to see if something exists or not. >> >> Resizing is done ONCE. > > Right. > >> Checking has to be done on EVERY REQUEST. > > Wrong. depends what you meean by checking: if the code goes load scaled image if fail rescale master image store scaled copy send scaled image then the only overhead is to check for failure of a load operation, but I don't see how you can get around that, You have to go to the database or the disk anyway to get the file, so its hardly an overhead to check if it fails. > > Micha > -- To people who know nothing, anything is possible. To people who know too much, it is a sad fact that they know how little is really possible - and how hard it is to achieve it.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-11 10:34 -0400 |
| Message-ID | <joj81g$6ik$1@dont-email.me> |
| In reply to | #5961 |
On 5/11/2012 9:01 AM, The Natural Philosopher wrote: > Michael Fesser wrote: >> .oO(Jerry Stuckle) >> >>> And a system which creates all the images once so it doesn't have to >>> keep needlessly checking to see if an image exists or not is more >>> efficient than one which constantly has to see if something exists or >>> not. >>> >>> Resizing is done ONCE. >> >> Right. >> >>> Checking has to be done on EVERY REQUEST. >> >> Wrong. > > depends what you meean by checking: if the code goes > > load scaled image > if fail > rescale master image > store scaled copy > send scaled image > > then the only overhead is to check for failure of a load operation, but > I don't see how you can get around that, > > You have to go to the database or the disk anyway to get the file, so > its hardly an overhead to check if it fails. > > > Loading the script, starting the scripting module, initializing the environment, interpreting and running the script, checking for the presence of the image, storing a resized script if necessary, loading the image and sending it, and cleaning up the environment. This vs. sending the image directly via an <img ...> tag. Nope, no extra overhead! And no way to send the image without a script! >> >> Micha >> > > -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
Back to top | Article view | comp.lang.php
csiph-web