| Re: Windows binaries 64bit for PHP [message #177989] |
Thu, 10 May 2012 03:52  |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/9/2012 6:23 PM, Michael Fesser wrote:
> .oO(Jerry Stuckle)
>
>> OK, so you do it "on the fly" and store the result. That still takes
>> more time than doing it once and forgetting it. Your way, you have to
>> check on every request for the image to see if your size exists before
>> deciding if you need to rescale it or not. Another unnecessary waste of
>> processing time.
>
> You can catch that with Apache's error handling. If the image is not
> found, the 404 error handler kicks in and creates it.
>
> Micha
>
Which is even more overhead...
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #177992 is a reply to message #177989] |
Thu, 10 May 2012 06:50  |
Michael Fesser
Messages: 215
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
.oO(Jerry Stuckle)
> On 5/9/2012 6:23 PM, Michael Fesser wrote:
>> .oO(Jerry Stuckle)
>>
>>> OK, so you do it "on the fly" and store the result. That still takes
>>> more time than doing it once and forgetting it. Your way, you have to
>>> check on every request for the image to see if your size exists before
>>> deciding if you need to rescale it or not. Another unnecessary waste of
>>> processing time.
>>
>> You can catch that with Apache's error handling. If the image is not
>> found, the 404 error handler kicks in and creates it.
>>
>> Micha
>>
>
> Which is even more overhead...
Wrong. The little overhead happens just once if the image doesn't exist
yet. After then it's just a static resource, which will be delivered
directly by the server.
Micha
--
http://mfesser.de/blickwinkel
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #177996 is a reply to message #177992] |
Thu, 10 May 2012 12:01 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/10/2012 2:50 AM, Michael Fesser wrote:
> .oO(Jerry Stuckle)
>
>> On 5/9/2012 6:23 PM, Michael Fesser wrote:
>>> .oO(Jerry Stuckle)
>>>
>>>> OK, so you do it "on the fly" and store the result. That still takes
>>>> more time than doing it once and forgetting it. Your way, you have to
>>>> check on every request for the image to see if your size exists before
>>>> deciding if you need to rescale it or not. Another unnecessary waste of
>>>> processing time.
>>>
>>> You can catch that with Apache's error handling. If the image is not
>>> found, the 404 error handler kicks in and creates it.
>>>
>>> Micha
>>>
>>
>> Which is even more overhead...
>
> Wrong. The little overhead happens just once if the image doesn't exist
> yet. After then it's just a static resource, which will be delivered
> directly by the server.
>
> Micha
>
Have you actually checked how much overhead there is to process a not
found? It is quite significant.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178020 is a reply to message #177996] |
Thu, 10 May 2012 19:01 |
Michael Fesser
Messages: 215
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
.oO(Jerry Stuckle)
> On 5/10/2012 2:50 AM, Michael Fesser wrote:
>> .oO(Jerry Stuckle)
>>
>>> On 5/9/2012 6:23 PM, Michael Fesser wrote:
>>>> .oO(Jerry Stuckle)
>>>>
>>>> > OK, so you do it "on the fly" and store the result. That still takes
>>>> > more time than doing it once and forgetting it. Your way, you have to
>>>> > check on every request for the image to see if your size exists before
>>>> > deciding if you need to rescale it or not. Another unnecessary waste of
>>>> > processing time.
>>>>
>>>> You can catch that with Apache's error handling. If the image is not
>>>> found, the 404 error handler kicks in and creates it.
>>>>
>>>> Micha
>>>>
>>>
>>> Which is even more overhead...
>>
>> Wrong. The little overhead happens just once if the image doesn't exist
>> yet. After then it's just a static resource, which will be delivered
>> directly by the server.
>
> Have you actually checked how much overhead there is to process a not
> found? It is quite significant.
Even if - how often does it happen? Exactly once for every image. So
where's the problem?
In many other cases the first request causes a lot of overhead as well,
be it the initial compiling of a PHP script or the downloading of a
static resource to the client. The first request always takes the most
time. After then the data is taken from some kind of cache. And here
it's exactly the same - on the first request the image is created, after
then it's a normal static resource. In practice there's absolutely no
problem with that and no wasted CPU time.
Micha
--
http://mfesser.de/blickwinkel
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178022 is a reply to message #178020] |
Thu, 10 May 2012 19:12 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/10/2012 3:01 PM, Michael Fesser wrote:
> .oO(Jerry Stuckle)
>
>> On 5/10/2012 2:50 AM, Michael Fesser wrote:
>>> .oO(Jerry Stuckle)
>>>
>>>> On 5/9/2012 6:23 PM, Michael Fesser wrote:
>>>> > .oO(Jerry Stuckle)
>>>> >
>>>> >> OK, so you do it "on the fly" and store the result. That still takes
>>>> >> more time than doing it once and forgetting it. Your way, you have to
>>>> >> check on every request for the image to see if your size exists before
>>>> >> deciding if you need to rescale it or not. Another unnecessary waste of
>>>> >> processing time.
>>>> >
>>>> > You can catch that with Apache's error handling. If the image is not
>>>> > found, the 404 error handler kicks in and creates it.
>>>> >
>>>> > Micha
>>>> >
>>>>
>>>> Which is even more overhead...
>>>
>>> Wrong. The little overhead happens just once if the image doesn't exist
>>> yet. After then it's just a static resource, which will be delivered
>>> directly by the server.
>>
>> Have you actually checked how much overhead there is to process a not
>> found? It is quite significant.
>
> Even if - how often does it happen? Exactly once for every image. So
> where's the problem?
>
> In many other cases the first request causes a lot of overhead as well,
> be it the initial compiling of a PHP script or the downloading of a
> static resource to the client. The first request always takes the most
> time. After then the data is taken from some kind of cache. And here
> it's exactly the same - on the first request the image is created, after
> then it's a normal static resource. In practice there's absolutely no
> problem with that and no wasted CPU time.
>
> Micha
>
And when you create the images one time, it's done ZERO times.
And no, the data isn't always taken from some kind of cache. It depends
on a lot of things. For instance, a PHP script is compiled every time
it's called unless the server can determine nothing has changed
(generally not the case) or you have installed additional PHP caching
software. Web servers do not cache compiled code, and neither does the
PHP module by itself.
Back to the subject at hand - every time the system has to handle a 404
there is wasted time. And it is a relatively significant amount of
time. Adding the necessity of resizing an image to that can be costly
on a busy server.
Of course, if all you get are 200 hits/day, it doesn't make any
difference how you code your scripts.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178045 is a reply to message #178043] |
Fri, 11 May 2012 10:50 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/11/2012 5:56 AM, Michael Fesser wrote:
> .oO(Jerry Stuckle)
>
>> Back to the subject at hand - every time the system has to handle a 404
>> there is wasted time. And it is a relatively significant amount of
>> time.
>
> After the image has been created, there won't be any 404s anymore. There
> will be just _one_ per image to trigger the rescaling.
>
> Micha
>
Yup, and with the 7.5M that images he claims he has, that's a lot of
wasted CPU.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178049 is a reply to message #178043] |
Fri, 11 May 2012 12:57 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Michael Fesser wrote:
> .oO(Jerry Stuckle)
>
>> Back to the subject at hand - every time the system has to handle a 404
>> there is wasted time. And it is a relatively significant amount of
>> time.
>
> After the image has been created, there won't be any 404s anymore. There
> will be just _one_ per image to trigger the rescaling.
>
you don't even have to have a 404. Use a php script to either load and
send the scaled page, or load rescale send and STORE the page.
> Micha
>
--
To people who know nothing, anything is possible.
To people who know too much, it is a sad fact
that they know how little is really possible -
and how hard it is to achieve it.
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178054 is a reply to message #178049] |
Fri, 11 May 2012 14:29 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/11/2012 8:57 AM, The Natural Philosopher wrote:
> Michael Fesser wrote:
>> .oO(Jerry Stuckle)
>>
>>> Back to the subject at hand - every time the system has to handle a
>>> 404 there is wasted time. And it is a relatively significant amount
>>> of time.
>>
>> After the image has been created, there won't be any 404s anymore. There
>> will be just _one_ per image to trigger the rescaling.
>>
>
> you don't even have to have a 404. Use a php script to either load and
> send the scaled page, or load rescale send and STORE the page.
>
>
>> Micha
>>
>
>
Which is even more processing!
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178059 is a reply to message #178049] |
Fri, 11 May 2012 18:32 |
Peter H. Coffin
Messages: 245
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Fri, 11 May 2012 13:57:50 +0100, The Natural Philosopher wrote:
> Michael Fesser wrote:
>> .oO(Jerry Stuckle)
>>
>>> Back to the subject at hand - every time the system has to handle a 404
>>> there is wasted time. And it is a relatively significant amount of
>>> time.
>>
>> After the image has been created, there won't be any 404s anymore. There
>> will be just _one_ per image to trigger the rescaling.
>>
>
> you don't even have to have a 404. Use a php script to either load and
> send the scaled page, or load rescale send and STORE the page.
I love it. (: OP's already resisted a proper build/rollout process as an
option anyway, let's build something that combines the *worst* of both
options...
--
"Every new technology carries with it an opportunity to invent a new
crime." --Laurence Urgenson (an assistant chief US attorney),
speaking in 1987 about the first arrests for what was later called
cellphone cloning.
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178062 is a reply to message #178059] |
Fri, 11 May 2012 19:01 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Peter H. Coffin wrote:
> On Fri, 11 May 2012 13:57:50 +0100, The Natural Philosopher wrote:
>> Michael Fesser wrote:
>>> .oO(Jerry Stuckle)
>>>
>>>> Back to the subject at hand - every time the system has to handle a 404
>>>> there is wasted time. And it is a relatively significant amount of
>>>> time.
>>> After the image has been created, there won't be any 404s anymore. There
>>> will be just _one_ per image to trigger the rescaling.
>>>
>> you don't even have to have a 404. Use a php script to either load and
>> send the scaled page, or load rescale send and STORE the page.
>
> I love it. (: OP's already resisted a proper build/rollout process as an
> option anyway, let's build something that combines the *worst* of both
> options...
>
not if you like your pikkies in a database...
--
To people who know nothing, anything is possible.
To people who know too much, it is a sad fact
that they know how little is really possible -
and how hard it is to achieve it.
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]