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 <> 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 <> 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 (
>> To unsubscribe, visit:

PHP General Mailing List (
To unsubscribe, visit:

Reply via email to