performance

In my never-ending quest to run larger and more complex drupal stacks for more and more users, I'm starting to hit the wall in what I'm able to accomplish with good old Siege, which has been my command-line tool of choice for benchmarking and performance testing for the past couple years. In particular, it breaks down too often in high-load simulations, and doesn't allow for any complex multi-threaded testing, making it very difficult to model near-reality user scenarios like "10 logged in users + 100 anons".

Lately, I've been getting into Jmeter, which has a lot more bells and whistles -- including a GUI! -- and which I think can offer a lot to Drupal developers. However, their basic web test plan barely scratches the surface of what's possible. With the right configuration, jmeter can effectively simulate complete user-behavior patterns like logging in, posting comments, etc.

I'm just getting started, but am curious if people "out there" are already way ahead of me, or if not if folks are interested in seeing the results of my testing work?

I suspect that the tables in the Nodequeue module can be optimized, but I'm not sure how to start. Nodequeue allows people to create arbitrarily ordered lists of nodes, and consists of queues and subqueues. A subqueue is a distinct list of nodes that inherits properties from its parent queue. Nodequeue's Smartqueue API allows modules to define new types of subqueues, such as a subqueue per-user or for each taxonomy term of one or more vocabularies. Below is the desc output of nodequeue's tables.

Hi folks. I'm looking for some feedback and advise on a odd performance issue.

We have a Drupal 6 multisite that we've developed that currently houses 7 sites. The sites themselves are, as Drupal sites go, not particularly exciting or complex. It even has fewer modules than most sites we build. (All of the sites use the same modules and configuration.)

On our development server, performance is fine.

On the client's test server, performance is fine.

I am currently trying to convince the bigwigs at my company that Drupal is the way to go to provide us with a CMS solution for our clients' sites. We set up new sites for clients all the time and manage and host them. Right now we are running on IIS utilizing a CMS written in classic ASP that cost the company some umpteen gaziliions of dollars to make.

I have created a low memory version of system.module for Drupal 6.10 which can be found here. I found it gave a modest performance improvement with low load performance testing on my development machine. Where it shines is under high load relative to tight memory conditions.

With ab -c 100 -n 1000 http://example.com/user on a real site, applying this patch gave somewhere between 18 and 40% reduction in average time per request.

I'm new to the High Performance group and I'm interested to find out if people here have run a site with the following stats:

• 4,000 simultaneous visitors, up to 500 who are logged in at once
• approaching 2 million comments
• 200,000 forum posts
• 30,000 registered users

While investigating a large descrepancy between query time ( 243 queries taking roughly 37 milliseconds) and total page execution time ~390 millisecond, I looked at various filters I have installed. I noticed video filter module added a significant overhead and by disabling it was abale to reduce the page execution time to ~212 milliseconds. I also opened an issue for the module here http://drupal.org/node/375415 and you can see more details about my test.

I already use APC.

Are there other filters or modules that you aware could add significant overhead to page execution time?

As most of us on this group are aware, drupal_lookup_path queries DB multiple times and several patches have been tried to fix this. None of it is in core yet. This discussion http://drupal.org/node/106559 has several patches and related links.

I tried to tackle this in a different way with an alias table with 50 records. I changed the engine for url_alias table from MyIsam to MEMORY. My reasoning was making it memory resident will give me almost the same (but not exact) benefit of memory resident array or variable the previous folks have tried. And it won't require any patches etc.

Hi All,

I have been using Drupal for quite some time and recently we went live. The performance scalability has been some issue of late. I have been looking into monitoring my MySQL parameters for quite sometime. Currently I'm using mysql tuner perl script to monitor what variables need change.

Some observations that need help:

I managed to get Drupal 6.9 running on my site (hooray) and am now looking at constructing a theme.

The basic design spec for the theme calls for 21 cells of identical height and width, floating in three equally-spaced columns having a total width of 800 pixels.

Drupal gives me the choice of defining the basic layout with either a cascading style sheet (CSS) or an HTML table.

My big question relates to the performance of a template using an HTML Table vs. a CSS:

(1) Will Drupal serve a page faster with a layout having a CSS design, or with an HTML Table design?