| Posted by sikkhost, 07-16-2008, 09:00 PM | | I run a rather large website which is accessed by a lot of users at once (not a ton of anywhere from 50-100 at most times).
I've been reading up on mysql_pconnect(), as I have some trouble with hitting the server limits on max users connected.
Which would you recommend that I use; mysql_connect() or mysql_pconnect() that would increase speed of connections and queries.
The site I'm referring to is: www.teripets.com if taking a look might help.
Thanks!
|
| Posted by jamesapnic, 07-16-2008, 09:21 PM | | I recommend you use pconnect, its the "preferred" method of doing things as it is much less intensive on mysql. Make sure you realise the caveats though, as mentioned on the PHP persistent connections page at http://uk.php.net/manual/en/features...onnections.php. On the other hand if you have lots of locking of tables and so forth, and your server can handle it, it might be better to use connect.
|
| Posted by Barti1987, 07-16-2008, 11:47 PM | | From PHP:
Self explanatory.
Peace,
|
| Posted by sikkhost, 07-17-2008, 12:49 AM | | Ok thanks. So I think that persistent connections will definitely be right for me.
What would you recommend I set my max server connections at? I will soon be running a
2 x Xeon 5410 Harpertown 2.33Ghz Quad Core
8GB Ram
15k SCSI Hard drive.
That'll be mainly for running SQL. What do you guys think a feasible max_connections would be?
Thanks for your help so far! I think that persistent connections will work well for me.
|
| Posted by The Universes, 07-17-2008, 01:12 AM | | If your connecting to the MySQL server locally (on the same machine), use sockets instead, its much faster. There are downsides to pconnect, which is part of the reason they were removed in mysqli.
my.cnf
Edit:
Heres a good article about this:
http://www.mysqlperformanceblog.com/...nections-evil/
|
| Posted by Saeven, 07-18-2008, 02:43 AM | | I'll definitely +1 on recommending that persistent connections be avoided. There are so many gotchas that can bite you down the road.
It's easy to claim efficiency, but the truth is that:
- descriptor based connections are nowadays inexpensive to setup/destroy
- persistent connections are still limited by the bottlenecks that usually create problems on any connection configuration - your MySQL's execution thread count and concurrency, and file IO
- number of connections. If you ever scale to a central SQL server with a number of external systems, you will run into different issues - connections being kept up for no reason
- even persistent connections must be 'maintained'. By nature, MySQL has wait_timeout and interactive-timeout directives that are charged with the destruction of useless connections. Your environment is then potentially 'charged' with a different type of keep-alive overhead that isn't really a lesser evil.
The argument for persistent connections, was that they are useful when you are otherwise consistently setting up/destroying a very large number of connections very rapidly, consistently. This is a tall order though, and there are a number of things that you will do before you get there, such as implementing relay mediators, using systems like memcached to interact with cached query/result data instead of the SQL server, etc.
I hope I've offered some food for thought!
Good luck.
Alex
|
| Posted by Steve_Arm, 07-19-2008, 12:12 PM | | And to add that then non persistent connect function, in latest php versions,
will search for an already open connection before creating a new one.
|
| Posted by creativeartist, 07-20-2008, 07:06 AM | | Are you using mysql enterprise version??.If you have a lot of hits its better to use enterprise version, it will be better
|
|
 Add to Favourites
 Print this Article
|
