[support] CPU usage

[Steve Power]

If you're servicing all the schools in kent, then maybe the figures are
real.  But tbh, you're barking up the wrong tree.  Dont take this the wrong
way, but you need to run this like a popular e-commerce site, not a hobby
site.  If you have thousands of users then shared hosting is no longer
appropriate and just wont scale as their business model relies on lots of
inactive websites.  Even if you could move hosts,  its not really going help
however you configure Drupal as the problem seems to be at an edge traffic
shaping device. Thats only my opinion tho.



On Thu, May 14, 2009 at 6:51 PM, Daniel Carrera <
daniel.carrera at theingots.org> wrote:

> Hi all,
>
> I have new information. At the time the school was blocked, this IP was
> taking up 500 HTTP connections and the server is configured to support 1000.
> So this one IP was taking up half of the HTTP connections.
>
> 500 connections seems absurd, and so I'm convinced that there's something
> wrong at the school. The best hypothesis so far is the pre-scanning thing
> (thanks Jamie).
>
> That said, I would like to better understand what "500 HTTP connections"
> means. If you get a single web page that has one HTML file, two images and
> two CSS files, is that one HTTP connection or five? In other words, does
> "500 HTTP connections" equate to 500 users or 100?
>
> Also, I have no idea if 1000 HTTP connections is a reasonable configuration
> or not.
>
> Thanks.
> Daniel.
>
>
> Jamie Holly wrote:
>
>> I know Websense does pretty much the same thing as Blue Coat in "pre
>> scanning" sites. The best solution is to use css compression/aggregation (in
>> D5+) and javascript compression/aggregation (D6) to reduce requests. Those
>> are some of the files these services latch onto, and when they read the
>> entire site they won't cache the files, but rather reread them on every page
>> request.This will help keep the cpu usage down since Apache won't have to
>> keep spawning connections for the files.
>>
>> Also any kind of caching you can get in there. There are some scenarios
>> and modules it won't work with. For example - if your Drupal install is in a
>> subfolder of the web root. One way to fix that is to put Drupal on its own
>> subdomain.  Also trying op-code level caching like APC is a big plus
>> (generally a 20%+ increase). Another option is using something like
>> cacherouter with memcache and then enabling the page caching through that.
>> With apc+cache router+memcache, I can pump out over 200 requests per second
>> on an old dual-core AMD server and my load never goes above 60 using D6.
>>
>
> --
> [ Drupal support list | http://lists.drupal.org/ ]
>



-- 
-- 
--
Steve Power
Principal Consultant
Mobile: +44 (0) 7747 027 243
Initsix Technology and Media
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/support/attachments/20090514/a67e2de3/attachment.htm>