{"id":199,"date":"2011-04-08T14:51:34","date_gmt":"2011-04-08T19:51:34","guid":{"rendered":"http:\/\/xlinesoft.com\/blog\/?p=199"},"modified":"2026-08-22T17:07:16","modified_gmt":"2026-08-22T22:07:16","slug":"improving-perfomance-of-phprunnerasprunnerpro-applications","status":"publish","type":"post","link":"https:\/\/xlinesoft.com\/blog\/2011\/04\/08\/improving-perfomance-of-phprunnerasprunnerpro-applications\/","title":{"rendered":"Improving PHPRunner Application Performance"},"content":{"rendered":"<p>When a PHPRunner application feels slow, the first step is to identify where the time is actually being spent. A slow List page can be caused by the database query, custom server-side code, the amount of data rendered on the page, large lookup controls, network latency or the web server itself.<\/p>\n<p>The most effective approach is to isolate the bottleneck first and optimize only the part that is actually slow.<\/p>\n<p><!--more--><\/p>\n<h2>1. Check whether the problem is server-specific<\/h2>\n<p>Before changing the application, compare its performance in more than one environment.<\/p>\n<p>For example, run the same project using your local or built-in web server and compare it with the copy deployed to your production server.<\/p>\n<p>If the application is fast locally but slow remotely, investigate the hosting environment, database connection, server resources and network latency before changing the project itself.<\/p>\n<p>It can also be useful to test the remote application from another computer or network. This helps distinguish application performance problems from local Internet connectivity issues.<\/p>\n<h2>2. Identify which page is slow<\/h2>\n<p>Do not start by trying to optimize the entire application.<\/p>\n<p>Determine whether the problem affects:<\/p>\n<ul>\n<li>one particular List page;<\/li>\n<li>all List pages;<\/li>\n<li>Add or Edit pages;<\/li>\n<li>searching or sorting;<\/li>\n<li>dashboard pages;<\/li>\n<li>pages that use large lookup tables;<\/li>\n<li>pages with custom events or external API calls.<\/li>\n<\/ul>\n<p>If only one page is slow, compare it with a similar page that performs well. Differences in SQL, fields, lookup controls and custom events can quickly point you in the right direction.<\/p>\n<h2>3. Measure the request in browser developer tools<\/h2>\n<p>Modern browsers include developer tools that show how long each request takes.<\/p>\n<p>In Chrome or Edge, press <strong>F12<\/strong>, open the <strong>Network<\/strong> tab and reload the page.<\/p>\n<p>Look at the main page request first. If the browser spends most of its time waiting for the server response, the bottleneck is likely on the server or in the database.<\/p>\n<p>If the server responds quickly but the page still takes a long time to finish loading, look at JavaScript, CSS, images, other network requests and the amount of HTML being rendered.<\/p>\n<p>This distinction is important. Optimizing CSS or JavaScript will not fix a database query that takes ten seconds to execute, and adding a database index will not fix a slow external API request.<\/p>\n<h2>4. Test the SQL query directly<\/h2>\n<p>Slow SQL queries are one of the most common causes of slow List pages.<\/p>\n<p>A typical List page needs to retrieve the records being displayed and may also need to calculate how many records match the current filter. Searches, joins, sorting, calculated fields and permissions can make those queries more expensive.<\/p>\n<p>Run the relevant SQL directly in your database administration tool and compare the execution time.<\/p>\n<p>If the query is slow there as well, the issue is primarily a database problem rather than a page-rendering problem.<\/p>\n<h2>5. Check database indexes<\/h2>\n<p>Indexes help the database find and sort records efficiently. They become especially important as tables grow.<\/p>\n<p>Fields frequently used in the following operations are good candidates to review:<\/p>\n<ul>\n<li>search conditions;<\/li>\n<li>WHERE clauses;<\/li>\n<li>JOIN conditions;<\/li>\n<li>sorting;<\/li>\n<li>foreign-key lookups.<\/li>\n<\/ul>\n<p>For example, if users frequently search a large table by <strong>Residence_City<\/strong>, an index on that field can make a major difference.<\/p>\n<p>The exact index syntax depends on the database you use. Before adding an index, examine the actual query and, when possible, use your database&#8217;s query execution plan or analysis tools to confirm where the query is spending its time.<\/p>\n<p>Avoid adding indexes to every field. Indexes improve many read operations, but they also require storage and must be maintained when records are inserted or updated.<\/p>\n<h2>6. Reduce the amount of data displayed<\/h2>\n<p>A List page that displays hundreds of records and dozens of fields will require more work in the database, on the server and in the browser.<\/p>\n<p>Display only as many records as users reasonably need at one time.<\/p>\n<p>Also review the number of fields shown in the grid. A useful List page normally presents the information needed to identify and work with a record. Less frequently used details can be shown on the View or Edit page.<\/p>\n<p>Reducing both the number of rows and the number of visible fields can improve performance while also making the page easier to use.<\/p>\n<h2>7. Review lookup fields<\/h2>\n<p>Lookup controls can become expensive when the lookup table contains a large number of records.<\/p>\n<p>This is especially noticeable on search, Add and Edit pages where multiple lookup fields may need to load data.<\/p>\n<p>If a lookup contains thousands of possible values, avoid designs that require the entire list to be loaded before the user can interact with the page. Prefer searchable or dynamically loaded lookup behavior where appropriate.<\/p>\n<p>Also check whether the lookup query itself contains unnecessary joins, sorting or calculated expressions.<\/p>\n<h2>8. Temporarily disable custom code<\/h2>\n<p>Custom events are another common source of performance problems.<\/p>\n<p>Pay particular attention to code that:<\/p>\n<ul>\n<li>runs a database query for every displayed record;<\/li>\n<li>calls an external API;<\/li>\n<li>reads files from disk;<\/li>\n<li>sends email;<\/li>\n<li>performs complex calculations;<\/li>\n<li>executes repeatedly during page rendering.<\/li>\n<\/ul>\n<p>Temporarily disable suspicious custom code and test the page again.<\/p>\n<p>If the page becomes much faster, re-enable the code piece by piece until you identify the expensive operation.<\/p>\n<p>A query that takes only 50 milliseconds may not look slow by itself, but if it runs once for each of 100 rows it can add several seconds to the page.<\/p>\n<h2>9. Avoid repeated database queries<\/h2>\n<p>When the same information is needed multiple times during a page request, retrieve it once when possible instead of executing the same query repeatedly.<\/p>\n<p>For example, if several rows need information from the same lookup table, consider whether the required data can be retrieved as part of the main query or loaded once and reused.<\/p>\n<p>This is especially important for code that runs once per grid row.<\/p>\n<h2>10. Review sorting, searching and calculated fields<\/h2>\n<p>Sorting and searching large datasets can become expensive when the database cannot use an appropriate index.<\/p>\n<p>Calculated SQL fields and functions applied to database columns may also prevent efficient index use in some situations.<\/p>\n<p>If a page becomes slow only after a particular search or sort is applied, test that exact query directly in the database and inspect its execution plan.<\/p>\n<p>This usually provides much more useful information than trying random application settings.<\/p>\n<h2>11. Check page size and browser rendering<\/h2>\n<p>If the server responds quickly but the browser still takes a long time to display the page, look at the total response size and the number of elements being rendered.<\/p>\n<p>Large grids, many images, complex dashboards and large amounts of HTML can make a page feel slow even when the database performs well.<\/p>\n<p>The browser&#8217;s Network and Performance tools can help distinguish download time from JavaScript execution and rendering time.<\/p>\n<h2>12. Check external services<\/h2>\n<p>If a page communicates with an external service, test that service separately.<\/p>\n<p>Examples include:<\/p>\n<ul>\n<li>REST APIs;<\/li>\n<li>mapping services;<\/li>\n<li>payment gateways;<\/li>\n<li>remote file storage;<\/li>\n<li>email services;<\/li>\n<li>AI APIs.<\/li>\n<\/ul>\n<p>A page may appear to be slow because it is waiting for another server.<\/p>\n<p>Where possible, avoid making a user wait for work that does not need to finish before the page can be displayed.<\/p>\n<h2>A practical troubleshooting order<\/h2>\n<p>When a PHPRunner page is slow, work through the problem in this order:<\/p>\n<ol>\n<li>Compare local and remote performance.<\/li>\n<li>Identify the specific page or action that is slow.<\/li>\n<li>Use browser developer tools to determine whether the delay is on the server or in the browser.<\/li>\n<li>Test the SQL query directly in the database.<\/li>\n<li>Check indexes and query execution plans.<\/li>\n<li>Reduce unnecessary rows, fields and lookup data.<\/li>\n<li>Temporarily disable custom events and external calls.<\/li>\n<li>Optimize the component that measurements show is actually slow.<\/li>\n<\/ol>\n<p>Performance problems are much easier to solve once you know where the time is being spent. Measure first, isolate the bottleneck, and then make the smallest change that addresses the actual problem.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>When a PHPRunner application feels slow, the first step is to identify where the time is actually being spent. A slow List page can be caused by the database query, custom server-side code, the amount of data rendered on the page, large lookup controls, network latency or the web server itself. The most effective approach is to isolate the bottleneck first and optimize only the part that is actually slow.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1,8],"tags":[],"class_list":["post-199","post","type-post","status-publish","format-standard","hentry","category-php-category","category-tutorials"],"_links":{"self":[{"href":"https:\/\/xlinesoft.com\/blog\/wp-json\/wp\/v2\/posts\/199","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/xlinesoft.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/xlinesoft.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/xlinesoft.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/xlinesoft.com\/blog\/wp-json\/wp\/v2\/comments?post=199"}],"version-history":[{"count":15,"href":"https:\/\/xlinesoft.com\/blog\/wp-json\/wp\/v2\/posts\/199\/revisions"}],"predecessor-version":[{"id":3464,"href":"https:\/\/xlinesoft.com\/blog\/wp-json\/wp\/v2\/posts\/199\/revisions\/3464"}],"wp:attachment":[{"href":"https:\/\/xlinesoft.com\/blog\/wp-json\/wp\/v2\/media?parent=199"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/xlinesoft.com\/blog\/wp-json\/wp\/v2\/categories?post=199"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/xlinesoft.com\/blog\/wp-json\/wp\/v2\/tags?post=199"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}