Since your requests are mainly selects and each select is returning a lot of data (more than 500K) you could eliminate most of your network problem with MySQL replication : You install a slave server on your web frontend and use it for all your selects: no need to upgrade your network anymore !
Regards, Joseph Bueno Benji Spencer wrote: > Been waiting for someone to ask. The entire database is actually > slightly over 30K (35K is a closer number...small non-the-less) > > How does 12 MBytes/s come from 35K rows? Part of the output is a large > text field. Each chunk of large text is no more then 100K and not each > has a large text with it (and some of the large texts which are returned > are essentially empty). It is possible for more then one select to > return a couple large text blocks, though the majority do not. > > Combine that data with 15-25 queries/sec (I am assuming in MSSQL that a > transaction = query of some sort), it is a chunk of data. Assume that > you also return more then one row at a time (select * from table where > start_date < now and end_date > now). > > The bandwidth numbers are something which PerfMon and MRTG are telling us. > > The underlying code is (currently) (ASP, so it is using ADO to do the > connection.) > > I also wouldn't disagree with some of the application elements being > no-very-good and that fixes are needed there. We can even make some code > changes which will help for the short term. However we are trying to > build a case for what is really needed both short term and long term. > Time and Money are also both issues which we are trying to work with. > > > I hate to jump into this, but I have to ask if you have only 30k > rows why > > are you producing such large amounts of data? Are you trying to store > > blobs > > or large text data types? I don't think you will ever find a database > > vendor that wants to compete with a local filesystem under those > kinds of > > conditions. How do you connect to get the data ODBC, JDBC, DBD:DBI, > PHP? > > none of these are designed to move large amounts of data. I think the > > problem you have is with the application not the database, I would > > encourage > > you to move away from MSSQL if possible, but in this case I don't think > > changing the RDBMS will fix the problem. > > > > --- > Ben Spencer > Web Support > [EMAIL PROTECTED] > x 2288 > --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
