I would like to know how many database requests per page view (that is, every page that an user browses will start multiple requests to retrieve data from the database) should be made in order to have an "optimum" performance when I am using shared or dedicated hosting servers whose hardware is the most "commonly" provided (for example that that offer HostMonster or Bluehost providers). For both cases, I would like to know that when
I use MySQL or another database system
The database size is 1, 10, 100, 1000 Megabyte
I don't or I do use cache optimization
Users browsing pages are 10, 100, 1000, 10000 per second
In few word, under what conditions (considering the above cases) the server will begin to slow down and the user experience will be affected in a negative way? I appreciate some statistics...
P.S.: At this time I am using Ruby on Rails 3, so it is "easy" to increase requests!
I've had Facebook apps hosted on a shared host that did about a million pages per month without too many issues. I generally did 5-8 queries per page request. The number of queries isn't usually the issue, it's how long each query takes. You can have a small data set that is poorly indexed and you'll start having issue. The hosting provider usually kills your query after a certain length of time.
If you are causing the CPU on the server to spike, for whatever reason, then they may start killing processes on you. That is usually the issue.
Related
I created a instance (8 core) of MySQL on GCP. And a simple database in it. When I run a load of 40000+ concurrent users (1500 req/sec), the response times come out very high (10 seconds+). However I can see the hardware cpu utilization only at 15% or so.
What can I do to get the response time in msec?
Cheers!
Deepak
Imagine cramming 40000 shoppers in a grocery store. How many hours would it take for a shopper to buy just one carton of milk?
Seriously, there is a limit to how many connections can be made to any device. Database computers will top out at a few hundred. After that, latency will suffer severely as all the connections are waiting for their turn at various shared resources.
Another approach
Let's say these are achievable:
10ms to connect, fetch info for a page, and disconnect.
1500 pages built per second. (By the way, make sure the web server can achieve this.)
15 concurrent connections, each running for 10 ms. That equals 1500 pages per second.
1500 pages per second = 90000 pages per minute.
So, let's specify "40000 pages delivered to different (or same) users in one minute". I suggest that will be easy. And it won't require much more than 15 concurrent users. (Traffic is never smooth [except in a benchmark], so 50 concurrent connections may happen.)
[thousands of database servers is] where i would like to go eventually...however i need to solve a basic problem of mine which I have posted above!
Right, you have to expand the number of database servers now if you are serving 40,000 concurrent queries. Not eventually.
But let's be clear about what comprises concurrent users. Here's an example:
mysql> show global status like 'threads%';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| Threads_connected | 1266 |
| Threads_running | 9 |
+-------------------+-------+
I've analyzed high-scale production sites for dozens of internet companies. It's typical to see hundreds or thousands of concurrent connections but few of these are executing an SQL query at any given moment. When a given thread is between executing queries, you can view it SHOW PROCESSLIST but it is only doing "Sleep".
This is fine, and it's normal.
I give the analogy to an ssh session: you may be connected to a shell on a linux server, but if you're doing nothing, just sitting at a shell prompt, you aren't taxing the server resources much. You could have hundreds of users connected with ssh to the same server at once. But if they all begin running applications at the same time, you're in trouble. The server might not handle that load well. At least, all of the users will experience slow performance.
It's the same with a MySQL database. If you need a server that can support 40,000 Threads_running, then you need to spread that load over many MySQL servers. There isn't any single server that exists today that can handle that.
But you might mean something different when you say 40,000 concurrent users. It might be that you have 40,000 users who are looking at some page on your website at the same time. But that's not resulting in continuous SQL queries in 40,000 database sessions all at the same time. Each person spends some time reading the web page they just loaded, and scrolling up and down, and perhaps typing into a form. While they are doing that, the website is waiting for their next request, and the web server and database server is not doing any work for that user while it's waiting. It can do some work for other users.
In this way, a single database server can support 40,000 (or more) users who are by some definition using the site, even though only a handful are invoking any code to run SQL queries at any given moment.
This is normal and most websites can handle that traffic with no problems.
If that's the reality of your application, and you still have problems scaling it, then you might have inefficient application code or unoptimized SQL queries. That is, the website could serve the requests easily if you wrote the code to be more efficient.
Inefficient code cannot be fixed by changing your server. The cost of inefficient code scales up faster than you can hope to handle it by upgrading the server. So you must solve performance problems by writing better code.
This is the point of an old tweet of mine:
The subject of scalable internet architecture is very complex. You need to do a lot of study and a lot of testing to grow a website and make it scalable.
You can start by reading. My favorite is Theo Schlossnagle's book Scalable Internet Architectures. Here is a video of Theo speaking about the same subject: https://www.youtube.com/watch?v=2WuT2rdLK5A
The book is from quite a few years ago. Perhaps the scale websites need to support is greater than it was back then, but the methods of achieving scalability are the same today.
Test
Identify bottlenecks
Rearchitect your web app code to relieve those bottlenecks
Test again
So I have developped this website with Symfony3 and Doctrine. I have one major concern about performance with MySQL and more specifically the number of simultaneous open connexions.
For the moment, one to five users are online on the website. What happens if, let's say, 1,500 users connect within one minute? Does Symfony3 or Doctrine handle this kind of situations? How can I be sure the website doesn't go down providing me with the Too many connections MySQL error?
And if I go up to 5,000? And 10,000? The server has 4GB of RAM and a 2.40Ghz mono-core processor but I wouldn't worry about the hardware as I'm more concerned about MySQL.
These situations already happened in the past but I was running the website with Wordpress and W3 Total Cache plugin. Should I consider using a cache manager such as memcached or else?
In short, I'm concerned about the website becoming unavailable in case of sudden high trafic (and thought of the MysQL Too many connections error in first but I might be missing something even more important).
Thanks for lightening me out on this one as I'm not fully aware about performance issues with Symfony.
I believe it does open one connection per visitor. Regardless of whether it does or not however neither Symfony or Doctrine has a magic bullet to handle every load/connection scenario.
Why don't you use a load testing tool (there are many) and see how it actually pans out? In my experience predicting a bottleneck is useless, as they will always crop up where you least expect it.
For example, the MySQL connection limit is only one part of the optimisation puzzle. It's no good just worrying about connection limits, you need to respond to web requests as quickly and efficiently as possible to free up MySQL connection resources (and other resources your app is using). So if your server is slow you will run out of connections (or some other resource) almost immediately under significant load, regardless of MySQL connection limits.
That said, those server specifications seem a little low for 5-10k users per minute. I wouldn't expect a machine like that to handle that kind of load without some serious optimisation/caching/etc.
The symfony performance page is a good starter, and there is also a good article on caching - there's a ton of available material on the subject. Good luck! :)
If you use php-fpm it depends on pm.max_children in fpm/pool.d/www.conf.
pm.max_children refers to the maximum number of concurrent PHP-FPM processes allowed to exist in such a pool. If the volume of incoming requests requires the creation of more PHP-FPM processes than the number allowed by the max_children limit, those additional requests are backlogged in a queue to await service.
So when pm.max_children > max_connections (my.cnf) and active users > max_connections you will get "Too many connections".
I have a .mdb MS Access 2007 which is connected to a SQL Server backend. The tables are linked using a system DSN.
I need to do a stress test on the system and I would like to know the maximum number of users who can use the system at the same time.
The access .mdb file is done through the WTS.
Thanks for the help
The max number of users is going to depend on how well the application is written, and how good the network each user has.
You might have a great application, but if they are connecting to SQL server over a slow network, then the application will be slow with 2 users, and will be slow with 250 users.
If the network is good, and the application is well written to respect bandwidth requirements, then the application will likely run the SAME speed with 2, 10, 20 or 100 users.
And deepening on how large and powerful the SQL server box is? Then you can easy scale out to 500 users at the same time.
So this question is much difficult to answer. The network from the Access application to the SQL server is an important factor.
And some applications perform poorly with 5 users and SQL server, and thus such applications will perform even WORSE with 100, or 200 users.
So how well does the application work with 5 users, and then with say 25. If it written well, you likely not notice the difference. On the other hand if it slow with 1 user, then you downhill all the way from that point on as you add more users.
So it better run REALLY well with one user if you planning to scale out to many users.
So it certainly possible to have a 1000 users at the same time without much effort. As noted this depends on how well the application was designed with SQL in mind. So the quality of the work the developers done will be the LARGEST factor in how many users you can scale out to. As noted the capacity of the server and SQL will also determine the max number of users.
With a typical application that respects SQL server, then running 50 or 100 users should hardly break SQL server into a sweat is should be easy obtainable.
In fact for those 50 users, your HUGE resource HOG will be WTS.
Assuming you mean windows terminal services, then that setup requires HUGE resources, and far more then your SQL server will. This system will require much more attention and resources then SQL server. As noted, if the application runs rather well with 1-2 users, then usually such applications will run easy with 25. If the application runs slow with only 1 or 2 users, then you going to have scaling problems as you add more users.
At the end of the day, there are FAR FAR too many factors to give an answer without a case by case knowledge of the server involved, the network bandwidth, the capacity of the WTS, and MOST important how well the application was designed (this factor is #1).
I want to set up a MySQL database for a social networking website for my college.
My app can have at most 10,000 users. What is the maximum number of concurrent MySQL connections possible?
As per the MySQL docs: http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html#sysvar_max_user_connections
maximum range: 4,294,967,295 (e.g. 2**32 - 1)
You'd probably run out of memory, file handles, and network sockets, on your server long before you got anywhere close to that limit.
You might have 10,000 users total, but that's not the same as concurrent users. In this context, concurrent scripts being run.
For example, if your visitor visits index.php, and it makes a database query to get some user details, that request might live for 250ms. You can limit how long those MySQL connections live even further by opening and closing them only when you are querying, instead of leaving it open for the duration of the script.
While it is hard to make any type of formula to predict how many connections would be open at a time, I'd venture the following:
You probably won't have more than 500 active users at any given time with a user base of 10,000 users.
Of those 500 concurrent users, there will probably at most be 10-20 concurrent requests being made at a time.
That means, you are really only establishing about 10-20 concurrent requests.
As others mentioned, you have nothing to worry about in that department.
I can assure you that raw speed ultimately lies in the non-standard use of Indexes for blazing speed using large tables.
I have read every possible answer to this question and searched via Google in order to find the correct answer to the following question, but I am rather a novice and don't seem to get a clear understanding.
A lot I've read has to do with web servers, but I don't have a web server, but an intranet database.
I have a MySQL dsatabase in a Windows server at work.
I will have many users accessing this database constantly to perform simple queries and writting back to it new records.
The read/write will not be that heavy (chances are 50-100 users will do so exactly at the same time, even if 1000's could be connected).
The GUI will be either via Excel forms and/or Access.
What I need to know is the maximum number of active connections I can have at any given time to the database.
I know I can change the number on Mysql Admin however I really need to know what will really work...
I don't want to put 1000 users if the system will really handle 100 correctly (after that, although connected, the performance will be too slow, for example)
Any ideas or own experiences will be appreciated
This depends mainly on your server hardware (RAM, cpu, networking) and server load for other processes if not dedicated to the database. I think you won't have an absolute answer and the best way is testing.
I think something like 1000 should work ok, as long as you use 64 bit MySQL server. With 32 bit, too many connections may create virtual memory pressure - a connection has an own thread, and every thread needs a stack, so the stack memory will reduce possible size of the buffer pool and other buffers.
MySQL generally does not slow down if you have many idle connections, however special commands e.g "show processlist" or "kill", that enumerate every connection will be somewhat slower.
If idle connection stays idle for too long (idle time exceeds wait_timeout parameter), it is dropped by the server. If this is the case in your possible scenario, you might want to increase wait_timeout (its default value is 8 hours)