Mark Rogers wrote:
That can just be another way of saying (and I don't know if that's the
case here) that the per-client load is negligible compared with the
overhead. Do you have any stats for how many simultaneous clients any
given server can support for either Perl, PHP or Java?
Not that I could lay my hands on easily. In any case, most of the
publicly available benchmarks are pretty artificial. BTW, my comments
on scaling up, as opposed to out, were referring to *very* big systems.
My impression is that most of us don't get involved very often with
the kind of thing that runs on a top-end Sun or IBM P-series or on a
decent sized IBM Z-series, which is the kind of big box I was referring to.
1) fashion - it is now perceived as the safe option, which is
important if your job and your boss's job depend on it. You're
unlikely to get fired for choosing Java. In the eyes of a lot of
corporate IT people, there are only two options - Microsoft or Java;
I don't see this. We see far more call for PHP (and I can't think when
someone last seriously proposed ASP for a job). Maybe I don't move much
in the corporate world :-)
I'm glad to hear that. Maybe people are learning at last. Sadly, my
experience is that in far too many large companies the senior IT people
still think in the way I described.
We usually define jobs in terms of the deliverables not the technology anyway.
If only more people thought this way! I hate to think how much time
I've wasted trying to convince clients to focus on the business
requirement and to worry about the technolgy when they know what they
want the system to do for them. In fact, most of them aren't clear
about what they want the system to do because they haven't really
figured out how they want their business to work and, hence, what they
want their *people* to do.
>> 5) the popular Java-based web servers are designed to allow you to
switch application modules in and out, and to reconfigure individual
applications without a restart.
I'm not sure really what you're saying here?
Whilst something like Apache will require a "restart" when its config
changes, its a zero-downtime restart; old connections complete normally,
new ones are made to a new process running with the new config. Once the
old threads have finished dealing with clients they stop taking new ones
and very quickly (usually <1sec) you're running on the new config.
Unless your new config is broken, of-course :-) But there are plenty of
ways to check that first.
On a moderate sized system, I entirely agree with you. On a *very* big
system, which was what I was referring to, it could take a lot longer.
Also, it depends upon what else is running on the same server. Big,
complex applications may not take too kindly to being restarted whenever
you feel like it. By complex, I'm talking about something like an ERP
system handling order processing, supply-chain management,
manufacturing, HR and finance for a business with several factories, a
dozen or more warehouses and maybe 30,000 products.
In nay case I would thoroughly recommend that any developer use more
than one language. Skills you learn in one almost always carry forward
to the others.
I entirely agree. My motto on these things is "horses for courses".
Tony Cowderoy
_______________________________________________
Peterboro mailing list
[email protected]
http://mailman.lug.org.uk/mailman/listinfo/peterboro
