Porting Java web application to Python to make it faster?

[Wolfgang Keller]

Hello,

as a non-developer I am currently participating in an industrial "research"
project to develop a so-called "web application". This application serves
at the same time as middleware to connect several other "conventional"
enterprise-applications such as ERP, SCADA etc. and to provide a GUI
frontend to the users. The developers are into Struts, Enterprise Java
Beans and the like, so it will be entirely implemented in Java with all the
processing on the server side and only static HTML pages on the client
side. It will have to "emulate" much of the GUI logic of a conventional
interactive application with multiple Eclipse-like collapsable panes,
XForms-like dynamic forms, lots of expandable tree views and sortable lists
everywhere, plus SOAP communication "behind the scenes" to get and put
loads of data all over the company's network.

The developers say it will require "considerable" hardware resources in
order to allow reasonable response times, according to them >>1GByte of RAM
for a rather small workgroup (<10 concurrent users). From my own personal
experience with applications implemented in Java (such as UML and database
modeling tools etc.) I fear that this might in fact mean that the reponse
times will be Godot-like and that the application will miserably choke as
soon as we confront it with real-world amounts of data going beyond the
usual "three items" toy demonstrations.

Now the question: If this desaster scenario (I'm working for the industrial
application partner in the project who expects to get some results that
will be actually usable for everydays' work) will actually happen (I hope
it won't, but still...), might there be a chance that by paying a cs
student for porting it to Python in his diploma thesis using such things as
Coil, Cheetah, Webware etc. it will get slimmer and faster? And if so, by
how much approximately? 10%? One order of magnitude?

TIA,

Best regards,

Wolfgang Keller

[Christopher Baus]

> Omit discussion on enterprise application in java or python.

Ok, I'll bite.

There was thread on a another list that I read like this recently. The
difference in performance between Java and python on the web server
probably doesn't really matter that much. If anything I might guess that
Java would be faster. Tons of huge applications are run by Java servers
everyday. A gig of RAM on the server is nothing. It might cost a couple
hundred dollars. Big deal. Certainly much less that re-writing the app in
python.

The performance problems will result from aggregating content from the
sources you mention. My guess is you'll be waiting around for the ERP to
respond longer than it take will render the pages in either java or
python.

In my opinion it would be a waste of money to redo this in python. If the
developers are skilled in java, then go with java. If they prefer python
then use it instead.

The only thing you will prove is that the app can be done in python or
java. If anything Java is the proven leader in this field.

--
Christopher Baus
http://www.baus.net/

[Wolfgang Keller]

Am Thu, 8 Jul 2004 00:10:18 -0700 (PDT) schrieb Christopher Baus:

Omit discussion on enterprise application in java or python.

If I had wanted to create a flamewar, I would have cross-posted to
comp.lang.java.* :-)
Ok, I'll bite.
Thanks for the answer.
There was thread on a another list that I read like this recently. The
difference in performance between Java and python on the web server
probably doesn't really matter that much. If anything I might guess that
Java would be faster. Tons of huge applications are run by Java servers
everyday. A gig of RAM on the server is nothing.
Errr, >>1 GByte just to provide an interactive GUI to something like 5
users and doing some inter-application communication - I wouldn't really
consider that as nothing. Especially not if it scales hyper-exponentially
with the number of users and/or the data volume. After this first
application, we expect to be able to use the same application for sites
with something like 100 concurrent users as well.
The performance problems will result from aggregating content from the
sources you mention. My guess is you'll be waiting around for the ERP to
respond longer than it take will render the pages in either java or
python.
The point is that this can be worked around by retrieving the data in
background and "caching" it in a local database. Sorry that I didn't
mention this. In fact such a database would have to be part of the
application, as some of the communication with other applications will have
to be offline, in "batch" mode, in both directions (get as well as put).
In my opinion it would be a waste of money to redo this in python.
Hmm, are cs students THAT expensive even as interns? >:->
If the developers are skilled in java, then go with java. If they prefer
python then use it instead.

None of them has ever mentioned Python at all. >:->

Best regards,

Wolfgang Keller

[Rick Lawson]

Disclaimer: I love Python but write Java webapps (mainly Struts) for a
living.

I don't think the problem is Java, server side it is very fast. With a
good data access layer and caching (like Hibernate) I think that a
Java webapp will be hard to beat. Sounds like the problem is the
design decision to emulate a rich desktop app as a web based app.
Since this is an internal app you may want to suggest a desktop client
(either Java or Python based) communicating via Soap or xmlrpc. The
nice thing about doing an rich client app in Java for a limited
audience is you can Webstart it which makes for painless deployment.
On the other hand, I've had good luck writing wxPython based rich
clients and using Inno Setup to deliver a clickable installer.

