and btw, complexity of design can go up considerably when you have to deal with more than 1 php and 1 mysql server, because the language forces inefficient constructs _and_ is "stuck on 1 server".... On Wed, Mar 24, 2010 at 9:36 AM, Rene Veerman <rene7705@xxxxxxxxx> wrote: > throw more hardware at it? > > how about you not butt into my business and how i save costs eh.. > > On Wed, Mar 24, 2010 at 9:31 AM, Per Jessen <per@xxxxxxxxxxxx> wrote: >> Tommy Pham wrote: >> >>> 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. >> >> Same answer - buy a bigger box (i.e. serverroom). I would certainly >> also start a redesign from the ground up, but to solve the immediate >> problem, get more 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? >> >> Rent space and maybe hardware. That's what most businesses do. >> >>> 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? >> >> If you believe threading is such a silver bullet, I really think you >> need to reconsider. This business has already invested in more >> hardware to satisfy demand, so the application has some scalability - >> presumably achieved by running multiple processes. Threads have some >> advantages over processes, but when your design doesn't take that into >> account anyway, why do you need threads? >> >> [snip] >>> In summary, you're saying that PHP can not grow/evolve with >>> business right? >> >> Certainly not. PHP is just a language, like most other programming >> languages, it doesn't grow nor does it evolve a lot. (the OOP paradigm >> is an example of where PHP evolved). >> I'm saying that a back-of-a-fag-packet design won't grow nor evolve very >> well, and its inevitable shortcomings will not be solved by bolting >> on "threading". >> >>> 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. >> >> Tommy, that's not about the language, that's a design issue. Run PHP in >> multiple processes, and you've got the parallelism you seem to seek. >> >> /Per >> >> -- >> Per Jessen, Zürich (6.8°C) >> >> >> -- >> PHP General Mailing List (http://www.php.net/) >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
