Web torture results

Ahmed Kamal email.ahmedkamal at googlemail.com
Sun Dec 24 22:55:19 UTC 2006


Under full load (~200 concurrent connections), this was the status

Proxy2 machine
===========
1- RAM 100% used, machine not swapping though (Linux ram utilization is a
bit complex though)
2- Squid was saturating the CPU (80~90%)
3- Lots and lots of httpd processess, each taking 0% cpu, and minimal ram
~0.7%
4- load average: 1.06, 0.94, 0.75. top is showing squid cpu utilization >
85%, while total cpu utilization = 7%!! This seems to be a bug?! So, I cant
trust the load numbers either

App1 server
=========
1- RAM 100% used, 0.5GB swapping
2- CPU saturated by large number of httpd processes
3- load average: 150.35, 143.94, 104.04. Cacti showing load peaking to 400,
while top doesnt go that high!
https://admin.fedoraproject.org/cacti/graph.php?action=zoom&local_graph_id=68&rra_id=0&view_type=tree&graph_start=1166864400&graph_end=1166878800

Best Regards


On 12/24/06, Mike McGrath <mmcgrath at fedoraproject.org> wrote:
>
> On 12/23/06, Paulo Santos <paulo.banon at googlemail.com> wrote:
> > > 3- Serving html is really the bottleneck. Unfortunately, Moin
> developers
> > acknowledged current version ( 1.5) is not cache friendly. Work for
> making
>
> It sounds like we really won't get much of a benefit till 1.6.  Our
> biggest issue last time appeard to be the dynamic generation of
> content, converting them to static content helped cpu load on fpserv
> quite a bit.
>
> How did the appserver handle the stress test?  How about the proxy
> server?  Not just in code generation and such but actual cpuload, that
> type of thing?
>
>              -Mike
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20061225/b75a3dab/attachment.html 


More information about the infrastructure mailing list