Windows binaries 64bit for PHP

[Dominique Ottello]

Hi,

ApacheLounge http://www.apachelounge.com/download/win64/
and MySQL http://www.mysql.com/downloads/mysql/5.5.html
gives us Windows 64 bit binaries for Apache and MySQL.

PHP does not do it!
Why? Could it be that complicated to compile for 32 AND 64 bit?

[J.O. Aho]

Why don't Microsoft do it? All the Linuxes and Unixes does that.

--

//Aho

[Dominique Ottello]

"J.O. Aho" <us...@example.net> écrivait :

> > PHP does not do it!
> > Why? Could it be that complicated to compile for 32 AND 64 bit?
>
> Why don't Microsoft do it? All the Linuxes and Unixes does that.

This is a typical response of Linux user who brings strictly no
explanation to my question.
Jesuit Response: You answer a question with another question.

Apache makes 64 bit binaries for Windows
MySQL makes 64 bit binaries for Windows
PHP does not.

[Arno Welzel]

Dominique Ottello, 06.05.2012 17:23:

Why do you need 64 bit binaries?


--
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

[Gregor Kofler]

Am 2012-05-06 17:23, Dominique Ottello meinte:

> "J.O. Aho"<us...@example.net> écrivait :
>
>>> PHP does not do it!
>>> Why? Could it be that complicated to compile for 32 AND 64 bit?

Perhaps not. But supposedly there is not enough demand for a 64 bit PHP
in the Windows world. Or they don't want to spend money on a compiler.
Ask them.

>> Why don't Microsoft do it? All the Linuxes and Unixes does that.
> This is a typical response of Linux user who brings strictly no
> explanation to my question.

I'm also a Linux chauvinist, however, I can turn to a search engine and
g**gle "windows php 5.4 64bit" and choose the second hit:

<http://www.anindya.com/php-5-4-0-x64-64-bit-for-windows/>

That was easy, wasn't it?

Gregor


--
http://vxweb.net

[Dominique Ottello]

Arno Welzel <use...@arnowelzel.de> écrivait :

> Why do you need 64 bit binaries?

Because 32 bit PHP binaries do not work with Apache 64 bit.

[Dominique Ottello]

Gregor Kofler <use...@gregorkofler.com> écrivait :

> <http://www.anindya.com/php-5-4-0-x64-64-bit-for-windows/>
>
> That was easy, wasn't it?

Oh yes ! I know. Anindya is my own source.
But the current PHP versions are 5.4.2 and 5.3.12
It will be a bit easier if PHP make them like Apache and MySQL.

[Arno Welzel]

Dominique Ottello, 06.05.2012 19:04:

> Arno Welzel <use...@arnowelzel.de> écrivait :
>
>> Why do you need 64 bit binaries?
> Because 32 bit PHP binaries do not work with Apache 64 bit.

Ok - why do you need 64 bit at all for a web server?

I run a web server for multiple domains with more than 1 mio hits in
total per month where about 50% are handled by an Apache PHP module. I
also use XCache and so far neither Apache nor XCache are getting to any
limit (XCache runs fine with 128 MB cache and only uses about 60-70 MB
of it and the whole system does not allocate more than about 1,5-1,8 GB
of RAM).

[The Natural Philosopher]

Arno Welzel wrote:
> Dominique Ottello, 06.05.2012 19:04:
>
>> Arno Welzel <use...@arnowelzel.de> écrivait :
>>
>>> Why do you need 64 bit binaries?
>> Because 32 bit PHP binaries do not work with Apache 64 bit.
>
> Ok - why do you need 64 bit at all for a web server?
>

helps a lot when rescaling images on the fly...

> I run a web server for multiple domains with more than 1 mio hits in
> total per month where about 50% are handled by an Apache PHP module. I
> also use XCache and so far neither Apache nor XCache are getting to any
> limit (XCache runs fine with 128 MB cache and only uses about 60-70 MB
> of it and the whole system does not allocate more than about 1,5-1,8 GB
> of RAM).
>
>
>


--

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.

[Jerry Stuckle]

On 5/7/2012 3:23 PM, The Natural Philosopher wrote:
> Arno Welzel wrote:
>> Dominique Ottello, 06.05.2012 19:04:
>>
>>> Arno Welzel <use...@arnowelzel.de> écrivait :
>>>
>>>> Why do you need 64 bit binaries?
>>> Because 32 bit PHP binaries do not work with Apache 64 bit.
>>
>> Ok - why do you need 64 bit at all for a web server?
>>
> helps a lot when rescaling images on the fly...
>
>
>> I run a web server for multiple domains with more than 1 mio hits in
>> total per month where about 50% are handled by an Apache PHP module. I
>> also use XCache and so far neither Apache nor XCache are getting to any
>> limit (XCache runs fine with 128 MB cache and only uses about 60-70 MB
>> of it and the whole system does not allocate more than about 1,5-1,8 GB
>> of RAM).
>>
>>
>>
>
>

Why would you repeatedly rescale images on the fly? You should know
what size you need for your pages and resize them once.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstu...@attglobal.net
==================

[Peter H. Coffin]

On Mon, 07 May 2012 20:23:24 +0100, The Natural Philosopher wrote:
> Arno Welzel wrote:
>> Dominique Ottello, 06.05.2012 19:04:
>>

>>> Arno Welzel <use...@arnowelzel.de> ??crivait :

>>>
>>>> Why do you need 64 bit binaries?
>>> Because 32 bit PHP binaries do not work with Apache 64 bit.
>>
>> Ok - why do you need 64 bit at all for a web server?
>>
> helps a lot when rescaling images on the fly...

Do you really do a lot of that, though? I mean, instead of pre-scaling
to a certain set number of sizes. Which seems more generally useful. If
you do, there's ways to handle that more rapidly and with less load than
the general purpose tools that PHP has wrappers for. EG: VIPS is
something like 4 times the speed at rescale than Gmagick.

--
I got told by a friend's ex-girlfriend that she could tell I was
a Linux geek from the way I *walked*.
-- Skud

[Daniel Pitts]

On 5/7/12 2:49 PM, Peter H. Coffin wrote:
> On Mon, 07 May 2012 20:23:24 +0100, The Natural Philosopher wrote:
>> Arno Welzel wrote:
>>> Dominique Ottello, 06.05.2012 19:04:
>>>
>>>> Arno Welzel<use...@arnowelzel.de> ??crivait :
>>>>
>>>>> Why do you need 64 bit binaries?
>>>> Because 32 bit PHP binaries do not work with Apache 64 bit.
>>>
>>> Ok - why do you need 64 bit at all for a web server?
>>>
>> helps a lot when rescaling images on the fly...
>
> Do you really do a lot of that, though? I mean, instead of pre-scaling
> to a certain set number of sizes. Which seems more generally useful. If
> you do, there's ways to handle that more rapidly and with less load than
> the general purpose tools that PHP has wrappers for. EG: VIPS is
> something like 4 times the speed at rescale than Gmagick.
>

