For a better experience, please enable JavaScript in your browser before proceeding. You are using an out of date browser. It may not display this or other websites correctly. You should upgrade or use an alternative browser.
Thread starter SirStevie3 Start date Sep 19, SirStevie3 Registered User. Local time Yesterday, Joined Jul 29, Messages So my primary table consists of 6, records. I have 18 Forms that utilize my tables and queries to make certain tasks a tad more convenient.
I have 10 reports so far with more on the "to do" list. I have about 84 different queries i use for various functions including updating records, creating records, and analyzing records. Is there a point where having too many queries becomes a problem?
Local time Yesterday, Joined Jan 23, Messages 13, It is difficult to say that X is too many of anything without knowing more about your database and business. What is the subject of the database? Have you normalized your tables? Perhaps you could post a copy of your tables and relationships to help readers understand what you have. Define what's acceptable in terms of response time, throughput, in normal and peek traffic conditions, and measure if these 10 queries are a problem or not i.
This approach amounts to an educated guess. Anything short of it is pure speculation, and worthless. If your application is already in production, and is working well in most cases, you can get feedback from users to determine pain points.
From there, you can model those pain points and corresponding load, and profile. Document your results. Once you make improvements to your application, you have a tool to determine if the optimizations you made achieved your goals. When new to development as I assume you are.
I recommend focusing on the most logical and obvious way to avoid over-processing. That is usually the avoidance of repeating a query by caching its first execution and checking for cached results before running queries. After that don't spend too much time thinking about the number of queries and focus on well-written code. That means a good use of classes, methods and functions. While still having much to learn, you do not want to over-complicate every interaction with the database.
Enjoy what you are doing and keep it neat. That will result in easier to debug code which in itself can lead to better performance when you have the knowledge to take your code further.
The performance of an application can be improved very quickly if the original work is well-written. I think its not a problem. Less is better no question but when you have - then you should think about your structure. And when you go in one query through a table with millions of rows without an index then are 10 to much. I understand that the correct answer in any context is related to what's needed to satisfy an application's functional requirements.
However, on projects where client requirements may be flexible or not properly set, or on projects where you as the developer have full control e. It depends how often the page is used, the latency between the app server and database server, and a lot of other factors. For a page which only displays data, my gut feeling is that is too many. However, there are some cases where that may be acceptable. In practice you should only optimise where necessary, which means you optimise the pages that people use the most, and ignore the minor ones.
In particular, the pages are not available to the public and the few authorised users hardly ever use them, there is no incentive to make them faster. Page accesses in the last 24 hours: — 6 pages viewed — 2 website visitors — 3 sessions. Once installed you will see a live query report at the top of your admin page.
If you click on this you can select queries by component, and that should tell you which plugins are making the most queries at any one time. Yep, when you do the math on page views x 80 or so queries, you are up in the half million queries a day mark. Skip to content WordPress.
Skip to content.
0コメント