3 Replies Latest reply on Sep 10, 2012 9:42 PM by mbraendle

    FM web publishing uses most of CPU on page error

    GarySprung

      While developing a new CWP solution, some of my pages have errors, like incorrect URLs. Whenever I call a page with an error, FM Web Publishing "freaks out" on my test machine running OSX Snow Leopard Server. Activity Monitor shows CPU activity in the 75-95% range. During this period, the web server serves pages very slowly, if at all. The database server shows high activity, too.

       

      FM Web Publishing eventually settles down to 0.1%, but it takes several minutes or more. Using the FMS Console to stop Web Publishing does not stop the activity. I have to also quite the database server to get it to stop.

       

      It's not infinite loops causing this. A simple incorrect URL will cause the problem (as well as other mistakes).

       

      Running FMS 11.04.404. Snow Leopard Server updated to newest.

       

      I reinstalled FMS this morning. Still have the problem.

       

      I don't recall ever seeing this problem before with FMS before about a month ago. It seems like FM Web Publishing should handle such errors much better.

       

      What to do? Where to look?

       

      Only clue: Immediately after re-install, two errors appeared in Publishing Engine Access log:

      2012-09-10 09:44:43Publishing Engine AccessError127.0.0.1:49834 - - "/fmi/conf/config.wpc?-iwp_enabled=yes&-xml_enabled=yes&-php_enabled=yes&-language=eng&-xslt_enabled=no" 401 0
      2012-09-10 09:44:46Publishing Engine AccessError127.0.0.1:49844 - - "/fmi/conf/config.wpc" 401 0

       

      Gary Sprung

        • 1. Re: FM web publishing uses most of CPU on page error
          mbraendle

          This is known behavior; usually the CWPE just tries to return all records of the database in case of a (otherwise correct) query in which a field or field value was simply forgotten.

           

          The only way is to identify and correct the wrong URLs. When you test, you may also initially limit the number of returned records using the FM PHP API setRange() function.

           

          CPU overload may also occur when a search engine robot returns with a previously stored URL with a database query, that is

           

          • either malformed
          • or is good, but in the meantime the database record has been deleted, so that the query does something unexpected

           

          Hence, it is good practice to check all query parameters in the $_REQUEST variable, e.g. by using the PHP array_key_exists(), and also check the validity (format, scope) of the query parameter values.

           

          I think I have published something on misbehavior of web robot queries years ago in TechTalk or on fmforums.com, but don't find that post anymore.

           

          See also this TechTalk archive message somewhat related to this.

          1 of 1 people found this helpful
          • 2. Re: FM web publishing uses most of CPU on page error
            GarySprung

            It sounds like you are suggesting that my memory may be incorrect (happens all the time), that this behavior was probably occurring regularly with my development server.

             

            Anyway, the use of setRange() and array_key_exists() sounds wise. The PHP function array_key_exists would definitely test a GET request adequately. So we can kill the page if the query lacks the suffix params. With a POST, doesn't array_key_exists yield true, since the key is there whether or not a value has been posted?

             

            Thanks.

            • 3. Re: FM web publishing uses most of CPU on page error
              mbraendle

              Yes, but then you can check the value using $_REQUEST['your_parameter_name'] .