distributing makumba (a.k.a. n-tier ; parallel processing ; distributed computing)

[ghost]

Reported by @frederikhabils on 19 Aug 2003 21:32 UTC I'm copying this thread from the mailing list. for the mail-bomb

-------- Original Message -------- Subject: Proposal for moving mak to a n-tier application Date: Sat, 16 Aug 2003 23:40:25 +0300 (EEST) From: "Sorin Pop"

Hey

I was thinking of a way to increase makumba's operability and speed. This not actually on our servers, but since mak is now used on commercial applications. The ideea is to move makumba from 2-tier application to an n-tier application. This offers great performance in a companyt where each applucation is hosted on a different server.Let's say there is a database server db and 3 applications A,B and C each one storred on a server and also a server where mak is installed. Each of A,B and C servers have a client for makumba so when the code is modified there is no need to have makumba changed on them, and the mak server where all the clients make requests. This way the application servers will never suffer from the change of the makumba code (once the client code is well-written). So when a mak object is called the client redirects the request to the makumba server and that is where the actual code processing will take place!

More information to come :))

Sorin Alexandru Pop

Migrated-From: http://trac.makumba.org/ticket/524

[ghost]

Comment by @frederikhabils on 19 Aug 2003 21:33 UTC From: Frederik Habils Date: Sun, 17 Aug 2003 17:00:49 +0200

I was thinking of a way to increase makumba's operability and speed. This not actually on our servers, but since mak is now used on commercial applications. The ideea is to move makumba from 2-tier application to an n-tier application. This offers great performance in a companyt where each

Hello Sorin,

It's nice to see others care about developing makumba!

I'm academically fascinated by the technical possibilities of furthering the 'parallel processing' aspect of makumba.

But, and yes, there's a but

• I'm not sure that this responds to the actual goals behind Makumba. Makumba was least that's what I've understood created for easy development of data-driven websites, by/for volunteer organisations like BEST, where expert technological skill is not always available in great quantity. So, makumba tries to offer "as much as possible" under a simple appearance. Ease of use. Makumba also tries not to limit "expert usage", true... but still, we needn't immediately worry about making Makumba competitive technology for the "enterprise market".

• Even before worrying about makumba's performance in the "enterprise market", there's still a lot of work (and 'marketing') to be done, to bring makumba to the 'open source market', e.g. to bring it to the attention of developers who are now using PHP. That is totally untouched ground, and one that I think we should try to conquer soon.

• Makumba itself being 2-tier, it is very performant, I would say. The difficulties we've had so far with karamba, were solely due to internal bugs, that appear to be resolved now. Frankly, we currently have no idea what the performance limit is of makumba (e.g. of karamba), because we haven't yet seen it fail under stress after the last bugfixes. Now that is a piece of quantitative information, that I would be interested in.

Anyway, if you are excited of improving makumba in any way, n-tier or other, don't hesitate to do so... Together, we'll figure out what's possible, and what's most needed and beneficial!

So, welcome to the makumba-dev community :-)

[ghost]

Comment by @frederikhabils on 19 Aug 2003 21:41 UTC From: Cristian Bogdan Date: Tue, 19 Aug 2003 12:43:40 +0200

Hi Fred, Sorin

But, and yes, there's a but

i have no such "but". i think the idea is cool. me and you could live without it and probably so can many others, but if it makes makumba better and provides a challenge for other makumba developers to get involved, let us go for it!

