| Re: Windows binaries 64bit for PHP [message #178091 is a reply to message #178085] |
Sun, 13 May 2012 11:46   |
Shake
Messages: 40
Registered: May 2012
Karma: 0
|
Member |
|
|
Après mûre réflexion, Jerry Stuckle a écrit :
> You need to get some better computers.
NOT. Only if I try to batch. On-the-fly everything goes well. SO
on-the-fly works better.
Batch requieres a lot of cpu and space to do all the work, On-the-fly
requires a little amount of cpu and space diluted in the normal server
work.
Greetings
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178092 is a reply to message #178091] |
Sun, 13 May 2012 12:50 |
Peter H. Coffin
Messages: 245
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Sun, 13 May 2012 13:46:06 +0200, Shake wrote:
> Apr?s m?re r?flexion, Jerry Stuckle a ?crit :
>
>> You need to get some better computers.
>
> NOT. Only if I try to batch. On-the-fly everything goes well. SO
> on-the-fly works better.
>
> Batch requieres a lot of cpu and space to do all the work, On-the-fly
> requires a little amount of cpu and space diluted in the normal server
> work.
'cause it takes SO MUCH LONGER to resize images on a computer that's
doing nothing but resize images than it does on a computer that's also
trying to answer http requests on a timely basis. Though I suppose it
would make a certain amount of sense if no one ever visited the website.
Then, you'd never need the images.
--
41. Once my power is secure, I will destroy all those pesky time-travel
devices.
--Peter Anspach's list of things to do as an Evil Overlord
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178093 is a reply to message #178091] |
Sun, 13 May 2012 13:06 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/13/2012 7:46 AM, Shake wrote:
> Après mûre réflexion, Jerry Stuckle a écrit :
>
>> You need to get some better computers.
>
> NOT. Only if I try to batch. On-the-fly everything goes well. SO
> on-the-fly works better.
>
> Batch requieres a lot of cpu and space to do all the work, On-the-fly
> requires a little amount of cpu and space diluted in the normal server
> work.
>
> Greetings
>
>
You aren't making any sense. Why would it take a server which is doing
more important things LESS time and resources to do the same job as
another machine not doing anything.
The answer is, it doesn't. In fact, overall, it takes the server MORE
time and resources to do the same job.
You have just shown you have absolutely no idea what load you're putting
on your server.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178094 is a reply to message #178092] |
Sun, 13 May 2012 14:15 |
Anders Wegge Keller
Messages: 30
Registered: May 2012
Karma: 0
|
Member |
|
|
"Peter H. Coffin" <hellsop(at)ninehells(dot)com> writes:
> 'cause it takes SO MUCH LONGER to resize images on a computer that's
> doing nothing but resize images than it does on a computer that's
> also trying to answer http requests on a timely basis.
Indeed it does, if you happen to have seven and a half million
images. I haven't followed this thread that m,uch, but ISTR that
figure being mentioned. Even if you had the hardware to resize 10
images a second, you are still looking at close to 10 days of
processing time. What do you propose to do in that period, when a
request for an image that has not yet been processed, arrives?
> Though I suppose it would make a certain amount of sense if no one
> ever visited the website. Then, you'd never need the images.
Ohh, the maturity of people in this group. It takes me back to my
kindergarten days :)
--
/Wegge
Leder efter redundant peering af dk.*,linux.debian.*
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178095 is a reply to message #178094] |
Sun, 13 May 2012 14:36 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/13/2012 10:15 AM, Anders Wegge Keller wrote:
> "Peter H. Coffin"<hellsop(at)ninehells(dot)com> writes:
>
>> 'cause it takes SO MUCH LONGER to resize images on a computer that's
>> doing nothing but resize images than it does on a computer that's
>> also trying to answer http requests on a timely basis.
>
> Indeed it does, if you happen to have seven and a half million
> images. I haven't followed this thread that m,uch, but ISTR that
> figure being mentioned. Even if you had the hardware to resize 10
> images a second, you are still looking at close to 10 days of
> processing time. What do you propose to do in that period, when a
> request for an image that has not yet been processed, arrives?
>
So you're going to force the server to waste its time resizing pages
instead of doing it's job (of serving web pages).
Of course, it's not a problem if you only bet 200 hits/day. But any
even moderately busy server has much better things to do.
>> Though I suppose it would make a certain amount of sense if no one
>> ever visited the website. Then, you'd never need the images.
>
> Ohh, the maturity of people in this group. It takes me back to my
> kindergarten days :)
>
He called it straight. I don't think anyone on this newsgroup has any
idea what an even moderately busy site is. They are amazed at 1M hits/ mo.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178096 is a reply to message #178093] |
Sun, 13 May 2012 16:54 |
Shake
Messages: 40
Registered: May 2012
Karma: 0
|
Member |
|
|
Jerry Stuckle a exposé le 13/05/2012 :
>
> You aren't making any sense. Why would it take a server which is doing more
> important things LESS time and resources to do the same job as another
> machine not doing anything.
This means you have to have two machines. At least.
>
> The answer is, it doesn't. In fact, overall, it takes the server MORE time
> and resources to do the same job.
But you have a server with MORE resources to do the job.
> You have just shown you have absolutely no idea what load you're putting on
> your server.
That's not true, simply you don't know which structure I had. And you
supposed I have a server doing all the job.
For generating little (thumbnails) images from other scaled image. The
resources used are really not so much. And the resources available by
the servers whre enought to do not change in a measurable way the time
delivering pages.
Tha fact is that having more machine more powerfull not doing nothing
else that reescaling images when required in batch proceses is a waste
of money and resources. In the other side, reescaling on the fly, of
course, implies some more process but not noticable.
Greetings
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178097 is a reply to message #178096] |
Sun, 13 May 2012 17:27 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/13/2012 12:54 PM, Shake wrote:
> Jerry Stuckle a exposé le 13/05/2012 :
>>
>> You aren't making any sense. Why would it take a server which is doing
>> more important things LESS time and resources to do the same job as
>> another machine not doing anything.
>
> This means you have to have two machines. At least.
>
You need a development machine in addition to your server, anyway. Or
do you do development on a live system?
And anyone who has 7.5M images has more than one machine!
>>
>> The answer is, it doesn't. In fact, overall, it takes the server MORE
>> time and resources to do the same job.
>
> But you have a server with MORE resources to do the job.
>
And more work to do. Of course, if you're only getting 200 hit/day,
that's not a problem.
>> You have just shown you have absolutely no idea what load you're
>> putting on your server.
>
> That's not true, simply you don't know which structure I had. And you
> supposed I have a server doing all the job.
>
Oh, I understand. What do you think will happen when you get to 300
hits/day?
> For generating little (thumbnails) images from other scaled image. The
> resources used are really not so much. And the resources available by
> the servers whre enought to do not change in a measurable way the time
> delivering pages.
>
You really have no idea how many resources it takes, that's obvious.
But then when you're only getting 200 hits/day you can do anything on
your server.
> Tha fact is that having more machine more powerfull not doing nothing
> else that reescaling images when required in batch proceses is a waste
> of money and resources. In the other side, reescaling on the fly, of
> course, implies some more process but not noticable.
>
> Greetings
>
>
The fact is, forcing a server with more important things to do to
rescale images is a complete waste of money and resources. But when you
only get 200 hits/day you have the resources to waste.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178099 is a reply to message #178096] |
Mon, 14 May 2012 03:26 |
Peter H. Coffin
Messages: 245
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Sun, 13 May 2012 18:54:01 +0200, Shake wrote:
> Jerry Stuckle a expos? le 13/05/2012 :
>
>> You aren't making any sense. Why would it take a server which is
>> doing more important things LESS time and resources to do the same
>> job as another machine not doing anything.
>
> This means you have to have two machines. At least.
Yes. Of course. That's what real websites do. They have multiple
webserver that JUST serve page data to the outside world. They have
a dedicated database machine. Usually at least two of those, some
accessable by the webservers, some not accessable from the outside at
all except through the sync connections to the outside db server. They
have at least one development server and a separate test server, for
website development alone. Other departments have their own machines as
well. What did you think we were talking about? Some little toy website
selling railroad models at a rate of three or four wagons a week?
--
The pluses in my current job include laughing in the face of Nobel
laureates who have just lost the only copy of their data. (Hey,
I'm still a BOFH).
-- Bob Dowling
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178105 is a reply to message #178099] |
Mon, 14 May 2012 07:51 |
Shake
Messages: 40
Registered: May 2012
Karma: 0
|
Member |
|
|
El 14/05/2012 5:26, Peter H. Coffin escribió:
> On Sun, 13 May 2012 18:54:01 +0200, Shake wrote:
>
>> Jerry Stuckle a expos? le 13/05/2012 :
>>
>>> You aren't making any sense. Why would it take a server which is
>>> doing more important things LESS time and resources to do the same
>>> job as another machine not doing anything.
>>
>> This means you have to have two machines. At least.
>
> Yes. Of course. That's what real websites do.
I was talking about the "server" like an entity, not entering on how
these one is "phisicaly".
For example the website I put as example, have two balanced front-ends
with php and apache, and two other machines with mysql, sphinx and a few
other servers. Images are on Amazon S3, and also we used (use) some ec2
machines.
But for me all this stuff is "the server". And to batch the image
scalating we are talking about using another "machine". For example the
machines for developers, or testing. They, of course, ar not powerful
machines. Don't need to be.
And I put numbers, about 266.000 page views per day. I am talking about
a real case. Not teorethical. And we tried both methods, batching and
on-the-fly.
And the result is: On the fly is more flexible, more quick to put on
production new sizes. And it have to be used when images are not so big.
If we have to scale the originals to a big size, on the fly could be a
big problem. The true is that always is a problem in any manner when you
have to scale to big sizes.
But when you need a new little image size, and you can use the nearest
bigger scaled image, process is quick enough to do on-the-fly without
penalizing speed, or overload on the server.
Greetings
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178111 is a reply to message #178105] |
Mon, 14 May 2012 12:04 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/14/2012 3:51 AM, Shake wrote:
> El 14/05/2012 5:26, Peter H. Coffin escribió:
>> On Sun, 13 May 2012 18:54:01 +0200, Shake wrote:
>>
>>> Jerry Stuckle a expos? le 13/05/2012 :
>>>
>>>> You aren't making any sense. Why would it take a server which is
>>>> doing more important things LESS time and resources to do the same
>>>> job as another machine not doing anything.
>>>
>>> This means you have to have two machines. At least.
>>
>> Yes. Of course. That's what real websites do.
>
> I was talking about the "server" like an entity, not entering on how
> these one is "phisicaly".
>
> For example the website I put as example, have two balanced front-ends
> with php and apache, and two other machines with mysql, sphinx and a few
> other servers. Images are on Amazon S3, and also we used (use) some ec2
> machines.
>
> But for me all this stuff is "the server". And to batch the image
> scalating we are talking about using another "machine". For example the
> machines for developers, or testing. They, of course, ar not powerful
> machines. Don't need to be.
>
> And I put numbers, about 266.000 page views per day. I am talking about
> a real case. Not teorethical. And we tried both methods, batching and
> on-the-fly.
>
> And the result is: On the fly is more flexible, more quick to put on
> production new sizes. And it have to be used when images are not so big.
>
> If we have to scale the originals to a big size, on the fly could be a
> big problem. The true is that always is a problem in any manner when you
> have to scale to big sizes.
>
> But when you need a new little image size, and you can use the nearest
> bigger scaled image, process is quick enough to do on-the-fly without
> penalizing speed, or overload on the server.
>
> Greetings
You can do that when you have such a light load. Get a real load and
you're in trouble.
But even with that, you should be resizing offline and not requiring the
server to do it.
But it sounds like you're too cheap to get your developers decent
machines, and have no idea how to scale images. The "nearest bigger
scaled image" will almost certainly give a substandard image, especially
when you repeatedly rescale them.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178114 is a reply to message #178111] |
Mon, 14 May 2012 12:25 |
Shake
Messages: 40
Registered: May 2012
Karma: 0
|
Member |
|
|
El 14/05/2012 14:04, Jerry Stuckle escribió:
>
> You can do that when you have such a light load. Get a real load and
> you're in trouble.
No. The EC2 machines does the image scaling and save the results on S3.
The thing is that first user getting the image will have to wait a
little more. That's true, but the server will not be overloaded.
Ec2 could "grow" when necesary getting more CPU to "battle" the overload
without troubles. And cheapest than buying big machines to process
millions ob images offline, and then put online wasting a lot of traffic...
> But even with that, you should be resizing offline and not requiring the
> server to do it.
Not always possible, My way, first user, 2 second delay (in worst cases,
reescaling 4x3 images). Your way, all users three weeks of waiting.
In real traffic, new images are scaled dilued inside normal traffic in
an unnoticeable wat. After putting on a new size.. next weeks or average
time per pages have no noticeable changes.
>
> But it sounds like you're too cheap to get your developers decent
> machines,
Me? I am a developer. Not the boss. And as a developer I don't need
powerfull machines able to reescale milions of images :)
> and have no idea how to scale images. The "nearest bigger
> scaled image" will almost certainly give a substandard image, especially
> when you repeatedly rescale them.
Of course I know. I don't repeatedly scale all of them. You talk a lot
about things you don't know. I try to don't put every detail because I
though yoou can at least get the chance to believe that people have do
its work.
How we scale images (at lest since a few months)
Original size -> Big Size (watermarked if user wants)
Original size -> profile Size (Watermarked if user wants)
profile Size (previous to watermarking) -> Thumb_orig
profile Size (previous to watermarking) -> Thumb_size_2
profile Size (previous to watermarking) -> Thumb_size_3
Thumb orig_ is the bigger thumbs we have. And new are always smaller. So
from this point we use thumb_orig to create new thumb sizes. Its of
course a second reescale, but for this little images is enought. And the
alternative was to use the original, that usually is a to big image.
Using an >5Mpixels image to generate a 100x70px (for example) image have
no sense.
The "important" images are original, big and profile. The others are
just web little images.
Greetings
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178120 is a reply to message #178114] |
Mon, 14 May 2012 13:37 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/14/2012 8:25 AM, Shake wrote:
> El 14/05/2012 14:04, Jerry Stuckle escribió:
>>
>> You can do that when you have such a light load. Get a real load and
>> you're in trouble.
>
> No. The EC2 machines does the image scaling and save the results on S3.
> The thing is that first user getting the image will have to wait a
> little more. That's true, but the server will not be overloaded.
>
Get a rteal load and you're in trouble. You'll be taking CPU time
resizing images - EVERYONE will have to wait, not just one user. Get
busy enough and you'll bring the server to its knees.
> Ec2 could "grow" when necesary getting more CPU to "battle" the overload
> without troubles. And cheapest than buying big machines to process
> millions ob images offline, and then put online wasting a lot of traffic...
>
Or you can resize offline and not waste the server's resources. But
that would take a bit of skill, I do understand.
>> But even with that, you should be resizing offline and not requiring the
>> server to do it.
>
> Not always possible, My way, first user, 2 second delay (in worst cases,
> reescaling 4x3 images). Your way, all users three weeks of waiting.
>
It is always possible.
First of all, you shouldn't be waiting until the website is complete
before knowing what images you need to resize.
Second, you really have no idea how long it takes you to resize YOUR
images. You don't have 7.5M images - that was Daniel. And you have no
idea what equipment he has.
Third, if it does take 3 weeks to resize, then that's 3 weeks worth of
load you're requiring the server to perform. That's what you don't get
- the resizing takes time.
> In real traffic, new images are scaled dilued inside normal traffic in
> an unnoticeable wat. After putting on a new size.. next weeks or average
> time per pages have no noticeable changes.
>
In REAL traffic your server won't have time to serve the web pages - it
will be too busy resizing images. But your traffic is so light you
don't see it.
>>
>> But it sounds like you're too cheap to get your developers decent
>> machines,
>
> Me? I am a developer. Not the boss. And as a developer I don't need
> powerfull machines able to reescale milions of images :)
>
No, but the graphics people should. And good companies give their
developers good machines. And good companies know what shouldn't be
done on servers.
>> and have no idea how to scale images. The "nearest bigger
>> scaled image" will almost certainly give a substandard image, especially
>> when you repeatedly rescale them.
>
> Of course I know. I don't repeatedly scale all of them. You talk a lot
> about things you don't know. I try to don't put every detail because I
> though yoou can at least get the chance to believe that people have do
> its work.
>
That was your statement. And I suspect that's what you really do -
except this time you got caught at it. Nice try at back-pedaling.
> How we scale images (at lest since a few months)
>
> Original size -> Big Size (watermarked if user wants)
> Original size -> profile Size (Watermarked if user wants)
> profile Size (previous to watermarking) -> Thumb_orig
> profile Size (previous to watermarking) -> Thumb_size_2
> profile Size (previous to watermarking) -> Thumb_size_3
>
> Thumb orig_ is the bigger thumbs we have. And new are always smaller. So
> from this point we use thumb_orig to create new thumb sizes. Its of
> course a second reescale, but for this little images is enought. And the
> alternative was to use the original, that usually is a to big image.
> Using an >5Mpixels image to generate a 100x70px (for example) image have
> no sense.
>
> The "important" images are original, big and profile. The others are
> just web little images.
>
> Greetings
Gee, that's an awful lot of unnecessary work for the server. But I
guess as long as you get so little traffic you can afford to do so.
--
==================
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 #178123 is a reply to message #178120] |
Mon, 14 May 2012 14:22 |
Shake
Messages: 40
Registered: May 2012
Karma: 0
|
Member |
|
|
El 14/05/2012 15:37, Jerry Stuckle escribió:
> Get a rteal load and you're in trouble. You'll be taking CPU time
> resizing images - EVERYONE will have to wait, not just one user. Get
> busy enough and you'll bring the server to its knees.
¿?¿? You read/understood something of what I wrote?
[Balancer]
[httpd] [httpd] [EC2]
[Mysql*] [Sphinx*]
[] independent systems.
* And other services
EC2 Machine does the scaling. Both balanced httpd are ready to process
new incoming petitions. One of them have a process waiting answer from
ec2 and only this one take more time to finish. the "HARD WORK" is done
by auto-scalable EC2 machines.
>> Ec2 could "grow" when necesary getting more CPU to "battle" the overload
>> without troubles. And cheapest than buying big machines to process
>> millions ob images offline, and then put online wasting a lot of
>> traffic...
>
> Or you can resize offline and not waste the server's resources. But that
> would take a bit of skill, I do understand.
¿?¿? What you say is the easy way. But ineffective. And waste resources,
A LOT OF THEM. because implies having a few machines for a few days only
doing this work! And also implies a few days without having this work
available online!
The images have to be resizes yes or yes. You thought that "the server"
is only a http server. For me the server "do services". An the important
services for the company where I get a lot of experience about big
amount of image reescaling is having the images available for the user
today, just 2 seconds after the click, and not two weeks in the future,
just one second after the click.
If you think that doing resize on server is risky. Yes, it is. You have
to dimensionate correctly your hardware, and do a good logic. But it can
be done, it's done everyday by a lot of companies. I worked in one of
them. I saw. And I could empirecally (exists this word?) test the way
you explain and the way I explain. And the result in the real world, is
that the little overhead of this last is insignificant compared with the
benefits.
>
>>> But even with that, you should be resizing offline and not requiring the
>>> server to do it.
>>
>> Not always possible, My way, first user, 2 second delay (in worst cases,
>> reescaling 4x3 images). Your way, all users three weeks of waiting.
>>
>
> It is always possible.
Is not if images sizes changes before you finished reescaling.
>
> First of all, you shouldn't be waiting until the website is complete
> before knowing what images you need to resize.
This say nothing.
> Second, you really have no idea how long it takes you to resize YOUR
> images. You don't have 7.5M images - that was Daniel. And you have no
> idea what equipment he has.
I don't know how long take Daniel's images. I know how long takes mine.
I exposed mi case: 1million images. And post by post I have been
detailing some data about the structure used to host.
>
> Third, if it does take 3 weeks to resize, then that's 3 weeks worth of
> load you're requiring the server to perform. That's what you don't get -
> the resizing takes time.
You are mixing apples and oranges. It take 3 weeks to resize de images
in computers that are not thinked to do. And buy a "good computer" only
to scale off-line images is more expensive than using a good dimensioned
server.
>> In real traffic, new images are scaled dilued inside normal traffic in
>> an unnoticeable wat. After putting on a new size.. next weeks or average
>> time per pages have no noticeable changes.
>>
> In REAL traffic your server won't have time to serve the web pages - it
> will be too busy resizing images. But your traffic is so light you don't
> see it.
But it is now working. On real world. And with traffic. Perhaps I do
magic... and I am a wizard or you're wrong.
>
>>>
>>> But it sounds like you're too cheap to get your developers decent
>>> machines,
>>
>> Me? I am a developer. Not the boss. And as a developer I don't need
>> powerfull machines able to reescale milions of images :)
>>
>
> No, but the graphics people should. And good companies give their
> developers good machines. And good companies know what shouldn't be done
> on servers.
The graphics people? what are you talking about? we are talking about
rescaling images, not about its artistical content.
And also we are not talking about good or bad companies. And I you think
you have skills to judge about companies from a fragmented view you take
from a few words on Usenet... Perhaps you are also a wizard like me...
>
> That was your statement. And I suspect that's what you really do -
> except this time you got caught at it. Nice try at back-pedaling.
I said what I said. And there is a lot of things I don't said. But you
decided how I do what I don't said.
If explaining about this is for you "back-pedaling" what are you trying
to say? That I am lying or something like that?
And... Why? :) have no sense.
> Gee, that's an awful lot of unnecessary work for the server. But I guess
> as long as you get so little traffic you can afford to do so.
I wrote the traffic. 8 millions page views per month. And. Is work the
server have to do! Because we serve images!!! And we serv today, not
next week.
Greetings
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178124 is a reply to message #178123] |
Mon, 14 May 2012 14:45 |
Michael Fesser
Messages: 215
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
.oO(Shake)
> El 14/05/2012 15:37, Jerry Stuckle escribió:
>
>> Third, if it does take 3 weeks to resize, then that's 3 weeks worth of
>> load you're requiring the server to perform. That's what you don't get -
>> the resizing takes time.
>
> You are mixing apples and oranges. It take 3 weeks to resize de images
> in computers that are not thinked to do. And buy a "good computer" only
> to scale off-line images is more expensive than using a good dimensioned
> server.
Additionally resizing offline would create a whole bunch of images that
are hardly used, if ever, while doing it on-the-fly just creates what's
really needed.
Micha
--
http://mfesser.de/blickwinkel
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178128 is a reply to message #178123] |
Mon, 14 May 2012 15:53 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Shake wrote:
> El 14/05/2012 15:37, Jerry Stuckle escribió:
>> Get a rteal load and you're in trouble. You'll be taking CPU time
>> resizing images - EVERYONE will have to wait, not just one user. Get
>> busy enough and you'll bring the server to its knees.
>
> ¿?¿? You read/understood something of what I wrote?
No point in explaining anything to Stucklehead.
He is by his own definition, always right.
--
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 #178130 is a reply to message #178123] |
Mon, 14 May 2012 18:06 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/14/2012 10:22 AM, Shake wrote:
> El 14/05/2012 15:37, Jerry Stuckle escribió:
>> Get a rteal load and you're in trouble. You'll be taking CPU time
>> resizing images - EVERYONE will have to wait, not just one user. Get
>> busy enough and you'll bring the server to its knees.
>
> ¿?¿? You read/understood something of what I wrote?
>
Yes, I understood EVERYTHING you said.
>
> [Balancer]
>
> [httpd] [httpd] [EC2]
>
> [Mysql*] [Sphinx*]
>
> [] independent systems.
> * And other services
>
> EC2 Machine does the scaling. Both balanced httpd are ready to process
> new incoming petitions. One of them have a process waiting answer from
> ec2 and only this one take more time to finish. the "HARD WORK" is done
> by auto-scalable EC2 machines.
>
Which actually means nothing. The server is still tied up resizing
images, which means it can't do its real job (serving page requests).
>
>
>>> Ec2 could "grow" when necesary getting more CPU to "battle" the overload
>>> without troubles. And cheapest than buying big machines to process
>>> millions ob images offline, and then put online wasting a lot of
>>> traffic...
>>
>> Or you can resize offline and not waste the server's resources. But that
>> would take a bit of skill, I do understand.
>
> ¿?¿? What you say is the easy way. But ineffective. And waste resources,
> A LOT OF THEM. because implies having a few machines for a few days only
> doing this work! And also implies a few days without having this work
> available online!
>
It is a waste of SERVER resources to force the server to do it! And
that is much more critical than workstation resources.
> The images have to be resizes yes or yes. You thought that "the server"
> is only a http server. For me the server "do services". An the important
> services for the company where I get a lot of experience about big
> amount of image reescaling is having the images available for the user
> today, just 2 seconds after the click, and not two weeks in the future,
> just one second after the click.
>
Web sites don't go online in 5 minutes. You should know well ahead of
when the site goes "live" what resources are required, and plan to do
the resizing. But I also understand that's not possible when you're
flying by the seat of your pants.
> If you think that doing resize on server is risky. Yes, it is. You have
> to dimensionate correctly your hardware, and do a good logic. But it can
> be done, it's done everyday by a lot of companies. I worked in one of
> them. I saw. And I could empirecally (exists this word?) test the way
> you explain and the way I explain. And the result in the real world, is
> that the little overhead of this last is insignificant compared with the
> benefits.
>
In the "real world", people don't do unnecessary work on the server.
>
>>
>>>> But even with that, you should be resizing offline and not requiring
>>>> the
>>>> server to do it.
>>>
>>> Not always possible, My way, first user, 2 second delay (in worst cases,
>>> reescaling 4x3 images). Your way, all users three weeks of waiting.
>>>
>>
>> It is always possible.
>
> Is not if images sizes changes before you finished reescaling.
>
Sure, it is ALWAYS possible. But why would the image size change before
rescaling? You should know ahead of time what you're going to need.
It's called PLANNING, not flying by the seat of your pants.
And BTW - it's not just one user waiting - it's EVERYONE. You're taking
CPU resources, amongst other things, and there is a limit to what's
available. What it being taken by resizing is not available to anyone else.
Not a real problem when you have such a lightly loaded site as you do.
But I can see why you need all that power to serve so few hits.
>>
>> First of all, you shouldn't be waiting until the website is complete
>> before knowing what images you need to resize.
>
> This say nothing.
>
This is called PLANNING.
>
>> Second, you really have no idea how long it takes you to resize YOUR
>> images. You don't have 7.5M images - that was Daniel. And you have no
>> idea what equipment he has.
>
> I don't know how long take Daniel's images. I know how long takes mine.
> I exposed mi case: 1million images. And post by post I have been
> detailing some data about the structure used to host.
>
OK, 1M images should be done in a few hours on a decent machine, not the
3 weeks you claim. But you really have no idea how long it takes, do you?
And if that fast of a server takes an extra 2 seconds to resize one
image, you've got more problems than just the resizing.
>>
>> Third, if it does take 3 weeks to resize, then that's 3 weeks worth of
>> load you're requiring the server to perform. That's what you don't get -
>> the resizing takes time.
>
> You are mixing apples and oranges. It take 3 weeks to resize de images
> in computers that are not thinked to do. And buy a "good computer" only
> to scale off-line images is more expensive than using a good dimensioned
> server.
>
No, I'm not mixing anything. And a good dimensioned server is MUCH MORE
EXPENSIVE - both to purchase and to maintain - than one decent workstation.
>>> In real traffic, new images are scaled dilued inside normal traffic in
>>> an unnoticeable wat. After putting on a new size.. next weeks or average
>>> time per pages have no noticeable changes.
>>>
>> In REAL traffic your server won't have time to serve the web pages - it
>> will be too busy resizing images. But your traffic is so light you don't
>> see it.
>
> But it is now working. On real world. And with traffic. Perhaps I do
> magic... and I am a wizard or you're wrong.
>
260K hits/day is not "traffic". But you're already showing the
inefficiencies by needing that much power for that few hits. I do more
than that on one of my VPS's, for instance.
>>
>>>>
>>>> But it sounds like you're too cheap to get your developers decent
>>>> machines,
>>>
>>> Me? I am a developer. Not the boss. And as a developer I don't need
>>> powerfull machines able to reescale milions of images :)
>>>
>>
>> No, but the graphics people should. And good companies give their
>> developers good machines. And good companies know what shouldn't be done
>> on servers.
>
> The graphics people? what are you talking about? we are talking about
> rescaling images, not about its artistical content.
>
It is graphics, and is best handled by graphics people. That's the way
major companies do it, for instance.
> And also we are not talking about good or bad companies. And I you think
> you have skills to judge about companies from a fragmented view you take
> from a few words on Usenet... Perhaps you are also a wizard like me...
>
I can tell from what you told me about your operation.
>>
>> That was your statement. And I suspect that's what you really do -
>> except this time you got caught at it. Nice try at back-pedaling.
>
> I said what I said. And there is a lot of things I don't said. But you
> decided how I do what I don't said.
>
Yes, and if you didn't mean what you said, you shouldn't have said it.
> If explaining about this is for you "back-pedaling" what are you trying
> to say? That I am lying or something like that?
>
You're changing your story when you got caught.
> And... Why? :) have no sense.
>
>> Gee, that's an awful lot of unnecessary work for the server. But I guess
>> as long as you get so little traffic you can afford to do so.
>
> I wrote the traffic. 8 millions page views per month. And. Is work the
> server have to do! Because we serve images!!! And we serv today, not
> next week.
>
> Greetings
Yes, 8M is a light load. But you need an awful lot of power to even
handle that light load. Now I know why.
--
==================
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 #178131 is a reply to message #178124] |
Mon, 14 May 2012 18:07 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/14/2012 10:45 AM, Michael Fesser wrote:
> .oO(Shake)
>
>> El 14/05/2012 15:37, Jerry Stuckle escribió:
>>
>>> Third, if it does take 3 weeks to resize, then that's 3 weeks worth of
>>> load you're requiring the server to perform. That's what you don't get -
>>> the resizing takes time.
>>
>> You are mixing apples and oranges. It take 3 weeks to resize de images
>> in computers that are not thinked to do. And buy a "good computer" only
>> to scale off-line images is more expensive than using a good dimensioned
>> server.
>
> Additionally resizing offline would create a whole bunch of images that
> are hardly used, if ever, while doing it on-the-fly just creates what's
> really needed.
>
> Micha
>
Why would you resize an image if it's never needed? And if it's needed
even ONCE resizing offline is better.
--
==================
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 #178132 is a reply to message #178130] |
Mon, 14 May 2012 18:36 |
Shake
Messages: 40
Registered: May 2012
Karma: 0
|
Member |
|
|
Après mûre réflexion, Jerry Stuckle a écrit :
>
> Yes, I understood EVERYTHING you said.
Sure?
>> [httpd] [httpd] [EC2]
>> EC2 Machine does the scaling.
>
> Which actually means nothing. The server is still tied up resizing images,
> which means it can't do its real job (serving page requests).
The server that have to serve page request, is not resizing images.
Perhaps, if someone ask you if you understood, the first thing you have
to do if check if really you understood.
And I finish here, because if obvious that if the habitual people of
this group is not capable to dialogue with you, me and my poor english
are totally out of any posibility to do.
Greetings
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178134 is a reply to message #178132] |
Mon, 14 May 2012 18:53 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/14/2012 2:36 PM, Shake wrote:
> Après mûre réflexion, Jerry Stuckle a écrit :
>>
>> Yes, I understood EVERYTHING you said.
>
> Sure?
>
>>> [httpd] [httpd] [EC2]
>>> EC2 Machine does the scaling.
>>
>> Which actually means nothing. The server is still tied up resizing
>> images, which means it can't do its real job (serving page requests).
>
> The server that have to serve page request, is not resizing images.
> Perhaps, if someone ask you if you understood, the first thing you have
> to do if check if really you understood.
>
You have stated you have the server resizing the images. Now you're
saying it's not. Which is it?
> And I finish here, because if obvious that if the habitual people of
> this group is not capable to dialogue with you, me and my poor english
> are totally out of any posibility to do.
>
> Greetings
>
>
It's not your ENGLISH which is making you incapable of understanding.
--
==================
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 #178138 is a reply to message #178131] |
Mon, 14 May 2012 20:37 |
Michael Fesser
Messages: 215
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
.oO(Jerry Stuckle)
> On 5/14/2012 10:45 AM, Michael Fesser wrote:
>
>> Additionally resizing offline would create a whole bunch of images that
>> are hardly used, if ever, while doing it on-the-fly just creates what's
>> really needed.
>
> Why would you resize an image if it's never needed?
You don't know beforehand which images will really be requested by the
visitors. Some of them may only be used once a month, if ever.
Micha
--
http://mfesser.de/blickwinkel
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178139 is a reply to message #178130] |
Mon, 14 May 2012 21:00 |
Michael Fesser
Messages: 215
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
.oO(Jerry Stuckle)
> On 5/14/2012 10:22 AM, Shake wrote:
>
>> [Balancer]
>>
>> [httpd] [httpd] [EC2]
>>
>> [Mysql*] [Sphinx*]
>>
>> [] independent systems.
>> * And other services
>>
>> EC2 Machine does the scaling. Both balanced httpd are ready to process
>> new incoming petitions. One of them have a process waiting answer from
>> ec2 and only this one take more time to finish. the "HARD WORK" is done
>> by auto-scalable EC2 machines.
>
> Which actually means nothing. The server is still tied up resizing
> images, which means it can't do its real job (serving page requests).
Obviously a picture server doesn't serve pages.
>> ¿?¿? What you say is the easy way. But ineffective. And waste resources,
>> A LOT OF THEM. because implies having a few machines for a few days only
>> doing this work! And also implies a few days without having this work
>> available online!
>
> It is a waste of SERVER resources to force the server to do it! And
> that is much more critical than workstation resources.
How could a server waste resources by doing the job it is dedicated for?
Does a database server waste resource by answering SQL requests? If
there's a server (even a virtual one) dedicated to serve pictures in
various formats, how could it waste resources by doing exactly that?
>> The images have to be resizes yes or yes. You thought that "the server"
>> is only a http server. For me the server "do services". An the important
>> services for the company where I get a lot of experience about big
>> amount of image reescaling is having the images available for the user
>> today, just 2 seconds after the click, and not two weeks in the future,
>> just one second after the click.
>
> Web sites don't go online in 5 minutes. You should know well ahead of
> when the site goes "live" what resources are required, and plan to do
> the resizing. But I also understand that's not possible when you're
> flying by the seat of your pants.
So you know beforehand which resources will actually be requested by
your visitors? Do you also know the lottery numbers for next week?
With a million images there's a good chance that a lot of them will
hardly be requested, if ever. I consider it a waste of server and
network resources to pre-calculate and upload all of them at once.
If there's a picture server - let it do the work as necessary.
>> If you think that doing resize on server is risky. Yes, it is. You have
>> to dimensionate correctly your hardware, and do a good logic. But it can
>> be done, it's done everyday by a lot of companies. I worked in one of
>> them. I saw. And I could empirecally (exists this word?) test the way
>> you explain and the way I explain. And the result in the real world, is
>> that the little overhead of this last is insignificant compared with the
>> benefits.
>
> In the "real world", people don't do unnecessary work on the server.
Doesn't seem to happen here. Obviously the EC2 cloud does exactly what
it is intended to do and paid for.
> And BTW - it's not just one user waiting - it's EVERYONE. You're taking
> CPU resources, amongst other things, and there is a limit to what's
> available. What it being taken by resizing is not available to anyone else.
In a cloud environment CPU power is the least problem.
> Not a real problem when you have such a lightly loaded site as you do.
> But I can see why you need all that power to serve so few hits.
No paragraph of you without insults, directly or subtly. You can't live
without that, right?
>>> First of all, you shouldn't be waiting until the website is complete
>>> before knowing what images you need to resize.
>>
>> This say nothing.
>
> This is called PLANNING.
You can't plan your visitors.
Micha
--
http://mfesser.de/blickwinkel
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178140 is a reply to message #178134] |
Mon, 14 May 2012 21:04 |
Michael Fesser
Messages: 215
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
.oO(Jerry Stuckle)
> On 5/14/2012 2:36 PM, Shake wrote:
>> Après mûre réflexion, Jerry Stuckle a écrit :
>>>
>>> Yes, I understood EVERYTHING you said.
>>
>> Sure?
>>
>>>> [httpd] [httpd] [EC2]
>>>> EC2 Machine does the scaling.
>>>
>>> Which actually means nothing. The server is still tied up resizing
>>> images, which means it can't do its real job (serving page requests).
>>
>> The server that have to serve page request, is not resizing images.
>> Perhaps, if someone ask you if you understood, the first thing you have
>> to do if check if really you understood.
>
> You have stated you have the server resizing the images. Now you're
> saying it's not. Which is it?
Obviously you didn't understand EVERYTHING he said. Might I suggest to
read the thread again?
Micha
--
http://mfesser.de/blickwinkel
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178142 is a reply to message #178138] |
Mon, 14 May 2012 21:47 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/14/2012 4:37 PM, Michael Fesser wrote:
> .oO(Jerry Stuckle)
>
>> On 5/14/2012 10:45 AM, Michael Fesser wrote:
>>
>>> Additionally resizing offline would create a whole bunch of images that
>>> are hardly used, if ever, while doing it on-the-fly just creates what's
>>> really needed.
>>
>> Why would you resize an image if it's never needed?
>
> You don't know beforehand which images will really be requested by the
> visitors. Some of them may only be used once a month, if ever.
>
> Micha
>
If you need it once a millenium, you need to resize it. And if you
don't know what's needed on the site, you need to look more closely at
your site.
Sure, there may be products which will never be looked at - but how do
you know who might want a $10,000 ping pong ball?
Offline resizing is free as far as the server is concerned. And the
server load is most important.
--
==================
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 #178143 is a reply to message #178140] |
Mon, 14 May 2012 21:48 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/14/2012 5:04 PM, Michael Fesser wrote:
> .oO(Jerry Stuckle)
>
>> On 5/14/2012 2:36 PM, Shake wrote:
>>> Après mûre réflexion, Jerry Stuckle a écrit :
>>>>
>>>> Yes, I understood EVERYTHING you said.
>>>
>>> Sure?
>>>
>>>> > [httpd] [httpd] [EC2]
>>>> > EC2 Machine does the scaling.
>>>>
>>>> Which actually means nothing. The server is still tied up resizing
>>>> images, which means it can't do its real job (serving page requests).
>>>
>>> The server that have to serve page request, is not resizing images.
>>> Perhaps, if someone ask you if you understood, the first thing you have
>>> to do if check if really you understood.
>>
>> You have stated you have the server resizing the images. Now you're
>> saying it's not. Which is it?
>
> Obviously you didn't understand EVERYTHING he said. Might I suggest to
> read the thread again?
>
> Micha
>
Yes, I did understand him, Micha. He has way more server than is
required for his load, probably due to his poor coding techniques
(loading the servers down with unnecessary work).
--
==================
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 #178144 is a reply to message #178139] |
Mon, 14 May 2012 21:57 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/14/2012 5:00 PM, Michael Fesser wrote:
> .oO(Jerry Stuckle)
>
>> On 5/14/2012 10:22 AM, Shake wrote:
>>
>>> [Balancer]
>>>
>>> [httpd] [httpd] [EC2]
>>>
>>> [Mysql*] [Sphinx*]
>>>
>>> [] independent systems.
>>> * And other services
>>>
>>> EC2 Machine does the scaling. Both balanced httpd are ready to process
>>> new incoming petitions. One of them have a process waiting answer from
>>> ec2 and only this one take more time to finish. the "HARD WORK" is done
>>> by auto-scalable EC2 machines.
>>
>> Which actually means nothing. The server is still tied up resizing
>> images, which means it can't do its real job (serving page requests).
>
> Obviously a picture server doesn't serve pages.
>
Nope, but resizing an image requires server resources which can be
better spent elsewhere.
>>> ¿?¿? What you say is the easy way. But ineffective. And waste resources,
>>> A LOT OF THEM. because implies having a few machines for a few days only
>>> doing this work! And also implies a few days without having this work
>>> available online!
>>
>> It is a waste of SERVER resources to force the server to do it! And
>> that is much more critical than workstation resources.
>
> How could a server waste resources by doing the job it is dedicated for?
> Does a database server waste resource by answering SQL requests? If
> there's a server (even a virtual one) dedicated to serve pictures in
> various formats, how could it waste resources by doing exactly that?
>
The server is made for serving requests. Resizing images is not
necessary for serving the request, if the correct image size has been
uploaded already.
Having to have a special server just to serve images in different sizes
should tell you how much server load is being wasted!
And your question about SQL is completely unrelated. I will ignore it.
>>> The images have to be resizes yes or yes. You thought that "the server"
>>> is only a http server. For me the server "do services". An the important
>>> services for the company where I get a lot of experience about big
>>> amount of image reescaling is having the images available for the user
>>> today, just 2 seconds after the click, and not two weeks in the future,
>>> just one second after the click.
>>
>> Web sites don't go online in 5 minutes. You should know well ahead of
>> when the site goes "live" what resources are required, and plan to do
>> the resizing. But I also understand that's not possible when you're
>> flying by the seat of your pants.
>
> So you know beforehand which resources will actually be requested by
> your visitors? Do you also know the lottery numbers for next week?
>
I know what sizes of images are going to be needed, where they are
needed, and what I have to start with images. That's all I need to
provide the correct size for all images.
> With a million images there's a good chance that a lot of them will
> hardly be requested, if ever. I consider it a waste of server and
> network resources to pre-calculate and upload all of them at once.
> If there's a picture server - let it do the work as necessary.
>
"hardly be requested" is not the same as "never needed". And uploading
images is almost no load at all on a server; you could probably upload
10K pictures and not use as many server resources as resizing one image
(ftp is VERY resource unintensive!).
As for network resources - no, if your server is pushing 10mb/s or more,
then I wouldn't recommend doing it at that time. However, it doesn't do
it all the time. On the busy sites I've had, I know when the peaks are
and don't even touch the server at those times.
>>> If you think that doing resize on server is risky. Yes, it is. You have
>>> to dimensionate correctly your hardware, and do a good logic. But it can
>>> be done, it's done everyday by a lot of companies. I worked in one of
>>> them. I saw. And I could empirecally (exists this word?) test the way
>>> you explain and the way I explain. And the result in the real world, is
>>> that the little overhead of this last is insignificant compared with the
>>> benefits.
>>
>> In the "real world", people don't do unnecessary work on the server.
>
> Doesn't seem to happen here. Obviously the EC2 cloud does exactly what
> it is intended to do and paid for.
>
Yea, and if he resized the images offline he wouldn't need all that
power. As I told him - I have one VPS handling more hits than that per
day. And it's not even a full server. But it does use a lot of PHP and
MySQL (plus some perl).
>> And BTW - it's not just one user waiting - it's EVERYONE. You're taking
>> CPU resources, amongst other things, and there is a limit to what's
>> available. What it being taken by resizing is not available to anyone else.
>
> In a cloud environment CPU power is the least problem.
>
If he had a true cloud environment, that would be true. But it isn't.
>> Not a real problem when you have such a lightly loaded site as you do.
>> But I can see why you need all that power to serve so few hits.
>
> No paragraph of you without insults, directly or subtly. You can't live
> without that, right?
>
Just a fact. I can see why he needs all that power.
>>>> First of all, you shouldn't be waiting until the website is complete
>>>> before knowing what images you need to resize.
>>>
>>> This say nothing.
>>
>> This is called PLANNING.
>
> You can't plan your visitors.
>
> Micha
>
No, but I don't need to plan the visitors. I only need to plan the site.
--
==================
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 #178229 is a reply to message #178074] |
Wed, 23 May 2012 20:45 |
PlastiqueMAN
Messages: 5
Registered: September 2010
Karma: 0
|
Junior Member |
|
|
On 2012-05-11 23:38:06 +0000, The Natural Philosopher said:
> Shake wrote:
>> Jerry Stuckle avait écrit le 11/05/2012 :
>>> On 5/11/2012 2:58 PM, Shake wrote:
>>>> Jerry Stuckle a couché sur son écran :
>>>> >
>>>> > Loading the script, starting the scripting module, initializing the
>>>> > environment, interpreting and running the script, checking for the
>>>> > presence of the image, storing a resized script if necessary, loading
>>>> > the image and sending it, and cleaning up the environment.
>>>> >
>>>> > This vs. sending the image directly via an <img ...> tag.
>>>> >
>>>> > Nope, no extra overhead! And no way to send the image without a script!
>>>> >
>>>>
>>>> The Extra overhead is something like in the code that generate the page:
>>>>
>>>> <?php
>>>> if(!file_exists(IMG_PATH.$image_file)) scaleImage($image_file);
>>>> ?>
>>>>
>>>> Not look like an "application killer" to me.
>>>>
>>>> Greetings.
>>>>
>>>>
>>>
>>> There's a lot more to the overhead than that!
>>
>> Which?
>>
>> Is the image going to be accessed directly by its URL, or is loaded
>> inside a webpage? I am sure is this last case.
>>
>> So Loading a PHP script will occur 99.999% if you reescaled the image
>> previously with a batch or not. All the work of load an script, will be
>> done always.
>>
>> I don't believe that "react" to a 404 error is the good aproach, but
>> generating dinamically the scaled images when the page that show them
>> is required.
>>
>> And this only need the few lines to test if file exists and generate
>> the images if not.
>>
>> The fact that the image is directly accessed without pasing first for
>> the php script...
>
> is hardly any CPU.
>
> The same actions take place: the file must be opened headers
> constricted and then data streamed. whether apache or PHP does this is
> scarcely an issue.
Sorry to say this, but PHP compared to the default handler in Apache is
sloooooow. You can test this simply by writing a php script that copies
some large files from a directory to another and then write an
identical C program...
If this site we're talking about needs to serve a lot of request, I
have to agree with Jerry on this one.
>>
>> Someone talked about a catalog of image... I am sure they are accessed
>> through a we, not directly.
>>
>> Even if they are accessed via search engines, these search engines have
>> to visit the scripts that would generate the scaled images.
>>
>> Greetings.
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178236 is a reply to message #178229] |
Thu, 24 May 2012 04:18 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/23/2012 4:45 PM, PlastiqueMAN wrote:
> On 2012-05-11 23:38:06 +0000, The Natural Philosopher said:
>
>> Shake wrote:
>>> Jerry Stuckle avait écrit le 11/05/2012 :
>>>> On 5/11/2012 2:58 PM, Shake wrote:
>>>> > Jerry Stuckle a couché sur son écran :
>>>> >>
>>>> >> Loading the script, starting the scripting module, initializing the
>>>> >> environment, interpreting and running the script, checking for the
>>>> >> presence of the image, storing a resized script if necessary, loading
>>>> >> the image and sending it, and cleaning up the environment.
>>>> >>
>>>> >> This vs. sending the image directly via an <img ...> tag.
>>>> >>
>>>> >> Nope, no extra overhead! And no way to send the image without a
>>>> >> script!
>>>> >>
>>>> >
>>>> > The Extra overhead is something like in the code that generate the
>>>> > page:
>>>> >
>>>> > <?php
>>>> > if(!file_exists(IMG_PATH.$image_file)) scaleImage($image_file);
>>>> > ?>
>>>> >
>>>> > Not look like an "application killer" to me.
>>>> >
>>>> > Greetings.
>>>> >
>>>> >
>>>>
>>>> There's a lot more to the overhead than that!
>>>
>>> Which?
>>>
>>> Is the image going to be accessed directly by its URL, or is loaded
>>> inside a webpage? I am sure is this last case.
>>>
>>> So Loading a PHP script will occur 99.999% if you reescaled the image
>>> previously with a batch or not. All the work of load an script, will
>>> be done always.
>>>
>>> I don't believe that "react" to a 404 error is the good aproach, but
>>> generating dinamically the scaled images when the page that show them
>>> is required.
>>>
>>> And this only need the few lines to test if file exists and generate
>>> the images if not.
>>>
>>> The fact that the image is directly accessed without pasing first for
>>> the php script...
>>
>> is hardly any CPU.
>>
>> The same actions take place: the file must be opened headers
>> constricted and then data streamed. whether apache or PHP does this is
>> scarcely an issue.
>
> Sorry to say this, but PHP compared to the default handler in Apache is
> sloooooow. You can test this simply by writing a php script that copies
> some large files from a directory to another and then write an identical
> C program...
>
What do you expect - an interpreted program versus q compiled program?
The compiled program will always wind.
> If this site we're talking about needs to serve a lot of request, I have
> to agree with Jerry on this one.
>
>>>
>>> Someone talked about a catalog of image... I am sure they are
>>> accessed through a we, not directly.
>>>
>>> Even if they are accessed via search engines, these search engines
>>> have to visit the scripts that would generate the scaled images.
>>>
>>> Greetings.
>
>
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178239 is a reply to message #178236] |
Thu, 24 May 2012 09:40 |
Stig Vestl
Messages: 1
Registered: May 2012
Karma: 0
|
Junior Member |
|
|
On 2012-05-24 04:18:30 +0000, Jerry Stuckle said:
> On 5/23/2012 4:45 PM, PlastiqueMAN wrote:
>> On 2012-05-11 23:38:06 +0000, The Natural Philosopher said:
>>
>>> Shake wrote:
>>>> Jerry Stuckle avait écrit le 11/05/2012 :
>>>> > On 5/11/2012 2:58 PM, Shake wrote:
>>>> >> Jerry Stuckle a couché sur son écran :
>>>> >>>
>>>> >>> Loading the script, starting the scripting module, initializing the
>>>> >>> environment, interpreting and running the script, checking for the
>>>> >>> presence of the image, storing a resized script if necessary, loading
>>>> >>> the image and sending it, and cleaning up the environment.
>>>> >>>
>>>> >>> This vs. sending the image directly via an <img ...> tag.
>>>> >>>
>>>> >>> Nope, no extra overhead! And no way to send the image without a
>>>> >>> script!
>>>> >>>
>>>> >>
>>>> >> The Extra overhead is something like in the code that generate the
>>>> >> page:
>>>> >>
>>>> >> <?php
>>>> >> if(!file_exists(IMG_PATH.$image_file)) scaleImage($image_file);
>>>> >> ?>
>>>> >>
>>>> >> Not look like an "application killer" to me.
>>>> >>
>>>> >> Greetings.
>>>> >>
>>>> >>
>>>> >
>>>> > There's a lot more to the overhead than that!
>>>>
>>>> Which?
>>>>
>>>> Is the image going to be accessed directly by its URL, or is loaded
>>>> inside a webpage? I am sure is this last case.
>>>>
>>>> So Loading a PHP script will occur 99.999% if you reescaled the image
>>>> previously with a batch or not. All the work of load an script, will
>>>> be done always.
>>>>
>>>> I don't believe that "react" to a 404 error is the good aproach, but
>>>> generating dinamically the scaled images when the page that show them
>>>> is required.
>>>>
>>>> And this only need the few lines to test if file exists and generate
>>>> the images if not.
>>>>
>>>> The fact that the image is directly accessed without pasing first for
>>>> the php script...
>>>
>>> is hardly any CPU.
>>>
>>> The same actions take place: the file must be opened headers
>>> constricted and then data streamed. whether apache or PHP does this is
>>> scarcely an issue.
>>
>> Sorry to say this, but PHP compared to the default handler in Apache is
>> sloooooow. You can test this simply by writing a php script that copies
>> some large files from a directory to another and then write an identical
>> C program...
>>
>
> What do you expect - an interpreted program versus q compiled program?
> The compiled program will always wind.
That was the point i was trying to make. If performance is an issue,
let apache serve the images.
The overhead of using PHP to check if an image exists before sending it
on every request is huge.
>
>> If this site we're talking about needs to serve a lot of request, I have
>> to agree with Jerry on this one.
>>
>>>>
>>>> Someone talked about a catalog of image... I am sure they are
>>>> accessed through a we, not directly.
>>>>
>>>> Even if they are accessed via search engines, these search engines
>>>> have to visit the scripts that would generate the scaled images.
>>>>
>>>> Greetings.
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178240 is a reply to message #178239] |
Thu, 24 May 2012 10:00 |
Shake
Messages: 40
Registered: May 2012
Karma: 0
|
Member |
|
|
El 24/05/2012 11:40, Stig Vestøl escribió:
>
> That was the point i was trying to make. If performance is an issue, let
> apache serve the images.
> The overhead of using PHP to check if an image exists before sending it
> on every request is huge.
There is no need to check every request.
Check the process:
Supose that the images are on the home of the image gallery:
GET /Index.php -> served by PHP (by Apache) *
GET /scaleY/image1.png -> served by Apache (or LIGHTTP) **
GET /scaleY/image2.png -> served by Apache (or LIGHTTP) **
GET /scaleY/image3.png -> served by Apache (or LIGHTTP) **
GET /scaleY/image4.png -> served by Apache (or LIGHTTP) **
GET /scaleY/image5.png -> served by Apache (or LIGHTTP) **
*
Index.php check image files... If one of the images doesn't exists, it
generates.
If all images exists, no matters. Anyway PHP have to process index.php
so there is no overhead beyond a "if(file_exists))" in a foreach of images.
**
no PHP needed, images here had been always created.
Can anyone access to "/scaleY/image5.png" directly ? how? from where he
get the address?
From google? (google have to had visited the index.php) Or other search
engine? (IDEM).
Rgds.
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178243 is a reply to message #178240] |
Thu, 24 May 2012 13:12 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/24/2012 6:00 AM, Shake wrote:
> El 24/05/2012 11:40, Stig Vestøl escribió:
>>
>> That was the point i was trying to make. If performance is an issue, let
>> apache serve the images.
>> The overhead of using PHP to check if an image exists before sending it
>> on every request is huge.
>
> There is no need to check every request.
>
> Check the process:
>
> Supose that the images are on the home of the image gallery:
>
> GET /Index.php -> served by PHP (by Apache) *
> GET /scaleY/image1.png -> served by Apache (or LIGHTTP) **
> GET /scaleY/image2.png -> served by Apache (or LIGHTTP) **
> GET /scaleY/image3.png -> served by Apache (or LIGHTTP) **
> GET /scaleY/image4.png -> served by Apache (or LIGHTTP) **
> GET /scaleY/image5.png -> served by Apache (or LIGHTTP) **
>
> *
> Index.php check image files... If one of the images doesn't exists, it
> generates.
> If all images exists, no matters. Anyway PHP have to process index.php
> so there is no overhead beyond a "if(file_exists))" in a foreach of images.
>
Right. Someone has to check on every request whether the image exists
or not. In your case it is index.php. And although you think each test
is a small overhead, it all adds up - very quickly.
It's completely unnecessary if the images have been generated offline
and uploaded.
> **
> no PHP needed, images here had been always created.
>
>
> Can anyone access to "/scaleY/image5.png" directly ? how? from where he
> get the address?
>
> From google? (google have to had visited the index.php) Or other search
> engine? (IDEM).
>
> Rgds.
Sure they could. It's a URI, just like every other resource on the
server. And there are any number of ways of getting the URI, especially
if you're using a pattern to generate the file names.
--
==================
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 #178246 is a reply to message #178243] |
Thu, 24 May 2012 18:41 |
Michael Fesser
Messages: 215
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
.oO(Jerry Stuckle)
> On 5/24/2012 6:00 AM, Shake wrote:
>>
>> Index.php check image files... If one of the images doesn't exists, it
>> generates.
>> If all images exists, no matters. Anyway PHP have to process index.php
>> so there is no overhead beyond a "if(file_exists))" in a foreach of images.
>>
>
> Right. Someone has to check on every request whether the image exists
> or not.
And usually that's done by Apache itself for every single requested
resource. If the resource is not there, it triggers a 404.
Micha
--
http://mfesser.de/blickwinkel
|
|
|
|
| Re: Windows binaries 64bit for PHP [message #178247 is a reply to message #178246] |
Thu, 24 May 2012 19:17 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 5/24/2012 2:41 PM, Michael Fesser wrote:
> .oO(Jerry Stuckle)
>
>> On 5/24/2012 6:00 AM, Shake wrote:
>>>
>>> Index.php check image files... If one of the images doesn't exists, it
>>> generates.
>>> If all images exists, no matters. Anyway PHP have to process index.php
>>> so there is no overhead beyond a "if(file_exists))" in a foreach of images.
>>>
>>
>> Right. Someone has to check on every request whether the image exists
>> or not.
>
> And usually that's done by Apache itself for every single requested
> resource. If the resource is not there, it triggers a 404.
>
> Micha
>
Yup, and handling a 404 adds a significant amount of unnecessary overhead.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]