Re: ftp vs. http servers [was Re: lug-bg: Slackware 9.1]

[George Danchev <danchev@xxxxxxxxx>]

On Monday 29 September 2003 15:42, Васил Колев wrote:
> Ами... Честно казано, основно съм си играл с много заявки към малки
> файлове, но в който и да е случай, apache си е бавен на много паралелни
> заявки, може той да води хората до такъв извод... Има разбира се и
> другия момент - много хора ползват 'download manager'-и, който правят по
> 10 връзки за един файл (нещо, което за FTP не се прави, странно защо), и
> така товарят много повече, въпреки че като гледам , при тебе не е такъв
> случая:)

за кой апах иде реч тука: apache 1.3.x или някой от build вариантите  на 2.x: 
2.x prefork (тоя е ясен като 1.x) или worker или perchild или threadpool, щото 
последните два трябва да са по-бързи и то доста що се касае до парелелни 
процеси, незнам доколко са thread/smp safe и доколко са stable вече е друга 
тема ;-) 

> Питах те в първия момент, защото поне по мои наблюдения HTTP  е много
> по-лек протокол от FTP (не се отварят допълнителни връзки, една
> заявка,един отговор и т.н.), и ми се вижда странно да е по-бавен. Като
> намеря време, ще потърся HTTP сървър, който да може да работи спокойно с
> големи файлове (щях да препоръчам thttpd, но то има голям проблем на
> 32битови машини, защото използва mmap, и не му стига адресното
> пространство),и ще пробвам... Моите наблюдения м/у другото показват, че
> при 3000 паралелни заявки, и при около 600-700 заявки в секунда,
> машината стои с load 1 , ако е с thttpd (около 40mbps),и ще ми е
> интересно да направя такъв тест, само че с големи файлове, и много
> паралелни заявки.

така, явно трябва да включиме и rsync в спора. Вярно ли е, че при много заявки 
хапва яко cpu time ... иначе е бърз и надежден като протокол и демон чувам. 

> На нд, 2003-09-28 в 20:31, Nickola Kolev записа:
> > Здрасти,
> >
> > Смятам така, понеже съм сравнявал системното натоварване, което оказва
> > един http сървър (apache) и един ftp сървър (proftpd). Става въпрос за
> > машина с приблизително 1000 едновременни http връзки (или конекции, ако
> > така предпочитате), и в същото време тя е почти неизползваема. Бях
> > направил всички възможни настройки, за които се сетих и които намерих из
> > нета, но load average беше почти винаги над 2.00. След като смених всички
> > URL-та да сочат към ftp сървър на същата машина, системното натоварване
> > падна на около 0.5, и дори още повече, когато подмених proftpd с vsftpd.
> > Тук става въпрос за теглене на големи файлове, с обем почти същия като на
> > едно ISO, и постоянен трафик вариращ между 30 и 60Мбит/с. Това са данни
> > от преди около половин година. В момента при пиков брой на ftp връзките
> > около 2500 и трафик към 100Мбита, системното натоварване стои малко над
> > 1.00. Съмнявам се един apache да издържи толкова, и да не убие машината,
> > на която работи. Нямам и намерение обаче да правя изпитания, за да се
> > опровергавам. :)

е apache 1.3.x май е най-тежък от всички ftp daemons за които мога да се сетя.
това с умирането на машината на какъв kernel се случва. щото колкото и да е 
нахален апаха за ресурси не мисля, че OOM killer-а ще му прости ... най-много 
да запълни process table-a с нови и нови форкове, ама и това не ми се вярва 
да мине лесно, щото kernel-a си пази запас (както и от ram) за да може да 
реагира активно на такива волни или неволни атаки... остава да хаби cpu 
time ... но това не убива машината. Това горното се отнася за ядра които не 
рестриктират заемането на ресурсите за даден интерал от време. 
Някой да има опит с /etc/security/limits.conf и на кои kernel versions точно. 
Щото това е по-въпроса ограничаването на ползването на ресурси ... за grsec 
вече знаем, че може да стегнеш потребителите така, че да не могат да 
работят...  

> > Разбира се, не изключвам това прекалено натоварване да се е дължало на
> > нещо друго, но съм останал с впечатлението, че ftp сървърите, и
> > по-специално vsftpd се отнасят доста по-милостиво към системните ресурси,
> > отколкото apache.

мда vsftpd носи много... някой нещо лошо да каже за sftp-server, освен, че не 
може standalone ? 

между другото си мисля, че щом мерите производителността на демоните за големи 
и малки files, то няма как да не отчитате и върху какви filesystems се 
намират тези малки и/или големи files ...  reiserfs бие при малките, xfs при 
големите files (дори и само за четене)... Освен това директориййната 
йерархия, т.е. дълбочината също има значение, по-плитко по-бързо. 

-- 
pub  4096R/0E4BD0AB 2003-03-18 <keyserver.bu.edu>
1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 
                      
   

============================================================================
A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers).
http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora
To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html
============================================================================