Migration from Java?
Wed Sep 22 11:29:49 CEST 2004
this would be the Erlang applications I would investigate:
As front end -
Yaws : http://yaws.hyber.org/
for dynamic and static pages. It is a quite capable engine that has been
benchmarked for 80000 parallell sessions. See:
For your XML/XSL support you could use xmerl:
If you do not need to be XSL standards compliant xmerl has
native support for transforms in an XSL:ish fashion:
otherwise you have a Sablotron adapter:
The standard Erlang/OTP distribution comes with an odbc application
as well as the Erlang native database Mnesia. See the database
If you use http calls to the backend servers the http client in the inets
application (which is in Erlang/OTP) supports asynchromous calls.
The Yaws webserver also has a reverse proxy.
Now it is just to assemble the pieces and start the application :-)
Mon 20 Sep 2004 08:23 Tim Lavoie wrote:
> Hello all,
> I've stumbled across Erlang fairly recently, and have started reading,
> stepping through tutorials and so on. So far, so good! This has been
> primarily for my own interest, so far, but I can see where it might
> scratch an itch or two for my employer as well. It hasn't been
> suggested yet, never mind approved, but I would like to explore the
> ways in which Erlang might help, as well as any land mines to avoid.
> Perhaps it would be helpful to describe the current scenario to some
> degree, and where I see Erlang being helpful.
> Our current environment is modular, running on a variety of hardware
> and operating systems, with a web-based interface. A Java app server
> runs the front part, perhaps with a separate web server out in front,
> handling static content. The Java app is the main piece I'm involved
> with, and it touches everything. XSL templates are used to generate
> the pages dynamically, and a relational database is used fairly
> extensively. Also, some operations involve passing beefy chunks of XML
> to a separate number-crunching server, which can run for minutes on
> I'm not expecting to get anyone to make huge changes any time soon,
> but would like to at demonstrate that there are alternatives to some
> design choices which might be good to know about. If that helps
> improve things down the road, I'm happy.
> My main area of concern tends to be performance, so I have run
> repeatedly into areas which could use help.
> First, XSL. I understand now why it was chosen, back in the mists of
> time. I don't know that Erlang is able to help directly here, but it
> does cause headaches. Even if things stay in Java, there is some hope
> that this will go away. It's fine for morphing documents on occasion,
> but brutal when generating many large, dynamic pages while someone is
> waiting. Incidentally, my boss was the original architect, but took it
> well when I ranted unwittingly about this particular ugliness in his
> baby. I'm guessing there is hope for future change. <grin>
> Now, the main issue as I see it is that scalability is a problem. The
> performance woes are less apparent when subjected to few users, and
> the application server layer can be scaled with more hardware... given
> sufficient will and resources. Still, a few dozen users on this large
> app, and the app server is suffering badly.
> One area I can see Erlang's approach helping is with asyncronous I/O,
> combined with message passing. Right now, everything effectively
> blocks sequentially. Page transitions mean that current state gets
> written to the database, though most often this is "just in
> case". Similarly, requests needing that back-end number cruncher
> essentially tie up the user's browser until it comes back.
> I can see the database writes being implemented as sending the message
> to a process which handles the details, with the original web request
> then continuing on its way without waiting. This isn't generally an
> issue in my performance-test environment, but on client sites, with
> different networking and servers, it creates delays. In the case where
> the original process needs the result, it could ask for notification
> back, and carry on from there.
> The requests to the back-end server(s) are similar, and also block
> until done. Some of these requests naturally take longer than others,
> so I see Erlang as providing something of a more intelligent
> queue. Now, all requests are spawned together, so they slow down if
> there are more requests than processors. I'd like to see this as a
> queue with a notification back, like the database. Also, since we know
> what type of requests take much longer, Erlang's selective receive
> mechanism is a natural for giving priority to those which should
> return quickly.
> Phew... Sorry, that was long-winded, and I still have questions.
> - Has anyone migrated a large project of this sort? How did it go?
> - Is there some equivalent of Java's JDBC? Relational databases are
> pretty much a given, and persistent connection pools are pretty much
> required. I have seen mention of ODBC for Erlang; if this does the
> trick, particularly from Linux, that's a good start. Targets are the
> main RDBMS vendors, on several platforms.
> - Any other suggestions are naturally welcome.
> Tim Lavoie
More information about the erlang-questions