I haven't been following this thread, but I'll talk about my personal
experience with image sizes.

My particular company has a huge catalog of images. Right now, we do
prescale the images to all the various sizes that might be needed, which
works alright except that our design department every once in a while
needs a new size. The amount of time required and effort to back-fill
the old data is relatively large, and we don't necessarily need every
size for every image (we just don't know where the images will show up
eventually).

Dynamic image scaling solves that problem nicely. With caching in place
of course.

[Jerry Stuckle]

I've had clients who have the same need. It's pretty simple to scale a
large number of images with a batch file (PHP, BASH, etc.), and proper
naming/cataloging takes care of the rest.

Who cares if you don't use all of the sizes? Disk space is cheap - much
cheaper than processor time.

[Daniel Pitts]

Pretty simple if you have a small enough set of images. The processor
time that would be needed to resize every last image in our catalog was
calculated in months. Making this a distributed task would be necessary,
and not entirely easy to do in PHP/BASH.

> Who cares if you don't use all of the sizes? Disk space is cheap - much
> cheaper than processor time.
>

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.

[Arno Welzel]

Daniel Pitts, 08.05.2012 05:37:

> On 5/7/12 5:15 PM, Jerry Stuckle wrote:

[...]

>> I've had clients who have the same need. It's pretty simple to scale a
>> large number of images with a batch file (PHP, BASH, etc.), and proper
>> naming/cataloging takes care of the rest.
> Pretty simple if you have a small enough set of images. The processor
> time that would be needed to resize every last image in our catalog was
> calculated in months. Making this a distributed task would be necessary,
> and not entirely easy to do in PHP/BASH.

Months?

You have to deal with several million images? Because otherwise its hard
to imagine that scaling images to a number of sizes - not print
resolutions since these images are only used for a web site - will take
*months*.

["Álvaro G. Vicario"]

Well... Last time I checked, official Apache 2.2 32-bit binaries were
using an obsolete compiler that would clash with PHP's more modern
binaries and there weren't official Apache 2.4 binaries at all, neither
32 nor 64. So I don't know if it's difficult (though it probably is,
given that you can hardly find unofficial standalone binaries out there)
but it's not true that Apache gets it right.

I've been using Anindya's binaries for a while, given that he's the only
one who's taken the time to compile the official MSI installers, and
I've found no problems so far, though of course that means you must
basically trust a stranger :)

http://www.anindya.com/

As an alternative, you can use a WAMP bundle like Xampp if you don't
mind the added complexity.


--
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://borrame.com
-- Mi web de humor satinado: http://www.demogracia.com
--

[Jerry Stuckle]

That does not compute. Repeatedly resizing the images on the fly would
then take years.

>> Who cares if you don't use all of the sizes? Disk space is cheap - much
>> cheaper than processor time.
>>
> 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!

[Daniel Pitts]

Who said repeatedly rescale? The process I've been talking about is more
like "lazy" scaling.

[Michael Fesser]

.oO(Jerry Stuckle)

You missed the word 'caching'. You rescale when needed, and only once.

Micha

--
http://mfesser.de/blickwinkel

[Peter H. Coffin]

How is this different than pre-scaling the images?

--
Compared to system administration, being cursed forever is a step up.
-- Paul Tomko

[Erwin Moller]

On 5/9/2012 4:29 AM, Peter H. Coffin wrote:
> On Tue, 08 May 2012 22:25:26 +0200, 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.
>
> How is this different than pre-scaling the images?
>

Hi Peter,

It is different because they are *only* rescaled when not found.

One approach I used:

1) Need image xyz_2012_march_nr12_300x500.jpg
(The 300x500 is dimensions needed.)
2) Check if it exists.
If not: Create it out of original (xyz_2012_march_nr12.jpg in this case)
and store it.

One can easily wrap this functionality in a function.

So the difference is that you don't need a batchjob that apparently
needs months and that will resize many images that are never needed, or
never needed on that size.
(I have my doubts about the alleged months, but that doesn't matter.)

Regards,
Erwin Moller

--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens

[Jerry Stuckle]

No, I didn't. By definition, caching is temporary storage which can be
erased at any time.

[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.

And you still haven't answered the question as to why it would take
months to rescale your images.

[Jerry Stuckle]

And another waste of time. You should know what size(s) you need, and
be able to prescale your images. I don't think I've ever seen a site
which needs more than 3-4 sizes for an image, and most sites don't need
that.

[Erwin Moller]

It is not that simple, Jerry.
When you have simple design-once website: yes, then I agree.

But when you deal with a team that uses lots of pictures, you don't want
to come back every time some design-guru decides to change the looks of
the website and needs different formats for the existing pictures. I
rather make a routine and be done with the problem.

[Jerry Stuckle]

It is even easier than that, Erwin. A quick batch file can easily
convert pictures to any size you want.

But how often does that happen? My clients don't generally make changes
to their site layout very often. And when they do, there's a lot more
to it than just converting images.

[Erwin Moller]

Yes, I understand that.
The point is that I expect less than 1% of them will be used in that
format eventually. So it feels like a waste of diskspace to produce them
in all formats.

> But how often does that happen? My clients don't generally make changes
> to their site layout very often. And when they do, there's a lot more to
> it than just converting images.
>

In my case it is a website for city promotion.
There is a huge amount of image data, and most is seldom used.

[Gregor Kofler]

Am 2012-05-09 15:14, Jerry Stuckle meinte:

>> Who said repeatedly rescale? The process I've been talking about is more
>> like "lazy" scaling.
>
> 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.

Please... Having a page with a bunch of images uploaded by users in
various (normally large) sizes the scaling on the fly takes the
proverbial ages (i.e. several seconds). Particularly on shared hosts.
Checking for the existence of a file (you know the output size and you
changed the file name of you rescaled images accordingly) is negligible.
Rescaling happens once, retrieving thousands of times (or more).

> And you still haven't answered the question as to why it would take
> months to rescale your images.

Indeed.

Gregor

[Jerry Stuckle]

So it takes a few seconds to do it once? It's going to take the same
total amount of time to do the scaling later, and you skip the overhead
of needlessly checking to see if the image exists "thousands of times
(or more)".

[Jerry Stuckle]

So? You know what sizes you need (or at least you should). You don't
need every possible size from 1x1 to 1000x1000 pixels.

And "seldom used" is not the same as "unused".

[Peter H. Coffin]

On Wed, 09 May 2012 09:56:44 +0200, Erwin Moller wrote:
> On 5/9/2012 4:29 AM, Peter H. Coffin wrote:
>> On Tue, 08 May 2012 22:25:26 +0200, 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.
>>
>> How is this different than pre-scaling the images?
>>
>
> Hi Peter,
>
> It is different because they are *only* rescaled when not found.
>
> One approach I used:
>
> 1) Need image xyz_2012_march_nr12_300x500.jpg
> (The 300x500 is dimensions needed.)
> 2) Check if it exists.
> If not: Create it out of original (xyz_2012_march_nr12.jpg in this case)
> and store it.
>
> One can easily wrap this functionality in a function.
>
> So the difference is that you don't need a batchjob that apparently
> needs months and that will resize many images that are never needed, or
> never needed on that size.
> (I have my doubts about the alleged months, but that doesn't matter.)

Still seems a waste to use webserver CPU to do something that's
apparently time-critical and intensive to do what could be handled as
part of a production build. I mean, don't you KNOW what size image
you're going to need? Will you suddenly need
xyz_2012_march_nr12_318x1260.jpg ? Or are you working around someone
just forgetting to build something that IS known about and should be
part of a documented process?

--
_ o
|/)

