FirstServed Homepage FirstServed Web Hosting | Housing | Domain Names Order Hosting and Domain names FirstServed Help | Support FirstServed Company Information
FirstServed Technical Blog
  • 8th Jul, 2009

    One of our customers has a Drupal enabled website… as many of you might know, Drupal is an open source CMS system with nice features, but it also is quite a bottleneck on server performance.

    We suggest drupal enabled website hosting customers to opt for a Virtual Private Server Light or even Virtual Private Server Standard setup. This means you can set up a nice isolated environment for a Drupal driven CMS website with dedicated server performance at severe reduced cost.

    When setting up the environment be sure to run through the following checklist:

    • CentOS 5.3 (for example)
    • Apache 2.2 webserver
    • MySQL 5.0 database server
    • PHP 5.1 or even better, 5.2
    • and, very important: eAccelerator 9.5.3 or higher.

    Why the eAccelerator? Well Drupal uses a lot of cached pages. Enabling Drupal caching already gives you a boost but installing eAccelerator makes sure frequently used php scripts are stored in a compiled state thus allow retrieval faster.

    On top of that, you may optimize the MySQL query_caching settings, as they Drupal also uses a lot of the same queries.

    You can find the latest version of eAccelerator here: http://eaccelerator.net/

    Take care,

    Dominique

    No Comments
  • 14th Oct, 2008

    One of our websites is using gettext for displaying dutch and french language. Based on the host header, we define the locale/environment variable. Sometimes it seemed that the locale and the environment variables were getting lost.

    After some testing we found the problem, just look at the warning on the PHP website:

    "The locale information is maintained per process, not per thread. If you are running PHP on a multithreaded server api like IIS or Apache on Windows you may experience sudden changes of locale settings while a script is running although the script itself never called setlocale() itself. This happens due to other scripts running in different threads of the same process at the same time changing the processwide locale using setlocale()."

     So when requests of the dutch site are running at the same time as request on the french site, the locale was getting mixed up. The chance of this problem occuring, gets bigger when requesting slower pages. The problem might not be visible when all pages are fetched very fast.

    Solution? Put each website in his own app pool, or move to linux

    Cheers
    Peter

     

     

    No Comments