Good luck,
Rick

Wolfgang Keller <wo********************@gmx.de> wrote in message news:<1i******************************@40tude.net> ...

Hello,

as a non-developer I am currently participating in an industrial "research"
project to develop a so-called "web application". This application serves
at the same time as middleware to connect several other "conventional"
enterprise-applications such as ERP, SCADA etc. and to provide a GUI
frontend to the users. The developers are into Struts, Enterprise Java
Beans and the like, so it will be entirely implemented in Java with all the
processing on the server side and only static HTML pages on the client
side. It will have to "emulate" much of the GUI logic of a conventional
interactive application with multiple Eclipse-like collapsable panes,
XForms-like dynamic forms, lots of expandable tree views and sortable lists
everywhere, plus SOAP communication "behind the scenes" to get and put
loads of data all over the company's network.

The developers say it will require "considerable" hardware resources in
order to allow reasonable response times, according to them >>1GByte of RAM
for a rather small workgroup (<10 concurrent users). From my own personal
experience with applications implemented in Java (such as UML and database
modeling tools etc.) I fear that this might in fact mean that the reponse
times will be Godot-like and that the application will miserably choke as
soon as we confront it with real-world amounts of data going beyond the
usual "three items" toy demonstrations.

Now the question: If this desaster scenario (I'm working for the industrial
application partner in the project who expects to get some results that
will be actually usable for everydays' work) will actually happen (I hope
it won't, but still...), might there be a chance that by paying a cs
student for porting it to Python in his diploma thesis using such things as
Coil, Cheetah, Webware etc. it will get slimmer and faster? And if so, by
how much approximately? 10%? One order of magnitude?

TIA,

Best regards,

Wolfgang Keller

[Istvan Albert]

Porting your application to python will not make it *faster* but you
will see a whole lot *sooner* what the problems, bottlenecks and unexpected
complexities are in your implementation. If possible draft and test
it in python then finalize it in Java.

Istvan.

[Christopher Baus]

>> There was thread on a another list that I read like this recently. The

difference in performance between Java and python on the web server
probably doesn't really matter that much. If anything I might guess
that
Java would be faster. Tons of huge applications are run by Java servers
everyday. A gig of RAM on the server is nothing.
Errr, >>1 GByte just to provide an interactive GUI to something like 5
users and doing some inter-application communication - I wouldn't really
consider that as nothing. Especially not if it scales hyper-exponentially
with the number of users and/or the data volume. After this first
application, we expect to be able to use the same application for sites
with something like 100 concurrent users as well.

And python will solve this problem how?
Hmm, are cs students THAT expensive even as interns? >:->

If the CS students are so cheap, why don't you just have them write it in
the first place. If the project can be done by CS students why waste your
time on the Java engineers?

If the developers are skilled in java, then go with java. If they
prefer
python then use it instead.

None of them has ever mentioned Python at all. >:->

If the architecture is the same, Python will likely save you nothing.
Python is a neat language. I like using it. But Java really is the big
player in this space, and it works fine. In many ways I think having a
strongly typed language like Java is better for production than Python,
but I'll leave that argument for another day.

Instead of wasting time having the CS student re-write the app in python,
have him or her look at why the app is slow or using excessive of memory.
That will be time better spent. The CS student might be less expensive,
but I'm sure your time isn't free either.

[Irmen de Jong]

Istvan Albert wrote:

Porting your application to python will not make it *faster* but you
will see a whole lot *sooner* what the problems, bottlenecks and unexpected
complexities are in your implementation. If possible draft and test
it in python then finalize it in Java.

This is actually a very good point! "mod parent up" :-)
--Irmen

[flab ba]

I agree with the folks that responded ... it probably wouldn't be
worthwhile to convert your app to Python. I think Java is better for your
type of project - not because the language is superior to Python (I don't
think it is), or because Java has static type checking (for an interesting
discussion why, see the following link, but remember testing is the key):

http://www.artima.com/weblogs/viewpost.jsp?thread=4639
, but because Java has better libraries and frameworks for exactly this
type of thing.

Your developers *may* want to consider Turbine/Velocity or Tapestry as an
alternative to Struts.

Also, as another poster mentioned, a thick client that communicates by web
services might be better ... maybe look into the Eclipse Framework.

Instead of worrying about what language to use at this point in time, I
would employ the principles in this book :

Performance by Design : Computer Capacity Planning By Example by Daniel A.
Menasce, Lawrence W. Dowdy, Virgilio A.F. Almeida

http://www.amazon.com/exec/obidos/tg...glance&s=books