in fact makumba designers (me, Toto, Stefan at the time) thought of something similar in an early makumba meeting (early 2001 i think it was). the basic idea (which is similar to Sorin's proposal) was to have a makumba DB server and a makumba JSP server, possibly running on different machines. then the makumba application can make calls on each, or only the db, etc.

this may increase performance in some conditions, due the higher parallellism that you can achieve (while a jsp call waits for a db operation to be completed on the db machine, other jsp calls can begin to be treated on the "JSP machine", etc). the modularity also lets you change (parts of) makumba without changing/restarting the application(s), as Sorin illustrated.

one drawback that you have to pay is that whenever you separate a component in another process (possibly running on another machine) you have to marshall/unmarshall data between those processes (i.e. data that previously was in memory now has to travel through streams, and for that, you need to represent it unidimensionally and, at the other end, re-create it from a unidimensional representation, and all of this needs a bit of computation, and communication time). so there are limits to this, and a careful balance must be achieved between parallelism and the overhead of distribution.

i can identify some candidates for "breaking up" a makumba runtime into a distributed system: the SQL engine (already separated nowadays), the DB layer, the controller, the JSP rendering engine, tomcat (servlet container), and the BL. it may be that breaking one of them (e.g. the JSP rendering) "somewhere in the middle" may give better results.

that the BL is part of the application and (in the BL case) it is not the application that calls makumba (as Sorin implies) but the other way around!

problems:

• there is a large data traffic between the JSP layer and the DB layer. that traffic already exists in stream form between the DB layer and the SQL engine. if the DB and JSP run on differnt machines, that traffic would be doubled. still, that doesn't mean that performance would be worse. also, the JSP-DB separation seems good during development/maintenance: one would not have to restart the whole thing, just reload the JSP renderer or the DB engine...
• is it worth having the BL part on another machine (to have parallelism between BL and application-independent makumba)? isn't BL generally lightweight (so the parallelism would be asymetric)? isn't it better to simply reload the BL whenever makumba is restarted or when the BL changes, so makumba and the application can vary independently? (which is a benefit that Sorin foresees, but without the application-makumba separation that he suggests)
• it may seem that the makumba JSP rendering can run outside tomcat. no doubt that makumba JSP processing is very intensive, but if it is separated from tomcat, what is left to tomcat (especially when the http front-end is performed by apache) ? wouldn't the parallelism be too asymetric also in this case? (btw, at the moment it seems difficult to me to make the makumba JSP rendering engine run outide tomcat, but it could be a nice challenge, maybe it can be general enough for sugesting a change to tomcat itself)

one interesting breakup option is: tomcat+controller+JSPrendering on one machine, BL+DB+SQL engine on another.

the most general implementation is to allow both separated and in-the-same-process options for every pair of components that interact (tomcat with JSP, JSP (via controller) with BL, JSP with DB, BL with DB), and then play with configurations to see which achieves better performance.

whoever wants to do this refactoring (in whatever final form it will be designed) will have to have a good understanding/overview of the makumba code, while not having to make huge changes in existing code (only add distribution code). i like that, it's a good way to handover code. plus, in order to find better breakups, close study of the code is necessary.

• I'm not sure that this responds to the actual goals behind Makumba. Makumba was least that's what I've understood created for easy development of data-driven websites, by/for volunteer organisations like BEST, where expert technological skill is not always available in great quantity. So, makumba tries to offer "as much as possible" under a simple appearance.

in principle, this would be a makumba refactoring, with no impact on the makumba user (application writer). that would maintain makumba's goals _as_longas:

• installation work will not be made more difficult for simple cases (i.e. a mak-user should be able to install a simple configuration as easy as today, while a production site would probably use the parallelism to the maximum, and would have a more complex configuration, the question remains whether such a complex configuration is something that can be sustained in an amateur environment like ITC)
• performance will not be affected too much for the un-optimized cases (and of course, not at all for the production ones...)

• Even before worrying about makumba's performance in the "enterprise market", there's still a lot of work (and 'marketing') to be done, to bring makumba to the 'open source market', e.g. to bring it to the attention of developers who are now using PHP. That is totally

agreed

• Makumba itself being 2-tier, it is very performant, I would say.

hmmmm. one can think of plently of things to improve. up to now, we only tried to provide basic functionality, with little attention to performance. performance issues were only addressed when they were critical, or when some part of the code needed to be rewritten anyway (see jsp recently). even if this particular performance idea was mentioned in 2001, nothing was done because design and implementation of basic functionality was more urgent.

The difficulties we've had so far with karamba, were solely due to internal bugs, that appear to be resolved now. Frankly, we currently have no idea what the performance limit is of makumba (e.g. of karamba), because we haven't yet seen it fail under stress after the last bugfixes. Now that is a piece of quantitative information, that I would be interested in.

well, there are no tests to prove that it won't fail. and without such tests, even if there is failure, there is little possibility to reproduce the performance problem, examine makumba internals, and fix. so this year ITC might just have been lucky :)

Anyway, if you are excited of improving makumba in any way, n-tier or other, don't hesitate to do so... Together, we'll figure out what's possible, and what's most needed and beneficial!

absolutely agreed. i just want to add: make as much use as possible of existing code. see your contribution as a refactoring, not as major rewriting.

So, welcome to the makumba-dev community :-)

