We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 22303 MODX Staff
    • 10,725 Posts
    Lucas:

    FWIW, Evo is a much lighter, procedural solution, and as such baseline requests with no other processing involved tend to be a lot faster in Evo, and always will on comparable environments. However, as you scale the system up in terms of data and code, Revo performs better as you add more tags, scripts, and content. If you are stuck on minimal hardware, older PHP releases, and/or need more speed out of the gate for relatively small sites, Evo may however be a better fit in some cases.

    Also, I recommend using opcode caching via APC or PHPAccelerator to greatly increase Revo performance. There are a lot of classes involved that if you do not have to load on every request, improves throughput on Revo sites significantly.

    -Jason
      • 33968
      • 863 Posts
      Hi Jason, thanks for the explanation. I'm now certain the issue is due to the poor server, looking forward to giving Revo a better machine to run on.

      Developing locally on MAMP I've found Revo to be much faster than Evo. It also loads the blank page faster from the db and about the same from cache, so no issues there:
      MySql: 0.0000 s s, 0 request(s), PHP: 0.0349 s s, total: 0.0349 s s, document retrieved from database.
      MySql: 0.0000 s s, 0 request(s), PHP: 0.0166 s s, total: 0.0166 s s, document retrieved from cache.
      

      I'm using a lot of custom data, code and caching, and it's about 50 times faster than Evo in some cases... no complaints at all smiley
        • 36398
        • 13 Posts
        My Problem is not the request time for a site it is under 1 sec, my main problem is the cpu usage. I have no shared server it is only for my site. But the cpu usage is very high after open a page with is not cached and to high by a cached site. I tried xcache, eaccelerator and apc to reduce the cpu usage but i can not see any changes in cpu usage. Is there something i need to do to use this things with mode? Or is there any better opcode tool to use with modx?
          • 34178
          • 212 Posts
          Hi opengeek,
          Quote from: opengeek at Sep 09, 2011, 10:05 AM
          [...] The queries executed through xPDO take no longer than queries through the mysql extension[...]

          We cannot confirm this statement for our revo-installation (2.2.0-pl2). The first of the following calls (for counting objects of this year) takes 4.16797 seconds for execution. The second one only 0.00474 seconds:

          1. Call using xPDO (4.16797 sec)
          $start = microtime(true);
          $path = $modx->getOption('core_path') . 'components/ourpath/';
          $result = $modx->addPackage('ourpath',$path . 'model/','xyz_');
          
          $database = $modx->getCollection('datas', array('timestamp:>' => $startoftheyear, 'confirmed:!=' => ''));
          $count = count($database);
          echo "Since beginning of the year: ".$count;
          $end = microtime(true);
          $runtime = $end-$start;
          echo "xPDO: ".$runtime." seconds ";
          


          2. Call using mysql_query (0.00474 sec)
          $start = microtime(true);
          $server = ...;
          $user = ...;
          $password = ...;
          $table = ...;
          $connection = mysql_connect($server, $user, $password) or die ("no connection");
          mysql_select_db($table) or die ("table doesn´t exist");
          $SQL1="SELECT * FROM datas WHERE confirmed!='' AND timestamp>'$startoftheyear'";
          $result1=mysql_query($SQL1);
          $count = mysql_num_rows($result1);
          $end = microtime(true);
          $runtime = $end-$start;
          
          echo "Since the beginning of the year: ".$count;
          echo "Runtime mysql_query: ".$runtime." seconds ";
          


          Do you have any idea why the xpdo-call in our case needs so much longer than the mysql-call? Are there any settings of modx we might have set in a wrong way?

          Letti [ed. note: lettis last edited this post 14 years, 6 months ago.]
            • 22303 MODX Staff
            • 10,725 Posts
            lettis:

            You are comparing xPDO, which builds, performs, and creates rich, API objects from the results sets, to just getting the result sets of a pre-built query via MySQL. You do not have to load objects with the xPDO API; you can work with the result sets directly, as you would in MySQL. If you want to compare the speed of the actual queries, that is where you would benchmark it.

            Loading only lightweight facades of the xPDO objects is the next feature of xPDO already being developed to reduce the overhead involved in hydrating the richer xPDOObjects in read-only situations. This is the performance difference you are looking at in your benchmark, and can be avoided in these read-only situations by working with the PDO result sets directly where you do not need access to the API methods provided by the objects. These facades would then load the xPDOObjects on-demand if/when access was needed to API methods, writing data, or the object/relational metadata.
              • 34178
              • 212 Posts
              Hi opengeek,
              thanks a lot for this explanation.

              Btw I also tested $modx->getCount and the result was: 0.04463 seconds for the same query what is still 10 times slower than the mysql_query but hundred times faster than using getCollection followed by a count()-tag.

              Letti