[Daniel Pitts]

Our content producers upload images using our CMS and, they currently
get scaled to the "common" sizes. We currently have a catalog of 7.5
million images.

Now, it happens every so often that one of our (many) design teams or
product teams decide that one of our (many) sites needs a redesign.
When that happens, sometimes they want a new size (or have some specific
cropping requirements, etc...).

If it takes 1 second to reprocess an image (and it averages much higher
than that), it would take 12 days to reprocess our entire catalog.

We are not a little shop working on a site for a single client. We are a
large media company. Some things that work with small to medium sized
sites do not work at all when you're dealing with millions of images.

The point is, if you don't need dynamic resizing, good for you, don't go
to the trouble. Some of us on the other hand work on a different scale.

[The Natural Philosopher]

Gregor Kofler wrote:
> Am 2012-05-09 15:14, Jerry Stuckle meinte:
>
>>> Who said repeatedly rescale? The process I've been talking about is more
>>> like "lazy" scaling.
>>
>> 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.
>
> Please... Having a page with a bunch of images uploaded by users in
> various (normally large) sizes the scaling on the fly takes the
> proverbial ages (i.e. several seconds).

No it doesnt.

> Particularly on shared hosts.

well I cant answer for crap hosts.

> Checking for the existence of a file (you know the output size and you
> changed the file name of you rescaled images accordingly) is negligible.
> Rescaling happens once, retrieving thousands of times (or more).

Often never used again.

>
>> And you still haven't answered the question as to why it would take
>> months to rescale your images.
>
> Indeed.
>
> Gregor
>

[Gregor Kofler]

Am 2012-05-09 20:36, The Natural Philosopher meinte:

> Gregor Kofler wrote:
>> Am 2012-05-09 15:14, Jerry Stuckle meinte:
>>
>>>> Who said repeatedly rescale? The process I've been talking about is
>>>> more
>>>> like "lazy" scaling.
>>>
>>> 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.
>>
>> Please... Having a page with a bunch of images uploaded by users in
>> various (normally large) sizes the scaling on the fly takes the
>> proverbial ages (i.e. several seconds).
>
> No it doesnt.

It does. People tend to upload their images straight as they come from
their camera/smartphone. And I need them as 300x200 thumbs and in an
enlarged 900x600 something format. Perhaps sharpened.

>> Particularly on shared hosts.
>
> well I cant answer for crap hosts.

Frequently not something the developer can decide.

>
>> Checking for the existence of a file (you know the output size and you
>> changed the file name of you rescaled images accordingly) is negligible.
>> Rescaling happens once, retrieving thousands of times (or more).
>
> Often never used again.

They lookup and/or rescaling happens, when an image is displayed. Not
before. You do the rescaling when it is required, and then you do it
only once. IOW the one-time-storing and the frequent checking for file
existence replaces the frequent on-the-fly resizing. No way, that the
latter one is faster (I do websites which are visited by more than one
person - hopefully).

Gregor

[Jerry Stuckle]

You need to get rid of that TRS-80 and get a decent machine. It
shouldn't take anywhere near a second to resize an image.

[Daniel Pitts]

Our source images are often extremely high resolution, so part of the
processing time is IO bound. I haven't actually worked on the image
processing codebase, and I do suspect there are some efficiencies that
could be gained somewhere, but the fact remains that at our scale,
dynamic resizing is a better solution.

[Michael Fesser]

.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

--
http://mfesser.de/blickwinkel

[Michael Fesser]

.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

--
http://mfesser.de/blickwinkel

[Daniel Pitts]

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".

[Jerry Stuckle]

Which is even more overhead...

[Jerry Stuckle]

Repeatedly resizing the files is a huge waste of processor resources.

[Jerry Stuckle]

By definition a cache is temporary.

[Michael Fesser]

.oO(Jerry Stuckle)

>Repeatedly resizing the files is a huge waste of processor resources.

Maybe you should get a decent machine? And "when needed" is not the same
as "repeatedly". It's done _once_ and may only be repeated if someone
would clear the image cache.

Micha

--
http://mfesser.de/blickwinkel

[Michael Fesser]

.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

[Jerry Stuckle]

Have you actually checked how much overhead there is to process a not
found? It is quite significant.

[Jerry Stuckle]

On 5/10/2012 2:49 AM, Michael Fesser wrote:
> .oO(Jerry Stuckle)
>
>> Repeatedly resizing the files is a huge waste of processor resources.
>
> Maybe you should get a decent machine? And "when needed" is not the same
> as "repeatedly". It's done _once_ and may only be repeated if someone
> would clear the image cache.
>
> Micha
>

Yup. And a cache is by definition temporary - meaning that the images
will have to be resized repeatedly.

Or are you going to create a 1TB image cache?

[Michael Fesser]

.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

[Michael Fesser]

.oO(Jerry Stuckle)

>Yup. And a cache is by definition temporary

This could mean minutes, but also years.

>meaning that the images
>will have to be resized repeatedly.

Only if someone intentionally deletes the cache.

>Or are you going to create a 1TB image cache?

If necessary, why not? Google caches almost its entire index of
websites.

But if you're so picky about definitions, don't call it an image cache,
but "automated creation of static image resources".

Micha

--
http://mfesser.de/blickwinkel

[Jerry Stuckle]

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.

[Jerry Stuckle]

On 5/10/2012 3:09 PM, Michael Fesser wrote:
> .oO(Jerry Stuckle)
>
>> Yup. And a cache is by definition temporary
>
> This could mean minutes, but also years.
>

Yup, if you only get 200 hits a day it could be years. Active systems
typically measure this in minutes at best.

>> meaning that the images
>> will have to be resized repeatedly.
>
> Only if someone intentionally deletes the cache.
>

Or the image is deleted from the cache to make more room, which is
typically in seconds.

>> Or are you going to create a 1TB image cache?
>
> If necessary, why not? Google caches almost its entire index of
> websites.
>

