All this talk of beans and Java and I start coming out in a rash :) As for the application server implementation, since perl threading is rather limited, attempting to do object caching/brokering is not really worthwhile. It's better to have application servers that are essentially stateless, throwaway boxes. Trying to replicate session data across them and then keep track of which request went to which server is just too much to deal with and only really an issue when you have Very high traffic sites.
With MySQL being as fast as it is, opening and closing sessions for each request is not a problem. The secret is to limit the number of database connections (have a pool) because although MySQL is very fast and good at handling large tables its not so good at handling large numbers of simultaneous connections. Neither is Linux in general for that matter (assuming you are using linux) - which is another reason why trying to write extremely high performance application servers isnt hugely worthwhile. You are better of making sure that it will scale fairly well and have lots of low-midrange boxes if you need to serve allot of requests. MySQL now has good replication features now which mean you can setup a pool of "readonly" servers and make those session requests nice and snappy!. So yes, it can be hairy - it certainly took me ages to get a hang of managing the process pools. How to make sure that the parent process in this preforking application ALWAYS knew exactly how many children were there so that it could ensure there was enough available to take new requests. I tried using unix sockets/pipes/signals and I couldnt get any to work fast or reliable enough and had to use shared memory message queues which work like a dream (and they are even supported on HPUX! I also did things like slightly randomise the number of requests each process would handle so they wouldnt all finish at the same time and create a bottleneck. Since I didnt want to bother with caching objects or having a brokering type system I just start each application process with a couple of empty shell objects for the user and session. These are then populated as soon as a request comes in. Becuase the we have this separate session server (which is really a glorified MySQL connection pool) opening a session takes no time at all, less than 0.1 seconds. At the end of each request, all objects pertaining to that request are destroyed. If an application server dies its no big deal, the other one just starts to receive double the requests. The single point of failure is with the "writable" MySQL database and thankfully MySQL is pretty damn stable and also has an dynamic failover cababilities now. Im curious to know how you combined SOAP::Lite with your own application server - did you use the provided HTTP Transports or write your own? For our SOAP interface we just catch the raw XML and allow Apache to to the HTTP side of things. This is why it isnt particularly quick for us and is there moslty so we can speak to the outside world when required. SPOPS and Tangram sounds interesting - im certainly going to look into them. -----Original Message----- From: Tod Harter [mailto:[EMAIL PROTECTED]] Sent: 04 February 2003 22:19 To: Pavel Penchev; Tom Howe Cc: [EMAIL PROTECTED] Subject: Re: AxKit for web applications Sounds to me like his system is basically identical in most respects to the one I came up with for a virtual private exchange (sort of an auction server type system). We used SOAP::Lite entirely, each XSP taglib was just a thin wrapper over a stub API that called back to the application server running on a seperate set of back-end servers. The back-end servers in turn implemented a series of SOAP services that were very "bean-like" in there structure, though personally I think EJB is kaka in many respects, still the basic concept is sound. In our case we created our own object system, though there are some pretty good ones like Tangram and SPOPS out there for perl already. You might check them out. I will warn you though, there are some real hairy things to deal with! Everything at all levels has to be basically sessionless because you never know when people are going to come and go. You can't really cache objects in memory on the application server since you don't have session affinity between it and the front-end (and even if you did you'd have multiple caches, one for each back-end child apache). Of course you could implement your own SOAP server on the backend that was a single process, but even then it would need threads and perl threads can't share variables as of yet, so its a pretty big stumbling block. Overall though it was a nice approach and worked well for us, though our marketing people were too feeble to actually sell the project properly, sigh.... On Tuesday 04 February 2003 12:25 pm, Pavel Penchev wrote: > Hi, > > I got interested in your post - I'm in the planning stage of a system > just like yours: AxKit as a front delivery toolkit and a custom > application server as a business logic backbone. Is Storable fast > enough for complex data structures returned from the RMI/RPC calls - > results from database queries, complex hashes, etc? I guess the app > server servers some bean-like perl modules - do you have a > standartized skeleton for perl modules turning them into "Perl beans"? > I've met some very old projects in cpan that had done some work in the > bean direction. > > Are you planning to release the app server as open source ;)) > > Pavel > ----- Original Message ----- > From: Tom Howe > To: Robin Berjon > Cc: brian wheeler ; [EMAIL PROTECTED] > Sent: Tuesday, February 04, 2003 5:30 PM > Subject: Re: AxKit for web applications > > > Here at Deluxe Media Services we use AxKit at the front end (on our > webservers) and a custom perl application server sitting behind to handle > all our business logic. All database queries, data munging, session > handling etc is handled on the application servers. > > Every page requested is based on the same fundamental XSP page that > forges a connection with the application server. Additional XSP > components are then included where required to provide functionality > on a web page. These components use the connection with the > application server to send/receive object/method type requests. We > have a simple RMI/RPC type interface on the application server that > now supports SOAP but the default communications is a fast proprietary > message using Storable. > > The advantage of such a setup is that > * we have an additional layer of security (keeping all business > data/logic away from the front end web servers) > * we have higher separation of code/content which makes it easier to > manage > * we have a more granular means of scaling our website > > The connection required for each page does have a performance hit but we > have not found it to be an issue and the fact that we can scale in a > fairly linear fashion more than makes up for this. > > Feel free to ask for more details if this is a route you are interested > in. > > Tom Howe > > On Tue, 4 Feb 2003, Robin Berjon wrote: > > brian wheeler wrote: > > > On Tue, 2003-02-04 at 01:29, Kip Hampton wrote: > > >>I personally favor using something like CGI::XMLApplication because > > >> the model fits the way I like to work, but nothing that baroque is > > >> required. Again, as long as it can return an XML document to the > > >> Provider when needed, it can be as quick-hacky or as over-engineered > > >> as the situation warrants. > > > > > > I've found that using Apache::RegistryFilter and Apache::ASP filtered > > > into AxKit makes for neat fun. > > > > I'm curious as to the performance of that kind of setup, do you have > > any numbers? > > > > -- > > Robin Berjon <[EMAIL PROTECTED]> > > Research Engineer, Expway http://expway.fr/ > > 7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488 > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Tod Harter Giant Electronic Brain --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
