2010/3/24 Tommy Pham <tommyhp2@xxxxxxxxx>: > On Tue, Mar 23, 2010 at 3:33 PM, Per Jessen <per@xxxxxxxxxxxx> wrote: >> Tommy Pham wrote: >> >>> On Tue, Mar 23, 2010 at 2:04 AM, Per Jessen <per@xxxxxxxxxxxx> 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 http//www.kronan-net.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
