[wsf-c-dev] Issues for a next generation C stack

[James Clark]

On Fri, 2006-12-08 at 00:23 -0500, nandika at wso2.com wrote:
> I think before we actually decide on whether to do evolution or revolution
> we should do the possible obvious improvment of Droping unncessary OO types
> and macros in the existing code base.
> (I think more than 60% of the code can be changed to use opeque structures
> instead of OO types which will substancially reduce the memory usage and
> improve performance. It is possible to do the change within 2 weeks
> considering some of the changes that were done in the past.)

Suppose we decide we want to do several major changes to the current
code base.  For example

- dropping unnecessary OO
- introducing exception handling for fatal errors
- using memory pools

Do you think it would be quicker to combine these changes and make them
all at the same time? Or would that take just as much time as doing them
one by one?

> Even if we were to give up the existing code base, this will be great for
> who ever that is going to use the code.

Yup.  There's definitely a lot that could be done with the current code
base to make it better.

> (It is a possibility that we may actually have a community who will
> maintain the code outside of wso2 by another year)
> 
> 1. Then measure performance, memory usage etc and compare the results with
> existing other soap stacks such as gSOAP , Axis C++, Axis2 Java ,Xfire etc.

We should definitely do this.

> If the numbers are bad that means definite need for rewriting but if they
> are good, the best option would be the evolutionary path.

I don't think the decision is that simple:

- even if the numbers are bad, it might be possible to fix things
evolutionarily

- even if the numbers are good, there might be a revolutionary approach
that was much better

Also evolution vs revolution isn't a binary decision.  For example,
revolutionizing AXIOM wouldn't necessarily be incompatible with staying
in Apache.

> 2. It is always better to have solid facts in numbers on why we should
> drop the existing stuff, if we are to do so.
> 
> 3. Measuring preformence will reveal the real bottle necks of the existing
> code ,which we should take care to avoid if we are to redo the code.

This is important, but it's a non-trivial effort to do it well.  We need
to ensure our performance testing covers a broad range of scenarios:

- small messages
- large messages
- messages with MTOM attachments
- large numbers of simultaneous clients
- middle tier scenarios (where servicing a request involves making
requests to other web services)
- performance with security
- performance with reliability
- C level performance
- data-binding performance
- PHP level performance

Another aspect to performance is to ensure that we scale smoothly.  Part
of having a real enterprise-quality product in my view is being able to
gracefully handle workloads that push various limits to insane levels.

- Can we handle a 1Gb message?
- Can we handle a 1Gb MTOM attachment?
- Can we handle a 1,000,000 simultaneous clients?

If not, how far can we go before we grind to a halt?

To get ultimate performance, eventually we will probably need to be able
to run outside of Apache httpd.  For example, it seems likely that to
obtain the best possible performance on Windows, we should use the HTTP
Server API, which leverages the kernel-mode HTTP support.

James