Re: apache::dbi vs mysql relay
Perrin Harkins wrote: Are there any benchmark comparisons between apache::dbi and mysql relay? I've never heard of this mysql relay before. A Google search found this: http://www.firstworks.com/sqlrelay.html Is that it? Looks interesting! On http://www.firstworks.com/sqlrelay/programming/perldbd.html it says: For the duration of the session, the client stays connected to a database connection daemon. While one client is connected, no other client can connect. Care should be taken to minimize the length of a session. Doesn't seem good at all. Reminds me of the early days of mSQL (is it still working with one client at a time?) _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: apache::dbi vs mysql relay
On http://www.firstworks.com/sqlrelay/programming/perldbd.html it says: For the duration of the session, the client stays connected to a database connection daemon. While one client is connected, no other client can connect. Care should be taken to minimize the length of a session. Doesn't seem good at all. Reminds me of the early days of mSQL (is it still working with one client at a time?) The documentation is confusing. My impression is that there is a pool of available database connections, as well as a pool of listener daemons. This statement seems to be saying that while connected you tie up one listener and one database connection. Their theory seems to be that connecting to their daemon is much faster than connecting to the database, and the actual database connections are kept open by the daemons. What I don't understand is why they separate the listener and database connection daemons if you always need one of each to do anything. In theory, using this thing could result in fewer database connections although it would impact performance at least a little. - Perrin
Re: apache::dbi vs mysql relay
What I don't understand is why they separate the listener and database connection daemons if you always need one of each to do anything. Probably for scalability. The database engines are doing the work and the sooner they can free themselves up (due to a slow client, for example), the better. Rob
Re: apache::dbi vs mysql relay
Are there any benchmark comparisons between apache::dbi and mysql relay? I've never heard of this mysql relay before. A Google search found this: http://www.firstworks.com/sqlrelay.html Is that it? Looks interesting! We're planning on having four sql servers, one of them will do all of the writes to the db and the other three will only be used for reads from the db. The data in the db that is doing the writing will be constantly replicated across the other three machines. Which would be better to use to initiate a persistent database connection? The main concern we have is having to have two different database handles open for one script, one to the machine that does the writing and the other to do the reads. Can Apache::DBI detect this? Apache::DBI can certainly tell the difference between two database handles. It caches based on your connection parameters. For raw performance, you can't beat Apache::DBI. It simply does a hash lookup, and uses an already open connection if there is one. SQL Relay appears to need at least one socket connection to be created at the beginning of each request and torn down at the end. SQL Relay looks like it would scale further though, in situations where the number of open database connections becomes an issue. This is generally not a problem for small sites or sites running databases like Oracle on big iron, but it could be in your situation, using MySQL. Also, SQL Relay claims to have load balancing features between multiple replicated databases. With Apache::DBI, you would need to configure your mod_perl servers to point to specific databases. If you try this thing out, please report back to the list on how it works for you. I think a lot of people here might be interested. - Perrin
