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 #178130 is a reply to message #178123] Mon, 14 May 2012 18:06 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 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
==================

Report message to a moderator

[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: Sat Nov 30 06:14:53 GMT 2024

Total time taken to generate the page: 0.05577 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.1.3.
Copyright ©2001-2023 FUDforum Bulletin Board Software