| Re: Windows binaries 64bit for PHP [message #177988] |
Thu, 10 May 2012 03:53  |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178025 is a reply to message #177988] |
Thu, 10 May 2012 20:15  |
Daniel Pitts
Messages: 68
Registered: May 2012
Karma: 0
|
Member |
|
|
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.
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178026 is a reply to message #178025] |
Thu, 10 May 2012 20:48 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178028 is a reply to message #178025] |
Thu, 10 May 2012 21:05 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178030 is a reply to message #178028] |
Thu, 10 May 2012 21:29 |
Daniel Pitts
Messages: 68
Registered: May 2012
Karma: 0
|
Member |
|
|
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.
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178033 is a reply to message #178030] |
Thu, 10 May 2012 23:35 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178034 is a reply to message #178030] |
Fri, 11 May 2012 00:07 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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
.....IN CPU usage, but not disk storage....
> than one that will create
> all known previous sizes and then reprocessing all old images as new
> requirements are introduced.
>
>
--
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.
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178036 is a reply to message #178033] |
Fri, 11 May 2012 01:50 |
Daniel Pitts
Messages: 68
Registered: May 2012
Karma: 0
|
Member |
|
|
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.
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178037 is a reply to message #178036] |
Fri, 11 May 2012 02:22 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178044 is a reply to message #178033] |
Fri, 11 May 2012 09:58 |
Michael Fesser
Messages: 215
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
.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
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178046 is a reply to message #178044] |
Fri, 11 May 2012 10:51 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178050 is a reply to message #178044] |
Fri, 11 May 2012 13:01 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178056 is a reply to message #178050] |
Fri, 11 May 2012 14:34 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178057 is a reply to message #178037] |
Fri, 11 May 2012 17:03 |
Daniel Pitts
Messages: 68
Registered: May 2012
Karma: 0
|
Member |
|
|
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*
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178058 is a reply to message #178057] |
Fri, 11 May 2012 17:56 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178061 is a reply to message #178056] |
Fri, 11 May 2012 18:58 |
Shake
Messages: 40
Registered: May 2012
Karma: 0
|
Member |
|
|
Jerry Stuckle a couché sur son écran :
>
> 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!
>
The Extra overhead is something like in the code that generate the
page:
<?php
if(!file_exists(IMG_PATH.$image_file)) scaleImage($image_file);
?>
Not look like an "application killer" to me.
Greetings.
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178063 is a reply to message #178046] |
Fri, 11 May 2012 19:11 |
Michael Fesser
Messages: 215
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
.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
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178064 is a reply to message #178063] |
Fri, 11 May 2012 19:29 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178065 is a reply to message #178061] |
Fri, 11 May 2012 19:30 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/11/2012 2:58 PM, Shake wrote:
> Jerry Stuckle a couché sur son écran :
>>
>> 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!
>>
>
> The Extra overhead is something like in the code that generate the page:
>
> <?php
> if(!file_exists(IMG_PATH.$image_file)) scaleImage($image_file);
> ?>
>
> Not look like an "application killer" to me.
>
> Greetings.
>
>
There's a lot more to the overhead than that!
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178066 is a reply to message #178065] |
Fri, 11 May 2012 19:46 |
Shake
Messages: 40
Registered: May 2012
Karma: 0
|
Member |
|
|
Jerry Stuckle avait écrit le 11/05/2012 :
> On 5/11/2012 2:58 PM, Shake wrote:
>> Jerry Stuckle a couché sur son écran :
>>>
>>> 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!
>>>
>>
>> The Extra overhead is something like in the code that generate the page:
>>
>> <?php
>> if(!file_exists(IMG_PATH.$image_file)) scaleImage($image_file);
>> ?>
>>
>> Not look like an "application killer" to me.
>>
>> Greetings.
>>
>>
>
> There's a lot more to the overhead than that!
Which?
Is the image going to be accessed directly by its URL, or is loaded
inside a webpage? I am sure is this last case.
So Loading a PHP script will occur 99.999% if you reescaled the image
previously with a batch or not. All the work of load an script, will be
done always.
I don't believe that "react" to a 404 error is the good aproach, but
generating dinamically the scaled images when the page that show them
is required.
And this only need the few lines to test if file exists and generate
the images if not.
The fact that the image is directly accessed without pasing first for
the php script...
Someone talked about a catalog of image... I am sure they are accessed
through a we, not directly.
Even if they are accessed via search engines, these search engines have
to visit the scripts that would generate the scaled images.
Greetings.
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178067 is a reply to message #178064] |
Fri, 11 May 2012 19:53 |
Michael Fesser
Messages: 215
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
.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
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178068 is a reply to message #178065] |
Fri, 11 May 2012 19:53 |
Luuk
Messages: 329
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 11-05-2012 21:30, Jerry Stuckle wrote:
> On 5/11/2012 2:58 PM, Shake wrote:
>> Jerry Stuckle a couché sur son écran :
>>>
>>> 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!
>>>
>>
>> The Extra overhead is something like in the code that generate the page:
>>
>> <?php
>> if(!file_exists(IMG_PATH.$image_file)) scaleImage($image_file);
>> ?>
>>
>> Not look like an "application killer" to me.
>>
>> Greetings.
>>
>>
>
> There's a lot more to the overhead than that!
>
only when file does not exists,
and, of course, the scaleImage wil make sure that it exists next time!
So, there will only be some overhead 1 time ....
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178069 is a reply to message #178067] |
Fri, 11 May 2012 22:11 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178070 is a reply to message #178066] |
Fri, 11 May 2012 22:14 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/11/2012 3:46 PM, Shake wrote:
> Jerry Stuckle avait écrit le 11/05/2012 :
>> On 5/11/2012 2:58 PM, Shake wrote:
>>> Jerry Stuckle a couché sur son écran :
>>>>
>>>> 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!
>>>>
>>>
>>> The Extra overhead is something like in the code that generate the page:
>>>
>>> <?php
>>> if(!file_exists(IMG_PATH.$image_file)) scaleImage($image_file);
>>> ?>
>>>
>>> Not look like an "application killer" to me.
>>>
>>> Greetings.
>>>
>>>
>>
>> There's a lot more to the overhead than that!
>
> Which?
>
See my other posts. It is actually quite involved, and I'm not going to
repeat it (again).
> Is the image going to be accessed directly by its URL, or is loaded
> inside a webpage? I am sure is this last case.
>
> So Loading a PHP script will occur 99.999% if you reescaled the image
> previously with a batch or not. All the work of load an script, will be
> done always.
>
Nope. If you rescaled the image via a batch script, the image is there
and it can be served directly.
> I don't believe that "react" to a 404 error is the good aproach, but
> generating dinamically the scaled images when the page that show them is
> required.
>
Which has significant overhead, as I've pointed out in my other posts.
> And this only need the few lines to test if file exists and generate the
> images if not.
>
There's a lot more to it than that.
> The fact that the image is directly accessed without pasing first for
> the php script...
>
> Someone talked about a catalog of image... I am sure they are accessed
> through a we, not directly.
>
A catalog of images doesn't mean the images aren't being served directly.
> Even if they are accessed via search engines, these search engines have
> to visit the scripts that would generate the scaled images.
>
> Greetings.
>
>
More unnecessary overhead.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178071 is a reply to message #178068] |
Fri, 11 May 2012 22:15 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/11/2012 3:53 PM, Luuk wrote:
> On 11-05-2012 21:30, Jerry Stuckle wrote:
>> On 5/11/2012 2:58 PM, Shake wrote:
>>> Jerry Stuckle a couché sur son écran :
>>>>
>>>> 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!
>>>>
>>>
>>> The Extra overhead is something like in the code that generate the page:
>>>
>>> <?php
>>> if(!file_exists(IMG_PATH.$image_file)) scaleImage($image_file);
>>> ?>
>>>
>>> Not look like an "application killer" to me.
>>>
>>> Greetings.
>>>
>>>
>>
>> There's a lot more to the overhead than that!
>>
>
> only when file does not exists,
> and, of course, the scaleImage wil make sure that it exists next time!
> So, there will only be some overhead 1 time ....
>
One time for each image, vs. 0 times for each image if they are resized
offline in a batch script.
That overhead x 7.5 million images the op indicates he has is significant.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178072 is a reply to message #178069] |
Fri, 11 May 2012 23:00 |
Michael Fesser
Messages: 215
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
.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
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178073 is a reply to message #178063] |
Fri, 11 May 2012 23:36 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178074 is a reply to message #178066] |
Fri, 11 May 2012 23:38 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Shake wrote:
> Jerry Stuckle avait écrit le 11/05/2012 :
>> On 5/11/2012 2:58 PM, Shake wrote:
>>> Jerry Stuckle a couché sur son écran :
>>>>
>>>> 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!
>>>>
>>>
>>> The Extra overhead is something like in the code that generate the page:
>>>
>>> <?php
>>> if(!file_exists(IMG_PATH.$image_file)) scaleImage($image_file);
>>> ?>
>>>
>>> Not look like an "application killer" to me.
>>>
>>> Greetings.
>>>
>>>
>>
>> There's a lot more to the overhead than that!
>
> Which?
>
> Is the image going to be accessed directly by its URL, or is loaded
> inside a webpage? I am sure is this last case.
>
> So Loading a PHP script will occur 99.999% if you reescaled the image
> previously with a batch or not. All the work of load an script, will be
> done always.
>
> I don't believe that "react" to a 404 error is the good aproach, but
> generating dinamically the scaled images when the page that show them is
> required.
>
> And this only need the few lines to test if file exists and generate the
> images if not.
>
> The fact that the image is directly accessed without pasing first for
> the php script...
is hardly any CPU.
The same actions take place: the file must be opened headers constricted
and then data streamed. whether apache or PHP does this is scarcely an
issue.
>
> Someone talked about a catalog of image... I am sure they are accessed
> through a we, not directly.
>
> Even if they are accessed via search engines, these search engines have
> to visit the scripts that would generate the scaled images.
>
> Greetings.
>
>
--
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.
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178075 is a reply to message #178067] |
Fri, 11 May 2012 23:38 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178076 is a reply to message #178068] |
Fri, 11 May 2012 23:40 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Luuk wrote:
> On 11-05-2012 21:30, Jerry Stuckle wrote:
>> On 5/11/2012 2:58 PM, Shake wrote:
>>> Jerry Stuckle a couché sur son écran :
>>>> 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!
>>>>
>>> The Extra overhead is something like in the code that generate the page:
>>>
>>> <?php
>>> if(!file_exists(IMG_PATH.$image_file)) scaleImage($image_file);
>>> ?>
>>>
>>> Not look like an "application killer" to me.
>>>
>>> Greetings.
>>>
>>>
>> There's a lot more to the overhead than that!
>>
>
> only when file does not exists,
> and, of course, the scaleImage wil make sure that it exists next time!
> So, there will only be some overhead 1 time ....
>
exactly.
Jerry is as usual talking out of his arse..he must have taken his head out.
--
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.
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178077 is a reply to message #178072] |
Sat, 12 May 2012 00:44 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178078 is a reply to message #178074] |
Sat, 12 May 2012 00:46 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/11/2012 7:38 PM, The Natural Philosopher wrote:
> Shake wrote:
>> Jerry Stuckle avait écrit le 11/05/2012 :
>>> On 5/11/2012 2:58 PM, Shake wrote:
>>>> Jerry Stuckle a couché sur son écran :
>>>> >
>>>> > 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!
>>>> >
>>>>
>>>> The Extra overhead is something like in the code that generate the
>>>> page:
>>>>
>>>> <?php
>>>> if(!file_exists(IMG_PATH.$image_file)) scaleImage($image_file);
>>>> ?>
>>>>
>>>> Not look like an "application killer" to me.
>>>>
>>>> Greetings.
>>>>
>>>>
>>>
>>> There's a lot more to the overhead than that!
>>
>> Which?
>>
>> Is the image going to be accessed directly by its URL, or is loaded
>> inside a webpage? I am sure is this last case.
>>
>> So Loading a PHP script will occur 99.999% if you reescaled the image
>> previously with a batch or not. All the work of load an script, will
>> be done always.
>>
>> I don't believe that "react" to a 404 error is the good aproach, but
>> generating dinamically the scaled images when the page that show them
>> is required.
>>
>> And this only need the few lines to test if file exists and generate
>> the images if not.
>>
>> The fact that the image is directly accessed without pasing first for
>> the php script...
>
> is hardly any CPU.
>
> The same actions take place: the file must be opened headers constricted
> and then data streamed. whether apache or PHP does this is scarcely an
> issue.
>
Wrong. The server is much more efficient at serving images than a PHP
script is. But then I would expect this type of statement from a ditch
digger who got fired because he didn't know which end of a shovel to use.
>>
>> Someone talked about a catalog of image... I am sure they are accessed
>> through a we, not directly.
>>
>> Even if they are accessed via search engines, these search engines
>> have to visit the scripts that would generate the scaled images.
>>
>> Greetings.
>>
>>
>
>
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178079 is a reply to message #178071] |
Sat, 12 May 2012 08:00 |
Luuk
Messages: 329
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 12-05-2012 00:15, Jerry Stuckle wrote:
> On 5/11/2012 3:53 PM, Luuk wrote:
>> On 11-05-2012 21:30, Jerry Stuckle wrote:
>>> On 5/11/2012 2:58 PM, Shake wrote:
>>>> Jerry Stuckle a couché sur son écran :
>>>> >
>>>> > 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!
>>>> >
>>>>
>>>> The Extra overhead is something like in the code that generate the
>>>> page:
>>>>
>>>> <?php
>>>> if(!file_exists(IMG_PATH.$image_file)) scaleImage($image_file);
>>>> ?>
>>>>
>>>> Not look like an "application killer" to me.
>>>>
>>>> Greetings.
>>>>
>>>>
>>>
>>> There's a lot more to the overhead than that!
>>>
>>
>> only when file does not exists,
>> and, of course, the scaleImage wil make sure that it exists next time!
>> So, there will only be some overhead 1 time ....
>>
>
> One time for each image, vs. 0 times for each image if they are resized
> offline in a batch script.
>
So, offline is for 'free' ?
You are comparing apples with oranges here....
> That overhead x 7.5 million images the op indicates he has is significant.
>
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178081 is a reply to message #178079] |
Sat, 12 May 2012 11:29 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/12/2012 4:00 AM, Luuk wrote:
> On 12-05-2012 00:15, Jerry Stuckle wrote:
>> On 5/11/2012 3:53 PM, Luuk wrote:
>>> On 11-05-2012 21:30, Jerry Stuckle wrote:
>>>> On 5/11/2012 2:58 PM, Shake wrote:
>>>> > Jerry Stuckle a couché sur son écran :
>>>> >>
>>>> >> 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!
>>>> >>
>>>> >
>>>> > The Extra overhead is something like in the code that generate the
>>>> > page:
>>>> >
>>>> > <?php
>>>> > if(!file_exists(IMG_PATH.$image_file)) scaleImage($image_file);
>>>> > ?>
>>>> >
>>>> > Not look like an "application killer" to me.
>>>> >
>>>> > Greetings.
>>>> >
>>>> >
>>>>
>>>> There's a lot more to the overhead than that!
>>>>
>>>
>>> only when file does not exists,
>>> and, of course, the scaleImage wil make sure that it exists next time!
>>> So, there will only be some overhead 1 time ....
>>>
>>
>> One time for each image, vs. 0 times for each image if they are resized
>> offline in a batch script.
>>
>
> So, offline is for 'free' ?
> You are comparing apples with oranges here....
>
>> That overhead x 7.5 million images the op indicates he has is significant.
>>
>
I never said offline is 'free'. But it can be done on any machine; it
doesn't require taking response time from a live server.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178082 is a reply to message #178079] |
Sat, 12 May 2012 11:47 |
Peter H. Coffin
Messages: 245
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Sat, 12 May 2012 10:00:26 +0200, Luuk wrote:
> On 12-05-2012 00:15, Jerry Stuckle wrote:
>>
>> One time for each image, vs. 0 times for each image if they are resized
>> offline in a batch script.
>>
>
> So, offline is for 'free' ?
> You are comparing apples with oranges here....
offline *is* free from the standpoint of load on the frontline http
servers. Which should be top priority in considering how expensive
something is.
--
CANNIBAL, n.
A gastronome of the old school who preserves the simple tastes and
adheres to the natural diet of the pre-pork period.
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178083 is a reply to message #178070] |
Sat, 12 May 2012 12:42 |
Shake
Messages: 40
Registered: May 2012
Karma: 0
|
Member |
|
|
I thought you don't understood.
I would use the catalogue example:
People visits this page to see the image catalogue. Search engines
visits this page to index images.
If nobody human or machine have entered to this page, there is no
directy linked image nowhere.
So, at this point nobody knows any url to any image of this site. And
there is no image that could be accessed.
The only way to knwo about one of these images is when anyone enter the
php page. And when this occurs, reescaling process will be done if
necesary.
Never, any image will be directly delivered without previosly have been
executed the php.
We have the image /catalogue/images/size_1/123213.jpg Original
We have the image /catalogue/images/size_2/123213.jpg Scaled
We have the image /catalogue/images/size_3/123213.jpg No Scaled.
The catalogue was listed throught /catalogue/index.php that yesterday
was modified using a new size fo thumbnails (size_3).
The third size was created yesterday. Nobody knows his existence, there
is no link to it in any web, search engine or human brain. So nobody
could access. That is a lucky thing, because the image no exist.
When the first visit is done to the /catalogue/index.php the size_2
images start to be generated. If the visit is from a search engine,
then the new images are indexed and could be directly accessed.
so /catalogue/index.php is executed always previous to put on the net
the existence of new images. Included if we have batch reescaled them.
These images will not have internet existence never if the
catalogue/index.php is not executed. with or without reescaling.
And then, this mean that all the supossed overhead about executing PHP
always happen even if you batched the process.
And it's obvious. we are talking about web pages that are created with
php.
I worked for four years in a website for artists. Not the bigger
company but with reasonable traffic, 8 millions page visits per month,
por than 250.000 pages per day. And about 1 million image artwork. A
lot of them of big resolucion.
And in this company we fight against this problem. In some cases we
decided to use batch process and in other cases we decided to do
"on-the-fly".
Big images requires watermarking and some other processes, too slow to
do on-fly. The reescaling required 3 weeks to be done , using three 3
computers.
Other times, for new set of small sizes, we used on the fly. withouth
usign 404 to react to.
Just first time any one enters a page that have new images, new images
were generated. And never happened that any image have been accesses
directly previous to its generation.
The images are always served directly throught lighttp, the php
necesary to generate images was always inside the php app that generate
the web pages.
Greetings
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178085 is a reply to message #178083] |
Sat, 12 May 2012 15:04 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/12/2012 8:42 AM, Shake wrote:
> I thought you don't understood.
>
> I would use the catalogue example:
>
> People visits this page to see the image catalogue. Search engines
> visits this page to index images.
>
> If nobody human or machine have entered to this page, there is no
> directy linked image nowhere.
>
The link is there, whether a human or machine has requested the page or
not. Links don't just magically appear!
Whether the link has been accessed or not is a different story - but
immaterial to whether it exists or not.
> So, at this point nobody knows any url to any image of this site. And
> there is no image that could be accessed.
>
Still doesn't make any difference whether someone knows about the image
or not.
> The only way to knwo about one of these images is when anyone enter the
> php page. And when this occurs, reescaling process will be done if
> necesary.
>
At additional overhead to the server. This overhead can be completely
eliminated by simply resizing the images offline.
> Never, any image will be directly delivered without previosly have been
> executed the php.
>
And once the images have been created offline, the server doesn't have
to execute ANY PHP to deliver the image.
> We have the image /catalogue/images/size_1/123213.jpg Original
> We have the image /catalogue/images/size_2/123213.jpg Scaled
> We have the image /catalogue/images/size_3/123213.jpg No Scaled.
>
> The catalogue was listed throught /catalogue/index.php that yesterday
> was modified using a new size fo thumbnails (size_3).
>
> The third size was created yesterday. Nobody knows his existence, there
> is no link to it in any web, search engine or human brain. So nobody
> could access. That is a lucky thing, because the image no exist.
>
If there is no link, then why would the image be created?
> When the first visit is done to the /catalogue/index.php the size_2
> images start to be generated. If the visit is from a search engine, then
> the new images are indexed and could be directly accessed.
>
And if the images are created offline, none of that needs to be done.
The images can be sent without any PHP involvement at all.
> so /catalogue/index.php is executed always previous to put on the net
> the existence of new images. Included if we have batch reescaled them.
> These images will not have internet existence never if the
> catalogue/index.php is not executed. with or without reescaling.
>
But if you're listing them in the catalog, then there is a link to them.
> And then, this mean that all the supossed overhead about executing PHP
> always happen even if you batched the process.
>
Sure, but the batch process is done on another machine, taking
unnecessary work off the server.
> And it's obvious. we are talking about web pages that are created with php.
>
Which has nothing to do with resizing of images. The page with the link
MAY be a PHP page. But it could also be a Perl page, a Python page, a
Ruby (on Rails) page or even static HTML.
> I worked for four years in a website for artists. Not the bigger company
> but with reasonable traffic, 8 millions page visits per month, por than
> 250.000 pages per day. And about 1 million image artwork. A lot of them
> of big resolucion.
>
8 million hits a month is a bit below average, but a lot more than most
of the people in this newsgroup work on.
> And in this company we fight against this problem. In some cases we
> decided to use batch process and in other cases we decided to do
> "on-the-fly".
>
Sure, doing the batch process means less work for the server.
> Big images requires watermarking and some other processes, too slow to
> do on-fly. The reescaling required 3 weeks to be done , using three 3
> computers.
>
You need to get some better computers. 1M images shouldn't take
anywhere near 9 computer weeks to do! But then maybe you're using
Windows, which has significant overhead. Of course you could also do it
in a compiled language like C, which will also tremendously speed up the
process (a C program to do something like this is pretty simple).
> Other times, for new set of small sizes, we used on the fly. withouth
> usign 404 to react to.
>
Good you're not using the 404. But it's still a lot of unnecessary
overhead.
How long would it take your 3 computers to resize all the images you're
currently doing on your server? You're dumping that amount of overhead
plus more on the server.
> Just first time any one enters a page that have new images, new images
> were generated. And never happened that any image have been accesses
> directly previous to its generation.
>
Which is putting unnecessary overhead on the server.
> The images are always served directly throught lighttp, the php necesary
> to generate images was always inside the php app that generate the web
> pages.
>
> Greetings
>
>
You still have significant overhead on the server. Plus now you've
added unnecessary complexity to your application.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178086 is a reply to message #178085] |
Sat, 12 May 2012 16:40 |
Shake
Messages: 40
Registered: May 2012
Karma: 0
|
Member |
|
|
WTF
you don't understand nothing of what I wrote... Probably the problem
it's me and my lack of knowledge of english language...
The thing is in:
"And once the images have been created offline, the server doesn't have
to execute ANY PHP to deliver the image."
Yes you have... the image will never exists on the net, without first
having executed a PHP. (Not to deliver the image). And this is what I
could not explain to you.
GReetings.
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178087 is a reply to message #178086] |
Sat, 12 May 2012 19:49 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/12/2012 12:40 PM, Shake wrote:
> WTF
>
>
> you don't understand nothing of what I wrote... Probably the problem
> it's me and my lack of knowledge of english language...
>
> The thing is in:
>
> "And once the images have been created offline, the server doesn't have
> to execute ANY PHP to deliver the image."
>
> Yes you have... the image will never exists on the net, without first
> having executed a PHP. (Not to deliver the image). And this is what I
> could not explain to you.
>
> GReetings.
>
>
I do understand what you're saying. And I'm saying you create the image
offline and upload it to the server. The server should not have to
spend its time resizing images - it has a lot more important things to do.
Whether the server executes PHP other than resizing the image is
completely immaterial to the issue.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178090 is a reply to message #178086] |
Sat, 12 May 2012 21:59 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Shake wrote:
> WTF
>
>
> you don't understand nothing of what I wrote... Probably the problem
> it's me and my lack of knowledge of english language...
>
> The thing is in:
>
> "And once the images have been created offline, the server doesn't have
> to execute ANY PHP to deliver the image."
>
> Yes you have... the image will never exists on the net, without first
> having executed a PHP. (Not to deliver the image). And this is what I
> could not explain to you.
>
Probably because its nonsense.
there is no law of nature that says that PHP must exist on the internet.
Nor that anything it can accomplish cant be accomplished in some other way.
images have been on the net before PHP existed.
> GReetings.
>
>
--
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.
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]