And make sure you do some architectural experimentation. Evaluate a *few*
competing alternative architectures to solve your problem. Make sure you
have data (from simulations, models) to back up your decision.

Don't forget to consider a load-generation tool like LoadRunner (expensive
as heck, though). Maybe you could find something cheaper that would fit
the bill.

-A



On Thu, 08 Jul 2004 08:53:19 +0200, Wolfgang Keller wrote:

Hello,

as a non-developer I am currently participating in an industrial
"research" project to develop a so-called "web application". This
application serves at the same time as middleware to connect several
other "conventional" enterprise-applications such as ERP, SCADA etc. and
to provide a GUI frontend to the users. The developers are into Struts,
Enterprise Java Beans and the like, so it will be entirely implemented
in Java with all the processing on the server side and only static HTML
pages on the client side. It will have to "emulate" much of the GUI
logic of a conventional interactive application with multiple
Eclipse-like collapsable panes, XForms-like dynamic forms, lots of
expandable tree views and sortable lists everywhere, plus SOAP
communication "behind the scenes" to get and put loads of data all over
the company's network.

The developers say it will require "considerable" hardware resources in
order to allow reasonable response times, according to them >>1GByte of
RAM for a rather small workgroup (<10 concurrent users). From my own
personal experience with applications implemented in Java (such as UML
and database modeling tools etc.) I fear that this might in fact mean
that the reponse times will be Godot-like and that the application will
miserably choke as soon as we confront it with real-world amounts of
data going beyond the usual "three items" toy demonstrations.