indeed!

[ghost]

Comment by @cristianbogdan on 20 Aug 2003 16:17 UTC From: cristi 20 aug 2003, 15:40 a reply to Sorin, his message is quoted

Sorin Pop wrote:

The ideea is to have BL on another machine for makeing the application a "multitasking and multithreading" at the same time. You can read about 3-Tier on http://www.corba.ch/e/3tier.html You will from that document all the advantages to use a 3-tier applicatio, rather than explaining to you them.

i know approximately what 3 tier is. the document you cite is very much referring to traditional 2tier, with the BL and the presentation layer on one side (desktop computer), and the data layer on the other. most of the disadvantages of 2tier are related to the fact that the "intelligence" is on the client machine (and must be managed there), which is not the case for web applications, where intelligence is in the web server, which connects to the db tier. in fact i have seen books that talk about such web-db applications (like makumba applications are) as being 3 tier (one tier being the web browser)

anyway, i think we agree on the fact that distributing more makumba applications may make them more performant and easier to manage.

one interesting breakup option is: tomcat+controller+JSPrendering on one machine, BL+DB+SQL engine on another.

Yeap.

this would indeed separate presentation and interaction (JSP taglib+ mak controller) from application code (BL + DB), and would allow a whole cluster of tomcats to connect to the same application server (which, in the scenario above, is not separated from the makumba part of the DB layer). it remains to be seen whether performance and manageability will improve. manageability will surely improve when changing BL: you would not have to restart tomcat or reload the webapp

i really think we should go for this, but the current same-process JSP+(BL+DB) code should still be kept and used when the two tiers run in the same task. that would surely be faster than running the inter-tier communication protocol. for example, when doing development, it will be much more handy.

some more points:

• for implementation, i can think of Remote Method Invocation (a Java-only version of CORBA). org.makumba.Database and org.makumba.controller.Logic would be remote objects called by the JSP and by the makumba controller (org.makumba.controller.http). it's just that their method arguments and return results have to be java.io.Serializable.

• i think separating just the BL in an application server (without the makumba DB layer) would be too little granularity: the BL is i think less then 10% from the resources needed by the best makumba applications (known as karamba). separating them would only add the overhead of communication between them and the other parts.

• may be related: the BL design as it is today is pretty poor, there are discussions of improving it, see e.g. http://bugs.best.eu.org/show_bug.cgi?id=234 (however, as it is now, the number of SQL/OQL queries with business objects would be higher than with the present design, maybe a combination between the two would be better)

• a very interesting optimization would be to do data grouping (currently in org.makumba.view.Grouper) at the DB/application tier. that is, the DB tier could give the JSP tier data in the form (student1 (course1, course2, course3)) and not ((student1 course1), (student1, course2), (student1, course3)). that would reduce a lot the data traffic between the two tiers. this may seem like mixing presentation with data processing, but in a sense every SQL query has some presentation aspects (ORDER BY for example)

[ghost]

Modified by @manuelbernhardt on 28 Jun 2010 07:36 UTC

[ghost]

Modified by @manuelbernhardt on 28 Jun 2010 09:16 UTC