2010/3/24 Tommy Pham <tommy...@gmail.com>:
> On Tue, Mar 23, 2010 at 3:33 PM, Per Jessen <p...@computer.org> wrote:
>> Tommy Pham wrote:
>>> On Tue, Mar 23, 2010 at 2:04 AM, Per Jessen <p...@computer.org> wrote:
>>>> Use the right tool for the right job - PHP is a scripting/interpreted
>>>> language, it does not need threading (IMO of course).
>>>> --
>>>> Per Jessen, Zürich (9.4°C)
>>> I couldn't agree more.  But here's a real life example.  Your client
>>> has a forum and is using phpbb for their in house use.  They also have
>>> an in house custom PHP app, integrated with phpbb, built to suit their
>>> needs.  Now they want to implement some kind of CMS.  You come in and
>>> implemented a PHP based CMS to integrate into their existing
>>> applications.  Then you realize something troublesome, you have a
>>> performance issue where it could be resolved by implementing thread.
>>> What are you going to do?
>> The standard, mature, experienced answer is - buy a bigger box.
> The company started small.  As their business grows because they have
> products & services that do not exist in the marketplace, their
> hardware are already growing along side with it, (load balancers,
> clusters).  So then your solution is buy bigger/more boxes?  What if
> the their server room is filled and already using recent hardware.
> Their current business needs doesn't need to move to a bigger
> building.  What then? Hire data center's services?  What if they want
> to protect their proprietary break through products and services?
> What about unnecessary additional total cost of ownership (licenses,
> power consumption, etc...) for more/bigger boxes, even if they have
> available space, that could be avoided by just implementing threads?

That screams poor code design. Then to solve the problem might not be
threading or change of language but a reanalyze of the code and the
design, probably a re-write.

>> [snip]
>>> What do you think the client's response is when their need for the
>>> solution requires a short time frame of, if not immediate,
>>> implementation?
>> There are no immediate solutions to immediate performance problems.  If
>> you have a poor design that restricts your throughput, you can 1) throw
>> hardware at it or 2) change the design.  At some point you'll hit yet
>> another limit with 1), and you are forced back to 2).  Somewhere along
>> the line the original designer has presumably left or been made to.
>> /Per
>> --
>> Per Jessen, Zürich (7.5°C)
> If throwing hardware at it won't work because of the above mentioned,
> then you would change the design right?  How long would that take?
> What if PHP has threads, how long would it take you implement threads
> with minor changes versus and overhaul of application design, coding,
> QA, etc... In summary, you're saying that PHP can not grow/evolve with
> business right?  If the company started small and want to use
> available open source solutions, then grow quickly because of their
> unique and quality products and services, and become enterprise level
> with-in a few years, what then?  Slow down business growth just so
> that IT can migrate everything to another language? Of all the
> enterprise applications I've seen, they used threads.

Same answer as above.

> Regards,
> Tommy
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php

MvH / Hans Åhlin
Tel: +46761488019

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to