Now the question: If this desaster scenario (I'm working for the
industrial application partner in the project who expects to get some
results that will be actually usable for everydays' work) will actually
happen (I hope it won't, but still...), might there be a chance that by
paying a cs student for porting it to Python in his diploma thesis using
such things as Coil, Cheetah, Webware etc. it will get slimmer and
faster? And if so, by how much approximately? 10%? One order of
magnitude?

TIA,

Best regards,

Wolfgang Keller

[Paul Boddie]

"Christopher Baus" <ch*********@baus.net> wrote in message news:<ma************************************@pytho n.org>...

Omit discussion on enterprise application in java or python.
Ok, I'll bite.

There was thread on a another list that I read like this recently. The
difference in performance between Java and python on the web server
probably doesn't really matter that much. If anything I might guess that
Java would be faster. Tons of huge applications are run by Java servers
everyday. A gig of RAM on the server is nothing. It might cost a couple
hundred dollars. Big deal. Certainly much less that re-writing the app in
python.

I think previous discussions reached a certain consensus that Java
would possibly scale better "out of the box" with more hardware thrown
at it, whereas a single Python process doesn't benefit hugely from
having more CPUs thrown at it. However, Python Web application
frameworks seem to employ a more varied set of architectures for
distributing work than the average non-clustered Java application
server; whether a single Python process can effectively use 8 CPUs
becomes less relevant in that context.

Usually when people start comparing Java to the "P languages", it's
often noted that the initial application footprint of those languages
is more modest than Java - one particular Java application server
really gets upset unless it has 512MB to start up in, for example.
Yes, it could well be possible that with a server farm the size of the
Moon, Java applications will scale to make good use of it, but the
issue is whether you'd need to be so extravagant with, say, Apache and
mod_python.
The performance problems will result from aggregating content from the
sources you mention. My guess is you'll be waiting around for the ERP to
respond longer than it take will render the pages in either java or
python.
Apparently, the Apache Cocoon people have done work with aggregating
information from SAP. However, my personal experience is that
functionally sufficient frameworks could be implemented with
mod_python and libxslt with equivalent performance and without the
"horsing around in the sitemap" that Cocoon applications demand.
In my opinion it would be a waste of money to redo this in python. If the
developers are skilled in java, then go with java. If they prefer python
then use it instead.

The only thing you will prove is that the app can be done in python or
java. If anything Java is the proven leader in this field.

It's safer to go with Java, yes, and if you don't have to do the work
yourself then you could possibly save yourself the hassle of
justifying an alternative solution. However, I've found the
aforementioned alternative technologies to be invaluable in
prototyping solutions, and I'd be confident in deploying those
prototypes in a slightly more polished form instead.

Paul

[Mark 'Kamikaze' Hughes]

Christopher Baus <ch*********@baus.net>
wrote on Thu, 8 Jul 2004 00:10:18 -0700 (PDT):

Omit discussion on enterprise application in java or python.

Ok, I'll bite.
There was thread on a another list that I read like this recently. The
difference in performance between Java and python on the web server
probably doesn't really matter that much. If anything I might guess that
Java would be faster. Tons of huge applications are run by Java servers
everyday. A gig of RAM on the server is nothing. It might cost a couple
hundred dollars. Big deal. Certainly much less that re-writing the app in
python.
The performance problems will result from aggregating content from the
sources you mention. My guess is you'll be waiting around for the ERP to
respond longer than it take will render the pages in either java or
python.
In my opinion it would be a waste of money to redo this in python. If the
developers are skilled in java, then go with java. If they prefer python
then use it instead.
The only thing you will prove is that the app can be done in python or
java. If anything Java is the proven leader in this field.

I agree. For a living, I write Python when I can, Java most of the
time, and PHP when necessary. For fun, I write games in Java and
Python, or work on my web site in PHP. Performance matters quite a bit
to what I do.

Java's startup time is awful, but its performance once it's started is
really very good. Python starts up faster, but it's not that fast a
language. Java uses an insane amount of memory by old-time standards,
but an equally-powerful Python program will use as much or more.

Python's certainly more pleasant to work with, but Java
Servlets/JSP/Taglibs are the best balance of power and ease of use in
web frameworks, and JDBC handles database interaction better than
anything I've ever seen: it doesn't gloss over what the database really
does, but presents the highest-level tools possible.

If the actual developers know Java and think it's the right tool for
the job, they're almost certainly right.

--
<a href="http://kuoi.asui.uidaho.edu/~kamikaze/"> Mark Hughes </a>
"The void breathed hard on my heart, turning its illusions to ice, shattering
them. Was reborn, then, free to scrawl own design on this morally blank
world. Was Rorschach." --Alan Moore, _Watchmen #6_, "The Abyss Gazes Also"

[J]

On 2004-07-08 08:19:30 -0400, Wolfgang Keller
<wo********************@gmx.de> said:

There was thread on a another list that I read like this recently. The
difference in performance between Java and python on the web server
probably doesn't really matter that much. If anything I might guess that
Java would be faster. Tons of huge applications are run by Java servers
everyday. A gig of RAM on the server is nothing.

Errr, >>1 GByte just to provide an interactive GUI to something like 5
users and doing some inter-application communication - I wouldn't really
consider that as nothing. Especially not if it scales hyper-exponentially
with the number of users and/or the data volume. After this first
application, we expect to be able to use the same application for sites
with something like 100 concurrent users as well.

i have a gig of memory in my laptop. Memory is cheap. If you are
going to have a DB, WebServer, Application Server on a server 1 gig of
memory is a mininum. I create database data loads, and my boss almost
lost his lunch when I told him I want a server 10gigs of main memory.
--
J
"If there is anything I can do for you or more to the point to you, let
me know."

[Michele Simionato]

Wolfgang Keller <wo********************@gmx.de> wrote in message news:<1u*****************************@40tude.net>. ..

Hmm, are cs students THAT expensive even as interns? >:->

Speaking for direct experience ... interns can be VERY expensive.
Think to the training time and to the time spend in fixing their bugs,
time which has to be spent by experienced *expensive* programmers.
A Python (or Java) guru may cost you 10 times more than a student,
but it may actually be more convenient for you to hire the guru.
Unless you can find a student which is also a guru, but you must be
very lucky to find one, don't count on that too much.
Michele Simionato

[Y2KYZFR1]

Wolfgang Keller <wo********************@gmx.de> wrote in message news:<1i******************************@40tude.net> ...

Hello,

as a non-developer
<snipped a bunch of non-developer non-sense>
TIA,

Best regards,

Wolfgang Keller

stick to non-developing, the questions you ask and the assumptions you
made make it painfully apparent that you won't understand the answers
nor that the questions you are asking are the wrong ones.

good luck with your single student writing something that you need to
use every day.

[Rick Lawson]

Wow, with your interpersonal skills you must be a real developer !

[Wolfgang Keller]

Am 8 Jul 2004 05:48:16 -0700 schrieb Rick Lawson:

Sounds like the problem is the
design decision to emulate a rich desktop app as a web based app.
Unfortunately >;-> this was more or less the whole point of the project
right from the start. This is a _research_ project, partially publicly
funded, so the industrial application partner is not in the situation of a
paying customer. And the project was more about proving a point (that the
above mentioned architecture is possible, together with web-services
everywhere) than about solving actual real-world problems the most
efficient way. So the developers, who come from a university/research
institute background, are not necessarily as concerned about certain issues
as the application partner (which I happen to work for). And we are not in
the position to tell them how we want them to do certain things.
Since this is an internal app you may want to suggest a desktop client
(either Java or Python based) communicating via Soap or xmlrpc.

Given the answers I got here, maybe we'll end up paying someone for
re-implementing the desktop client (as a Qt application?) and keeping the
"Web Portal" interface mainly for PDAs.

Best regards,

Wolfgang Keller