ladon

Arguments for choosing Ladon, please clarify

Asked by Alex Railean

1. are there any statistics and tests that illustrate how well Ladon deals with real world applications? Specifically, have you got any performance measurements? How well does it scale? How many requests per second can it handle? etc.

My guess is that the answer is a function of the underlying stack - which WSGI server is used, on which OS, etc. Still, there may be other aspects involved, so I'd rather ask about Ladon's overhead explicitly.

2. it would be great if the site also included a list of references to real world systems that rely on Ladon. Such a portfolio would increase credibility and make it easier for me to convince others that Ladon is a strong candidate. Can you provide such examples?

3. Ladon is a relatively new system, I see that the oldest historical records I found are from ~2010. This raises the question whether Ladon is mature and if someone who wants to use it in high-demand/high-availability systems is making the right choice.

Having a portfolio (as in #2) would help with this matter; what would also help is a set of comparisons between Ladon and alternatives such as rpclib, which I am reviewing too (github.com/arskom/rpclib).

4. Ladon's description says it is SOAP 1.1 compliant. One of the requirements we have to implement for a system we're working on says it needs to be SOAP 1.2

I haven't yet delved deep enough to figure out whether this is a simple difference to address, or if it is a show-stopper, because the delta is rooted somewhere deep inside the core.

Having reviewed articles that summarize the difference between the versions - I found them relatively superficial. But that's a dangerous conclusion, as I've never tinkered with SOAP - so my perspective can be skewed.

- Is there a roadmap? Where is the project heading?
- What are your comments on SOAP 1.1 vs 1.2 in the context of Ladon?

Question information

Language:
English Edit question
Status:
Solved
For:
ladon Edit question
Assignee:
No assignee Edit question
Solved by:
jsgaarde
Solved:
Last query:
Last reply:
Revision history for this message
jsgaarde (jakob-simon-gaarde) said : 		#1

I will answer during the weeken :-)

Best Regards
Jakob Simon-Gaarde

Revision history for this message
Best jsgaarde (jakob-simon-gaarde) said : 		#2

1. I have been wanting to do that for a long time though, but there always seems to be something more important to be done. Never the less, I can tell you that I have been a back-end developer for more than 6 years now, and one of the main reasons for developing Ladon was the desire for performance. I have used ZSI, SOAPpy and rpclib before and they all perform badly compared with Ladon.

Why? For instance I have been very stubborn with the use of Python primitives as datatypes instead of implementing type classes like most other Python web service frameworks. Constructing and destructing framework-specific type classes gives more overhead.
Another example is Ladon's way of handling attachments, no matter how large attachments are sent or recieved the memory consumption related to the attachments on the server side never exceed 4K per thread (minus the loaded python mudules). Attachments are always passed up and down through the framework using open fileobjects.

As for most of your questions, it would be nice if someone helped out and contributed with such a performance test, it is actually better that way for the sake of objectivity.

Since Ladon is developed with performance in mind I would say (as you also mentioned) that the biggest bottleneck is the underlying logic of the service being developed (like poor database design etc.)

2. I'd love to do that, but I haven't got any references, because I've never asked users for feedback :-(
You can have a look at this though:
https://jsonfs.limbosoft.com/service/JSONFS

It is a complete working json based online fileservice based on Ladon. It will be accessable in a dropbox manner later this year.

3. The rpclib main developer actually made such a comparison:
http://arskom.github.com/rpclib/comparison.html
The comparison is not entirely objective though, it's very focused on what Ladon doesn't support and not so much on what Ladon supports that rpclib doesn't ;-)

4. SOAP 1.2 is not a high-priority. Instead I try to encourage others to help out by writing new interface classes:
http://packages.python.org/ladon/extending.html

It's as easy as writing a single Python module to extend Ladon with a new Protocol, so it would probably be a small re-write of the existing soap interface:
http://bazaar.launchpad.net/~ladon-dev-team/ladon/ladon/view/head:/frameworks/python/src/ladon/interfaces/soap.py

Future focuses (or roadmap):
a. The current focus is the development of a C++ client for JSON-WSP, which is to be used to create script bindings to other programming languages like php, Lua, Perl etc.

If you haven't studied JSON-WSP, it is a much more intuative (and human readable) protocol than SOAP. It is inspired from JSON-RPC, but with a service description specification (like WSDL) which JSON-RPC does not have. And in terms of performance which I gather is in your interrest, JSON-WSP has a much smaller network footprint than SOAP. SOAP is actually probably the web service protocol with the largest overhead of them all, simply because of the size of request and response objects.

Learn about JSON-WSP:
http://en.wikipedia.org/wiki/JSON-WSP

b. Tasks, I want Ladon to stand out from other frameworks by supporting task-type service methods. This will be the focus after the C++ JSON-WSP client. Task-type methods meens that a method that is timeconsuming can be implemented as a task method that will be run in a separate thread on the server. When you implement a task-type method another method is automatically added to the service to poll for progress. The task is then resposible for updating the progress via a callback method.

Revision history for this message
jsgaarde (jakob-simon-gaarde) said : 		#3

Ups the JSONFS development server is down for maintanence (sorry)

Revision history for this message
jsgaarde (jakob-simon-gaarde) said : 		#4

Do you need more info - or should we call this one solved?

Revision history for this message
Alex Railean (gr8dude) said : 		#5

Thank you for the detailed and clear response.

I decided to go for Ladon in developing a pretty large system, I hope all goes well and you'll be able to use this experience on the "who uses Ladon?" front.

Currently I have to stick to SOAP for interoperability reasons. I am aware of the fact that there is a lot of overhead, but this module must be able to "talk" to other systems, which are standardized - so there's no room for maneuvering.

I think I'll have to implement a SOAP 1.2 interface as a side-effect, I'll add it to the project if that will be the case.

Revision history for this message
Alex Railean (gr8dude) said : 		#6

Thanks jsgaarde, that solved my question.

Revision history for this message
jsgaarde (jakob-simon-gaarde) said : 		#7

Hi Alex.

Sounds cool, I will help you out if needed. I can comfort you with the fact
that we use Ladon for large systems too here at the company I work for, and
it hasn't failed us yet.

Since your information request last week, I have started asking people to
be kind to write a few words about how they utilize Ladon, so if you can
write a few words too that would be nice. The plan is to make a case-study
menu-item on the ladonize.org site.

Best Regards
Jakob Simon-Gaarde

2012/1/10 Alex Railean <email address hidden>

> Question #183694 on ladon changed:
> https://answers.launchpad.net/ladon/+question/183694
>
> Status: Answered => Solved
>
> Alex Railean confirmed that the question is solved:
> Thank you for the detailed and clear response.
>
> I decided to go for Ladon in developing a pretty large system, I hope
> all goes well and you'll be able to use this experience on the "who uses
> Ladon?" front.
>
>
> Currently I have to stick to SOAP for interoperability reasons. I am aware
> of the fact that there is a lot of overhead, but this module must be able
> to "talk" to other systems, which are standardized - so there's no room for
> maneuvering.
>
> I think I'll have to implement a SOAP 1.2 interface as a side-effect,
> I'll add it to the project if that will be the case.
>
> --
> You received this question notification because you are an answer
> contact for ladon.
>

--
Med venlig hilsen / Best regards
Jakob Simon-Gaarde

Revision history for this message
Alex Railean (gr8dude) said : 		#8

The link to JasonFS does not work, can you please double-check it?

Revision history for this message
jsgaarde (jakob-simon-gaarde) said : 		#9

Hi Alex.

The server is currently not running, but it will soon. Sorry, I'll notify you when it is back up.

/ Jakob