FUDforum - خوراک RDF
http://fudforum.org/forum/index.php
Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=177988&th=122650#msg_177988
> 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@attglobal.net
==================]]>Jerry Stuckle2012-05-10T03:53:36-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178025&th=122650#msg_178025
> 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.]]>Daniel Pitts2012-05-10T20:15:10-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178026&th=122650#msg_178026
> 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.]]>The Natural Philosoph2012-05-10T20:48:19-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178028&th=122650#msg_178028
> On 5/9/12 8:53 PM, Jerry Stuckle wrote:
>> On 5/9/2012 6:28 PM, Daniel Pitts wrote:
>>> On 5/9/12 3:19 PM, Michael Fesser wrote:
>>>> .oO(Jerry Stuckle)
>>>>
>>>> > On 5/8/2012 4:25 PM, Michael Fesser wrote:
>>>> >> .oO(Jerry Stuckle)
>>>> >>
>>>> >>> On 5/7/2012 11:37 PM, Daniel Pitts wrote:
>>>> >>>> Exactly true, but if you scale to sizes you don't need, you indeed
>>>> >>>> use
>>>> >>>> more processor time! Our disk space is definitely not the
>>>> >>>> bottleneck.
>>>> >>>
>>>> >>> And if you repeatedly rescale the same image to the same size,
>>>> >>> you're
>>>> >>> using even more processor time!
>>>> >>
>>>> >> You missed the word 'caching'. You rescale when needed, and only
>>>> >> once.
>>>> >
>>>> > No, I didn't. By definition, caching is temporary storage which can be
>>>> > erased at any time.
>>>>
>>>> Correct. And then the rescaled images are created again when needed, so
>>>> what's the problem? It all happens automatically.
>>>>
>>>> Micha
>>>>
>>>
>>> Caching needn't be temporary, and you can ensure it isn't "erased at any
>>> time" by just not erasing the "cache". There are many different types of
>>> "cache".
>>
>> By definition a cache is temporary.
>>
> Whose definition?
> According to <http://www.thefreedictionary.com/cache>
>
> 1. "A collection of items of the same type stored in a hidden or
> inaccessible place."
> 2. Computer Science: A fast storage buffer in the central processing
> unit of a computer. Also called cache memory.
>
> That doesn't define it as temporary. Perhaps you're mistaking your
> understanding of the concept with reality. Reality wins over your
> understanding.
>
> Anyway, I've had enough fun arguing with an obvious "expert" in this
> field. Enjoy being "right" on the internet.
>
> Good day,
> Daniel.
And you obviously don't understand what you're reading.
Since when is "memory" permanent? I thought that's why we had hard
drives. And I don't see any thing in your definition about hard drives.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. jstucklex@attglobal.net
==================]]>Jerry Stuckle2012-05-10T21:05:42-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178030&th=122650#msg_178030
> 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.]]>Daniel Pitts2012-05-10T21:29:30-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178033&th=122650#msg_178033
> On 5/10/12 2:05 PM, Jerry Stuckle wrote:
>> On 5/10/2012 4:15 PM, Daniel Pitts wrote:
>>> On 5/9/12 8:53 PM, Jerry Stuckle wrote:
>>>> On 5/9/2012 6:28 PM, Daniel Pitts wrote:
>>>> > On 5/9/12 3:19 PM, Michael Fesser wrote:
>>>> >> .oO(Jerry Stuckle)
>>>> >>
>>>> >>> On 5/8/2012 4:25 PM, Michael Fesser wrote:
>>>> >>>> .oO(Jerry Stuckle)
>>>> >>>>
>>>> >>>>> On 5/7/2012 11:37 PM, Daniel Pitts wrote:
>>>> >>>>>> Exactly true, but if you scale to sizes you don't need, you
>>>> >>>>>> indeed
>>>> >>>>>> use
>>>> >>>>>> more processor time! Our disk space is definitely not the
>>>> >>>>>> bottleneck.
>>>> >>>>>
>>>> >>>>> And if you repeatedly rescale the same image to the same size,
>>>> >>>>> you're
>>>> >>>>> using even more processor time!
>>>> >>>>
>>>> >>>> You missed the word 'caching'. You rescale when needed, and only
>>>> >>>> once.
>>>> >>>
>>>> >>> No, I didn't. By definition, caching is temporary storage which
>>>> >>> can be
>>>> >>> erased at any time.
>>>> >>
>>>> >> Correct. And then the rescaled images are created again when
>>>> >> needed, so
>>>> >> what's the problem? It all happens automatically.
>>>> >>
>>>> >> Micha
>>>> >>
>>>> >
>>>> > Caching needn't be temporary, and you can ensure it isn't "erased at
>>>> > any
>>>> > time" by just not erasing the "cache". There are many different
>>>> > types of
>>>> > "cache".
>>>>
>>>> By definition a cache is temporary.
>>>>
>>> Whose definition?
>>> According to <http://www.thefreedictionary.com/cache>
>>>
>>> 1. "A collection of items of the same type stored in a hidden or
>>> inaccessible place."
>>> 2. Computer Science: A fast storage buffer in the central processing
>>> unit of a computer. Also called cache memory.
>>>
>>> That doesn't define it as temporary. Perhaps you're mistaking your
>>> understanding of the concept with reality. Reality wins over your
>>> understanding.
>>>
>>> Anyway, I've had enough fun arguing with an obvious "expert" in this
>>> field. Enjoy being "right" on the internet.
>>>
>>> Good day,
>>> Daniel.
>>
>> And you obviously don't understand what you're reading.
>>
>> Since when is "memory" permanent? I thought that's why we had hard
>> drives. And I don't see any thing in your definition about hard drives.
>>
> So, lets take a step back here.
>
> Forget the word caching, and your misunderstanding of it altogether.
>
> A system which will resize an image on-demand, and store the resize
> image for later retrieval is more efficient than one that will create
> all known previous sizes and then reprocessing all old images as new
> requirements are introduced.
>
>
I do not misunderstand caching. Just because YOU have no idea what
you're talking about doesn't mean anyone else doesn't.
And a system which creates all the images once so it doesn't have to
keep needlessly checking to see if an image exists or not is more
efficient than one which constantly has to see if something exists or not.
Resizing is done ONCE. Checking has to be done on EVERY REQUEST.
But then you're got your mind made up. After all, it would take
"months" for you to resize your images.
A good system can resize several hundred images a second. At most we're
taking a few hours to do 7.5M images, even if they are high-res. But
your TRS-80's may only be able to do one a second.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. jstucklex@attglobal.net
==================]]>Jerry Stuckle2012-05-10T23:35:21-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178034&th=122650#msg_178034
> 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.]]>The Natural Philosoph2012-05-11T00:07:17-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178036&th=122650#msg_178036
> 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"
Granted, this machine is shared with many other tools.]]>Daniel Pitts2012-05-11T01:50:19-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178037&th=122650#msg_178037
> On 5/10/12 4:35 PM, Jerry Stuckle wrote:
>> On 5/10/2012 5:29 PM, Daniel Pitts wrote:
>>> On 5/10/12 2:05 PM, Jerry Stuckle wrote:
>>>> On 5/10/2012 4:15 PM, Daniel Pitts wrote:
>>>> > On 5/9/12 8:53 PM, Jerry Stuckle wrote:
>>>> >> On 5/9/2012 6:28 PM, Daniel Pitts wrote:
>>>> >>> On 5/9/12 3:19 PM, Michael Fesser wrote:
>>>> >>>> .oO(Jerry Stuckle)
>>>> >>>>
>>>> >>>>> On 5/8/2012 4:25 PM, Michael Fesser wrote:
>>>> >>>>>> .oO(Jerry Stuckle)
>>>> >>>>>>
>>>> >>>>>>> On 5/7/2012 11:37 PM, Daniel Pitts wrote:
>>>> >>>>>>>> Exactly true, but if you scale to sizes you don't need, you
>>>> >>>>>>>> indeed
>>>> >>>>>>>> use
>>>> >>>>>>>> more processor time! Our disk space is definitely not the
>>>> >>>>>>>> bottleneck.
>>>> >>>>>>>
>>>> >>>>>>> And if you repeatedly rescale the same image to the same size,
>>>> >>>>>>> you're
>>>> >>>>>>> using even more processor time!
>>>> >>>>>>
>>>> >>>>>> You missed the word 'caching'. You rescale when needed, and only
>>>> >>>>>> once.
>>>> >>>>>
>>>> >>>>> No, I didn't. By definition, caching is temporary storage which
>>>> >>>>> can be
>>>> >>>>> erased at any time.
>>>> >>>>
>>>> >>>> Correct. And then the rescaled images are created again when
>>>> >>>> needed, so
>>>> >>>> what's the problem? It all happens automatically.
>>>> >>>>
>>>> >>>> Micha
>>>> >>>>
>>>> >>>
>>>> >>> Caching needn't be temporary, and you can ensure it isn't "erased at
>>>> >>> any
>>>> >>> time" by just not erasing the "cache". There are many different
>>>> >>> types of
>>>> >>> "cache".
>>>> >>
>>>> >> By definition a cache is temporary.
>>>> >>
>>>> > Whose definition?
>>>> > According to <http://www.thefreedictionary.com/cache>
>>>> >
>>>> > 1. "A collection of items of the same type stored in a hidden or
>>>> > inaccessible place."
>>>> > 2. Computer Science: A fast storage buffer in the central processing
>>>> > unit of a computer. Also called cache memory.
>>>> >
>>>> > That doesn't define it as temporary. Perhaps you're mistaking your
>>>> > understanding of the concept with reality. Reality wins over your
>>>> > understanding.
>>>> >
>>>> > Anyway, I've had enough fun arguing with an obvious "expert" in this
>>>> > field. Enjoy being "right" on the internet.
>>>> >
>>>> > Good day,
>>>> > Daniel.
>>>>
>>>> And you obviously don't understand what you're reading.
>>>>
>>>> Since when is "memory" permanent? I thought that's why we had hard
>>>> drives. And I don't see any thing in your definition about hard drives.
>>>>
>>> So, lets take a step back here.
>>>
>>> Forget the word caching, and your misunderstanding of it altogether.
>>>
>>> A system which will resize an image on-demand, and store the resize
>>> image for later retrieval is more efficient than one that will create
>>> all known previous sizes and then reprocessing all old images as new
>>> requirements are introduced.
>>>
>>>
>>
>> I do not misunderstand caching. Just because YOU have no idea what
>> you're talking about doesn't mean anyone else doesn't.
> I have some idea, as I actually work on such a system. You seem to have
> little real-world experience, as you seem to think that one solution
> suits all
I have over 40 years of "real world experience", including 13 with IBM
and 22 as a consultant. I suspect I was programming before you were born.
>>
>> And a system which creates all the images once so it doesn't have to
>> keep needlessly checking to see if an image exists or not is more
>> efficient than one which constantly has to see if something exists or
>> not.
> Whatever is serving your static content must check if it exists or not.
> You can hook into the "or-not" case, which happens only once per image
> per size that is *actually* used.
It's a simple file load from Apache. No additional application
programming required. And, being a compiled program, it's quite fast.
With your way, Apache has to load a PHP script (same process as I just
referenced). But then it has to start call the PHP module to establish
the PHP environment, interpret the script, execute the script, which
then has to check to see if the file exists or not. Much more
processing than above, and it has to be done on every request.
Or, let Apache try to load the file. If the load fails, call the 404
error handler (more overhead) which then has to go through all the
processing to load an execute a PHP file (as noted above) then resizing
the image.
Either way there is significantly more overhead than resizing once and
forgetting it. But you don't seem to understand that.
>>
>> Resizing is done ONCE. Checking has to be done on EVERY REQUEST.
> Checking has to be done on every request regardless. This is not an
> extra step.
>
See above. If the file exists, Apache can handle it directly.
>> But then you're got your mind made up. After all, it would take "months"
>> for you to resize your images.
> Months may have been a slight exaggeration, but it does take more than a
> few days to resize every possible image.
>
Even days is an exaggeration if you get rid of your TRS-80. You
obviously have NO IDEA how long anything would take. You're just
guessing (again).
>> A good system can resize several hundred images a second. At most we're
>> taking a few hours to do 7.5M images, even if they are high-res. But
>> your TRS-80's may only be able to do one a second.
> It is still easier to set up this lazy-loading once, than to have to run
> a "few hours" of scripts every time requirements change. The site will
> perform well enough (storing the resized images permanently, plus having
> edge cache in front of them). Why waste an engineers time running such a
> script (which is more expensive than CPU time needed to handle the lazy
> resizing).
>
You've got it. It's easier to set up the lazy-loading. It takes actual
skill to be able to write a script which will resize all the images for you.
> The actual hardware in question is a "Compaq DL385 G6"
>
> CPU: 12 x 2200 MHz Six-Core AMD Opteron 2427, 512 KB cache
> Memory: 64461MB
>
> Granted, this machine is shared with many other tools.
>
If that actually were your system, then it should take nowhere near 12
days to process 7.5M images. But you don't know - you're still guessing
because you don't have the skills to figure out how to resize the images
from a script.
But we know all you've got is your trusty TRS-80.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. jstucklex@attglobal.net
==================]]>Jerry Stuckle2012-05-11T02:22:51-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178044&th=122650#msg_178044
> 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]]>Michael Fesser2012-05-11T09:58:50-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178046&th=122650#msg_178046
> .oO(Jerry Stuckle)
>
>> And a system which creates all the images once so it doesn't have to
>> keep needlessly checking to see if an image exists or not is more
>> efficient than one which constantly has to see if something exists or not.
>>
>> Resizing is done ONCE.
>
> Right.
>
>> Checking has to be done on EVERY REQUEST.
>
> Wrong.
>
> Micha
>
You really have no idea what you're talking about, do you? But you'll
argue it anyway.
After all - you think there's no overhead in 404 processing!
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. jstucklex@attglobal.net
==================]]>Jerry Stuckle2012-05-11T10:51:36-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178050&th=122650#msg_178050
> .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.]]>The Natural Philosoph2012-05-11T13:01:05-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178056&th=122650#msg_178056
> Michael Fesser wrote:
>> .oO(Jerry Stuckle)
>>
>>> And a system which creates all the images once so it doesn't have to
>>> keep needlessly checking to see if an image exists or not is more
>>> efficient than one which constantly has to see if something exists or
>>> not.
>>>
>>> Resizing is done ONCE.
>>
>> Right.
>>
>>> Checking has to be done on EVERY REQUEST.
>>
>> Wrong.
>
> depends what you meean by checking: if the code goes
>
> load scaled image
> if fail
> rescale master image
> store scaled copy
> send scaled image
>
> then the only overhead is to check for failure of a load operation, but
> I don't see how you can get around that,
>
> You have to go to the database or the disk anyway to get the file, so
> its hardly an overhead to check if it fails.
>
>
>
Loading the script, starting the scripting module, initializing the
environment, interpreting and running the script, checking for the
presence of the image, storing a resized script if necessary, loading
the image and sending it, and cleaning up the environment.
This vs. sending the image directly via an <img ...> tag.
Nope, no extra overhead! And no way to send the image without a script!
>>
>> Micha
>>
>
>
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. jstucklex@attglobal.net
==================]]>Jerry Stuckle2012-05-11T14:34:22-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178057&th=122650#msg_178057
> 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*]]>Daniel Pitts2012-05-11T17:03:54-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178058&th=122650#msg_178058
> On 5/10/12 7:22 PM, Jerry Stuckle wrote:
>> On 5/10/2012 9:50 PM, Daniel Pitts wrote:
>>> On 5/10/12 4:35 PM, Jerry Stuckle wrote:
>>>> On 5/10/2012 5:29 PM, Daniel Pitts wrote:
>>>> > On 5/10/12 2:05 PM, Jerry Stuckle wrote:
>>>> >> On 5/10/2012 4:15 PM, Daniel Pitts wrote:
>>>> >>> On 5/9/12 8:53 PM, Jerry Stuckle wrote:
>>>> >>>> On 5/9/2012 6:28 PM, Daniel Pitts wrote:
>>>> >>>>> On 5/9/12 3:19 PM, Michael Fesser wrote:
>>>> >>>>>> .oO(Jerry Stuckle)
>>>> >>>>>>
>>>> >>>>>>> On 5/8/2012 4:25 PM, Michael Fesser wrote:
>>>> >>>>>>>> .oO(Jerry Stuckle)
>>>> >>>>>>>>
>>>> >>>>>>>>> On 5/7/2012 11:37 PM, Daniel Pitts wrote:
>>>> >>>>>>>>>> Exactly true, but if you scale to sizes you don't need, you
>>>> >>>>>>>>>> indeed
>>>> >>>>>>>>>> use
>>>> >>>>>>>>>> more processor time! Our disk space is definitely not the
>>>> >>>>>>>>>> bottleneck.
>>>> >>>>>>>>>
>>>> >>>>>>>>> And if you repeatedly rescale the same image to the same size,
>>>> >>>>>>>>> you're
>>>> >>>>>>>>> using even more processor time!
>>>> >>>>>>>>
>>>> >>>>>>>> You missed the word 'caching'. You rescale when needed, and
>>>> >>>>>>>> only
>>>> >>>>>>>> once.
>>>> >>>>>>>
>>>> >>>>>>> No, I didn't. By definition, caching is temporary storage which
>>>> >>>>>>> can be
>>>> >>>>>>> erased at any time.
>>>> >>>>>>
>>>> >>>>>> Correct. And then the rescaled images are created again when
>>>> >>>>>> needed, so
>>>> >>>>>> what's the problem? It all happens automatically.
>>>> >>>>>>
>>>> >>>>>> Micha
>>>> >>>>>>
>>>> >>>>>
>>>> >>>>> Caching needn't be temporary, and you can ensure it isn't
>>>> >>>>> "erased at
>>>> >>>>> any
>>>> >>>>> time" by just not erasing the "cache". There are many different
>>>> >>>>> types of
>>>> >>>>> "cache".
>>>> >>>>
>>>> >>>> By definition a cache is temporary.
>>>> >>>>
>>>> >>> Whose definition?
>>>> >>> According to <http://www.thefreedictionary.com/cache>
>>>> >>>
>>>> >>> 1. "A collection of items of the same type stored in a hidden or
>>>> >>> inaccessible place."
>>>> >>> 2. Computer Science: A fast storage buffer in the central processing
>>>> >>> unit of a computer. Also called cache memory.
>>>> >>>
>>>> >>> That doesn't define it as temporary. Perhaps you're mistaking your
>>>> >>> understanding of the concept with reality. Reality wins over your
>>>> >>> understanding.
>>>> >>>
>>>> >>> Anyway, I've had enough fun arguing with an obvious "expert" in this
>>>> >>> field. Enjoy being "right" on the internet.
>>>> >>>
>>>> >>> Good day,
>>>> >>> Daniel.
>>>> >>
>>>> >> And you obviously don't understand what you're reading.
>>>> >>
>>>> >> Since when is "memory" permanent? I thought that's why we had hard
>>>> >> drives. And I don't see any thing in your definition about hard
>>>> >> drives.
>>>> >>
>>>> > So, lets take a step back here.
>>>> >
>>>> > Forget the word caching, and your misunderstanding of it altogether.
>>>> >
>>>> > A system which will resize an image on-demand, and store the resize
>>>> > image for later retrieval is more efficient than one that will create
>>>> > all known previous sizes and then reprocessing all old images as new
>>>> > requirements are introduced.
>>>> >
>>>> >
>>>>
>>>> I do not misunderstand caching. Just because YOU have no idea what
>>>> you're talking about doesn't mean anyone else doesn't.
>>> I have some idea, as I actually work on such a system. You seem to have
>>> little real-world experience, as you seem to think that one solution
>>> suits all
>>
>> I have over 40 years of "real world experience", including 13 with IBM
>> and 22 as a consultant. I suspect I was programming before you were born.
>>
>>>>
>>>> And a system which creates all the images once so it doesn't have to
>>>> keep needlessly checking to see if an image exists or not is more
>>>> efficient than one which constantly has to see if something exists or
>>>> not.
>>> Whatever is serving your static content must check if it exists or not.
>>> You can hook into the "or-not" case, which happens only once per image
>>> per size that is *actually* used.
>>
>> It's a simple file load from Apache. No additional application
>> programming required. And, being a compiled program, it's quite fast.
>>
>> With your way, Apache has to load a PHP script (same process as I just
>> referenced). But then it has to start call the PHP module to establish
>> the PHP environment, interpret the script, execute the script, which
>> then has to check to see if the file exists or not. Much more processing
>> than above, and it has to be done on every request.
>>
>> Or, let Apache try to load the file. If the load fails, call the 404
>> error handler (more overhead) which then has to go through all the
>> processing to load an execute a PHP file (as noted above) then resizing
>> the image.
>>
>> Either way there is significantly more overhead than resizing once and
>> forgetting it. But you don't seem to understand that.
>>
>>>>
>>>> Resizing is done ONCE. Checking has to be done on EVERY REQUEST.
>>> Checking has to be done on every request regardless. This is not an
>>> extra step.
>>>
>>
>> See above. If the file exists, Apache can handle it directly.
>>
>>>> But then you're got your mind made up. After all, it would take
>>>> "months"
>>>> for you to resize your images.
>>> Months may have been a slight exaggeration, but it does take more than a
>>> few days to resize every possible image.
>>>
>>
>> Even days is an exaggeration if you get rid of your TRS-80. You
>> obviously have NO IDEA how long anything would take. You're just
>> guessing (again).
>>
>>>> A good system can resize several hundred images a second. At most we're
>>>> taking a few hours to do 7.5M images, even if they are high-res. But
>>>> your TRS-80's may only be able to do one a second.
>>> It is still easier to set up this lazy-loading once, than to have to run
>>> a "few hours" of scripts every time requirements change. The site will
>>> perform well enough (storing the resized images permanently, plus having
>>> edge cache in front of them). Why waste an engineers time running such a
>>> script (which is more expensive than CPU time needed to handle the lazy
>>> resizing).
>>>
>>
>> You've got it. It's easier to set up the lazy-loading. It takes actual
>> skill to be able to write a script which will resize all the images for
>> you.
> Ad hominem attacks huh? You have no idea of my skill level, and have yet
> to prove yours.
>
> I did a little digging into the history of this newsgroup. I didn't
> realize you were the resident troll, and was trying to use reason with
> you. It's been fun sparing with you, but you have proven to me that you
> have no interest in facts and reason.
>
> *plonk*
>
Just responding to your comment about my having no experience. But then
like all trolls, you can dish it out - but you can't take it.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. jstucklex@attglobal.net
==================]]>Jerry Stuckle2012-05-11T17:56:48-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178061&th=122650#msg_178061
>
> 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:
Greetings.]]>Shake2012-05-11T18:58:21-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178063&th=122650#msg_178063
> 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]]>Michael Fesser2012-05-11T19:11:07-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178064&th=122650#msg_178064
> .oO(Jerry Stuckle)
>
>> On 5/11/2012 5:58 AM, Michael Fesser wrote:
>>> .oO(Jerry Stuckle)
>>>
>>>> And a system which creates all the images once so it doesn't have to
>>>> keep needlessly checking to see if an image exists or not is more
>>>> efficient than one which constantly has to see if something exists or not.
>>>>
>>>> Resizing is done ONCE.
>>>
>>> Right.
>>>
>>>> Checking has to be done on EVERY REQUEST.
>>>
>>> Wrong.
>>>
>>> Micha
>>>
>>
>> You really have no idea what you're talking about, do you? But you'll
>> argue it anyway.
>
> You still miss the point (or just don't want to accept it, as usual). If
> there's a static image file, there is absolutely no additional checking
> for existance necessary (besides the one that has to be done for every
> resource the server wishes to deliver, but this doesn't matter here).
>
> If the file is there, it will be delivered as-is, if not, it triggers a
> 404 (which could then create the requested resource on demand). That's
> the same for every static HTML or CSS file, so your claim from above
> "Checking has to be done on EVERY REQUEST" is simply wrong.
>
>> After all - you think there's no overhead in 404 processing!
>
> A little maybe, but I don't think it really matters. What much has the
> server to do after it didn't find the requested resource? Deliver
> another page or call a script. I can't think of much more, except maybe
> a second log entry. The typical redirects from http://example.com/foo to
> http://example.com/foo/, which are still seen on many sites, are much
> more expensive.
>
> Micha
>
No, you don't get it. A 404 causes even more overhead - Apache has to
detect the 404, determine which is the correct error page to load, and
load it. In this case it's a PHP file, so the PHP module has to be
loaded and the environment initialized, etc.
Then the PHP code needs to determine if it is even a request for an
image, and if the image can be found and resized. If so, the code must
resize the image and send it. Then the module cleanup has to be performed.
Plus, depending on what the sysadmin has installed for Apache
extensions, other modules may be called in the process.
That's a lot of overhead, especially when you know the images and the
sizes you need ahead of time.
It's fine if you're running 200 hits/day, but not in a busy server.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. jstucklex@attglobal.net
==================]]>Jerry Stuckle2012-05-11T19:29:19-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178065&th=122650#msg_178065
> 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@attglobal.net
==================]]>Jerry Stuckle2012-05-11T19:30:03-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178066&th=122650#msg_178066
> 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.]]>Shake2012-05-11T19:46:46-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178068&th=122650#msg_178068
> 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 ....]]>Luuk2012-05-11T19:53:13-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178067&th=122650#msg_178067
> 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]]>Michael Fesser2012-05-11T19:53:27-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178069&th=122650#msg_178069
> .oO(Jerry Stuckle)
>
>> On 5/11/2012 3:11 PM, Michael Fesser wrote:
>>>
>>> A little maybe, but I don't think it really matters. What much has the
>>> server to do after it didn't find the requested resource? Deliver
>>> another page or call a script. I can't think of much more, except maybe
>>> a second log entry. The typical redirects from http://example.com/foo to
>>> http://example.com/foo/, which are still seen on many sites, are much
>>> more expensive.
>>
>> No, you don't get it. A 404 causes even more overhead - Apache has to
>> detect the 404
>
> Happens all the time for every single resource.
>
Nope. A static page is served up immediately. No 404 processing
required. Even a PHP page is served up with less overhead than a PHP
page with 404 processing.
404 is not cheap, and can be quite expensive (relatively) if there are a
number of optional modules loaded.
>> , determine which is the correct error page to load
>
> Which is defined in the server configuration.
>
And has to be found in the configuration - not required when the
resource is found.
>> and
>> load it.
>
> Happens all the time for every single resource.
>
Two loads - one failed attempt for the missing resource and a second
successful attempt once it figures out which page has to be loaded.
>> In this case it's a PHP file, so the PHP module has to be
>> loaded and the environment initialized, etc.
>
> On a site using PHP the module is already there and ready to work.
>
Maybe, maybe not. It depends on the server. But even if it is loaded,
it still has to be attached to the thread or process, the environment
initialized.
>> Then the PHP code needs to determine if it is even a request for an
>> image, and if the image can be found and resized. If so, the code must
>> resize the image and send it.
>
> That's the only additional work, once per image. So what?
>
Completely unnecessary work, but ok if your site only has 200 hits per day.
>> Then the module cleanup has to be performed.
>
> Nope, the module stays there. There's just the usual cleanup as for
> every other PHP page.
>
The module must still perform cleanup after the script terminates.
>> Plus, depending on what the sysadmin has installed for Apache
>> extensions, other modules may be called in the process.
>
> Possible, but rather unlikely and irrelevant.
>
Not at all unlikely nor irrelevant.
>> That's a lot of overhead, especially when you know the images and the
>> sizes you need ahead of time.
>>
>> It's fine if you're running 200 hits/day, but not in a busy server.
>
> After a short period of time all most requested images are there.
> Creating another missing image every now and then won't bring a server
> to its knees.
>
> Micha
>
Creating them once with a script means the images are there from the start.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. jstucklex@attglobal.net
==================]]>Jerry Stuckle2012-05-11T22:11:49-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178070&th=122650#msg_178070
> 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@attglobal.net
==================]]>Jerry Stuckle2012-05-11T22:14:25-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178071&th=122650#msg_178071
> 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@attglobal.net
==================]]>Jerry Stuckle2012-05-11T22:15:46-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178072&th=122650#msg_178072
> 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]]>Michael Fesser2012-05-11T23:00:02-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178073&th=122650#msg_178073
> .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.]]>The Natural Philosoph2012-05-11T23:36:16-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178074&th=122650#msg_178074
> 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.]]>The Natural Philosoph2012-05-11T23:38:06-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178075&th=122650#msg_178075
> .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.]]>The Natural Philosoph2012-05-11T23:38:52-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178076&th=122650#msg_178076
> 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.]]>The Natural Philosoph2012-05-11T23:40:08-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178077&th=122650#msg_178077
> .oO(Jerry Stuckle)
>
>> On 5/11/2012 3:53 PM, Michael Fesser wrote:
>>> .oO(Jerry Stuckle)
>>>
>>>> On 5/11/2012 3:11 PM, Michael Fesser wrote:
>>>> >
>>>> > A little maybe, but I don't think it really matters. What much has the
>>>> > server to do after it didn't find the requested resource? Deliver
>>>> > another page or call a script. I can't think of much more, except maybe
>>>> > a second log entry. The typical redirects from http://example.com/foo to
>>>> > http://example.com/foo/, which are still seen on many sites, are much
>>>> > more expensive.
>>>>
>>>> No, you don't get it. A 404 causes even more overhead - Apache has to
>>>> detect the 404
>>>
>>> Happens all the time for every single resource.
>>>
>>
>> Nope. A static page is served up immediately.
>
> But the server always has to check if it's there. How else could he
> deliver it?
>
> And if a previous 404 causes an image file to be created - from that
> time on it will also be "served up immediately". The overhead for that
> single image happens exactly one time. That's nothing to worry about.
>
Not a problem when you're doing 200 hits/day.
>>> Which is defined in the server configuration.
>>
>> And has to be found in the configuration - not required when the
>> resource is found.
>
> The configuration is loaded before and the handlers are defined.
> It's just one function call or another (more or less):
>
> if (resourceIsFound()) {
> sendResource();
> } else {
> sendErrorDocument();
> }
>
You really think that's all there is to it? ROFLMAO!
What does resourceIsFound() do? What does sendErrorDocument() do? A
lot more than just a simple C function call!
>>>> In this case it's a PHP file, so the PHP module has to be
>>>> loaded and the environment initialized, etc.
>>>
>>> On a site using PHP the module is already there and ready to work.
>>
>> Maybe, maybe not. It depends on the server. But even if it is loaded,
>> it still has to be attached to the thread or process, the environment
>> initialized.
>
> Like on every other PHP page.
>
Yes, and if the resource is found, no PHP page is required.
>>>> Then the PHP code needs to determine if it is even a request for an
>>>> image, and if the image can be found and resized. If so, the code must
>>>> resize the image and send it.
>>>
>>> That's the only additional work, once per image. So what?
>>
>> Completely unnecessary work, but ok if your site only has 200 hits per day.
>
> The work has to be done either way.
>
Not at all. It can be done once offline, instead of on the web server.
And doing a bunch of images offline is far more efficient than trying
to handle a 404.
> If you have 100.000 images and get 100.000 hits a day, each one for a
> different image, all the images are created on that single day and can
> be served directly from that time on. Only the first requester of a
> particular image might notice a little delay.
>
You've obviously never had a site which had 100,000 hits a day. I
suspect your sites never exceed 200 hits/day.
>>>> That's a lot of overhead, especially when you know the images and the
>>>> sizes you need ahead of time.
>>>>
>>>> It's fine if you're running 200 hits/day, but not in a busy server.
>>>
>>> After a short period of time all most requested images are there.
>>> Creating another missing image every now and then won't bring a server
>>> to its knees.
>>
>> Creating them once with a script means the images are there from the start.
>
> Which also takes a lot of time and creates images which might not be
> used at all.
>
Less time than creating them on the fly. Plus it's done offline and not
taking web server time.
> In short: These are two totally different approaches, but both have
> their uses and are reasonable. Doing it the "all-before-way" is OK, but
> so is the "on-demand-way". There's absolutely nothing wrong about the
> latter: The server load is almost the same, just spread across time.
>
> Micha
>
In short, you have no idea how to optimize even a slightly busy site.
Your approach works fine for your sites which never have more than 200
hits/day. It does not scale to an even moderately busy site.
I'm not in favor of premature optimization. However, I AM in favor of
not putting an unnecessary load on the web server. But then the sites I
deal with are moderately busy, also.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. jstucklex@attglobal.net
==================]]>Jerry Stuckle2012-05-12T00:44:16-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178078&th=122650#msg_178078
> 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@attglobal.net
==================]]>Jerry Stuckle2012-05-12T00:46:27-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178079&th=122650#msg_178079
> 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.
> ]]>Luuk2012-05-12T08:00:26-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178081&th=122650#msg_178081
> 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@attglobal.net
==================]]>Jerry Stuckle2012-05-12T11:29:41-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178082&th=122650#msg_178082
> 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.]]>Peter H. Coffin2012-05-12T11:47:41-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178083&th=122650#msg_178083
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]]>Shake2012-05-12T12:42:40-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178085&th=122650#msg_178085
> 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@attglobal.net
==================]]>Jerry Stuckle2012-05-12T15:04:49-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178086&th=122650#msg_178086
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.]]>Shake2012-05-12T16:40:26-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178087&th=122650#msg_178087
> 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@attglobal.net
==================]]>Jerry Stuckle2012-05-12T19:49:32-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178090&th=122650#msg_178090
> 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.]]>The Natural Philosoph2012-05-12T21:59:08-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178091&th=122650#msg_178091
> You need to get some better computers.
NOT. Only if I try to batch. On-the-fly everything goes well. SO
on-the-fly works better.
Batch requieres a lot of cpu and space to do all the work, On-the-fly
requires a little amount of cpu and space diluted in the normal server
work.
Greetings]]>Shake2012-05-13T11:46:06-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178092&th=122650#msg_178092
> Apr?s m?re r?flexion, Jerry Stuckle a ?crit :
>
>> You need to get some better computers.
>
> NOT. Only if I try to batch. On-the-fly everything goes well. SO
> on-the-fly works better.
>
> Batch requieres a lot of cpu and space to do all the work, On-the-fly
> requires a little amount of cpu and space diluted in the normal server
> work.
'cause it takes SO MUCH LONGER to resize images on a computer that's
doing nothing but resize images than it does on a computer that's also
trying to answer http requests on a timely basis. Though I suppose it
would make a certain amount of sense if no one ever visited the website.
Then, you'd never need the images.
--
41. Once my power is secure, I will destroy all those pesky time-travel
devices.
--Peter Anspach's list of things to do as an Evil Overlord]]>Peter H. Coffin2012-05-13T12:50:49-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178093&th=122650#msg_178093
> Après mûre réflexion, Jerry Stuckle a écrit :
>
>> You need to get some better computers.
>
> NOT. Only if I try to batch. On-the-fly everything goes well. SO
> on-the-fly works better.
>
> Batch requieres a lot of cpu and space to do all the work, On-the-fly
> requires a little amount of cpu and space diluted in the normal server
> work.
>
> Greetings
>
>
You aren't making any sense. Why would it take a server which is doing
more important things LESS time and resources to do the same job as
another machine not doing anything.
The answer is, it doesn't. In fact, overall, it takes the server MORE
time and resources to do the same job.
You have just shown you have absolutely no idea what load you're putting
on your server.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. jstucklex@attglobal.net
==================]]>Jerry Stuckle2012-05-13T13:06:39-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178094&th=122650#msg_178094
hellsop@ninehells.com> writes:
> 'cause it takes SO MUCH LONGER to resize images on a computer that's
> doing nothing but resize images than it does on a computer that's
> also trying to answer http requests on a timely basis.
Indeed it does, if you happen to have seven and a half million
images. I haven't followed this thread that m,uch, but ISTR that
figure being mentioned. Even if you had the hardware to resize 10
images a second, you are still looking at close to 10 days of
processing time. What do you propose to do in that period, when a
request for an image that has not yet been processed, arrives?
> Though I suppose it would make a certain amount of sense if no one
> ever visited the website. Then, you'd never need the images.
Ohh, the maturity of people in this group. It takes me back to my
kindergarten days :)
--
/Wegge
Leder efter redundant peering af dk.*,linux.debian.*]]>Anders Wegge Keller2012-05-13T14:15:37-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178095&th=122650#msg_178095
> "Peter H. Coffin"<hellsop@ninehells.com> writes:
>
>> 'cause it takes SO MUCH LONGER to resize images on a computer that's
>> doing nothing but resize images than it does on a computer that's
>> also trying to answer http requests on a timely basis.
>
> Indeed it does, if you happen to have seven and a half million
> images. I haven't followed this thread that m,uch, but ISTR that
> figure being mentioned. Even if you had the hardware to resize 10
> images a second, you are still looking at close to 10 days of
> processing time. What do you propose to do in that period, when a
> request for an image that has not yet been processed, arrives?
>
So you're going to force the server to waste its time resizing pages
instead of doing it's job (of serving web pages).
Of course, it's not a problem if you only bet 200 hits/day. But any
even moderately busy server has much better things to do.
>> Though I suppose it would make a certain amount of sense if no one
>> ever visited the website. Then, you'd never need the images.
>
> Ohh, the maturity of people in this group. It takes me back to my
> kindergarten days :)
>
He called it straight. I don't think anyone on this newsgroup has any
idea what an even moderately busy site is. They are amazed at 1M hits/ mo.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. jstucklex@attglobal.net
==================]]>Jerry Stuckle2012-05-13T14:36:55-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178096&th=122650#msg_178096
>
> You aren't making any sense. Why would it take a server which is doing more
> important things LESS time and resources to do the same job as another
> machine not doing anything.
This means you have to have two machines. At least.
>
> The answer is, it doesn't. In fact, overall, it takes the server MORE time
> and resources to do the same job.
But you have a server with MORE resources to do the job.
> You have just shown you have absolutely no idea what load you're putting on
> your server.
That's not true, simply you don't know which structure I had. And you
supposed I have a server doing all the job.
For generating little (thumbnails) images from other scaled image. The
resources used are really not so much. And the resources available by
the servers whre enought to do not change in a measurable way the time
delivering pages.
Tha fact is that having more machine more powerfull not doing nothing
else that reescaling images when required in batch proceses is a waste
of money and resources. In the other side, reescaling on the fly, of
course, implies some more process but not noticable.
Greetings]]>Shake2012-05-13T16:54:01-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178097&th=122650#msg_178097
> Jerry Stuckle a exposé le 13/05/2012 :
>>
>> You aren't making any sense. Why would it take a server which is doing
>> more important things LESS time and resources to do the same job as
>> another machine not doing anything.
>
> This means you have to have two machines. At least.
>
You need a development machine in addition to your server, anyway. Or
do you do development on a live system?
And anyone who has 7.5M images has more than one machine!
>>
>> The answer is, it doesn't. In fact, overall, it takes the server MORE
>> time and resources to do the same job.
>
> But you have a server with MORE resources to do the job.
>
And more work to do. Of course, if you're only getting 200 hit/day,
that's not a problem.
>> You have just shown you have absolutely no idea what load you're
>> putting on your server.
>
> That's not true, simply you don't know which structure I had. And you
> supposed I have a server doing all the job.
>
Oh, I understand. What do you think will happen when you get to 300
hits/day?
> For generating little (thumbnails) images from other scaled image. The
> resources used are really not so much. And the resources available by
> the servers whre enought to do not change in a measurable way the time
> delivering pages.
>
You really have no idea how many resources it takes, that's obvious.
But then when you're only getting 200 hits/day you can do anything on
your server.
> Tha fact is that having more machine more powerfull not doing nothing
> else that reescaling images when required in batch proceses is a waste
> of money and resources. In the other side, reescaling on the fly, of
> course, implies some more process but not noticable.
>
> Greetings
>
>
The fact is, forcing a server with more important things to do to
rescale images is a complete waste of money and resources. But when you
only get 200 hits/day you have the resources to waste.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. jstucklex@attglobal.net
==================]]>Jerry Stuckle2012-05-13T17:27:53-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178099&th=122650#msg_178099
> Jerry Stuckle a expos? le 13/05/2012 :
>
>> You aren't making any sense. Why would it take a server which is
>> doing more important things LESS time and resources to do the same
>> job as another machine not doing anything.
>
> This means you have to have two machines. At least.
Yes. Of course. That's what real websites do. They have multiple
webserver that JUST serve page data to the outside world. They have
a dedicated database machine. Usually at least two of those, some
accessable by the webservers, some not accessable from the outside at
all except through the sync connections to the outside db server. They
have at least one development server and a separate test server, for
website development alone. Other departments have their own machines as
well. What did you think we were talking about? Some little toy website
selling railroad models at a rate of three or four wagons a week?
--
The pluses in my current job include laughing in the face of Nobel
laureates who have just lost the only copy of their data. (Hey,
I'm still a BOFH).
-- Bob Dowling]]>Peter H. Coffin2012-05-14T03:26:24-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178105&th=122650#msg_178105
> On Sun, 13 May 2012 18:54:01 +0200, Shake wrote:
>
>> Jerry Stuckle a expos? le 13/05/2012 :
>>
>>> You aren't making any sense. Why would it take a server which is
>>> doing more important things LESS time and resources to do the same
>>> job as another machine not doing anything.
>>
>> This means you have to have two machines. At least.
>
> Yes. Of course. That's what real websites do.
I was talking about the "server" like an entity, not entering on how
these one is "phisicaly".
For example the website I put as example, have two balanced front-ends
with php and apache, and two other machines with mysql, sphinx and a few
other servers. Images are on Amazon S3, and also we used (use) some ec2
machines.
But for me all this stuff is "the server". And to batch the image
scalating we are talking about using another "machine". For example the
machines for developers, or testing. They, of course, ar not powerful
machines. Don't need to be.
And I put numbers, about 266.000 page views per day. I am talking about
a real case. Not teorethical. And we tried both methods, batching and
on-the-fly.
And the result is: On the fly is more flexible, more quick to put on
production new sizes. And it have to be used when images are not so big.
If we have to scale the originals to a big size, on the fly could be a
big problem. The true is that always is a problem in any manner when you
have to scale to big sizes.
But when you need a new little image size, and you can use the nearest
bigger scaled image, process is quick enough to do on-the-fly without
penalizing speed, or overload on the server.
Greetings]]>Shake2012-05-14T07:51:24-00:00Re: Windows binaries 64bit for PHP
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=178111&th=122650#msg_178111
> El 14/05/2012 5:26, Peter H. Coffin escribió:
>> On Sun, 13 May 2012 18:54:01 +0200, Shake wrote:
>>
>>> Jerry Stuckle a expos? le 13/05/2012 :
>>>
>>>> You aren't making any sense. Why would it take a server which is
>>>> doing more important things LESS time and resources to do the same
>>>> job as another machine not doing anything.
>>>
>>> This means you have to have two machines. At least.
>>
>> Yes. Of course. That's what real websites do.
>
> I was talking about the "server" like an entity, not entering on how
> these one is "phisicaly".
>
> For example the website I put as example, have two balanced front-ends
> with php and apache, and two other machines with mysql, sphinx and a few
> other servers. Images are on Amazon S3, and also we used (use) some ec2
> machines.
>
> But for me all this stuff is "the server". And to batch the image
> scalating we are talking about using another "machine". For example the
> machines for developers, or testing. They, of course, ar not powerful
> machines. Don't need to be.
>
> And I put numbers, about 266.000 page views per day. I am talking about
> a real case. Not teorethical. And we tried both methods, batching and
> on-the-fly.
>
> And the result is: On the fly is more flexible, more quick to put on
> production new sizes. And it have to be used when images are not so big.
>
> If we have to scale the originals to a big size, on the fly could be a
> big problem. The true is that always is a problem in any manner when you
> have to scale to big sizes.
>
> But when you need a new little image size, and you can use the nearest
> bigger scaled image, process is quick enough to do on-the-fly without
> penalizing speed, or overload on the server.
>
> Greetings
You can do that when you have such a light load. Get a real load and
you're in trouble.
But even with that, you should be resizing offline and not requiring the
server to do it.
But it sounds like you're too cheap to get your developers decent
machines, and have no idea how to scale images. The "nearest bigger
scaled image" will almost certainly give a substandard image, especially
when you repeatedly rescale them.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. jstucklex@attglobal.net
==================]]>Jerry Stuckle2012-05-14T12:04:38-00:00