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. <br>
<br><br><br><div class="gmail_quote">On Thu, May 14, 2009 at 6:51 PM, Daniel Carrera <span dir="ltr"><<a href="mailto:daniel.carrera@theingots.org">daniel.carrera@theingots.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi all,<br>
<br>
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.<br>
<br>
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).<br>
<br>
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?<br>
<br>
Also, I have no idea if 1000 HTTP connections is a reasonable configuration or not.<div class="im"><br>
<br>
Thanks.<br>
Daniel.<br>
<br>
<br>
Jamie Holly wrote:<br>
</div><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.<br>
<br>
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.<br>
</blockquote>
<br></div><div><div></div><div class="h5">
--<br>
[ Drupal support list | <a href="http://lists.drupal.org/" target="_blank">http://lists.drupal.org/</a> ]<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>-- <br>--<br>Steve Power<br>Principal Consultant<br>Mobile: +44 (0) 7747 027 243<br>Initsix Technology and Media<br>--<br>