* Thus wrote Kevin Grigorenko: > "Zareef Ahmed" <za@xxxxxxxx> wrote in message > news:001d01c4ba3b$a9e91c80$0100a8c0@xxxxxxxxxxx > > -----Original Message----- > > From: Kevin Grigorenko [mailto:kevin@xxxxxxxxxxxxxxxxx] > > Sent: Monday, October 25, 2004 12:36 AM > > To: php-general@xxxxxxxxxxxxx > > Subject: MySQL Scalability, part 2 > > > > Hi, > > > > First, sorry for posting an attachment. Second, I fixed my problem to > > use > > files, but I just had a general question: > > > > Is it really scalable to use MySQL on every page hit as compared to > > writing > > to files? Is it true that it only has a certain number of connections > > it > > can open at a time (20-30?), and the contention is larger? > > > > [>>] Yes mysql is much faster than file writing. And you can open > > multiple connection to it. > > What is this statement based on? I'm absolutely not questioning you, I am > just skeptical (if you have any websites or performance benchmarks, please > provide). It's hard for me to imagine that a file system access (let alone > appending one line to the end of a file) is slower than a MySQL execution. > Even if we assume that MySQL does everything in memory, here are just some > of the things that have to happen: > > 1. A MySQL connection may be opened. Perhaps there is connection pooling, > and this isn't too bad, just finds a reference to an already open MySQL > connection. Performance hit ~ 0 Using a file, a file handle must be otbained, depending on OS, Filesystem, hardware, etc. introduces many variables. > 2. mysql_query is executed, which first must go through the PHP library, > then connect to a socket (perhaps on another server, but we'll assume on the > same server for now). Performance hit ~ negligible if the mysql daemon is > on the same server > 3. The mysql daemon then has to process this request along with whatever > load is already on the daemon, then needs to get locks on the table to > insert into it. Performance hit ~ could be a lot, I doubt MySQL is faster at > locking than flock() I'm not sure how you come up with that belief, but you forget one important thing, the client does not have to wait for the insert to actually occur before returning. > 4. MySQL has to probably do a lot of in memory operations and then send the > result back over the socket. It sounds like you are almost trying to make up excuses not to use mysql. > > But if you have some webpages that prove otherwise, i will be VERY GLAD to > see them, because mysql sure makes everything much easier. I just can't see > it yet based on such a simple statement as above. Well just the other day, one of my webservers was gettting 150 hits per second. Each page has several queries, at least one insert, and mabey an update or two. Load on the database: 0.10. The bottle neck occured at the webserver, the number of processes that were running used up more RAM than it had. so in theory if I gave the webserver enough power so it could handle 1,500 hits per second, the database server might actually start using 100% of its cpu. Seeking advice on a mysql list might help. Curt -- Quoth the Raven, "Nevermore." -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
