5

The question, simply put, is the one in the title. Is it possible?

So far, my experience with scripting languages is that, to increase performance, you need to cache everything and later just serve the generated HTML files.

That's ok for some use cases, but when you really need to generate a new page in realtime, it's just impossible.

Drupal can take up to 3 seconds (or more!) to render some web pages (PHP execution time, not DB). That's crazy. Completely crazy.

If many projects (like Facebook) are using PHP, obviously the problem is mine. But googling for this problem shows that it's common. Too common.

(Of course I installed APC for PHP. It certainly helps, but PHP is still ultra-slow).

Must I assume this is the reality for Drupal / PHP?

Thanks.

Juan
  • 989
  • 1
  • 14
  • 22
  • 2
    A note: facebook.com uses AJAX and that is a very big performance plus. – Alin Purcaru Jan 03 '11 at 15:20
  • Sure it's possible. It just always depends on what kind of machine! Maybe look for Drupal optimization tips first? Its plugin system can be very heavy. Also, I've seen Drupal pages do 700 database queries *per request*. That's also something worth investigating – Pekka Jan 03 '11 at 15:21
  • Do those 3 seconds include browser output? – Alin Purcaru Jan 03 '11 at 15:22
  • @Alin: AJAX doesn't implicitly improve performance. (Sure, you don't need to re-render the entire page on each request, but you're also likely doing many more requests, so it balances out). – ircmaxell Jan 03 '11 at 15:23
  • @ircmaxell I don't see where those "many more requests" can be. I only saw one per link follow. And that request retrieves data in JSON format. By not retrieving HTML each time and only updating the parts that change I think performance is increased significantly. – Alin Purcaru Jan 03 '11 at 15:30
  • 4
    @Alin but don't forget that the Drupal bootstrap will run for each Ajax request separately. The subjective impression will be faster, but the overall stress for the server will probably be increased – Pekka Jan 03 '11 at 15:40
  • @Alin Purcaru thats not true in general , since every ajax call is at least one bootstrap call @Juan Medín short awnser: no, longer awnser: yes - if your page doesn't have many elements / doesn't force drupal to make complex Requests and and your mysql Cache (mysql, NOT drupal DB based) is configured halfway descend. But Without any cache - honestly, response time bellow 200ms .. no, I don't think so – Hannes Jan 03 '11 at 16:10
  • Which pages are taking 3+ seconds? – ceejayoz Jan 03 '11 at 16:36
  • 1
    Facebook uses XHP: https://github.com/facebook/xhp/ with HipHop: https://github.com/facebook/hiphop-php/wiki/ – Phill Pafford Jan 03 '11 at 17:30
  • 1
    @Pekka I did. I've implemented many of the optimization modules and set the configuration that I found useful. Now Drupal is *noticeably* faster, but still extremely slow. Even in my local computer (MBP 2.6Ghz 8GB) – Juan Jan 04 '11 at 06:35
  • @Alin Purcaru Yes, in my local machine – Juan Jan 04 '11 at 06:35
  • @Hannes Just ignore the DB time. I'm benchmarking both and the 3s are for the PHP part – Juan Jan 04 '11 at 06:39
  • @ceejayoz Speed can't be measured this way, but just to show the kind of page: I've used Drupal for a hobby project (you can check it here: http://destinotailandia.com) The main page is cached, but if you click on profile pages -just click over an user name- they aren't. And man, they are painfully slow (again, the DB is taking less than 100ms). It's an extremely low traffic site, so probably you will be alone with a 2.4Ghz core and 1GB RAM. Times in my local machine are better, but not that much. – Juan Jan 04 '11 at 06:44
  • @Juan Medín well, but you must do more then just bootstraping for example : http://pastebin.com/1V9XDrkR (pure bootstraping, nothing else - only takes about 0.040 S) and bootstraping + pagecallback : http://pastebin.com/SFZhf7Ku is usually in the area of 3 Seconds – Hannes Jan 04 '11 at 08:17
  • @Juan weird. Any chance of breaking down further what causes this? My number one suspect would be the many `include()` operations. – Pekka Jan 04 '11 at 10:44

4 Answers4

4

Short answer is no. But why would you not want to cache?

What do you mean by 'generate a new page in realtime'? Authenticated users (anyone logged in) can see new content right away. Anonymous users may have to wait a little bit (if you are using Boost, for example), BUT, you can always control it, or flush it when new content is added. You should cache as much as you can.

You can install Boost (static HTML files), Memcache, and enable Drupal cache. It's encouraged, especially the last one. You can also run nginx on the server.

You can also try using Pressflow, a drop-in replacement for Drupal that will give you better performance.

http://pressflow.org/

Its been discussed many times.. you can make Drupal extremely fast if you want to. Check out some of the 2bits articles:

http://2bits.com/contents/articles

Utilizing the available methods of caching will help you keep your hosting cost low, instead of throw more hardware on an unoptimized site.

Kevin
  • 13,153
  • 11
  • 60
  • 87
  • 1
    One reason why you may not be able to cache is if you have a dynamic content block that you want to display on every page. I'm battling with this exact problem at the moment; I'd love to use a cache, but we need the dynamic functionality, and none of the caching solutions I've found have been able to work with it. See my question here: http://stackoverflow.com/questions/4511721/caching-a-drupal-site-with-session-specific-data-on-every-page – Spudley Jan 04 '11 at 14:05
  • 1
    Yes. I forgot to mention that block caching is a tricky thing- but there are modules that get around this by making blocks requested via ajax, like Ajax Blocks: http://drupal.org/project/ajaxblocks – Kevin Jan 04 '11 at 14:12
2

As you say, Facebook uses PHP, and they clearly have reason to need good performance. Their solution was to write their own compiler for PHP called HipHop, which they released as open source. If you're worried about PHP's performance, you should give it a try as it will definitely improve things.

The downside is that it doesn't (yet) cover 100% of the PHP function set, so some PHP programs may not compile. I don't know where Drupal fits into this, but it would be worth trying it out - there's nothing to be lost by doing a test compilation; if its not going to work, you won't have lost anything.

On a similar vein, there is a project in the Drupal community to convert parts of the Drupal Core into a PHP Extension, meaning that some key Drupal functions are then built-in to the PHP runtime as compiled code. See the project page here. But note that this is still in a fairly early stage of development: it's still listed as experimental, and only covers a small number of functions. It might be worth keeping an eye on the project, though.

Spudley
  • 166,037
  • 39
  • 233
  • 307
0

According to http://groups.drupal.org/node/34076, yes you can get a < 200ms response time with Drupal without caching.

Pierre Buyle
  • 4,883
  • 2
  • 32
  • 31
0

The tips that I've received from some friends regarding Drupal load performance is to install less than 40 modules.

More than 40, especially if those contrib modules use too much hooks and memory, and the performance will be decreased.

Other tips:

  • remove imagecache ui and views ui on production site
  • if possible put htaccess on vhost.conf so that htaccess will only be called once on apahe start
  • use throttle module
  • use gzip for all html, css and js files
  • use cdn module and amazon server solution
  • use ajax for some parts or blocks of your site
  • last and if there is enough budget, migrate to oracle
saluce
  • 13,035
  • 3
  • 50
  • 67
Winyo
  • 1