Perrin, On Tuesday, November 26, 2002, at 09:01 PM, Perrin Harkins wrote:
That will be slow. All of the shared-memory modules are slow except IPC::MM. They're probably slower than using a database in most cases. File-based ones like MLDBM::Sync are faster.Quite odd. I read the performance thread that's on the P5EE page which showed that DBI (with MySQL underneath) was very fast, came in 2nd. Anyone care to elaborate why this is? After all, shared-memory is a thing in RAM, why isn't that faster?
But this isn't really the issue at hand so let's move on to more interesting things.
I'm not saying I want entity beans here ;) It's just that I've been doing perl to pay for bills and stuff the past few years and see a lot of people having some (possibly perceived?) need for something missing in perl. I think that is also the reason the P5EE effort started. Like I said: I've been reading up on J2EE lately and, even though it's not something in particular, I do read about stuff that seems to be solved (more or less) there that I've been designing/programming "by hand".Again; I don't know exactly but when I read stuff about entity-, session- and message beans, JMS etc., it has a lot of resemblance with what I'm currently doing "by hand" i.e. implement functionality like that on top of a "bare" Apache/mod_perl server.You'd have to be more specific, but in my experience people generally should not use Enterprise Java Beans unless they are doing something foolish like transactions across two databases. I think you're overestimating their value for common projects. If you just want a good way to do object persistence in an RDBMS, this isn't it.
If I read your mail, you mention some solutions/directions for some problems I'm dealing with, but that's just my issue (I think; it's just coming to me): we have a lot of "raw metal" but we do have to do a lot of welding and fitting before we can solve our business problems.
That is basically the point.
To illustrate that, I'll try to give a real-world example and my thoughts on them (the less interested reader can stop now ;)).
1) Handling of queued messages
Not sure if this is the right title so I'll describe what I mean from a real-world scenario.
My backend server generates push messages to end-users. This is a generic push message in the sense that they could be e-mail messages, SMS messages, WAP push messages etc. and there are lots of transport mechanisms involved to actually deliver those messages (e-mail/HTTP POST/UCP to an SMS-C etc.). To avoid having to handle all these different types and transports, my backend server just generates an object (of class PushMessage or subclass thereof) that logically defines the message and slaps some addressing info onto it which ultimately defines the target address (e-mail address/phone number etc.) and how to reach that target address.
To deliver these messages, I send them off to another server (using my own invented pseudo-RMI to call a method on that server). Due to the various transport mechanisms limitations, I can't deliver the messages synchronously otherwise I'd occupy my backend server while I'm connecting to some remote machine over the Internet which could take up to 5 seconds.
What do I do to solve this?
perl:
1. The server that does the delivery has plenty of threads (errrrr, a Apache/mod_perl child) so I hope I have enough of them to deliver the messages at the rate the backend server generates them: one child might take up to 5 seconds to deliver the message but there are plenty childs.
Not good. I've seen how this works and miserably fails when a delivery mechanism barfs.
2. Same as 1 but I never allow one delivery mechanism to use all my Apache/mod_perl children by adding some form of IPC (darned, need to solve my data sharing issues first!) so the children check what the others are currently doing: if a request comes in for a particular delivery mechanism, I check if we're already doing N delivery attempts and drop the request somewhere (database/file, whatever) if not. I have a daemon running that monitors that queue.
That daemon gets complicated quickly as it also has to throttle delivery attempts, I need some form of persistent storage (with locking), what do I do when the delivery mechanism has failed for 6 hours and I have 12000 messages in the queue *and* make sure current messages get sent in time?
Nasty.
3. I install qmail on the various servers, and use that to push messages around. This'll take me a week or so (hopefully) to get it running reliably in production (I'm not a sysadmin by default). Later on, I realise that for each messages, a fullblown process is forked *per message*: load up perl, compile perl code etc.. One of our apps is successfull and we go to >30 messages/second, oh my, my machine's load goes up to 60... 70... darned, I can't control it anymore! Uh oh. Call colocation facility to reset it!
(the above one is not really based on facts so don't blame me if some things are incorrect ;)).
java:
1. I write a 6-liner message bean. I'll use JBoss which is free and comes with a JMS provider. I can configure a lot of things in the JMS provider like the max. number of concurrent invocations of the message bean so I don't overload my machine. I could probably configure an expiry attribute to messages so messages that have become too old are dropped by the JMS provider.
Well, this is just one example, I was going to give 2 more, one on data-sharing between "threads" (Apache/mod_perl child in perl, thread in java) and one on remote method invocation (remote servers runs instances, I call methods on them from client machine) but I'm out of time for today.
BTW, object persistency would also be an interesting topic (Alzabo/Tangram/SPOPS/Class::DBI/hand-coded etc.) but after reading a very long discussion on entity beans, JDO and the myriad of O/R mappers on a java forum it appears it's not solved there as well ;)
I intentionally overstate things a bit, hopefully you all understand what I mean that with perl, there's a lot of raw metal out there but you still have to do a lot of labour before you can solve complex business problems. And even though I'm not sure at all that J2EE solves all of these, I do get the impression it offers solutions for these types of problems that work quite well.
Regards,
Bas.
