Are there any tricks to transferring and/or sharing the Resource Links across multiple PHP pages? I do not want the server to continue connecting to the database just to obtain another link to the same user in the same database.
Remember that the link returned from mysql_connect() is automatically closed after the script it originated on completes executing. Is there anyway to close it manually at the end of each session instead?
PHP allows persistent mysql connections, but there are drawbacks. Most importantly, idle apache children end up sitting around, holding idle database connections open. Database connections take up a decent amount of memory, so you really only want them open when they're actually being used.
If your user opens one page every minute, it's far better to have the database connection closed for the 59 seconds out of every minute you're not using it, and re-open it when needed, than to hold it open continually.
Instead, you should probably look into connection pooling.
One of the advantages of Mysql over other heavier-weight database servers is that connections are cheap and quick to setup.
If you are concerned about large numbers of connections to retrieve the save information, you may like to look at such things as caching of information instead, or as well as getting the information from disk. As usual, profiling of the number, and type of calls to SQL that are being made, will tell you are great deal more than anyone here guessing at what you should really be doing next.
Related
On my website, when an user opens his profile or any other page, (almost all pages use data from mysql), my website makes around 50 connections to mysql in loading the page. This is the case on my development server, running elementary OS.
When I came to know about persistent connections in mysql, I was puzzled. If I am to run this website on a VPS (with low RAM in starting), and considering the overhead produced by a large number of mysql connections, will using persistent connections improve my website's performance?
Currently, I start and end a connection in every function. Is there a better way to connect to mysql?
And, taking into account that if 100 users are using my website simultaneously, what will be the performance if each page makes around 50-60 connections?
You asked so I will answer. You are doing this incorrectly. You should start the processing on each page request (each externally-accessible .php file) by using a common function to establish a single database connection, then you should reuse that connection.
You are getting away with this because you're probably using an automatic connection pool built in to your php database-access library, and because you have not yet scaled up your application.
You won't be able to scale this up very far using this multiconnection strategy because it will perform very badly indeed when you add users.
There are lots of examples of working open-source php-based web app systems you can look at. WordPress is an example. You'll find that most of them start by opening a database connection and storing its handle in a global variable.
You asked:
According to CBroe's comment, I changed my strategy. Actually, I am
using multiple database connections, but the functions are same (don't
ask why lol). So if I open connections on start, and then pass the
handler to the function, will that be an improvement?
Yes, that will be fine. You need to avoid churning connections to get best performance.
If you need connections to more than one different database, you can open them all. But it sounds like you need to hit just one database.
PHP doesn't have significant overhead when passing a handler to a function, so don't worry about that.
As explained wonderfully by Ollie Jones, I opened the connection on start, and my connections dropped from 50-60 per page to 1 per page. Although I don't see any change in performance on my local development server, this will surely we a great improvement when its on a live server. There is no need for me to use persistent connections yet.
I have a webapp written in PHP that currently creates a DB connection (using mysqli_connect) on every page to pull data from the database.
Recently, my website has slowed down (with some traffic increase), and I was wondering if the creation of so many connections - one for every user that is on any page - is causing the slow down?
Is there any fix for this?
Is it possible to create one sharable connection for the server? I know this is possible in python, but I do not know how I would implement such a model in PHP.
Note: My site is on BlueHost...I don't know if that also makes a difference.
Well two things to do.
Setup the slow query log in MySQL and see if there are queries that
are slow. Optimize these slow queries by using the EXPLAIN command
to identify missing indexes etc.
Setup connection pooling to eliminate opening a connection all the
time. See this link Connection Pooling In PHP for more information.
You can prepend host by "p:" when passing it to mysqli_connect to open a persistent connection.
You can read about Persistent Connections from the links below:
http://us2.php.net/manual/en/features.persistent-connections.php
http://php.net/manual/en/mysqli.persistconns.php
http://us2.php.net/manual/en/function.mysql-pconnect.php
But I would strongly suggest NOT to use Persistent Connections.
You will need to find out what is actually slowing your website.
Ping a website that loads fast for you. eg. google.com.
Ping your webserver, if the ping difference is a lot then you should ask BlueHost to resolve it.
Check whether there is any lag between your Web Server and Database Server. They could probably be:
on the same machine (mostly no lag)
on different machines in the same local network (mostly no lag unless there is a LAN problem, ask BlueHost)
on different machines in different networks (there could be issues, ask BlueHost if they could shift the Database Server within the same Local Network)
If everything above is fine and the pages are still loading slowly.
You could try explicitly calling mysqli_close() after your DB work in the page is done. This will free up your connection immeditely instead of waiting for the page to fully execute. You will then need to figure what is slowing the page after your DB work is over.
You can use mictotime() on your slow pages to see what code is slowing it down.
You could use this link: Accurate way to measure execution times of php scripts
Is it possible to keep a SQL connection/session "open" between PHP program iterations, so the program doesn't have to keep re-logging in?
I've written a PHP program that continually (and legally/respectfully) polls the web for statistical weather data, and then dumps it into a local MYSQL database for analysis. Rather than having to view the data through the local database browser, I've wanted to have it available as an online webpage hosted by an external web host.
Not sure of the best way to approach this, I exported the local MYSQL database up onto my web host's server, figuring that because the PHP program needs to be continually looping (and longer than the default runtime, with HTML also continually refreshing its page), it would be best if I kept the "engine" on my local computer where I can have the page continually looping in a browser, and then have it connect to the database up on my web server and dump the data there.
It worked for a few hours. But then, as I feared might happen, I lost access to my cPanel login/host. I've since confirmed through my own testing that my IP has been blocked (the hosting company is currently closed), no doubt due to the PHP program reconnecting to the online SQL database once every 10 minutes. I didn't think this behavior and amount of time between connections would be enough to warrant an IP blacklisting, but alas, it was.
Now, aside from the possibility of getting my IP whitelisted with the hosting company, is there a way to keep a MYSQL session/connection alive so that a program doesn't have to keep re-logging in between iterations?
I suppose this might only be possible if I could keep the PHP program running indefinitely, perhaps after manually adjusting the max run-time limits (I don't know if there would be other external limitations, too, perhaps browser limits). I'm not sure if this is feasible, or would work.
Is there some type of low-level system-wide "cookie" for a MYSQL connection? With the PHP program finishing and closing (and then waiting for the HTML to refresh the page), I suppose the only way to not have to re-log in again would be with some type of cookie, or IP address access (which would need server-side functionality/implementation).
I'll admit that my approach here probably isn't the most efficient/effective way to accomplish this. Thus, I'm also open to alternative approaches and suggestions that would accomplish the same end result -- a continual web-scrape loop that dumps into a database, and then have the database continually dumped to a webpage.
(I'm seeking a way to accomplish this other than asking my webhost for an IP whitelist, or merely determining their firewall's access ban rate. I'll do either of these if there's truly no feasible or better way.)
Perhaps you can try Persistent Database Connection.
This link explains about persistent connectivity: http://in2.php.net/manual/en/function.mysql-pconnect.php
I'm implementing an application that will have a lot of clients querying lots of small data packages from my webserver. Now I'm unsure whether to use persistent data connections to the database or not. The database is currently on the same system as the webserver and could connect via the socket, but this may change in the near future.
As I know a few releases of PHP ago mysqli_pconnect was removed because it behaved suboptimally. In the meantime it seems to be back again.
Based on my scenario I suppose I won't have an other chance to handle thousands of queries per minute but with loads of persistent connections and a MySQL configuration that reserves only little resources per connection, right?
Thanks for your input!
What happened when you tested it?
With the nest will in the world, there's no practical way you can convey all the informaton required for people to provide a definitive answer in a SO response. However usually there is very little overhead in establishing a mysql connection, particularly if it resides on the same system as the database client (in this case the webserver). There's even less overhead if you use a filesystem rather than a network socket.
So I'd suggest abstracting all your database calls so you can easily switch between connection types, but write your system to use on-demand connections, and ensure you code explicitly releases the connection as soon as practical - then see how it behaves.
C.
Are PHP persistant connections evil?
The problem is there can be only so
many connections active between Host
“Apache” and Host “MySQL”
Persistant connections usually give problems in that you hit the maximum number of connections. Also, in your case it does not give a great benefit since your database server is on the same host. Keep it to normal connections for now.
As they say, your mileage may vary, but I've never had good experiences using persistent connections from PHP, including MySQL and Oracle (both ODBC and OCI8). Every time I've tested it, the system fails to reuse connections. With high load, I end up hitting the top limit while I have hundreds of idle connections.
So my advice is that you actually try it and find out whether your set-up is reusing connections properly. If it isn't working as expected, it won't be a big lose anyway: opening a MySQL connection is not particularly costly compared to other DBMS.
Also, don't forget to reset all relevant settings when appropriate (whatever session value you change, it'll be waiting for you next time to stablish a connection and happen to reuse that one).
When I load a php page on my browser, it connects to the DB and runs some sql... let's say I now follow a link and it takes me to another page within the same website. What happened server wise? Did my first connection to the DB close, and re-opened again? Is that what happens in most cases?
Its very likely that the connection to your database is closed once the page has been processed by PHP, obviously then the result of the PHP is sent to the browser and viewed by the user.
Assuming you're running MySQL the only reason this wouldn't be the case is if the PHP script uses mysql_pconnect, where the connection will be kept open. However its usually good practice not use use this unless the MySQL server and the PHP server have a low bandwidth connection that's unused by other processes.
Yes, in most cases your database connection will close and re-open. In particular if the PHP interpreter is restarted for each page then it has no choice but to do this.
I believe the typical exception (although I've never used this myself) is where you're using something like mod_php.so (for Apache) and you arrange for a DB connection object to be stored as part of the user's session state. I don't believe that's recommended practise, though.
See http://php.net/manual/en/features.persistent-connections.php for more.
That's the usual case yes. But if you're talking about MySQL, you can use mysql_pconnect to keep persistent connections.
It depends on how the PHP was developed. If it was coded to close after each transaction, then yes it will be re-opened each time you view a page.
There is also the concept of a database connection pool. When a connection is used it is not closed but placed into a "pool" of connections waiting to be used again. Once a specified amount of time is passed without the connection being used it is then closed to save resources.
Pooling connections saves on processing time having to reopen a connection on each page reload.