Question about Drupal performance
From the admin staff on a web host I am using I got a message saying: "Personally I'll recommend Drupal when pigs can fly, because I believe it is just that ... a pig. Slow even when I tried it on my dedicated server... its very full featured, but it is hardly peppy, at the best of times... and, I'm not aware of many Drupal sites on the platform -- there are definitely better choices performance wise at the current juncture." Can you comment on this, please? I am just going to setup some more Drupal site and got a bit frustrated. - L
Hi Lennart, Drupal's great flexibility brings some drawbacks regarding performance, many DB requests, function calls etc. But it depends a lot on how many and which modules you enable and how many blocks, links etc. you display on your pages. Drupal's cache works very good and greatkly increases performance. An additional op code cache will help too. Moreover there are some 3rd party cache modules. - yaph
From the admin staff on a web host I am using I got a message saying:
"Personally I'll recommend Drupal when pigs can fly, because I believe it is just that ... a pig. Slow even when I tried it on my dedicated server... its very full featured, but it is hardly peppy, at the best of times... and, I'm not aware of many Drupal sites on the platform -- there are definitely better choices performance wise at the current juncture."
Can you comment on this, please? I am just going to setup some more Drupal site and got a bit frustrated.
- L
-- Ramiro Gómez Software developer with focus on content management systems, SEO, and open source. Websites: www.ramiro.org www.seo-expert-blog.com www.torlaune.de
Hi Ramiro, Thanks. If you imagine some ten thousands of people going to a meeting, will Drupal be a good CMS for the information they need and create? I guess this meeting will involve a lot of discussions and comments. I have read that Drupal has been used a lot for different political campaigns. This would be something similar. - L Ramiro Gómez wrote:
Hi Lennart,
Drupal's great flexibility brings some drawbacks regarding performance, many DB requests, function calls etc. But it depends a lot on how many and which modules you enable and how many blocks, links etc. you display on your pages. Drupal's cache works very good and greatkly increases performance. An additional op code cache will help too. Moreover there are some 3rd party cache modules.
- yaph
From the admin staff on a web host I am using I got a message saying:
"Personally I'll recommend Drupal when pigs can fly, because I believe it is just that ... a pig. Slow even when I tried it on my dedicated server... its very full featured, but it is hardly peppy, at the best of times... and, I'm not aware of many Drupal sites on the platform -- there are definitely better choices performance wise at the current juncture."
Can you comment on this, please? I am just going to setup some more Drupal site and got a bit frustrated.
- L
Khalid just sent some impressive numbers. I think you couldn't run ebay on Drupal but with good hardware, PHP accelarators and caching you can serve lots of users.
Hi Ramiro,
Thanks. If you imagine some ten thousands of people going to a meeting, will Drupal be a good CMS for the information they need and create? I guess this meeting will involve a lot of discussions and comments.
I have read that Drupal has been used a lot for different political campaigns. This would be something similar.
- L
Not wanting to say anything bad in regards to the admin staff at your web hosting company but I believe that they are wrong. Drupal out of the box is going to be slow. Just as 98% of all web applications will be until you take the time to configure them properly. 1) Turn on Drupal caching 2) Enable an Opcode Optimizer such as eAccelerator, XCache, APC 3) Enable Memcache (can be a bit tricky) 4) Tweak Apache to meet your needs. 5) Tweak MySQL to meet your needs. Performancing of ANY web site/web application is an ongoing process and should always be revisited to ensure that you're getting the most out of your hardware. -t Tony Guntharp Co-Founder SourceForge.net fusion94@damagestudios.net 1-415-692-5507 1-415-680-5361 On Jul 9, 2007, at 2:54 PM, Lennart Borgman (gmail) wrote:
From the admin staff on a web host I am using I got a message saying:
"Personally I'll recommend Drupal when pigs can fly, because I believe it is just that ... a pig. Slow even when I tried it on my dedicated server... its very full featured, but it is hardly peppy, at the best of times... and, I'm not aware of many Drupal sites on the platform -- there are definitely better choices performance wise at the current juncture."
Can you comment on this, please? I am just going to setup some more Drupal site and got a bit frustrated.
- L
Tony Guntharp wrote:
Not wanting to say anything bad in regards to the admin staff at your web hosting company but I believe that they are wrong. Drupal out of the box is going to be slow. Just as 98% of all web applications will be until you take the time to configure them properly.
1) Turn on Drupal caching 2) Enable an Opcode Optimizer such as eAccelerator, XCache, APC 3) Enable Memcache (can be a bit tricky)
Thanks Tony, I saw there was a release of the Drupal Memcache Module 1.0 on 2007-06-27. Is it still tricky to use?
4) Tweak Apache to meet your needs. 5) Tweak MySQL to meet your needs.
Performancing of ANY web site/web application is an ongoing process and should always be revisited to ensure that you're getting the most out of your hardware.
-t
Tony Guntharp Co-Founder SourceForge.net
Thanks for that good initiative too :-)
fusion94@damagestudios.net 1-415-692-5507 1-415-680-5361
Lennart, The Memcache module isn't hard to use at all, the tricky bits are getting memcached installed. If you follow the README/INSTALL files it's pretty straight forward. I'm running an older version of it on a site which the administrative bits aren't working so I'm not sure if the latest has that enabled. -t Tony Guntharp Co-Founder SourceForge.net fusion94@damagestudios.net 1-415-692-5507 1-415-680-5361 On Jul 9, 2007, at 4:25 PM, Lennart Borgman (gmail) wrote:
Tony Guntharp wrote:
Not wanting to say anything bad in regards to the admin staff at your web hosting company but I believe that they are wrong. Drupal out of the box is going to be slow. Just as 98% of all web applications will be until you take the time to configure them properly. 1) Turn on Drupal caching 2) Enable an Opcode Optimizer such as eAccelerator, XCache, APC 3) Enable Memcache (can be a bit tricky)
Thanks Tony, I saw there was a release of the Drupal Memcache Module 1.0 on 2007-06-27. Is it still tricky to use?
4) Tweak Apache to meet your needs. 5) Tweak MySQL to meet your needs. Performancing of ANY web site/web application is an ongoing process and should always be revisited to ensure that you're getting the most out of your hardware. -t Tony Guntharp Co-Founder SourceForge.net
Thanks for that good initiative too :-)
fusion94@damagestudios.net 1-415-692-5507 1-415-680-5361
Remember also that this applies only to a host under your control, which means a VPS or dedicated host. You can't install memcached on a shared host. On 7/9/07, Tony Guntharp <fusion94@damagestudios.net> wrote:
Lennart, The Memcache module isn't hard to use at all, the tricky bits are getting memcached installed. If you follow the README/INSTALL files it's pretty straight forward. I'm running an older version of it on a site which the administrative bits aren't working so I'm not sure if the latest has that enabled.
-t
Tony Guntharp Co-Founder SourceForge.net fusion94@damagestudios.net 1-415-692-5507 1-415-680-5361
On Jul 9, 2007, at 4:25 PM, Lennart Borgman (gmail) wrote:
Tony Guntharp wrote:
Not wanting to say anything bad in regards to the admin staff at your web hosting company but I believe that they are wrong. Drupal out of the box is going to be slow. Just as 98% of all web applications will be until you take the time to configure them properly. 1) Turn on Drupal caching 2) Enable an Opcode Optimizer such as eAccelerator, XCache, APC 3) Enable Memcache (can be a bit tricky)
Thanks Tony, I saw there was a release of the Drupal Memcache Module 1.0 on 2007-06-27. Is it still tricky to use?
4) Tweak Apache to meet your needs. 5) Tweak MySQL to meet your needs. Performancing of ANY web site/web application is an ongoing process and should always be revisited to ensure that you're getting the most out of your hardware. -t Tony Guntharp Co-Founder SourceForge.net
Thanks for that good initiative too :-)
fusion94@damagestudios.net 1-415-692-5507 1-415-680-5361
-- 2bits.com http://2bits.com Drupal development, customization and consulting.
On 7/9/07, Tony Guntharp <fusion94@damagestudios.net> wrote: ...
1) Turn on Drupal caching 2) Enable an Opcode Optimizer such as eAccelerator, XCache, APC 3) Enable Memcache (can be a bit tricky) 4) Tweak Apache to meet your needs. 5) Tweak MySQL to meet your needs.
This is basically what we have done, with drupal 5 running on a single box. We aren't using memcache yet but we *are* using squid. Apache bench output using regular caching looks like this: jeffg@opus jeffg> ab -c 5 -n 1000 http://community.activestate.com/ ... Concurrency Level: 5 Time taken for tests: 10.116279 seconds Complete requests: 1000 Failed requests: 0 Write errors: 0 Total transferred: 9984144 bytes HTML transferred: 9260251 bytes Requests per second: 98.85 [#/sec] (mean) Time per request: 50.581 [ms] (mean) Time per request: 10.116 [ms] (mean, across all concurrent requests) Transfer rate: 963.79 [Kbytes/sec] received I would expect for this test that almost all of it was served out of the squid cache actually, but for performance for users that are *logged in* APC and MySLQ 5 query caching are the biggest bonuses, and these are something the host should *want* to do for all of their customers to reduce processing demands on their boxes. JeffG
On 7/9/07, Lennart Borgman (gmail) <lennart.borgman@gmail.com> wrote:
From the admin staff on a web host I am using I got a message saying:
"Personally I'll recommend Drupal when pigs can fly, because I believe it is just that ... a pig. Slow even when I tried it on my dedicated server... its very full featured, but it is hardly peppy, at the best of times... and, I'm not aware of many Drupal sites on the platform -- there are definitely better choices performance wise at the current juncture."
There are definitely many site on Drupal for sure. Whoever says that he is not aware of many sites on it does not know how popular Drupal has become. Drupal is resource intensive, Yes. It does lots of queries. Yes. However, slow it is not. There are many big sites running Drupal and they have low page generation times (I have seen page generation times as low as 16 milliseconds, average is 100-300 ms, with spikes to 600 ms). I personally know sites that do 930,000 page views a day, 59,000 per hour using the above averages. Even on a relatively inexpensive Xen VPS (forget Virtuozzo or OpenVZ, they are slow), performance is really snappy. Because Drupal uses a lot of queries, it will be slow on shared hosts that lump together lots of sites and their databases, or on sites that have no PHP accelerators. There are lots of resources on performance tuning and optimization for Drupal web sites. There is one forum on drupal.org, as well as a group on groups.drupal.org. 2bits.com has some articles on that as well. -- 2bits.com http://2bits.com Drupal development, customization and consulting.
Thanks to you all for your kind answers. The pointers you gave me are very useful for me. Khalid, I have some more q:s below. - L Khalid Baheyeldin wrote:
There are many big sites running Drupal and they have low page generation times (I have seen page generation times as low as 16 milliseconds, average is 100-300 ms, with spikes to 600 ms).
I personally know sites that do 930,000 page views a day, 59,000 per hour using the above averages.
Thanks for the figures. What kind of hosts is that? What kind of caching?
Even on a relatively inexpensive Xen VPS (forget Virtuozzo or OpenVZ, they are slow), performance is really snappy.
Because Drupal uses a lot of queries, it will be slow on shared hosts that lump together lots of sites and their databases, or on sites that have no PHP accelerators.
Thanks, I see. Is there anyting one can do to improve the situation when one has a Drupal site on a shared host (except turning on Drupal caching)?
There are lots of resources on performance tuning and optimization for Drupal web sites. There is one forum on drupal.org <http://drupal.org>, as well as a group on groups.drupal.org <http://groups.drupal.org>. 2bits.com <http://2bits.com> has some articles on that as well. -- 2bits.com <http://2bits.com> http://2bits.com Drupal development, customization and consulting.
Khalid Baheyeldin wrote:
There are many big sites running Drupal and they have low page generation times (I have seen page generation times as low as 16 milliseconds, average is 100-300 ms, with spikes to 600 ms).
I personally know sites that do 930,000 page views a day, 59,000 per hour using the above averages.
Thanks for the figures. What kind of hosts is that? What kind of caching?
In this case, it is a dual Opteron, 2GB dedicated, with no caching (yes, none!)
Even on a relatively inexpensive Xen VPS (forget Virtuozzo or OpenVZ,
they are slow), performance is really snappy.
Because Drupal uses a lot of queries, it will be slow on shared hosts that lump together lots of sites and their databases, or on sites that have no PHP accelerators.
Thanks, I see. Is there anyting one can do to improve the situation when one has a Drupal site on a shared host (except turning on Drupal caching)?
Find a better host is the short answer, specially if they have absurd caps on CPU seconds you can use, amount of memory per process or number of database queres. The long answer is to try to find what real bottlenecks your particular host has. Are they CPU starved? Are they database bound? Install the devel module to see how many queries you have per page. Try to cut down the number of modules you use. Read a bit on the tools and resources here http://2bits.com/articles/drupal-performance-tuning-and-optimization-for-lar... -- 2bits.com http://2bits.com Drupal development, customization and consulting.
On Monday 09 July 2007, Lennart Borgman (gmail) wrote:
Because Drupal uses a lot of queries, it will be slow on shared hosts that lump together lots of sites and their databases, or on sites that have no PHP accelerators.
Thanks, I see. Is there anyting one can do to improve the situation when one has a Drupal site on a shared host (except turning on Drupal caching)?
One of the things we're doing for Drupal 6 is to refactor how the code is organized to allow it to load a lot less code per page load. The early benchmarks showed a considerable benefit from that. I still need to go through and split up the rest of core, but I expect Drupal 6 will be a lot faster than Drupal 5 on non-opcode-cache sites. When in Drupal 5, as others have said be mindful of what you install. Many larger modules have separate "admin" and "normal" modules. Views is a natural example, where there are in fact 3 modules involved, only one of which is needed for Views to function. The other two are just for administrative functions, and will be very rarely needed once the site is launched. Turn those off, as well as any others that do a lot of database activity on every page (eg, statistics and tracker). -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
Can you comment on this, please? I am just going to setup some more Drupal site and got a bit frustrated.
From someone whose name and voice you won't hear much on this here list. Tell that so-called "admin" to go and take a looooong vacation and then come back, s/he apparently needs one, stress can cloud judgment.
From my personal experience, any framework/application is only as good as the intentions and abilities of the implementor. If your admin dismisses the viability of Drupal I have to question their abilities or intent for using it. In the past three years I have implemented, among other things:
* an infrastructure for users from fundamentalist/oppressive countries to communicate without fear of repercussion (Bloggers without Borders). BwoB is in active use inside some NGOs and would not have been possible with any other application or application framework in the extend and ease of implementation as it is with Drupal. * a complete solution, back- and frontend, for a commercial entity (Socialtext, www.socialtext.com). Implementation and responding to customer (in-house customers, you know, the ones whose reason is inverse proportional to your workload) demands was lightning fast while I supported this piece in-house. * Not one but three personal/small-community sites that are actually maintained by their owners these days. Try that with ANY other contender. "Hey, so I set this up, here's a URL to read up on maintenance, have a nice day". Works with Drupal. All in all, I'd hedge a bet, that this "admin" never REALLY looked at Drupal, never really set one site up, and never had to support anything else outside of his/her own limited area of knowledge. Tell them to either go and get a clue or contact me for some good old-fashioned lashing with the LART bat. jonas
* an infrastructure for users from fundamentalist/oppressive countries to communicate without fear of repercussion (Bloggers without Borders). BwoB is in active use inside some NGOs and would not have been possible with any other application or application framework in the extend and ease of implementation as it is with Drupal.
I should have mentioned that these are areas where "peppy" speed is more than paramount and hardware isn't available in masses and qualities we know in the US. Still, VERY peppy, still serving 90k users a day, holding up well during Katherina and the Tsunami in South-East Asia, even when Slashdotted, NPR-dotted, and CNN-dotted the same day.
Even on a relatively inexpensive Xen VPS (forget Virtuozzo or OpenVZ, they are slow), performance is really snappy.
I was actually disturbed when I saw this as my host is a VPS host that uses OpenVZ. So I did a little search and I'm not so sure this statement is accurate, not that I really care, but I'd rather be getting the best option for my money so I thought I'd point this benchmark out. http://community.livejournal.com/openvz/14024.html On 7/10/07, Jonas M Luster <jluster@jluster.org> wrote:
* an infrastructure for users from fundamentalist/oppressive countries to communicate without fear of repercussion (Bloggers without Borders). BwoB is in active use inside some NGOs and would not have been possible with any other application or application framework in the extend and ease of implementation as it is with Drupal.
I should have mentioned that these are areas where "peppy" speed is more than paramount and hardware isn't available in masses and qualities we know in the US. Still, VERY peppy, still serving 90k users a day, holding up well during Katherina and the Tsunami in South-East Asia, even when Slashdotted, NPR-dotted, and CNN-dotted the same day.
On 7/9/07, Ashraf Amayreh <mistknight@gmail.com> wrote:
Even on a relatively inexpensive Xen VPS (forget Virtuozzo or OpenVZ, they are slow), performance is really snappy.
I was actually disturbed when I saw this as my host is a VPS host that uses OpenVZ. So I did a little search and I'm not so sure this statement is accurate, not that I really care, but I'd rather be getting the best option for my money so I thought I'd point this benchmark out.
Here is the original article that I wrote (not a formal benchmark) http://2bits.com/articles/hosting-virtualization-openvz-vs-xen-which-is-best... Workhabit, who do a lot of hosting (Firebright), have the same observation on Xen vs Virtuozzo. http://www.workhabit.org/fifteen-tips-for-capacity-planning-and-initial-depl... On 7/10/07, Jonas M Luster < jluster@jluster.org> wrote:
* an infrastructure for users from fundamentalist/oppressive countries
to communicate without fear of repercussion (Bloggers without Borders). BwoB is in active use inside some NGOs and would not have been possible with any other application or application framework in the extend and ease of implementation as it is with Drupal.
I should have mentioned that these are areas where "peppy" speed is more than paramount and hardware isn't available in masses and qualities we know in the US. Still, VERY peppy, still serving 90k users a day, holding up well during Katherina and the Tsunami in South-East Asia, even when Slashdotted, NPR-dotted, and CNN-dotted the same day.
-- 2bits.com http://2bits.com Drupal development, customization and consulting.
On 10/07/07, Ashraf Amayreh <mistknight@gmail.com> wrote:
I was actually disturbed when I saw this as my host is a VPS host that uses OpenVZ. So I did a little search and I'm not so sure this statement is accurate, not that I really care, but I'd rather be getting the best option for my money so I thought I'd point this benchmark out.
One thing I noticed about that benchmark (I only had a quick glance) is that while OpenVZ seemed to handily beat Xen on the low level synthetic benchmarks, Xen seemed to equalise or even slightly beat OpenVZ on the higher level benchmark (siege). You really need to benchmark your actual applications (eg MySQL, Apache, PHP etc) to get worthwhile data. Also Khalid probably used a more recent version of Xen than the one in the OpenVZ benchmark. They used Xen 3.0.2 which was a pretty early immature version of Xen 3.x. Xen 3.1 is supposed to be faster than 3.0.x was. -- Cheers Anton
All I know is that XEN doesn't crash, where as OpenVZ did suffer from a lot of production stability problems. I've run Virtuozzo, OpenVZ, XEN, VMWare, LVS (which is good, and architectually sound). Of those, XEN has required the least fooling and breaks the least of all of them. Performance is secondary to the brittleness many virtualization technologies suffer from in regards to tuning various parameters - you want something that "just works," and if you can afford it, it's hard virtualization like XEN that delivers on that front. I ran large scale hosting for eZ Publish (yea yea) on Virtuozzo and it near about killed me. Had SW-Soft telling us we were, "The most technically demanding customers... [they had]," because we had all kinds of problems with resources that would cause catastrophic failures of systems - I hear its much better now. I think the benchmarks I've done closely match what was posted (on XEN 3.03) in so far as XEN really starts to shine when you have a higher load. We run a number of insanely high performance sites on XEN, including a couple of clusters that use XEN for frontend web servers serving (in a couple of cases) more than 1000 domains a cluster (some of which are very popular) on Drupal. And you know what the problem is with them? MySQL. Hehe, XEN works flawlessly. How did we get on this thread? ;-) My 2c. Jonathan Lambert WorkHabit On 7/9/07, Anton < anton.list@gmail.com> wrote:
On 10/07/07, Ashraf Amayreh < mistknight@gmail.com> wrote:
I was actually disturbed when I saw this as my host is a VPS host that uses OpenVZ. So I did a little search and I'm not so sure this statement is accurate, not that I really care, but I'd rather be getting the best option for my money so I thought I'd point this benchmark out.
One thing I noticed about that benchmark (I only had a quick glance) is that while OpenVZ seemed to handily beat Xen on the low level synthetic benchmarks, Xen seemed to equalise or even slightly beat OpenVZ on the higher level benchmark (siege). You really need to benchmark your actual applications (eg MySQL, Apache, PHP etc) to get worthwhile data.
Also Khalid probably used a more recent version of Xen than the one in the OpenVZ benchmark. They used Xen 3.0.2 which was a pretty early immature version of Xen 3.x. Xen 3.1 is supposed to be faster than 3.0.x was.
-- Cheers Anton
-- Jonathan Lambert Principal & CEO Email: j@firebright.com Work: 415-376-7274 WorkHabit / FireBright, Inc. http://www.workhabit.com/ http://www.workhabit.org/
Lennart Borgman (gmail) wrote:
From the admin staff on a web host I am using I got a message saying:
"Personally I'll recommend Drupal when pigs can fly, because I believe it is just that ... a pig. Slow even when I tried it on my dedicated server... its very full featured, but it is hardly peppy, at the best of times...
We've just launched a new Drupal site on our server and it didn't even register a blip on the server load. Page loading is reasonable, according to Firebug - less than a second, but the site is quite image-heavy. We've had it down to less than half a second on low-image pages, which is higher than Khalid's quoted 100-300ms, but then we've not done any optimization apart from turning non-aggressive cacheing on. If we had a large community site then we'd have to look into that.
and, I'm not aware of many Drupal sites on the platform --
Well, The Onion seems to do just fine. Maybe their readership has gone down. http://www.drupalsites.net/weblink/the-onion Every month there's a Drupal newsletter listing some new sites, which might provide good ammunition for situations just like this. (I'm damned if I can actually navigate to the correct forum unless there's a newsletter on the drupal.org front page, so someone else will need to find a link - apart from anything else I'd like to get our site mentioned in it!) There's also the aforementioned http://drupalsites.net/ , which at the current count is on over 1400 sites. One option for a hosting company is to run their own core Drupal system, with each customer being able to edit the contents of a subdirectory in the sites/ directory. That way they can keep control over much of the behaviour, keep it patched, remove CPU-hungry bits at their own discretion etc. I've not heard of anyone doing this yet, though. J-P
On 7/10/07, J-P Stacey <jp.stacey@torchbox.com> wrote:
We've just launched a new Drupal site on our server and it didn't even register a blip on the server load. Page loading is reasonable, according to Firebug - less than a second, but the site is quite image-heavy. We've had it down to less than half a second on low-image pages, which is higher than Khalid's quoted 100-300ms, but then we've not done any optimization apart from turning non-aggressive cacheing on. If we had a large community site then we'd have to look into that.
To clarify, my statement was on server side PHP page generation time, as measured by the devel module, not the browser full page loading time. They are very different things. For example, a single image node on a busy site with a few comments gives this when the devel module is enabled: Executed 168 queries in 201.84 milliseconds. Page execution time was 242.51ms. This means 41 ms for PHP, which is very good (powerful CPU, tuned system, accelator, ...etc.) The home page has 30 node teasers, and takes more to load: Executed 553 queries in 572.01 milliseconds. Page execution time was 771.64. More queries, and more PHP processing, but still good. The browser load time includes images, CSS, JS, and all the other baggage that are on the pages (e.g. loading ads from third party server, logging statistics (e.g. analytics). -- 2bits.com http://2bits.com Drupal development, customization and consulting.
J-P Stacey wrote:
One option for a hosting company is to run their own core Drupal system, with each customer being able to edit the contents of a subdirectory in the sites/ directory. That way they can keep control over much of the behaviour, keep it patched, remove CPU-hungry bits at their own discretion etc. I've not heard of anyone doing this yet, though.
Thanks J-P. I have always wondered why an installation like that is not the standard for shared web hosts. A problem is perhaps incompatibilities at when upgrading, but that could be solved by having the customer specific part pointing to a special location. When the web host upgrades Drupal (and other similar software) they could just do a fresh install in a new location. At the web host I am currently using they do not handle Drupal, WordPress etc that way (which surprised me a lot when I first saw it). Does Drupal have builtin support for this installation structure?
On 7/10/07, Lennart Borgman (gmail) <lennart.borgman@gmail.com> wrote:
J-P Stacey wrote:
One option for a hosting company is to run their own core Drupal system, with each customer being able to edit the contents of a subdirectory in the sites/ directory. That way they can keep control over much of the behaviour, keep it patched, remove CPU-hungry bits at their own discretion etc. I've not heard of anyone doing this yet, though.
Thanks J-P.
I have always wondered why an installation like that is not the standard for shared web hosts. A problem is perhaps incompatibilities at when upgrading, but that could be solved by having the customer specific part pointing to a special location. When the web host upgrades Drupal (and other similar software) they could just do a fresh install in a new location.
At the web host I am currently using they do not handle Drupal, WordPress etc that way (which surprised me a lot when I first saw it). Does Drupal have builtin support for this installation structure?
Specialized hosts (e.g. Bryght) does that already (have their own repository and sanctioned modules. However, most shared web hosts are small operations, or simply not into maintaining code of any kind. They are motel operators, not caterers, builders, or engineers. If they do this for Drupal, they have to do it for 100 other things their customers ask for. This is why there are things like Fantastico, which provides this feature for web hosts, and they subscribe to it and give it to their customers as a feature. So, don't expect any shared host to do this any time soon. -- 2bits.com http://2bits.com Drupal development, customization and consulting.
Any one else seeing this error on Drupal.org? Thanks Steve ERROR The requested URL could not be retrieved ---------------------------------------------------------------------------- ---- While trying to retrieve the URL: http://drupal.org/node/121662 The following error was encountered: a.. Zero Sized Reply Squid did not receive any data for this request. Your cache administrator is root@osuosl.org. ---------------------------------------------------------------------------- ---- Generated Tue, 10 Jul 2007 14:47:12 GMT by drupal2.drupal.org (squid/2.6.STABLE12)
This means that Apache has died (probably due to a PHP or APC problem), and what you are seeing is Squid's proxy cache saying that it got nothing from the other end (Apache that is). It happens occasionally. On 7/10/07, Steve Ringwood <nevets@mailbag.com> wrote:
Any one else seeing this error on Drupal.org?
Thanks Steve
ERROR The requested URL could not be retrieved ------------------------------
While trying to retrieve the URL: http://drupal.org/node/121662
The following error was encountered:
- *Zero Sized Reply *
Squid did not receive any data for this request.
Your cache administrator is root@osuosl.org. ------------------------------ Generated Tue, 10 Jul 2007 14:47:12 GMT by drupal2.drupal.org(squid/2.6.STABLE12)
-- 2bits.com http://2bits.com Drupal development, customization and consulting.
I've seen it before on a site I run w/ Squid. It usually means Drupal served a blank page which is usually caused by a PHP error. In practice, I have noticed that sometimes that PHP error has stemmed from a bad entry in Drupal's cache -- as deleting entries in the cache table fixed it, but this is mere speculation for this case. As such, the problem tends to go away when the cache automagically flushes. I have suspected also that it may be caused by duplicate insertions. ----- Original Message ----- From: "Steve Ringwood" <nevets@mailbag.com> To: development@drupal.org Sent: Tuesday, July 10, 2007 10:49:51 AM (GMT-0600) America/Chicago Subject: [development] Drupal.org problems Any one else seeing this error on Drupal.org? Thanks Steve ERROR The requested URL could not be retrieved While trying to retrieve the URL: http://drupal.org/node/121662 The following error was encountered: • Zero Sized Reply Squid did not receive any data for this request. Your cache administrator is root@osuosl.org . Generated Tue, 10 Jul 2007 14:47:12 GMT by drupal2.drupal.org (squid/2.6.STABLE12)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Tucker schrieb:
I've seen it before on a site I run w/ Squid. It usually means Drupal served a blank page which is usually caused by a PHP error.
In practice, I have noticed that sometimes that PHP error has stemmed from a bad entry in Drupal's cache -- as deleting entries in the cache table fixed it, but this is mere speculation for this case. As such, the problem tends to go away when the cache automagically flushes. I have suspected also that it may be caused by duplicate insertions.
On drupal.org this usually means that APC segfaulted. If anybody has insight as to why this might happen, we'd appreciate to hear your ideas on the infrastructure list. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGk9OFfg6TFvELooQRAhXVAJ9WR13JWgXWGVBa0DtHN5C8LxQ2rgCeP9GG 4bdOVxz8KvNCvL4kaYdbZ9Y= =4n4R -----END PGP SIGNATURE-----
Is there any reason why we're using APC and not eAccelerator or XCache? I've used all 3 in different production environment and APC has generally caused issues. -t Tony Guntharp Co-Founder SourceForge.net fusion94@damagestudios.net 1-415-692-5507 1-415-680-5361 On Jul 10, 2007, at 11:44 AM, Gerhard Killesreiter wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Eric Tucker schrieb:
I've seen it before on a site I run w/ Squid. It usually means Drupal served a blank page which is usually caused by a PHP error.
In practice, I have noticed that sometimes that PHP error has stemmed from a bad entry in Drupal's cache -- as deleting entries in the cache table fixed it, but this is mere speculation for this case. As such, the problem tends to go away when the cache automagically flushes. I have suspected also that it may be caused by duplicate insertions.
On drupal.org this usually means that APC segfaulted. If anybody has insight as to why this might happen, we'd appreciate to hear your ideas on the infrastructure list.
Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFGk9OFfg6TFvELooQRAhXVAJ9WR13JWgXWGVBa0DtHN5C8LxQ2rgCeP9GG 4bdOVxz8KvNCvL4kaYdbZ9Y= =4n4R -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tony Guntharp schrieb:
Is there any reason why we're using APC and not eAccelerator or XCache? I've used all 3 in different production environment and APC has generally caused issues.
When we initially set it up, eAccelerator seemed dead and XCache probably wasn't around yet. I'll raise the issue to try the others. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGk9hDfg6TFvELooQRAtuZAJ95bJvaaEAHICHLl6nJuiWvE9fM5ACgl9Mv 7vTExTC0DAyj2hbj/r4+ARw= =aidd -----END PGP SIGNATURE-----
Gerhard, I'll through up an instance of drupal 5.x on amazon ec2 with eAccelerator on it then hammer on it for a few days using siege if you're interested. -t Tony Guntharp Co-Founder SourceForge.net fusion94@damagestudios.net 1-415-692-5507 1-415-680-5361 On Jul 10, 2007, at 12:04 PM, Gerhard Killesreiter wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tony Guntharp schrieb:
Is there any reason why we're using APC and not eAccelerator or XCache? I've used all 3 in different production environment and APC has generally caused issues.
When we initially set it up, eAccelerator seemed dead and XCache probably wasn't around yet.
I'll raise the issue to try the others.
Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFGk9hDfg6TFvELooQRAtuZAJ95bJvaaEAHICHLl6nJuiWvE9fM5ACgl9Mv 7vTExTC0DAyj2hbj/r4+ARw= =aidd -----END PGP SIGNATURE-----
Tony Guntharp Co-Founder SourceForge.net fusion94@damagestudios.net 1-415-692-5507 1-415-680-5361
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tony Guntharp schrieb:
Gerhard, I'll through up an instance of drupal 5.x on amazon ec2 with eAccelerator on it then hammer on it for a few days using siege if you're interested.
Sure I am. Use wget -r with a registered user for some extra fun. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGk9yJfg6TFvELooQRAkETAKC5TTRcgHs0sNAnAuOWG3j+q7BGMgCeMVbA IVZyOjyQvhtKIcycTBL/pJc= =Z/Lk -----END PGP SIGNATURE-----
LOL, that could take _weeks_ on the actual d.o site. Gerhard Killesreiter wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tony Guntharp schrieb:
Gerhard, I'll through up an instance of drupal 5.x on amazon ec2 with eAccelerator on it then hammer on it for a few days using siege if you're interested.
Sure I am. Use wget -r with a registered user for some extra fun.
Cheers, Gerhard
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFGk9yJfg6TFvELooQRAkETAKC5TTRcgHs0sNAnAuOWG3j+q7BGMgCeMVbA IVZyOjyQvhtKIcycTBL/pJc= =Z/Lk -----END PGP SIGNATURE-----
-- Sean Robertson Web Developer NGP Software, Inc. seanr@ngpsoftware.com (202) 686-9330 http://www.ngpsoftware.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sean Robertson schrieb:
LOL, that could take _weeks_ on the actual d.o site.
Not really, it took about 15 minutes for a site with 1000 nodes. Anybody trying this on d.o will lose his account though. :p IIRC there is a SoC projecvt which could maybe deliver some benchmarking suite for such cases. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGk+QEfg6TFvELooQRAhp/AKDFWYlAxK0fJJbIlcrNPulBnFptOQCghpiN zCdE118E9B7HFBwZcvi21ao= =ZZQG -----END PGP SIGNATURE-----
On 7/10/07, Gerhard Killesreiter <gerhard@killesreiter.de> wrote:
Tony Guntharp schrieb:
Is there any reason why we're using APC and not eAccelerator or XCache? I've used all 3 in different production environment and APC has generally caused issues.
When we initially set it up, eAccelerator seemed dead and XCache probably wasn't around yet.
I'll raise the issue to try the others.
eAccelerator is not dead. I use it on several sites and it works well. Performance is 13% better than APC, and it saves far more memory per Apache process than APC as well. Still some segfaults in certain combinations. -- 2bits.com http://2bits.com Drupal development, customization and consulting.
On 7/10/07, Khalid Baheyeldin <kb@2bits.com> wrote:
On 7/10/07, Gerhard Killesreiter <gerhard@killesreiter.de> wrote:
Tony Guntharp schrieb:
Is there any reason why we're using APC and not eAccelerator or XCache? I've used all 3 in different production environment and APC has generally caused issues.
When we initially set it up, eAccelerator seemed dead and XCache probably wasn't around yet.
I'll raise the issue to try the others.
eAccelerator is not dead. I use it on several sites and it works well. Performance is 13% better than APC, and it saves far more memory per Apache process than APC as well.
Still some segfaults in certain combinations.
Depends on what you're using in your APC configuration, but generaly eAccelerator seems to perform a bit better than APC currently. In our experience APC has never crashed though ( php 5.1.6 FC6 ), and there are a number of things we can do to optimize it still, for example changing the locking strategy from file locks to spin locks like FaceBook does. JeffG
On Tue, 10 Jul 2007 21:04:35 +0200, Gerhard Killesreiter <gerhard@killesreiter.de> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tony Guntharp schrieb:
Is there any reason why we're using APC and not eAccelerator or XCache? I've used all 3 in different production environment and APC has generally caused issues.
When we initially set it up, eAccelerator seemed dead and XCache probably wasn't around yet.
I'll raise the issue to try the others.
FWIW, my one experience with XCache was it crashing mysteriously for 5 hours before the host we were dealing with turned it off and our Drupal site started miraculously working. We have another client that was running, I think, either eAccelerator or Zend's opcode cache and it's been running fine since last fall. I am but a single data point. --Larry Garfield
One option for a hosting company is to run their own core Drupal system, with each customer being able to edit the contents of a subdirectory in the sites/ directory. That way they can keep control over much of the behaviour, keep it patched, remove CPU-hungry bits at their own discretion etc. I've not heard of anyone doing this yet, though.
In fact this is the basic technology behind Bryght's open source hostmaster platform, and we've done this a lot for different customers. However, it's not a performance benefit, it's a maintainability benefit (in theory). You don't get less of a footprint in Apache because you share the underlying files. For shared hosts, there's no real benefit for them as they're not doing large enough scale systems to bother, plus most of them don't touch code (and wouldn't know Drupal from wordpress without grepping for it). Best, JL On 7/10/07, Khalid Baheyeldin <kb@2bits.com> wrote:
On 7/10/07, Lennart Borgman (gmail) <lennart.borgman@gmail.com> wrote:
J-P Stacey wrote:
One option for a hosting company is to run their own core Drupal system, with each customer being able to edit the contents of a subdirectory in the sites/ directory. That way they can keep control over much of the behaviour, keep it patched, remove CPU-hungry bits at their own discretion etc. I've not heard of anyone doing this yet, though.
Thanks J-P.
I have always wondered why an installation like that is not the standard
for shared web hosts. A problem is perhaps incompatibilities at when upgrading, but that could be solved by having the customer specific part pointing to a special location. When the web host upgrades Drupal (and other similar software) they could just do a fresh install in a new location.
At the web host I am currently using they do not handle Drupal, WordPress etc that way (which surprised me a lot when I first saw it). Does Drupal have builtin support for this installation structure?
Specialized hosts (e.g. Bryght) does that already (have their own repository and sanctioned modules.
However, most shared web hosts are small operations, or simply not into maintaining code of any kind. They are motel operators, not caterers, builders, or engineers. If they do this for Drupal, they have to do it for 100 other things their customers ask for.
This is why there are things like Fantastico, which provides this feature for web hosts, and they subscribe to it and give it to their customers as a feature.
So, don't expect any shared host to do this any time soon. -- 2bits.com http://2bits.com Drupal development, customization and consulting.
-- Jonathan Lambert Principal & CEO Email: j@workhabit.com Phone: 415-376-7274 WorkHabit, Inc. (Formerly FireBright, Inc.) http://www.workhabit.com/ http://www.workhabit.org/
participants (15)
-
Anton -
Ashraf Amayreh -
Eric Tucker -
Gerhard Killesreiter -
J-P Stacey -
Jeff Griffiths -
Jonas M Luster -
Jonathan Lambert -
Khalid Baheyeldin -
Larry Garfield -
Lennart Borgman (gmail) -
Ramiro Gómez -
Sean Robertson -
Steve Ringwood -
Tony Guntharp