Hi,

I am in the process of making online social network/community website... Basically similar to myspace.... I recently moved from shared hosting to VPS (obvious reasons). It is a Debian Etch3 box with 128 Mb RAM burstable to 256 mb..... That's for now, I will get additional 256 MB of RAM next month. I set up Apache/2.2.3 PHP/4, Mysql5, eAccelerator 0.9.5

What I am concerned mostly now is page execution time. First I thought mysql was slow, but now I am not sure.... For example, for the front page, I get:

Executed 80 queries in 774.35 milliseconds. Queries taking longer than 5 ms and queries executed more than once, are highlighted. Page execution time was 2060.83 ms.

Frontpage is mostly lots of panels, some of them display cached blocks, some of them display random SQL result. Why are queries executed in 0.7 seconds, and page execution time is 2 seconds ??? That surely has to be something with Apache configuration or php configuration.

in php.ini I set up memory_limit to 64M.
for eAccelerator I set up shm to 32M.

I really want to find out why is there such a big difference between query execution time and page execution time.... Page execution time should be a litlle bit higher than query execution time, right?

So, if you have any pointers for me where to look for solution, I would be more than thankful to you.

Thanks in advance

k.

Comments

NancyDru’s picture

The first thing I'd check is whether or not php is actually getting 64M (which is a bit high, but okay). Many host companies are using a php that is compiled without the ability to override the memory_limit. As a matter of fact, my host completely ignores both my php.ini and settings.php (at least the settings like memory and execution time).

Also, in a case of shameless self-promotion, I suggest the Site documentation module to look for possible little problems.

Nancy W.
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in your database

kalashari’s picture

Well, phpinfo() says that memory_limit IS 64M, just as I set it up. Did you mean to check it that way or some other way?

btw I just noticed I have plenty of php modules enabled as well... like: bcmath, bz2, calendar, ctype, dba, dbx etc... Don't know if I need all that, and if disabling some of them will reduce page execution time.

One other thing I read about on other thread is to try and put .htaccess file inside apache2.conf , so all the rules are loaded ONCE when the web server is started, and not on every page load. Will try that for sure.

Any other suggestions more than welcomed.

k.

yelvington’s picture

... php execution overhead. Are you sure eAccelerator is working properly?

You might try turning it on/off, or switching to apc, and see if there's a significant difference.

kalashari’s picture

it most probably is php overhead.... eAccelerator is working fine.. I tried turning it off, and I got even higher page execution times.

It's weird. When you click a link to load some page, it makes a pause of 1 or 2 seconds, and then it continues to load a page. See it for yourself: http://tranceplanet.org/ and try clicking on some links.

phpinfo is at http://tranceplanet.org/info.php

btw I lowered memory_limit in php to 32M

NancyDru’s picture

I went to your site and it loaded fairly fast for me. As busy as the front page is, I'm surprised it's not taking longer - especially the queries.

Nancy W.
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in your database

kbahey’s picture

80 queries in 700 ms is still high. Here is what I get on a Xen VPS (512MB though, but that should not matter):

Executed 269 queries in 92.61 milliseconds. Page execution time was 349.69 ms.

You seem to be on Virtuozzo (or OpenVZ), and its performance is known not to be good. I have moved clients who suffered under Virtuozzo to Xen or dedicated and they have been happier. I even shut external traffic and did a measurement to prove to the client that it is Virtuozzo and not hits from visitors that is causing the slowdown.

I bet this is the problem, but here are other suggestions.

I have seen similar things before, where PHP times is much more than query time, and it is almost always due to a stray module.

On 4.6, it used to be when you had a lot of aliases (thousands), and Drupal was trying to load them all in an associative array.

However, you seem to be running 4.7, so that would not be the issue.

Other things to look at:

- Do you have any module that opens sockets to other sites?

- Try installing the trace module and see where time is spend.
--
Drupal development and customization: 2bits.com
Personal: Baheyeldin.com

--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba

kalashari’s picture

- Yes, I just checked, I am on Openvz.... meanwhile they added more ram to my VPS, so it's 512 mb now.

- I tried APC an hour ago, but it seems that its performance is worse than eAccelerator, so I put back eAccelerator.

- I am running D 5.1

- I am not sure what stray module is?

- Yes, I do have lots of URL aliases (I think I applied patch for that from here: http://drupal.org/node/100301 )

- I don't have any modules that open sockets to other sites.

- I'll play with trace module and other stuff tomorrow, althought I won't be satisfied till I accomplish to have lower page execution times.

Thanks.

kalashari’s picture

Are there any other alternatives for trace module in D 5.1 ? How can I see where is most of the page execution time spent? Maybe to try Xdebug and debug my php scripts?

or maybe a lot of URL aliases is slowing the site down? I could have a site without all those fancy URL aliases if I knew page execution time would be higher.

I might turning off some modules as well and see how it goes with page load time.

kbahey’s picture

APC vs. eAccelerator: I have found that eAccelerator is 13% faster than APC, and also saves more memory per Apache process than APC. But that is a side point.

Aliases patch: Try the base 5.1 code, without any aliases patch. See if makes any difference. I would say the 5.1 code is OK.

An easy way to test if aliases are the problem is to disable the path.module and see if there is a difference in devel page execution times.

Profiling: For trying to pinpoint where the problem is, a profiler is needed. Xdebug has a profiler, but you have to use valgrind/cachegrind to visualize the results.

Initially I was suspecting that you have a bad module that is eating up time. But I think it is OpenVZ that is the culprit here. Memory would not help much. Try a Xen VPS host. If you don't have access to one, contact me privately if you are willing to send me a db dump and tar.gz of your site, and I can try it for you on a Xen box and give you the numbers.
--
Drupal development and customization: 2bits.com
Personal: Baheyeldin.com

--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba

kbahey’s picture

Home page
Executed 61 queries in 25.36 milliseconds. Page execution time was 285.24 ms.

/admin
Executed 37 queries in 10.13 milliseconds. Page execution time was 586.14 ms.

/forum
Executed 115 queries in 50.86 milliseconds. Page execution time was 340.5 ms.

/people
Executed 117 queries in 48.07 milliseconds. Page execution time was 367.32 ms.

Conclusion: Xen is better than OpenVZ.
--
Drupal development and customization: 2bits.com
Personal: Baheyeldin.com

--
Drupal performance tuning and optimization, hosting, development, and consulting: 2bits.com, Inc. and Twitter at: @2bits
Personal blog: Ba