I've been thinking about releasing it as open source for ages but it would mean finding the time to tidy it up and make it alot more accessible. Its not a great deal of code but without a cleanup would make updating and supporting it a pain.
Yes, Storable is certainly fast enough, we send pretty large amounts of data back and forth using it with no problems. Our infrastucture actually splits the app server into 2 layers. There is a general application server that sits and accepts requests from the webserver. It handles all the business logic. The second layer contains application servers that act as interfaces to other services. At the moment we have just one - a session server that manages connections to a MySQL database. The reason we do this is because the application server works in a pre-forking fashion. That is, it creates processes in advance of them being required. Since only a couple of connections to our MySQL server are ever required it doesnt make sense for every process of the main application server to have its own connection. Since every page request requires the users session to be pulled from the database and the sessions can (occassionally) be over a meg its important that the messaging system is quick and so far we havnt had any problems. In fact the bottleneck in our system is definately XPathScript rendering and the way we generate our XSP pages on the fly. The load on our webservers is much higher than our application servers. So anyway, we have 2 webservers running Apache, and 2 application servers - each running one application server and one session server. Both the application server and session server use the same preforking server codebase which takes similar parameters to apache. ie max processes, min processes, no of iterations per process etc .. In essence the application server works like this. 1 a listening port is created, 2 a number of processes are forked which take a copy of the listening port 3 the server goes into a loop and makes sure that there is always at least 1 idle process (it uses shared memory messaging to keep an eye on its children) 4 for each message the server recieves from the webserver it unpacks it and hands it over to the inherting application. 5 in the case of the main application server it then looks at the message for either - an RPC procedure call - runs 'builtin' methods like 'ping' - an RMI class and method - instantiates objects and invokes methods upon them 6 it then runs that procedure or method and returns the results. 7 if the connection is broken by the client, it cleans up, destroys all objects and gets ready for the next connection So, our applications dont have to follow any particular style or structure, the objects that are required are simply instantiated when required. When the classes are changes they are reloaded on the fly. The only difference between our modules and normal ones is that they expect to be given access to certain objects. So, whenever the application server first creates an object it attempts to provide it with access to other objects - ie session and user data. The connecting application (perl handler) needs to use a connector we have written that uses AUTOLOAD to transparently hand method calls over to the application server. A bit like this.. my $c = new Connector($server_ip,$server_port); my $clock = $c->new_object( 'Clock' ); print $clock->current_time(); In this example the $clock object is just a shell that sends any methods run upon it to the application server. We have also recently added a SOAP interface (SOAP::Lite) to it so we can talk to the outside world more easily but it's not especially quick. If you want to see the source for the core application server email me and Ill arrange something with you. regards, Tom -----Original Message----- From: Pavel Penchev [mailto:[EMAIL PROTECTED]] Sent: 04 February 2003 17:25 To: Tom Howe Cc: [EMAIL PROTECTED] Subject: Re: AxKit for web applications 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