Oh, so now you're writing systems as complicated as Google? ROFLMAO!

> But if you're so picky about definitions, don't call it an image cache,
> but "automated creation of static image resources".
>
> Micha
>

I'm using the term like it is defined. Just because you want to call a
cow a horse doesn't make it a horse.

[Daniel Pitts]

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.

[The Natural Philosopher]

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.

[Jerry Stuckle]

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.

[Daniel Pitts]

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.

[Jerry Stuckle]

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.

[The Natural Philosopher]

....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.
>
>

[Daniel Pitts]

I have some idea, as I actually work on such a system. You seem to have
little real-world experience, as you seem to think that one solution
suits all.

>
> And a system which creates all the images once so it doesn't have to
> keep needlessly checking to see if an image exists or not is more
> efficient than one which constantly has to see if something exists or not.

Whatever is serving your static content must check if it exists or not.
You can hook into the "or-not" case, which happens only once per image
per size that is *actually* used.

>
> Resizing is done ONCE. Checking has to be done on EVERY REQUEST.

Checking has to be done on every request regardless. This is not an
extra step.

> But then you're got your mind made up. After all, it would take "months"
> for you to resize your images.

Months may have been a slight exaggeration, but it does take more than a
few days to resize every possible image.

> A good system can resize several hundred images a second. At most we're
> taking a few hours to do 7.5M images, even if they are high-res. But
> your TRS-80's may only be able to do one a second.

It is still easier to set up this lazy-loading once, than to have to run
a "few hours" of scripts every time requirements change. The site will
perform well enough (storing the resized images permanently, plus having
edge cache in front of them). Why waste an engineers time running such a
script (which is more expensive than CPU time needed to handle the lazy
resizing).

The actual hardware in question is a "Compaq DL385 G6"

CPU: 12 x 2200 MHz Six-Core AMD Opteron 2427, 512 KB cache
Memory: 64461MB

Granted, this machine is shared with many other tools.

[Jerry Stuckle]

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.

[Michael Fesser]

.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

--
http://mfesser.de/blickwinkel

[Michael Fesser]

.oO(Jerry Stuckle)

>And a system which creates all the images once so it doesn't have to
>keep needlessly checking to see if an image exists or not is more
>efficient than one which constantly has to see if something exists or not.
>
>Resizing is done ONCE.

Right.

>Checking has to be done on EVERY REQUEST.

Wrong.

Micha

--
http://mfesser.de/blickwinkel

[Jerry Stuckle]

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.

[Jerry Stuckle]

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!

[Erwin Moller]

On 5/9/2012 6:23 PM, Jerry Stuckle wrote:
> On 5/9/2012 10:54 AM, Erwin Moller wrote:
>> On 5/9/2012 4:38 PM, Jerry Stuckle wrote:
>>> On 5/9/2012 10:23 AM, Erwin Moller wrote:
>>>> On 5/9/2012 3:17 PM, Jerry Stuckle wrote:
>>>>> On 5/9/2012 3:56 AM, Erwin Moller wrote:
>>>>>> On 5/9/2012 4:29 AM, Peter H. Coffin wrote:

>>>>>>> On Tue, 08 May 2012 22:25:26 +0200, 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.
>>>>>>>

