Are specialized application servers a good idea?

Post #123,533 by ben_tilly 10/31/03 12:30:08 AM Reply	Are specialized application servers a good idea? An interesting discussion on Perlmonks, [link\|http://www.perlmonks.org/index.pl?node_id=300988\|http://www.perlmonks...pl?node_id=300988]. I thought that it might be interesting to throw it open for discussion here. Cheers, Ben "good ideas and bad code build communities, the other three combinations do not" - [link\|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html\|Stefano Mazzocchi]
Post #123,538 by FuManChu 10/31/03 2:11:56 AM Reply	Only comment would be on a comment One of the respondents tossed off a line like, "you only want to separate layers if one of the data sources is slower than the others, which is rare." If you have total design control, perhaps. But throw someone else's code/API/app server/database/what-have-you into the mix and it rapidly becomes somewhat less than rare. The best advice I've found in the book "Thinking in Java", was to have a look at Python. Marijan Tadin, on comp.lang.python
Post #123,592 by ben_tilly 10/31/03 4:58:24 PM Reply	Down that path lies madness When programmers start spending time defending themselves from the incompetence of other programmers in their environment, any hope of sanity is gone. I'm not saying that there aren't sometimes very good reasons to embark on this path, but it should be a huge red flag that something is Fundamentally Not Working. Cheers, Ben "good ideas and bad code build communities, the other three combinations do not" - [link\|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html\|Stefano Mazzocchi]
Post #123,568 by dshellman 10/31/03 11:14:43 AM Reply	Re: Are specialized application servers a good idea? The main article wasn't particularly insightful. Obviously, remote calls are expensive. Wow, that's news. The use of separate physical layers has its place (he even mentions one). Use it where it makes sense, and don't use it where it doesn't. Of course, that tends to be easier said than done, as everyone has their own opinion of when and where. Unfortunately, whether something is "good" or "bad" in IT seems to resolve too much around "performance," whether that's via scalability (which is certainly important), throughput, latency, etc. Those are aspects of a system, but are not (necessarily) the most important (that's where the requirements come in). Some of the places where I think physical layers work (and not necessarily because of scalability, performance, or whatever): --Like he mentioned, the movement of static content into the web server is a definite performance gain (this is mostly because of the way the app servers are written and the use of memory, etc.). Unfortunately, in the J2EE world, this is a lost cause (to a certain extent), as the static content is usually bundled up with the web application, itself (it would be cool to see an app server/web server combo that was able to dynamically pull the static content out and stuff it onto the web server, but I digress). --Failover ('nuf said). --Organization (whether via politics, multiple clients types, etc.) --Budget issues (better cost utilization of hardware, via putting low processing stuff on cheaper boxes) --Security (firewalls, etc.) --Special circumstances (based upon special requirements, etc.) There are probably other reasons I couldn't think of off the top of my head, but that should prove sufficient. Dan
Post #123,591 by ben_tilly 10/31/03 4:55:54 PM Reply	It wasn't meant to be insightful It was an answer to a question that turned into a conversation which I found interesting. The main point made that I found interesting is that multiple physical layers are generally not a good idea for performance reasons in a web environment. A batch processing environment is a different kettle of fish. Your point about it being desirable to separate out different political groups is also good. But scalability is not a good way to go about it. Another interesting post in the same discussion is [link\|http://www.perlmonks.org/index.pl?node_id=301187\|http://www.perlmonks...pl?node_id=301187]. Cheers, Ben PS A note on your idea about moving static content into the webserver. This is fairly easy to do if Apache is your app server. See [link\|http://perl.apache.org/docs/1.0/guide/strategy.html\|http://perl.apache.o...ide/strategy.html] for some mod_perl configurations where you have separated the two. I have seen it done well with a make that generated the configuration files for multiple webservers from one static file (the idea being to make what is done dynamically with mod_perl in one match what is done statically in the next non-mod_perl enabled server). I see no reason why these strategies should be Perl-specific... "good ideas and bad code build communities, the other three combinations do not" - [link\|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html\|Stefano Mazzocchi]
Post #123,575 by tuberculosis 10/31/03 1:00:23 PM 8/21/07 5:57:30 AM Reply	I think they are used incorrectly I'm not a big fan of J2EE but the bit that I think is really silly is EJB. The rest of J2EE (servlets, jdbc, and the other services) aren't totally sucky (although jsp and the other java templating mechanisms that keep coming out are amazingly lame and clumsy to use). Of the web development environments I've used, I find Seaside amazing (the continuation based state management and html rendering api is very easy to use and thus productive), WebObjects very good (the quality is coming back with some new blood on the team), and Servlets only marginally better than CGI (the core advantage being some automatic session tracking and memory residency). While I am completely in favor of the logical business tier - I don't see any good reason to move it to another process space like EJB typically does. Nor do I find the constraints that EJB puts on my code to be acceptable. Whats left is nothing like objects. The one exception would be message driven beans - basically a reasonable way to have another process sit at the other end of a queue and chew away on async tasks. I'm forming more and more concrete opinions on this recently as I've begun working on a system in exchange for equity in a local startup. We acquired the system for pennies from another company that folded. It started out on WebLogic, but as they got into it they first pitched WL's jdbc connection pooling and wrote their own because of an inability to cache prepared sql statements. They also pitched JSP as being too simplistic and wrote their own html template processor. The object to database mapping was written by hand (ie - class methods provide meta info to their custom mapping code). Bottom line is that WL has been reduced to running servlets. Since we're a startup with no funding (everybody has a second job except me), I'm probably going to end up moving the thing to Tomcat or Jetty or something free like that. I think the whole J2EE app server market is overblown and agree that its mostly FUD and snake oil for sale there. In Java, you can't escape the creepy feeling. --James Gosling Edited by tuberculosis Aug. 21, 2007, 05:57:30 AM EDT Expand All History
Post #124,399 by gdaustin 11/5/03 10:22:45 PM Reply	Agree on most points.... >>I'm forming more and more concrete opinions on this recently as I've begun >>working on a system in exchange for equity in a local startup. We acquired >>the system for pennies from another company that folded. It started out on >>WebLogic, but as they got into it they first pitched WL's jdbc connection >>pooling and wrote their own because of an inability to cache prepared sql >>statements. When we switched to prepared SQL statements on DB2, our performance TRIPLED. So, I think this is HUGE. Prepared SQL statements are exactly how DB2 and Oracle win a lot of performance bakeoffs. The cached statements avoid the statement parser and optimizer, and that makes all the difference in world. >>They also pitched JSP as being too simplistic and wrote their own html >>template processor. The object to database mapping was written by hand (ie - >>class methods provide meta info to their custom mapping code). Bottom line >>is that WL has been reduced to running servlets. Since we're a startup with >>no funding (everybody has a second job except me), I'm probably going to end >>up moving the thing to Tomcat or Jetty or something free like that. Here's another thing I agree on. We used servlets first, then JSP, when the CEO didn't like the "look and feel" of the servlet code, and he wanted the creative arts department involved. But, it is clumsy to embed the Java into the HTML, especially when you want "really dynamic" OO pages. I'm really surprised that someone hasn't built a Smalltalk-like OO web tool that would build "dynamic web pages", using objects to assemble the screen dynamically with each request. I also agree that the highest performance is to keep as much as possible on a single machine, mainly because a in-system call overhead is usually about less than 1 millisecond on newer systems, and between-system overhead is at least 10-15 milliseconds, even on fast networks, similar machnes, with no marshalling. For each method call, it's at least a factor of 10 slower, and probably explains Maggie's 8 second transations on an EJB system. Glen Austin
Post #124,467 by tuberculosis 11/6/03 11:16:40 AM 8/21/07 6:19:40 AM Reply	RE: OO Web Tool I'm really surprised that someone hasn't built a Smalltalk-like OO web tool that would build "dynamic web pages", using objects to assemble the screen dynamically with each request. They have. Its called WebObjects. Use it once and most of the rest of the web app tool builders look like pikers. You can now use WO as part of your J2EE stack and deploy into existing app servers. So you can just use the presentation layer, or the OO/RDBMS mapping (which does in fact precalculate and prepare most statements it uses). Its only $700 but the tools only run (well) on Macs. Or you can switch to Smalltalk or Ruby and use Seaside which associates single argument blocks with form elements to let you store the results coming in anyway you like. Both of these make the conventional templating systems look like freshman level projects. "I believe that many of the systems we build today in Java would be better built in Smalltalk and Gemstone." -- Martin Fowler, JAOO 2003 Edited by tuberculosis Aug. 21, 2007, 06:19:40 AM EDT Expand All History
Post #123,695 by slugbug 11/2/03 12:01:47 PM Reply	Re: Are specialized application servers a good idea? Multiple physical layers are useful in some instances, but not for all types of apps or environments. For example, I've currently half a dozen sites that achieve sub-second response time to 1-2 second response time (depending on the SLA) using multiple physical layers. Leaving the GUI/static content on one layer seems to work just fine while calls for dynamic content can be made when needed (yes, there is some overhead with these calls). The middle tier (no EJBs) is tightly tuned to return results rapidly. The back-end data layer is also tuned for fast results. In this particular case, the physical split allows each layer to be individually fine tuned for performance. It also helps to have high-end hardware in the mix. In this particular example, there are also other benefits. All three physical layers are clustered between separate physical locations. The front end has clusters in two locations, the middle tier and backend also have clusters in two locations. This allows for on-the-fly load balancing and automated fail-over. Also, additional firewalling can be done between layers to increase security. The major down side I've seen thus far is that this type of arrangement is very complex to manage. More than once I've seen a component version change on one layer produce major problems. It is also very difficult to QA site changes to one or more layers in this type of architecture. Sites that do this definitely need a beefy QA environment. Perhaps this type of architecture is best for high-end sites or highly transactional environments that require added security and grainular high availability to meet compliance regulations (otherwise overkill)??? My $.02, -Slugbug
Post #123,697 by admin 11/2/03 12:19:31 PM Reply	Speaking of EJBs... (new thread) Created as new thread #123696 titled [link\|/forums/render/content/show?contentid=123696\|Speaking of EJBs...] Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #123,703 by ben_tilly 11/2/03 1:15:49 PM Reply	That makes sense Multiple physical layers should provide more security, and the ability to have multiple physical mirrors can give reliability guarantees that you can't get with a simpler system. However I would bet that getting this to work costs huge overhead in terms of equipment and skillsets just to make it happen. I would also bet that the performance (both latency and throughput) won't come near what the same investment could do with a simpler architecture. Data point. eToys in 2000 managed to serve over 2 million pages per hour in a heavily database-driven site using just a few dozen commodity Intel machines for webservers. (I don't know what the database was.) With today's hardware they would probably need only a handful. Perrin was instrumental in redeveloping the site to hit that load(1), and detailed notes on how he did it are [link\|http://www.perl.com/pub/a/2001/10/17/etoys.html\|here]. However an explicit design tradeoff was that overall site uptime and responsiveness is more important than perfect transactional semantics. If the webserver that you are being served from goes down, your current shopping basket gets lost. (If, however, you had made a purchase, you can bet that that purchase was securely recorded...) This means that you can cache certain kinds of data on the local webserver, removing pressure on the database and massively improving your potential scalability. By the time you have purchased a few beefy machines in a failover configuration, and purchased a QA environment, I simply don't see how you could be near their same cost point. And the performance that eToys had in 2000 is still more than sufficient for the vast majority of companies today. Including plenty that swear that they must have many physical layers to get the performance that they need. Cheers, Ben 1. A note for Karsten, Perrin ripped out the code that your former employer started with as a load of shite. "good ideas and bad code build communities, the other three combinations do not" - [link\|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html\|Stefano Mazzocchi]
Post #123,734 by kmself 11/2/03 6:54:30 PM 11/2/03 11:18:42 PM Reply	Database was... MySQL, initially. \r\n\r\n Later replaced with Oracle. Which Rob dissed thoroughly. Be interested to know Perrin's take on that -- better or worse or just different? Scuttlebut was that Oracle didn't like the fact that one of the top ten ecommerce sites wasn't running O. \r\n\r\n Perrin wouldn't have been the only person to call it that either, regarding the other comment. OS/Z was in the process of shedding most of the original code as well. Definitely not built for collaborative development, nor was the initial developer minded to cooperate. \r\n\r\n Edits: name fix --\r\n Karsten M. Self [link\|mailto:kmself@ix.netcom.com\|kmself@ix.netcom.com]\r\n [link\|http://kmself.home.netcom.com/\|http://kmself.home.netcom.com/]\r\n What part of "gestalt" don't you understand?\r\n [link\|http://twiki.iwethey.org/twiki/bin/view/Main/\|TWikIWETHEY] -- an experiment in collective intelligence. Stupidity. Whatever.\r\n \r\n Keep software free. Oppose the CBDTPA. Kill S.2048 dead.\r\n[link\|http://www.eff.org/alerts/20020322_eff_cbdtpa_alert.html\|http://www.eff.org/alerts/20020322_eff_cbdtpa_alert.html]\r\n Edited by kmself Nov. 2, 2003, 11:18:42 PM EST Expand All History
Post #123,745 by ben_tilly 11/2/03 9:02:37 PM Reply	Um, you have his name way wrong Perrin. Not Pippin. You could always email him at perrin@elem.com and ask. Or I could ask when I see him next. (I think that he is coming out in a month or so.) But as for Oracle vs MySQL, some better people to ask are [link\|/forums/render/user?username=broomberg\|broomberg], [link\|/forums/render/user?username=slugbug\|slugbug] and the like. Perrin was mainly concerned with the website/programming side. He isn't a DBA, nor does he pretend to be one, so he probably doesn't have strong opinions on that. Cheers, Ben "good ideas and bad code build communities, the other three combinations do not" - [link\|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html\|Stefano Mazzocchi]
Post #123,760 by kmself 11/2/03 11:26:51 PM Reply	Wups, fixed. DB... MySQL was principally "just a data store". There was relatively little reliance on higher-end database functions, and performance was at a premium. The claim was also that transactional integrity was provided through OM itself. \r\n\r\n Then again, I keep my salt-sack open when considering Rob's dictums. I've caught him at several times at really major fibs. E.g.: Linux doesn't do networking at runlevel zero, Molar volume is a (practically) constant number of molecules of gas at constant T & P. Given his background -- graduate biology w/ significant chemistry, and years of Linux programming and admin -- he really should have known these. Worst, he was insistant on being wrong. --\r\n Karsten M. Self [link\|mailto:kmself@ix.netcom.com\|kmself@ix.netcom.com]\r\n [link\|http://kmself.home.netcom.com/\|http://kmself.home.netcom.com/]\r\n What part of "gestalt" don't you understand?\r\n [link\|http://twiki.iwethey.org/twiki/bin/view/Main/\|TWikIWETHEY] -- an experiment in collective intelligence. Stupidity. Whatever.\r\n \r\n Keep software free. Oppose the CBDTPA. Kill S.2048 dead.\r\n[link\|http://www.eff.org/alerts/20020322_eff_cbdtpa_alert.html\|http://www.eff.org/alerts/20020322_eff_cbdtpa_alert.html]\r\n
Post #123,800 by CRConrad 11/3/03 9:25:57 AM Reply	i.e, Jordan, not Tolkien. But, hey, it's easy... ...to get your Fantasy writers mixed up, if you're not too much into that kind of stuff. :-) [Note for the uninitiated: Perrin is one of the main characters in Robert Jordan's "Wheel of Time" series, whereas Pippin, IIRC, is one of the hobbits in "the Ring".] [link\|mailto:MyUserId@MyISP.CountryCode\|Christian R. Conrad] (I live in Finland, and my e-mail in-box is at the Saunalahti company.) Resident [link\|http://z.iwethey.org/forums/render/content/show?contentid=119792\|zIWETHEY pilkunnussija]
Post #123,818 by ben_tilly 11/3/03 10:44:40 AM Reply	True, but Perrin is his real name "good ideas and bad code build communities, the other three combinations do not" - [link\|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html\|Stefano Mazzocchi]
Post #123,992 by CRConrad 11/4/03 3:03:38 AM Reply	Really? Kewl! First or last? And no, even if it were his given name, I'm not implying he'd have to be named for the character in Jordan's novels -- if nothing else, he'd have to be pretty precocious, as the first in the series appeared in (IIRC) 1989, and the series didn't reach greater fame until around the second or third book, a bit into the '90s. [link\|mailto:MyUserId@MyISP.CountryCode\|Christian R. Conrad] (I live in Finland, and my e-mail in-box is at the Saunalahti company.) Resident [link\|http://z.iwethey.org/forums/render/content/show?contentid=119792\|zIWETHEY pilkunnussija]
Post #124,020 by ben_tilly 11/4/03 9:58:36 AM Reply	First "good ideas and bad code build communities, the other three combinations do not" - [link\|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html\|Stefano Mazzocchi]
Post #124,408 by boxley 11/5/03 10:59:26 PM Reply	from a support point of view a good application will politely ask for a chunk of memory, an address to write data to and nothin else. Any other functions as to what machine/address space should be handled by the OS. thanx, bill "You're just like me streak. You never left the free-fire zone.You think aspirins and meetings and cold showers are going to clean out your head. What you want is God's permission to paint the trees with the bad guys. That wont happen big mon." Clete questions, help? [link\|mailto:pappas@catholic.org\|email pappas at catholic.org]

Welcome to IWETHEY!