Re: Tux serving graphics only

The separate graphics server is something we are looking at.  There are 
tons of static images, and I already had him add support to have all 
the images drawn from an images.domain.com subdomain... We have just 
not tried it yet, and have been looking for the best solution (thttpd, 
etc) that would take up the smallest footprint in memory.

Yes, I find it odd that Mandrake includes the userspace utilities but 
not the kernel patch for tux. ;)

But, with a bug randomly shutting down the server everyweek or so, it 
would be impossible to consider tux then... We have excellent uptime as 
it is, with no crashes of any kind except when he used all available 
space in /home ;)  That horked the machine pretty well...

According to Hans Reiser, if a partition starts to become over ~95%  
full, there can be problems with most of the filesystems (ext2/3, 
reiser, ntfs, etc)... Large slowdowns and high load...  they have 
worked on that problem for ResierFS, and XFS is supposed to handle it 
well too.. but most others, especially journaling ones, get very upset. 
<--- Neat info, even if off topic.


On Tuesday, August 26, 2003, at 10:10  AM, Marco Rothley wrote:

> Hello!
>
> Am Montag, 25. August 2003 21:48 schrieb Adam Goldstein:
>> Does anyone here have experience getting tux to work on a recent
>> Mandrake installation?
>>
>> Such as Mandrake 9.0, 9.1 or 9.2?
>>
>> Last time I tried, it would not recompile the kernel with tux
>> enabled... though, I am unsure if the mdk kernels have included or
>> discarded the tux code in the past couple revisions.
> As far as I know there isn't any TUX support in recent Mandrake 
> kernels. Best
> solution is to take a vanilla kernel and patch it. I took the patches 
> from
> Andrea 
> (ftp://ftp.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/)
> the last time I compiled the kernel on myself but I don't know when 
> there
> will be a patch for the 2.4.22 kernel. Another special thing with 
> Mandrake
> kernels is the supermount (http://supermount-ng.sourceforge.net/) 
> patch, if
> you want that feature. I haven't tried to patch the kernel with both 
> patches
> yet.
> There have also been some bugfix patches here on the list. What is the 
> status
> with them?
> There is a Mandrake rpm for the userspace TUX utilities but I would 
> prefer to
> compile the again.
>
>
>> One of my customers is running a very high volume website, 
>> 65-75million
>> hits/month  (~10million page views)  with heavy images and php mysql
>> calls.
>>
>> The server is a dual athlon 2000+ w/3.5G ram, U160 73G raid for main
>> pages&images and 36G 15K U160 for mysql. The server is steadily 
>> slowing
>> down under the user load and main partition becoming full of images
>> (1-300MB/day incoming, only small% being removed...).  Apache2.0.44,
>> php4.2.3, mysql4.0.13, Mandrake 9.0
>>
>> Would tux help in this situation, or just suck more precious resources
>> for a small% gain considering that 95% of the pages are dynamic mysql?
>
> That is hard to say. Sure, you will have a better performance with 
> TUX. But
> you might have problems with logfiles (if you need them). You will 
> have two
> different logfiles and - even worth - there is still a bug in TUX that 
> causes
> the whole machine to hang about once a week (on some installations). 
> As far
> as I know there isn't any patch to solve this problem, yet, and nobody 
> knows
> where the bug is.
> It's hard to say if the small performance gain and some saved 
> resources like
> memory are worth the risk if really 95% of all requests are dynamic 
> (don't
> you have some small static gifs in your dynamic generated pages? You 
> have
> really that many dynamic requests?)
>
> A different thing I'm considering is to have an apache without 
> keep-alive and
> lingerd to block the apache children only for a very short time and 
> use a
> small (fnord, thttpd, ...) http-server for the static files without 
> TUX. Is
> there anyone who has experience with such a setup?
>
>> We are actively trying to move to a multi-server setup, but that will
>> take some time to implement.
> That's always a good investment...
>
>
>
> Marco Rothley
>
> Tel.: +49 (0)6145 5466-50
> Fax: +49 (0)6145 5466-34
>
> dress-for-less GmbH
> Hafenstr. 11
> 65439 Floersheim/Main
>
> Germany
>
>
> _______________________________________________
> tux-list mailing list
> [email protected]
> https://www.redhat.com/mailman/listinfo/tux-list
>
-- 
Adam Goldstein
White Wolf Networks
http://whitewlf.net