>>>>>>> How is this different than pre-scaling the images?
>>>>>>>
>>>>>>
>>>>>> Hi Peter,
>>>>>>
>>>>>> It is different because they are *only* rescaled when not found.
>>>>>>
>>>>>> One approach I used:
>>>>>>
>>>>>> 1) Need image xyz_2012_march_nr12_300x500.jpg
>>>>>> (The 300x500 is dimensions needed.)
>>>>>> 2) Check if it exists.
>>>>>> If not: Create it out of original (xyz_2012_march_nr12.jpg in this
>>>>>> case)
>>>>>> and store it.
>>>>>>
>>>>>> One can easily wrap this functionality in a function.
>>>>>>
>>>>>> So the difference is that you don't need a batchjob that apparently
>>>>>> needs months and that will resize many images that are never
>>>>>> needed, or
>>>>>> never needed on that size.
>>>>>> (I have my doubts about the alleged months, but that doesn't matter.)
>>>>>>
>>>>>> Regards,
>>>>>> Erwin Moller
>>>>>>
>>>>>
>>>>> And another waste of time. You should know what size(s) you need,
>>>>> and be
>>>>> able to prescale your images. I don't think I've ever seen a site
>>>>> which
>>>>> needs more than 3-4 sizes for an image, and most sites don't need
>>>>> that.
>>>>>
>>>>
>>>> It is not that simple, Jerry.
>>>> When you have simple design-once website: yes, then I agree.
>>>>
>>>> But when you deal with a team that uses lots of pictures, you don't
>>>> want
>>>> to come back every time some design-guru decides to change the looks of
>>>> the website and needs different formats for the existing pictures. I
>>>> rather make a routine and be done with the problem.
>>>>
>>>> Regards,
>>>> Erwin Moller
>>>>
>>>>
>>>
>>> It is even easier than that, Erwin. A quick batch file can easily
>>> convert pictures to any size you want.
>>>
>>
>> Yes, I understand that.
>> The point is that I expect less than 1% of them will be used in that
>> format eventually. So it feels like a waste of diskspace to produce them
>> in all formats.
>>
>>
>>> But how often does that happen? My clients don't generally make changes
>>> to their site layout very often. And when they do, there's a lot more to
>>> it than just converting images.
>>>
>>
>> In my case it is a website for city promotion.
>> There is a huge amount of image data, and most is seldom used.
>>
>> Regards,
>> Erwin Moller
>>
>>
>
> So? You know what sizes you need (or at least you should).

How should I know?
These web designers change their mind every congress they visit.

I think it is easier to offer a simple way with dynamic scaling (AND
storing) that takes the best of both worlds: little wasted diskspace and
fast performance.

You don't
> need every possible size from 1x1 to 1000x1000 pixels.

No, but since I don't know beforehand WHAT they want tomorrow, I think
this approach is handy.

Regards,
Erwin Moller


--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens

[Jerry Stuckle]

No problem - a simple batch job rescales the images to whatever size you
specify.

> I think it is easier to offer a simple way with dynamic scaling (AND
> storing) that takes the best of both worlds: little wasted diskspace and
> fast performance.
>
> You don't
>> need every possible size from 1x1 to 1000x1000 pixels.
>
> No, but since I don't know beforehand WHAT they want tomorrow, I think
> this approach is handy.
>
> Regards,
> Erwin Moller
>
>

So? They tell you they need a new size. Run the batch job to create
the files. It would take you maybe 10 seconds to type the command in.

[The Natural Philosopher]

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

[The Natural Philosopher]

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.

[Erwin Moller]

That is one way.
It will take up a huge amount of diskspace, defining images that are
never used.
I don't see the point in approaching it like that.

Of course: when you have a small site that seldom changes, there is no
need for the approach, but when you deal with many images and designers
that want them in other formats on a regular basis, it is smarter to
define them on demand.
All you need for this is some approach that catches missing images,
which van be easily handles by, for example, Apache.

To be honest: I don't understand your reluctance at all.

[Jerry Stuckle]

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!

[Jerry Stuckle]

In case you haven't figured it out - disk space is cheap - much cheaper
than CPU. But then if you're only getting 200 hits a day I guess the
extra load doesn't make any difference.

[Jerry Stuckle]

On 5/11/2012 9:01 AM, The Natural Philosopher wrote:
> Michael Fesser wrote:
>> .oO(Jerry Stuckle)
>>
>>> And a system which creates all the images once so it doesn't have to
>>> keep needlessly checking to see if an image exists or not is more
>>> efficient than one which constantly has to see if something exists or
>>> not.
>>>
>>> Resizing is done ONCE.
>>
>> Right.
>>
>>> Checking has to be done on EVERY REQUEST.
>>
>> Wrong.
>
> depends what you meean by checking: if the code goes
>
> load scaled image
> if fail
> rescale master image
> store scaled copy
> send scaled image
>
> then the only overhead is to check for failure of a load operation, but
> I don't see how you can get around that,
>
> You have to go to the database or the disk anyway to get the file, so
> its hardly an overhead to check if it fails.
>
>
>

Loading the script, starting the scripting module, initializing the
environment, interpreting and running the script, checking for the
presence of the image, storing a resized script if necessary, loading
the image and sending it, and cleaning up the environment.

This vs. sending the image directly via an <img ...> tag.

Nope, no extra overhead! And no way to send the image without a script!

>>
>> Micha

[Daniel Pitts]

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*

[Jerry Stuckle]

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.

[Peter H. Coffin]

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.

[Peter H. Coffin]

On Fri, 11 May 2012 15:44:55 +0200, Erwin Moller wrote:
> On 5/11/2012 1:38 PM, Jerry Stuckle wrote:
>>
>> No problem - a simple batch job rescales the images to whatever size you
>> specify.
>
> That is one way.
> It will take up a huge amount of diskspace, defining images that are
> never used.
> I don't see the point in approaching it like that.

Why are the designers asking you for image sizes that will never be
used? (Aside from the admittedly-true "They're WEB DESIGNERS"...)

--
Windows gives you a nice view of clouds so you can't see any potentially
useful boot time messages.
-- Bill Hay in the Monastery

[Shake]

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.

[The Natural Philosopher]

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...

[Michael Fesser]

.oO(Jerry Stuckle)

>On 5/11/2012 5:58 AM, Michael Fesser wrote:
>> .oO(Jerry Stuckle)
>>
>>> And a system which creates all the images once so it doesn't have to
>>> keep needlessly checking to see if an image exists or not is more
>>> efficient than one which constantly has to see if something exists or not.
>>>
>>> Resizing is done ONCE.
>>
>> Right.
>>
>>> Checking has to be done on EVERY REQUEST.
>>
>> Wrong.
>>
>> Micha
>>
>
>You really have no idea what you're talking about, do you? But you'll
>argue it anyway.

You still miss the point (or just don't want to accept it, as usual). If
there's a static image file, there is absolutely no additional checking
for existance necessary (besides the one that has to be done for every
resource the server wishes to deliver, but this doesn't matter here).

If the file is there, it will be delivered as-is, if not, it triggers a
404 (which could then create the requested resource on demand). That's
the same for every static HTML or CSS file, so your claim from above
"Checking has to be done on EVERY REQUEST" is simply wrong.

>After all - you think there's no overhead in 404 processing!

A little maybe, but I don't think it really matters. What much has the
server to do after it didn't find the requested resource? Deliver
another page or call a script. I can't think of much more, except maybe
a second log entry. The typical redirects from http://example.com/foo to
http://example.com/foo/, which are still seen on many sites, are much
more expensive.

Micha

--
http://mfesser.de/blickwinkel

[Jerry Stuckle]

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.

[Jerry Stuckle]

There's a lot more to the overhead than that!

[Shake]

Jerry Stuckle avait écrit le 11/05/2012 :
> On 5/11/2012 2:58 PM, Shake wrote:
>> Jerry Stuckle a couché sur son écran :
>>>
>>> Loading the script, starting the scripting module, initializing the
>>> environment, interpreting and running the script, checking for the
>>> presence of the image, storing a resized script if necessary, loading
>>> the image and sending it, and cleaning up the environment.
>>>
>>> This vs. sending the image directly via an <img ...> tag.
>>>
>>> Nope, no extra overhead! And no way to send the image without a script!
>>>
>>
>> The Extra overhead is something like in the code that generate the page:
>>
>> <?php
>> if(!file_exists(IMG_PATH.$image_file)) scaleImage($image_file);
>> ?>
>>
>> Not look like an "application killer" to me.
>>
>> Greetings.
>>
>>
>
> There's a lot more to the overhead than that!

Which?

Is the image going to be accessed directly by its URL, or is loaded
inside a webpage? I am sure is this last case.

So Loading a PHP script will occur 99.999% if you reescaled the image
previously with a batch or not. All the work of load an script, will be
done always.

I don't believe that "react" to a 404 error is the good aproach, but
generating dinamically the scaled images when the page that show them
is required.

And this only need the few lines to test if file exists and generate
the images if not.

The fact that the image is directly accessed without pasing first for
the php script...

Someone talked about a catalog of image... I am sure they are accessed
through a we, not directly.

Even if they are accessed via search engines, these search engines have
to visit the scripts that would generate the scaled images.

Greetings.

[Michael Fesser]

.oO(Jerry Stuckle)

>On 5/11/2012 3:11 PM, Michael Fesser wrote:
>>
>> A little maybe, but I don't think it really matters. What much has the
>> server to do after it didn't find the requested resource? Deliver
>> another page or call a script. I can't think of much more, except maybe
>> a second log entry. The typical redirects from http://example.com/foo to
>> http://example.com/foo/, which are still seen on many sites, are much
>> more expensive.
>

>No, you don't get it. A 404 causes even more overhead - Apache has to
>detect the 404

Happens all the time for every single resource.

>, determine which is the correct error page to load

Which is defined in the server configuration.

>and
>load it.

Happens all the time for every single resource.

>In this case it's a PHP file, so the PHP module has to be
>loaded and the environment initialized, etc.

On a site using PHP the module is already there and ready to work.

>Then the PHP code needs to determine if it is even a request for an
>image, and if the image can be found and resized. If so, the code must
>resize the image and send it.

That's the only additional work, once per image. So what?

>Then the module cleanup has to be performed.

Nope, the module stays there. There's just the usual cleanup as for
every other PHP page.

>Plus, depending on what the sysadmin has installed for Apache
>extensions, other modules may be called in the process.

Possible, but rather unlikely and irrelevant.

>That's a lot of overhead, especially when you know the images and the
>sizes you need ahead of time.
>
>It's fine if you're running 200 hits/day, but not in a busy server.

After a short period of time all most requested images are there.
Creating another missing image every now and then won't bring a server
to its knees.

Micha

--
http://mfesser.de/blickwinkel

[Luuk]

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 ....

[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. 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.

[Jerry Stuckle]

On 5/11/2012 3:46 PM, Shake wrote:
> Jerry Stuckle avait écrit le 11/05/2012 :
>> On 5/11/2012 2:58 PM, Shake wrote:
>>> Jerry Stuckle a couché sur son écran :
>>>>
>>>> Loading the script, starting the scripting module, initializing the
>>>> environment, interpreting and running the script, checking for the
>>>> presence of the image, storing a resized script if necessary, loading
>>>> the image and sending it, and cleaning up the environment.
>>>>
>>>> This vs. sending the image directly via an <img ...> tag.
>>>>
>>>> Nope, no extra overhead! And no way to send the image without a script!
>>>>
>>>
>>> The Extra overhead is something like in the code that generate the page:
>>>
>>> <?php
>>> if(!file_exists(IMG_PATH.$image_file)) scaleImage($image_file);
>>> ?>
>>>
>>> Not look like an "application killer" to me.
>>>
>>> Greetings.
>>>
>>>
>>
>> There's a lot more to the overhead than that!
>
> Which?
>

See my other posts. It is actually quite involved, and I'm not going to
repeat it (again).

> Is the image going to be accessed directly by its URL, or is loaded
> inside a webpage? I am sure is this last case.
>
> So Loading a PHP script will occur 99.999% if you reescaled the image
> previously with a batch or not. All the work of load an script, will be
> done always.
>

Nope. If you rescaled the image via a batch script, the image is there
and it can be served directly.

> I don't believe that "react" to a 404 error is the good aproach, but
> generating dinamically the scaled images when the page that show them is
> required.
>

Which has significant overhead, as I've pointed out in my other posts.

> And this only need the few lines to test if file exists and generate the
> images if not.
>

There's a lot more to it than that.

> The fact that the image is directly accessed without pasing first for
> the php script...
>
> Someone talked about a catalog of image... I am sure they are accessed
> through a we, not directly.
>

A catalog of images doesn't mean the images aren't being served directly.

> Even if they are accessed via search engines, these search engines have
> to visit the scripts that would generate the scaled images.
>
> Greetings.
>
>

More unnecessary overhead.

[Jerry Stuckle]

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.

[Michael Fesser]

.oO(Jerry Stuckle)

>On 5/11/2012 3:53 PM, Michael Fesser wrote:
>> .oO(Jerry Stuckle)
>>
>>> On 5/11/2012 3:11 PM, Michael Fesser wrote:
>>>>
>>>> A little maybe, but I don't think it really matters. What much has the
>>>> server to do after it didn't find the requested resource? Deliver
>>>> another page or call a script. I can't think of much more, except maybe
>>>> a second log entry. The typical redirects from http://example.com/foo to
>>>> http://example.com/foo/, which are still seen on many sites, are much
>>>> more expensive.
>>>
>>> No, you don't get it. A 404 causes even more overhead - Apache has to
>>> detect the 404
>>
>> Happens all the time for every single resource.
>>
>
>Nope. A static page is served up immediately.

But the server always has to check if it's there. How else could he
deliver it?

And if a previous 404 causes an image file to be created - from that
time on it will also be "served up immediately". The overhead for that
single image happens exactly one time. That's nothing to worry about.

>> Which is defined in the server configuration.
>
>And has to be found in the configuration - not required when the
>resource is found.

The configuration is loaded before and the handlers are defined.
It's just one function call or another (more or less):

if (resourceIsFound()) {
sendResource();
} else {
sendErrorDocument();

}

>>> In this case it's a PHP file, so the PHP module has to be
>>> loaded and the environment initialized, etc.
>>
>> On a site using PHP the module is already there and ready to work.
>
>Maybe, maybe not. It depends on the server. But even if it is loaded,
>it still has to be attached to the thread or process, the environment
>initialized.

Like on every other PHP page.

>>> Then the PHP code needs to determine if it is even a request for an
>>> image, and if the image can be found and resized. If so, the code must
>>> resize the image and send it.
>>
>> That's the only additional work, once per image. So what?
>
>Completely unnecessary work, but ok if your site only has 200 hits per day.

The work has to be done either way.

If you have 100.000 images and get 100.000 hits a day, each one for a
different image, all the images are created on that single day and can
be served directly from that time on. Only the first requester of a
particular image might notice a little delay.

>>> That's a lot of overhead, especially when you know the images and the
>>> sizes you need ahead of time.
>>>
>>> It's fine if you're running 200 hits/day, but not in a busy server.
>>
>> After a short period of time all most requested images are there.
>> Creating another missing image every now and then won't bring a server
>> to its knees.
>

>Creating them once with a script means the images are there from the start.

Which also takes a lot of time and creates images which might not be
used at all.

In short: These are two totally different approaches, but both have
their uses and are reasonable. Doing it the "all-before-way" is OK, but
so is the "on-demand-way". There's absolutely nothing wrong about the
latter: The server load is almost the same, just spread across time.

Micha

--
http://mfesser.de/blickwinkel

[The Natural Philosopher]

Michael Fesser wrote:
> .oO(Jerry Stuckle)
>
>> On 5/11/2012 5:58 AM, Michael Fesser wrote:
>>> .oO(Jerry Stuckle)
>>>
>>>> And a system which creates all the images once so it doesn't have to
>>>> keep needlessly checking to see if an image exists or not is more
>>>> efficient than one which constantly has to see if something exists or not.
>>>>
>>>> Resizing is done ONCE.
>>> Right.
>>>
>>>> Checking has to be done on EVERY REQUEST.
>>> Wrong.
>>>
>>> Micha
>>>
>> You really have no idea what you're talking about, do you? But you'll
>> argue it anyway.
>
> You still miss the point (or just don't want to accept it, as usual). If
> there's a static image file, there is absolutely no additional checking
> for existance necessary (besides the one that has to be done for every
> resource the server wishes to deliver, but this doesn't matter here).
>
> If the file is there, it will be delivered as-is, if not, it triggers a
> 404 (which could then create the requested resource on demand). That's
> the same for every static HTML or CSS file, so your claim from above
> "Checking has to be done on EVERY REQUEST" is simply wrong.
>

the 404 response is evidence that a check has been done.

>> After all - you think there's no overhead in 404 processing!
>
> A little maybe, but I don't think it really matters. What much has the
> server to do after it didn't find the requested resource? Deliver
> another page or call a script. I can't think of much more, except maybe
> a second log entry. The typical redirects from http://example.com/foo to
> http://example.com/foo/, which are still seen on many sites, are much
> more expensive.
>

*shrug* serve the file via a PHP script. The check is minimal compared
top the actual serving of the data, and infinitely small compared with
rescaling.

> Micha

[The Natural Philosopher]

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.
>
>

[The Natural Philosopher]

Michael Fesser wrote:
> .oO(Jerry Stuckle)
>
>> On 5/11/2012 3:11 PM, Michael Fesser wrote:
>>> A little maybe, but I don't think it really matters. What much has the
>>> server to do after it didn't find the requested resource? Deliver
>>> another page or call a script. I can't think of much more, except maybe
>>> a second log entry. The typical redirects from http://example.com/foo to
>>> http://example.com/foo/, which are still seen on many sites, are much
>>> more expensive.
>> No, you don't get it. A 404 causes even more overhead - Apache has to
>> detect the 404
>
> Happens all the time for every single resource.
>
>> , determine which is the correct error page to load
>
> Which is defined in the server configuration.
>
>> and
>> load it.
>
> Happens all the time for every single resource.
>

exactly: so a check is always done. not never done.

[The Natural Philosopher]

exactly.

Jerry is as usual talking out of his arse..he must have taken his head out.

[Jerry Stuckle]

On 5/11/2012 7:00 PM, Michael Fesser wrote:
> .oO(Jerry Stuckle)
>
>> On 5/11/2012 3:53 PM, Michael Fesser wrote:
>>> .oO(Jerry Stuckle)
>>>
>>>> On 5/11/2012 3:11 PM, Michael Fesser wrote:
>>>>>
>>>>> A little maybe, but I don't think it really matters. What much has the
>>>>> server to do after it didn't find the requested resource? Deliver
>>>>> another page or call a script. I can't think of much more, except maybe
>>>>> a second log entry. The typical redirects from http://example.com/foo to
>>>>> http://example.com/foo/, which are still seen on many sites, are much
>>>>> more expensive.
>>>>
>>>> No, you don't get it. A 404 causes even more overhead - Apache has to
>>>> detect the 404
>>>
>>> Happens all the time for every single resource.
>>>
>>
>> Nope. A static page is served up immediately.
>
> But the server always has to check if it's there. How else could he
> deliver it?
>
> And if a previous 404 causes an image file to be created - from that
> time on it will also be "served up immediately". The overhead for that
> single image happens exactly one time. That's nothing to worry about.
>

Not a problem when you're doing 200 hits/day.

>>> Which is defined in the server configuration.
>>
>> And has to be found in the configuration - not required when the
>> resource is found.
>
> The configuration is loaded before and the handlers are defined.
> It's just one function call or another (more or less):
>
> if (resourceIsFound()) {
> sendResource();
> } else {
> sendErrorDocument();
> }
>

You really think that's all there is to it? ROFLMAO!

What does resourceIsFound() do? What does sendErrorDocument() do? A
lot more than just a simple C function call!

>>>> In this case it's a PHP file, so the PHP module has to be
>>>> loaded and the environment initialized, etc.
>>>
>>> On a site using PHP the module is already there and ready to work.
>>
>> Maybe, maybe not. It depends on the server. But even if it is loaded,
>> it still has to be attached to the thread or process, the environment
>> initialized.
>
> Like on every other PHP page.
>

Yes, and if the resource is found, no PHP page is required.

>>>> Then the PHP code needs to determine if it is even a request for an
>>>> image, and if the image can be found and resized. If so, the code must
>>>> resize the image and send it.
>>>
>>> That's the only additional work, once per image. So what?
>>
>> Completely unnecessary work, but ok if your site only has 200 hits per day.
>
> The work has to be done either way.
>

Not at all. It can be done once offline, instead of on the web server.
And doing a bunch of images offline is far more efficient than trying
to handle a 404.

> If you have 100.000 images and get 100.000 hits a day, each one for a
> different image, all the images are created on that single day and can
> be served directly from that time on. Only the first requester of a
> particular image might notice a little delay.
>

You've obviously never had a site which had 100,000 hits a day. I
suspect your sites never exceed 200 hits/day.

>>>> That's a lot of overhead, especially when you know the images and the
>>>> sizes you need ahead of time.
>>>>
>>>> It's fine if you're running 200 hits/day, but not in a busy server.
>>>
>>> After a short period of time all most requested images are there.
>>> Creating another missing image every now and then won't bring a server
>>> to its knees.
>>
>> Creating them once with a script means the images are there from the start.
>
> Which also takes a lot of time and creates images which might not be
> used at all.
>

Less time than creating them on the fly. Plus it's done offline and not
taking web server time.

> In short: These are two totally different approaches, but both have
> their uses and are reasonable. Doing it the "all-before-way" is OK, but
> so is the "on-demand-way". There's absolutely nothing wrong about the
> latter: The server load is almost the same, just spread across time.
>
> Micha
>

In short, you have no idea how to optimize even a slightly busy site.
Your approach works fine for your sites which never have more than 200
hits/day. It does not scale to an even moderately busy site.

I'm not in favor of premature optimization. However, I AM in favor of
not putting an unnecessary load on the web server. But then the sites I
deal with are moderately busy, also.

[Jerry Stuckle]

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.
>>
>>
>
>


--

[Luuk]

So, offline is for 'free' ?
You are comparing apples with oranges here....

[Thomas 'PointedEars' Lahn]

Gregor Kofler wrote:

> Am 2012-05-09 20:36, The Natural Philosopher meinte:
>> Gregor Kofler wrote:
>>> Am 2012-05-09 15:14, Jerry Stuckle meinte:
>>>>> Who said repeatedly rescale? The process I've been talking about is
>>>>> more like "lazy" scaling.
>>>>
>>>> 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.
>>>
>>> Please... Having a page with a bunch of images uploaded by users in
>>> various (normally large) sizes the scaling on the fly takes the
>>> proverbial ages (i.e. several seconds).
>> No it doesnt.
>
> It does. People tend to upload their images straight as they come from
> their camera/smartphone. […]

People need to be educated not to do that. High-resolution images with huge
dimensions result in large files. There is already a limitation in the
upload file size (upload_max_filesize), and that is good so. You can make
allowances and do not have to stick to the default 2M maximum, but allowing
people to upload files of *any* size to a server is virtual(ly) suicide. So
that is not a very convincing argument in favor of 64-bit processing.


PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

[Jerry Stuckle]

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.

[Peter H. Coffin]

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.

[Shake]

I thought you don't understood.

I would use the catalogue example:

People visits this page to see the image catalogue. Search engines
visits this page to index images.

If nobody human or machine have entered to this page, there is no
directy linked image nowhere.

So, at this point nobody knows any url to any image of this site. And
there is no image that could be accessed.

The only way to knwo about one of these images is when anyone enter the
php page. And when this occurs, reescaling process will be done if
necesary.

Never, any image will be directly delivered without previosly have been
executed the php.

We have the image /catalogue/images/size_1/123213.jpg Original
We have the image /catalogue/images/size_2/123213.jpg Scaled
We have the image /catalogue/images/size_3/123213.jpg No Scaled.

The catalogue was listed throught /catalogue/index.php that yesterday
was modified using a new size fo thumbnails (size_3).

The third size was created yesterday. Nobody knows his existence, there
is no link to it in any web, search engine or human brain. So nobody
could access. That is a lucky thing, because the image no exist.

When the first visit is done to the /catalogue/index.php the size_2
images start to be generated. If the visit is from a search engine,
then the new images are indexed and could be directly accessed.

so /catalogue/index.php is executed always previous to put on the net
the existence of new images. Included if we have batch reescaled them.
These images will not have internet existence never if the
catalogue/index.php is not executed. with or without reescaling.

And then, this mean that all the supossed overhead about executing PHP
always happen even if you batched the process.

And it's obvious. we are talking about web pages that are created with
php.

I worked for four years in a website for artists. Not the bigger
company but with reasonable traffic, 8 millions page visits per month,
por than 250.000 pages per day. And about 1 million image artwork. A
lot of them of big resolucion.

And in this company we fight against this problem. In some cases we
decided to use batch process and in other cases we decided to do
"on-the-fly".

Big images requires watermarking and some other processes, too slow to
do on-fly. The reescaling required 3 weeks to be done , using three 3
computers.

Other times, for new set of small sizes, we used on the fly. withouth
usign 404 to react to.

Just first time any one enters a page that have new images, new images
were generated. And never happened that any image have been accesses
directly previous to its generation.

The images are always served directly throught lighttp, the php
necesary to generate images was always inside the php app that generate
the web pages.

Greetings

[J.O. Aho]

Dominique Ottello wrote:
> "J.O. Aho"<us...@example.net> écrivait :
>
>>> PHP does not do it!
>>> Why? Could it be that complicated to compile for 32 AND 64 bit?
>>
>> Why don't Microsoft do it? All the Linuxes and Unixes does that.
> This is a typical response of Linux user who brings strictly no
> explanation to my question.
> Jesuit Response: You answer a question with another question.
>
> Apache makes 64 bit binaries for Windows
> MySQL makes 64 bit binaries for Windows
> PHP does not.

With PHP you don't really gain anything by running 64bit and ms-windows isn't
a real 64bit environment, mainly a 64bit kernel with a few 64bit tools.
Also Zend don't provide binaries to any other operating system, so having
those 32bit binaries is just an extra service for the OS which don't by
default have a simple mean to install a development environment.

--

//Aho

[Jerry Stuckle]

On 5/12/2012 8:42 AM, Shake wrote:
> I thought you don't understood.
>
> I would use the catalogue example:
>
> People visits this page to see the image catalogue. Search engines
> visits this page to index images.
>
> If nobody human or machine have entered to this page, there is no
> directy linked image nowhere.
>

The link is there, whether a human or machine has requested the page or
not. Links don't just magically appear!

Whether the link has been accessed or not is a different story - but
immaterial to whether it exists or not.

> So, at this point nobody knows any url to any image of this site. And
> there is no image that could be accessed.
>

Still doesn't make any difference whether someone knows about the image
or not.

> The only way to knwo about one of these images is when anyone enter the
> php page. And when this occurs, reescaling process will be done if
> necesary.
>

At additional overhead to the server. This overhead can be completely
eliminated by simply resizing the images offline.

> Never, any image will be directly delivered without previosly have been
> executed the php.
>

And once the images have been created offline, the server doesn't have
to execute ANY PHP to deliver the image.

> We have the image /catalogue/images/size_1/123213.jpg Original
> We have the image /catalogue/images/size_2/123213.jpg Scaled
> We have the image /catalogue/images/size_3/123213.jpg No Scaled.
>
> The catalogue was listed throught /catalogue/index.php that yesterday
> was modified using a new size fo thumbnails (size_3).
>
> The third size was created yesterday. Nobody knows his existence, there
> is no link to it in any web, search engine or human brain. So nobody
> could access. That is a lucky thing, because the image no exist.
>

If there is no link, then why would the image be created?

> When the first visit is done to the /catalogue/index.php the size_2
> images start to be generated. If the visit is from a search engine, then
> the new images are indexed and could be directly accessed.
>

And if the images are created offline, none of that needs to be done.
The images can be sent without any PHP involvement at all.

> so /catalogue/index.php is executed always previous to put on the net
> the existence of new images. Included if we have batch reescaled them.
> These images will not have internet existence never if the
> catalogue/index.php is not executed. with or without reescaling.
>

But if you're listing them in the catalog, then there is a link to them.

> And then, this mean that all the supossed overhead about executing PHP
> always happen even if you batched the process.
>

Sure, but the batch process is done on another machine, taking
unnecessary work off the server.

> And it's obvious. we are talking about web pages that are created with php.
>

Which has nothing to do with resizing of images. The page with the link
MAY be a PHP page. But it could also be a Perl page, a Python page, a
Ruby (on Rails) page or even static HTML.

> I worked for four years in a website for artists. Not the bigger company
> but with reasonable traffic, 8 millions page visits per month, por than
> 250.000 pages per day. And about 1 million image artwork. A lot of them
> of big resolucion.
>

8 million hits a month is a bit below average, but a lot more than most
of the people in this newsgroup work on.

> And in this company we fight against this problem. In some cases we
> decided to use batch process and in other cases we decided to do
> "on-the-fly".
>

Sure, doing the batch process means less work for the server.

> Big images requires watermarking and some other processes, too slow to
> do on-fly. The reescaling required 3 weeks to be done , using three 3
> computers.
>

You need to get some better computers. 1M images shouldn't take
anywhere near 9 computer weeks to do! But then maybe you're using
Windows, which has significant overhead. Of course you could also do it
in a compiled language like C, which will also tremendously speed up the
process (a C program to do something like this is pretty simple).

> Other times, for new set of small sizes, we used on the fly. withouth
> usign 404 to react to.
>

Good you're not using the 404. But it's still a lot of unnecessary
overhead.

How long would it take your 3 computers to resize all the images you're
currently doing on your server? You're dumping that amount of overhead
plus more on the server.

> Just first time any one enters a page that have new images, new images
> were generated. And never happened that any image have been accesses
> directly previous to its generation.
>

Which is putting unnecessary overhead on the server.

> The images are always served directly throught lighttp, the php necesary
> to generate images was always inside the php app that generate the web
> pages.
>
> Greetings
>
>

You still have significant overhead on the server. Plus now you've
added unnecessary complexity to your application.

[Shake]

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.