[phplib] Re: BEA Weblogic (was) Re: [phplib] [RFC] Future of phplib From: Kristian Koehntopp (kris <email protected>)
Date: 07/22/01

On Sun, Jul 22, 2001 at 07:09:53AM +0530, Tarique Sani <tarique <email protected>> wrote:
> > exceed the capabilities of PHP for the moment. At the moment I
> > am neck deep in a BEA Weblogic project...
>
> Hmm... ... Interesting care to elaborate on "exceed the
> capabilities" part No I dont want a flamewar - just very
> curious

BEA Weblogic is an application server, written in Java. Due to
the fact that Java is precompiled, not compiled on demand as
PHP, there is little need for a Bytecode cache.

Since Weblogic is a multithreaded, continously running server,
the application server can create an object as part of a session
and keep it alive beyond the lifetime of a single request, then
reuse it in a following request of the same session. In fact
there can be per-application, per session and a multitude of
other object lifetimes.

Java provides an interface for serializeable objects, which an
object can conform to. Such objects can be stored and restored
to a persistent memory such as a database, a disk file and
similar. This allows to cluster Weblogic servers, and to migrate
a session from one server instance to another by serializing it,
shipping the data to another instance and recreate the object
over there.

Since database connections are part of an object, and objects
can be kept alive beyond a single request or session, it is easy
to have objects that hold a predetermined pool of database
connections, and associate a database connection from the pool
with a session. This allows for a very finely grained tuning of
database connections.

Also, these pool objects can be clustered in the sense that the
Weblogic server running on instance 1 has your session, but the
only free database connection is in a pool on instance 3.
Weblogic then ships the database query to the connection in the
pool on instance 3, runs the query and returns the result to
instance 1. This happens transparently as far as possible.

On top of this you can use and integrate precompiled and
predefined external components from third parties, Enterprise
Java Beans. The Weblogic holds these beans (encapsulated object
instances) in one of several runtime contexts, and manages them
(how many on which server instance, within a separate process,
within a separate thread, within your server, serialuzed them to
disk if they are unused and so on). It provides a mechanism to
call functions with these beans, even if they are running on a
different machine than the original application.

Also, all this has a predefined and documented, unified
interface for runtime parameters (called properties), thus
deployment of the application is easily documented and there is
a large number of tuneable parameters such as database
connections per pool, number of EJB instances, avilable memory
for each kind of EJB objects and so on and so on.

In theory this should provide for very performant and highly
scaleable web application framework which is resistant to
failure of a single machine, also. It should be able to scale by
simply adding more CPUs and machines.

In practice it is an extremely complex system of interdependent
functionalities and communication channels, which is extremely
sensitive to deployment parameters. Also, debugging performance
problems is highly difficult, despite the fact that debugging
facilities are _way_ beyond what PHP provices. But one has to
remember that Weblogic has problems in areas which PHP can
hardly reach, either because it does not scale that way or
because these problems are in Weblogic subsystems which simply
have no functional PHP equivalence.

To a PHP developer this is all very strange at first, but
working with it, it slowly begins to make sense. Very much
sense, indeed, although all that tech does to protect you from
making extremely stupid design decisions like not implementing
the moral equivalent of PEAR::Cache or the Roxen output cache at
all, and requiring 8 CPUs running Cocoon to render the same XML
with the same XSLT again, and again, and again...

Anyway, by introducing something like that cache, the number of
XSLT runs was easily decreased by 100 times. I was not only
amazed by the stupidity of not having such a cache, but also by
the fact that such a cache could be introduced into the
application with so little hassle and code once I mentioned the
concept to the relevant coders. The whole thing went in globally
for all output in under 3 hours of coding, modulo an interface
to the content billing system (probably another 2 hours of
coding).

You wouldn't use such a system in a context where PHP is being
used. There is no way to host such solutions: each Java process
is configured to eat 128 MB or 512 MB of RAM. Our machines are
Netra-T1's with 1 GB of memory (cluster of 4) running a large
calendar and address book application, E220R with 2 CPUs and 2
GB of memory (cluster of 2 behind a Cisco 12000 Content Switch)
running 512 Apache instances each, and 2 E420R with 4 CPUs and 4
GB of memory, running the application server with the
application. Also, there are 3 Oracle databases, each mirrored
(total of 6 systems), one for the application, one for the
calendar and address book application, and one as the foundation
for the Oracle LDAP server, each on E220R or E420R systems.
There systems all have T1000 RAID arrays for data storage.

Then there is a E3500 system running a load generator software
to test system performance... :-)

The funny thing is, the whole stuff did not perform at all once
deployment started - the whole cluster logic broke down and
slowed down the calendar application. As soon as we reduced the
cluster instances from 4 to 1, the number of requests processed
per second rose 40-fold, no more timeouts, exceptions and stray
multicast packets on the wire.

So what does it all come down to?

I am intrigued by the number of clever concepts employed in this
system, and this being Java and me being able to handle a
decompiler, I am learning a lot. I am still not convinced by the
performance of the system, considering the pure amount of
hardware involved (this is five 19" racks full of tech, valued
in six to seven digit numbers of Deutschmark). Also, this system
is clearly too hard to administer for your average system
administration person, and development for it is _so_ much
harder than using something than PHP.

Clearly this whole project is like the wet dream of a buzzword
bingo addict, with words like "cluster", "XML", "XSLT",
"Cocoon", "Java", "Application Server", "cluster", "scaleable",
"redundant", "failover", "heartbeat", "database connection
pooling", "EJB", "instance pool sizing parameter" and the like
all over the place. If you push all that aside, there remains a
number of concepts that are well though out and which are
potentially useful, if fully understood and correctly
implemented and deployed.

Kristian 

-- 
Abbestellen mit Mail an:   phplib-unsubscribe <email protected>
Kommandoliste mit Mail an: phplib-help <email protected>