FUDforum
Fast Uncompromising Discussions. FUDforum will get your users talking.

Home » Imported messages » comp.lang.php » Re: Windows binaries 64bit for PHP
Show: Today's Messages :: Polls :: Message Navigator
Return to the default flat view Create a new topic Submit Reply
Re: Windows binaries 64bit for PHP [message #178111 is a reply to message #178105] Mon, 14 May 2012 12:04 Go to previous messageGo to previous message
Jerry Stuckle is currently offline  Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
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
==================
[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: is_dir true from cli, false from Apache
Next Topic: in_array performance in unsorted vs sorted array
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Sun Nov 03 12:37:09 GMT 2024

Total time taken to generate the page: 0.04391 seconds