I have a question I can't seem to find the answer to.
We are building a gRPC microservice in Go, to serve our main application written in PHP. I am running some tests on one of the functions now, to see the performance.
My results indicate that setting up the connection takes about 2 seconds, but after that, each call takes less than a microsecond.
How does it work in a real-life application? Does it open one shared connection that is kept alive for a while, or does each request to our application have to open its own connection to the service?
If each request has to open its own connection, is it possible to get around this to get rid of the overhead that comes with establishing a new connection?
What you need is called connection pool.
I found this PR https://github.com/grpc/grpc/issues/15426 after a short search on Google, but I am not sure if it is actually for pooling connections.
If you get able to create connections polls, you may just pick up one available connection and use for your request.
[EDITED]
I just found something that may work for your needs:
https://github.com/swoole/swoole-src#the-simplest-example-of-a-connection-pool
If you follow the example of the Redis connection pool you will be able to make a gRPC connection pool.
The latest php-grpc extension will keep your connections around and re-use them between requests.
Those are called "persistent" connections. A previous connection can be re-used if the set of parameters given to the connection constructor are exactly the same.
Source: php-grpc documentation: https://grpc.github.io/grpc/php/class_grpc_1_1_channel.html
By default, the underlying grpc_channel is "persistent". That is, given the same set of parameters passed to the constructor, the same underlying grpc_channel will be returned.
Related
I know that PHP automatically closes open MySQL connections at the end of the script, and the only viable way to open a persistent connection is to use the appropriate PHP function; many questions have been asked and answered.
What I would like to know is the benefit - or the inconvenient - of keeping a temporary connection instead of a persistent connection
EDIT :
A persistent connection for each PHP user session.
For instance, statements such as the following:
session_start();
$connection = new mysqli($host, $user, $pass, $db);
$_SESSION['connection'] = $connection;
might set up a reference to a mysqli object useful for performing multiple queries across navigation in the website within the same session by the same user.
If the connection is supposed to be used soon after its activation, would not be the right choice to leave it just open for further queries? Maybe this approach would generate an inconvenient situation (and possible security risks) when multiple users are HTTP-requesting pages from a web site which keeps MySQL connections alive?
I would like to know more. Thank you.
There's overhead to connecting to MySQL or any database, although it isn't typically large. This overhead can be greater when the MySQL service is running on a different server, or depending on the authentication method and init commands needed.
More, MySQL connections may have associated caches. So reusing a connection may be able to reuse these caches.
But saving a resource in the session doesn't work. Session data is serialized, and stored in e.g. a file between requests. That's why the persistent connect methods have to be used.
The reason is that the connection is ultimately a resource, or a socket connection on an internal class, and this can't be "saved" without special handling. Try it, and you'll see that you get an error (with PDO and mysqli.)
mysqli::query(): Couldn't fetch mysqli
I don't think there's any way to get session-specific connection reuse without writing an extension to implement it. Theoretically it's possible, though, and you could theoretically implement a method to pull a connection from the pool by session id.
There are a lot of potential drawbacks and risks to persistent db connections, though:
If your application creates TEMPORARY TABLEs, those tables will still exist on the next run, since it's the same MySQL session.
If you set any variables (SET SESSION or etc.), they will be retained.
Depending on how transactions are handled, it's theoretically possible a persistent connection may have an in-progress transaction.
If the application issues any LOCK commands or uses user-locks, the locks could be held between requests and unknowingly held in new requests.
On a multi-tenant (shared) webserver, the risk of another process somehow obtaining database access it shouldn't have is higher.
This may leave large numbers of connections open for long periods of time, increasing resource usage on the database server.
You still have to expect that the connection might be lost between requests.
I just ran a test creating 1000 non-persistent connections to mongodb via nginx/php fastcgi which took about 2.1 seconds on my dev machine. I then tried the same test using persistent connections, same result. I think I read somewhere that persistence in the php driver is now always enabled anyway. Next, I tried storing the connections to APC which resulted in a 7-9ms response time after the first request. Now I'm wondering a few things here:
There's almost never a time I can think of where I'd want to create more than one connection in my app at once and with a persistent connection from what I understand, new connections are created as needed by the mongo driver.
Creating a single connection seems to take about the same time as pulling the stored connection object from APC. Will caching the connection object ever really provide a benefit?
Caching the connection I know of course would still require some sort of check to see if it's even still a valid connection.. in performing this check each time, I wonder if it would negate the performance gain (if any) from pulling it from cache.
I can't seem to really find any material really covering any of this so I'm assuming it's because I'm confused in my understanding. Have any of you experimented with this?
Thanks!
First, as far as i know, APC is serializing data while storing it. so it would not make any sense to store any connection in APC.
Then, persistend connections will be reused by the php process for various requests. So a non persistend connection will be reestablished for each request the php process will receive.
Does the phpdriver for mongoDB provide a feature for starting the connection on demand - only.
Maybe this can save some load, although persistent connection is already really fast.
However, if there is a chance to optimize the application, i'd try this, too.
The alternative, calling the function to connect only on demand seems to be a bit tricky and makes my source very redundant.
The link H Hatfield posted addresses this question. Mongo::__construct() has a connect option that defaults to true, but you can specify false to delay the connection. The documentation isn't clear how lazy this is, as it only guarantees that the constructor will return without waiting for a connection to be established.
That said, you would be better off relying on persistent connections, which are being actively improved. I wouldn't be surprised if the lazy connection option was removed in a future major version of the driver.
On the documentation page when initiating the Manager it says:
this constructor performs no I/O. Connections will be initialized on demand, when the first operation is executed. So this is actually what you need already.
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).
I had never heard of persistent connections before, and I don't understand the advantages.
I run a PHP/MySQL based website, it receives tens of thousands of page views per day. In my header file on each of these pages I have just used mysql_connect() and I haven't bothered with terminating the connection in the footer file.
In my case are there any advantages of using mysql_pconnect()?
Using a persistent connection leaves the connection open after the script has finished executing. Opening and closing connections over and over causes overhead, while small, that will eventually mount up as the number of requests go up.
However, if you read the manual page for mysql_pconnect it states:
If PHP and MySQL are on the same server or local network, the connection time may be negligible, in which case there is no advantage to persistent connections.
If this is the case it may not be worth the trouble changing your code.
You can find more detailed information on persistent connections at the same site as above.
Check out this URL:
http://us3.php.net/manual/en/function.mysql-pconnect.php
Basically mysql_pconnect() tries to find a persistent connection already open with the credentials that you've specified. If it doesn't find one it makes a new one. It also doesn't close the connection after a statement is executed
So really in your case you may not notice a difference but in reality you should probably be using mysql_pconnect().