> > No. We don't need the persistence. I'm planning on > managing the flow > > and not sending the data if the app isn't available to > receive it on the > > other end. > > Will you need to resend? Nope. Not in-line. We have an off-line message processing procedure to handle the missed transactions. > > > > What version of PostgreSQL are you using? > > > > 7.4.x > > Too old, 8.1 and 8.2 have way better performance. Yikes. This may be something we do by the end of the year. The client's on SLES9, so we can go as high as they support for SLES9. > > > What's your vacuuming strategy? > > > > We've played around with a lot of them. Overall, it > doesn't do too bad. > > But, we're trying to squeeze as much out of it as we can. > > If 7.4 isn't too bad, you should be happy with 8.2. You should really > asses the newer versions before diving into redoing your > messaging from > scratch. > > BTW, with 1800 servers, I'd expect you'll have a centralized automated > package rollout. Yeah... software rollouts and package updates are generally done in an automated fashion. We'll probably test 8.X as part of our evaluation process. If the sockets don't gain us much/anything, and the new PG version doesn't prove to gain us much, I suppose we'll try to compile the get_message_queue stuff. Any predictions on what we might see for performance without upgrading the PG version? Thanks for your feedback, thus far. It's good to hear what others think about this, as I'm pretty uncertain which direction to concentrate in. I've already got some stuff done on the local sockets. Bob > > -- > How many Vietnam vets does it take to screw in a light bulb? > You don't know, man. You don't KNOW. > Cause you weren't THERE. http://bash.org/?255991 > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
