Re: ftp vs. http servers [was Re: lug-bg: Slackware 9.1]
има си overhead, но при мен резултатите са следните: openssh 3.6.1 клиент и сървър (знам, знам че са стари - теста не е правен сега) при бавна връзка (модем) разликата в скоростта на обмен е под 3% (ако се обменят файлове с ниска ентропия, компресията помага драстично) при 100мб лан, сървър P-200 и клиент P2-400 - 890 килобайта в секунда, при това на сървъра load avg ~ 1.0, за файл с голяма ентропия. не съм пробвал да изключа компресията, а май би трябвало - сигурността се намалява съвсем маргинално, а zlib си яде цикли на общо основание интересното в случая е че ps / top не отчитат повече от 30% време за sshd, вероятно заради малките парчета време с които се обработва stream мисля, че ако имаме машина с повече mips (поради естеството на изчислителната работа май даже bogomips са добър критерий), тя ще пропуска пропорционално повече данни. On Tuesday 30 September 2003 17:55, Ognyan Kulev wrote: > Спомените ми са за клиент с Pentium 200 MHz, където всъщност скоростта > беше под 100K/s в локална мрежа, така че наистина там може да е дефектът > (в процесора). Ще гледам скоро да го пробвам с клиент Pentium 4 1.6 GHz > и ако все още го сметна за бавно, непременно ще се обадя ;-) > > === >= 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 > === >= ) 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
Re: ftp vs. http servers [was Re: lug-bg: Slackware 9.1]
Vesselin Kolev wrote: Също като rsync: и двете страни имат доста да изчисляват. А разликата между FTP (или HTTP) и SFTP в локална мрежа е голяма (поне два пъти, дори и ако двата компютъра са сравнително бързи). Ehe:) Chak 2 pyti.. silno kazano. Ponezhe naposledyk mi se nalozhi da pravia shema, pri koiato osven cryptiran kanal traibva da ima i TLS login, napravih i seria testove. Ako iskash moga da ti napravia i zhiva demonstracia. Спомените ми са за клиент с Pentium 200 MHz, където всъщност скоростта беше под 100K/s в локална мрежа, така че наистина там може да е дефектът (в процесора). Ще гледам скоро да го пробвам с клиент Pentium 4 1.6 GHz и ако все още го сметна за бавно, непременно ще се обадя ;-) 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
Re: ftp vs. http servers [was Re: lug-bg: Slackware 9.1]
Thttpd откакто го ползвам, поддържа http-ranges :) И не знам да има момент,в който не е поддържало :) На пн, 2003-09-29 в 15:51, Georgi Chorbadzhiyski записа: > Проблемът при thttpd и boa е че не поддържат http-ranges (резюме), което > за download на големи файлове ги прави абсолютно неподходящи. За много > на брой малки файлчета (картинки, етц) са убийци :) signature.asc Description: This is a digitally signed message part
Re: ftp vs. http servers [was Re: lug-bg: Slackware 9.1]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > > Също като rsync: и двете страни имат доста да изчисляват. А разликата > между FTP (или HTTP) и SFTP в локална мрежа е голяма (поне два пъти, > дори и ако двата компютъра са сравнително бързи). Ehe:) Chak 2 pyti.. silno kazano. Ponezhe naposledyk mi se nalozhi da pravia shema, pri koiato osven cryptiran kanal traibva da ima i TLS login, napravih i seria testove. Ako iskash moga da ti napravia i zhiva demonstracia. Ta shemata e slednata. ProFTPD v dva rezhima: TLS i non-TLS. TLS: Login s X.509 certificate - RSA 2048 bits TLS: handshake : Key Exchange-RSA-2048 (RSA key from cert.) TLS: handshake : Authentication-RSA-2048 (RSA key from cert.) TLS: handshake : Encryption-BlowFish-128 (random generated key) non-TLS : plain text login Celta beshe transfer na 120 faila, kato za vzemaneto na vseki fail se izpolzva login. T.e. login-transfer-logout Slediat se dva etapa: 1) Skorost na login processa 2) Skorost na obmena na failovete FTP Server: CPU : Athlon 900 MHz RAM: 512 DDR HDD: Seagate SATA/7200/8MB OS: Linux Mandrake 9.1 FTPD: ProFTPD 1.2.9rc2(TLS patched) Rezultati: 1) Po pokazatel skorost na login processa - kakto e za ochakvane pecheli plain text shemata, no samo s 13% pred TLS login (pri CPU s po-malka taktova chestota razlikata nelineiono narastva zaradi RSA). Nuzhno e da se znae, che sypostavkata ne e mnogo korektna, zashtoto kato cialo TLS login processa vkliuichva tri etapa: udostoveriavane, obmen na kliuch, i nachalo na kodiraneto. 2) Po pokazatel scorost na obmen na fail - razlikata e edna 5%. Vsasnost tia zavisi ot izpokzvania encryption algorithm. Beshe napraven opit i sys sftp server, vmesto s ProFTPD. Prezultatite v sravnenie s ProFTPD sa v ramkite na greshkata na izmervaneto... Pozdravi Beco -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE/eVmh+48lZPXaa+MRAoJyAKCVKdp9oVcqjPw07v/+78qMm61kJgCdG4KG x1U+eHx62CONMY1E7hLB1oE= =iVtz -END PGP SIGNATURE- 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
Re: ftp vs. http servers [was Re: lug-bg: Slackware 9.1]
On Monday 29 September 2003 21:53, Nickola Kolev wrote: > Здрасти, > > On Mon, 29 Sep 2003 20:45:44 +0300 > George Danchev <[EMAIL PROTECTED]> wrote: > > [ кръц ] > > : мда vsftpd носи много... някой нещо лошо да каже за sftp-server, освен, > : че не може standalone ? > > Дано тук да имаш предвид vsftpd-server, а не sftp-server! ;) А той може да > работи standalone. Може и още как, но не съм сигурен дали от версия 1.0.x, vsftpd вече го знаем, дори ако разровиш архива на групата преди година мисля, ще видиш, че съм питал за standalone mode на vsftpd, впоследствие разбрах, че от 1.0.1 май е имплементирано;-) ставаше въпрос за sftp-server-а (написан от Marcus Friedl) идващ от проекта openssh.org и викан от sshd. протокола е sftp:// , клиенти sfp, gftp и кой знае още колко има за виндовс. Той не може да клечи на фона standalone, което ще го бави при установяването на всяка нова сесия, а аутентикацията е ясна, всичко каквото може ssh. между другото и rsync аутентикацията и трансфера може да се прекара през ssh. > : между другото си мисля, че щом мерите производителността на демоните за > : големи и малки files, то няма как да не отчитате и върху какви > : filesystems се намират тези малки и/или големи files ... reiserfs бие > : при малките, xfs при големите files (дори и само за четене)... Освен > : това директориййната йерархия, т.е. дълбочината също има значение, > : по-плитко по-бързо. > > Моите наблюдения са предимно върху jfs на IBM - справя се доста добре както > с големи, така и с малки файлове. Освен това като хардуер е необходимо за > уточня, че става въпрос за IDE RAID ATA133 устройства, както и за > самостоятелни IDE дискове, вързани на ATA100 канали. Предполага се, че при > IO операции един съвременен SCSI контролер с подходящи дискове няма да > товари толкова системата. по-скоро исках да кажа, че ftp и web areas трябва да са поставени при равни условия когато се мерят разни демони: на еднакви fs, еднакви директроийни ейрархии и кой знае още какво може да окаже влияние. Хардуера е ясен щото се избира да е на една машина и е еднакъв за всички. Някои демони при разпалелеляването могат да се възползват много мощно от SMP, други не. -- pub 4096R/0E4BD0AB 2003-03-18 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
Re: ftp vs. http servers [was Re: lug-bg: Slackware 9.1]
George Danchev wrote: така, явно трябва да включиме и rsync в спора. Вярно ли е, че при много заявки хапва яко cpu time ... иначе е бърз и надежден като протокол и демон чувам. rsync разделя файловете на блокове от 32k. Изтеглянето на единичен файл се състои в изчисление на checksum на всеки от тези блокове: и на клиента, _и на сървъра_. Всичко това е за да може да се изтеглят само блоковете, които са променени. Както се досещаш, това товари немалко и двете страни, особено сървъра. мда vsftpd носи много... някой нещо лошо да каже за sftp-server, освен, че не може standalone ? Също като rsync: и двете страни имат доста да изчисляват. А разликата между FTP (или HTTP) и SFTP в локална мрежа е голяма (поне два пъти, дори и ако двата компютъра са сравнително бързи). HTTP е потенциално по-производителен от FTP (има малко повече парсване на HTTP хедърите, но няма отваряне на допълнителна data connection), но сървъри като Apache се правят да бъдат модулни и оптимизирани за неща като PHP и май не се обръща толкова внимание на големите файлове. 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
Re: ftp vs. http servers [was Re: lug-bg: Slackware 9.1]
Здрасти, On Mon, 29 Sep 2003 20:45:44 +0300 George Danchev <[EMAIL PROTECTED]> wrote: [ кръц ] : мда vsftpd носи много... някой нещо лошо да каже за sftp-server, освен, че не : може standalone ? Дано тук да имаш предвид vsftpd-server, а не sftp-server! ;) А той може да работи standalone. Може и още как, но не съм сигурен дали от версия 1.0.x, или от 1.1.3 (предпоследната стабилна). Откъм бързодействие се съмнявам да има друг ftp сървър, който да може да се мери с него. За справка - http://vsftpd.beasts.org/. Не споря, че му липсва богатството от интерфейси за аутентикиране на потребители на proftpd, pureftpd и т.н., но при добро желание винаги може да се мине през PAM (макар от това да се губи производителност). С две думи - за анонимен, или пък такъв с малко системни потребители ftp сървър, vsftpd e идеалното решение. Ей, това последното прозвуча почти като рекламно изречение! : : между другото си мисля, че щом мерите производителността на демоните за големи : и малки files, то няма как да не отчитате и върху какви filesystems се : намират тези малки и/или големи files ... reiserfs бие при малките, xfs при : големите files (дори и само за четене)... Освен това директориййната : йерархия, т.е. дълбочината също има значение, по-плитко по-бързо. Моите наблюдения са предимно върху jfs на IBM - справя се доста добре както с големи, така и с малки файлове. Освен това като хардуер е необходимо за уточня, че става въпрос за IDE RAID ATA133 устройства, както и за самостоятелни IDE дискове, вързани на ATA100 канали. Предполага се, че при IO операции един съвременен SCSI контролер с подходящи дискове няма да товари толкова системата. -- Със здраве, Никола _ "Engineering does not require science. Science helps a lot but people built perfectly good brick walls long before they knew why cement works." -Alan Cox pgp0.pgp Description: PGP signature
Re: ftp vs. http servers [was Re: lug-bg: Slackware 9.1]
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 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
Re: ftp vs. http servers [was Re: lug-bg: Slackware 9.1]
On 2003 Sep 29 Monday 15:51, Georgi Chorbadzhiyski wrote: > Васил Колев wrote: > > Ами... Честно казано, основно съм си играл с много заявки към малки > > файлове, но в който и да е случай, apache си е бавен на много паралелни > > заявки, може той да води хората до такъв извод... Има разбира се и > > другия момент - много хора ползват 'download manager'-и, който правят по > > 10 връзки за един файл (нещо, което за FTP не се прави, странно защо), и > > така товарят много повече, въпреки че като гледам , при тебе не е такъв > > случая:) > > > > Питах те в първия момент, защото поне по мои наблюдения HTTP е много > > по-лек протокол от FTP (не се отварят допълнителни връзки, една > > заявка,един отговор и т.н.), и ми се вижда странно да е по-бавен. Като > > намеря време, ще потърся HTTP сървър, който да може да работи спокойно с > > големи файлове (щях да препоръчам thttpd, но то има голям проблем на > > 32битови машини, защото използва mmap, и не му стига адресното > > пространство),и ще пробвам... Моите наблюдения м/у другото показват, че > > при 3000 паралелни заявки, и при около 600-700 заявки в секунда, > > машината стои с load 1 , ако е с thttpd (около 40mbps),и ще ми е > > интересно да направя такъв тест, само че с големи файлове, и много > > паралелни заявки. > > Проблемът при thttpd и boa е че не поддържат http-ranges (резюме), което > за download на големи файлове ги прави абсолютно неподходящи. За много > на брой малки файлчета (картинки, етц) са убийци :) http://www.boa.org/news.html --- 24 November 2002 - Version 0.94.14rc7 released! The gzip tarball (160,521 bytes) is here and the detached signature for the tarball is here. The bzip2 tarball (135,601 bytes) is here and the detached signature for the tarball is here. This is 0.94.14rc7 - several 'range'-related bug fixes, including an inadvertant memory overwrite resulting in eventual corruption -- introduced in rc4 or rc5. Please give this a thorough testing, as this includes "range" (resume) support. boa-ta ot 2002 pone poddyrja ;) ---^^^ mislq che i w tux imashe support, ama ne dawam i 10% garanciq, tux syshto taka ima ftp poddryjka, ne samo http... -- Regards, Doncho N. Gunchev 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
Re: ftp vs. http servers [was Re: lug-bg: Slackware 9.1]
Ами... Честно казано, основно съм си играл с много заявки към малки файлове, но в който и да е случай, apache си е бавен на много паралелни заявки, може той да води хората до такъв извод... Има разбира се и другия момент - много хора ползват 'download manager'-и, който правят по 10 връзки за един файл (нещо, което за FTP не се прави, странно защо), и така товарят много повече, въпреки че като гледам , при тебе не е такъв случая:) Питах те в първия момент, защото поне по мои наблюдения HTTP е много по-лек протокол от FTP (не се отварят допълнителни връзки, една заявка,един отговор и т.н.), и ми се вижда странно да е по-бавен. Като намеря време, ще потърся HTTP сървър, който да може да работи спокойно с големи файлове (щях да препоръчам thttpd, но то има голям проблем на 32битови машини, защото използва mmap, и не му стига адресното пространство),и ще пробвам... Моите наблюдения м/у другото показват, че при 3000 паралелни заявки, и при около 600-700 заявки в секунда, машината стои с load 1 , ако е с thttpd (около 40mbps),и ще ми е интересно да направя такъв тест, само че с големи файлове, и много паралелни заявки. На нд, 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 да издържи толкова, и да не убие > машината, на която работи. Нямам и намерение обаче да правя изпитания, за да се > опровергавам. :) > > Разбира се, не изключвам това прекалено натоварване да се е дължало на нещо > друго, но съм останал с впечатлението, че ftp сървърите, и по-специално vsftpd > се отнасят доста по-милостиво към системните ресурси, отколкото apache. > > В никакъв случай не изключвам възможността да греша. signature.asc Description: This is a digitally signed message part
Re: ftp vs. http servers [was Re: lug-bg: Slackware 9.1]
Васил Колев wrote: Ами... Честно казано, основно съм си играл с много заявки към малки файлове, но в който и да е случай, apache си е бавен на много паралелни заявки, може той да води хората до такъв извод... Има разбира се и другия момент - много хора ползват 'download manager'-и, който правят по 10 връзки за един файл (нещо, което за FTP не се прави, странно защо), и така товарят много повече, въпреки че като гледам , при тебе не е такъв случая:) Питах те в първия момент, защото поне по мои наблюдения HTTP е много по-лек протокол от FTP (не се отварят допълнителни връзки, една заявка,един отговор и т.н.), и ми се вижда странно да е по-бавен. Като намеря време, ще потърся HTTP сървър, който да може да работи спокойно с големи файлове (щях да препоръчам thttpd, но то има голям проблем на 32битови машини, защото използва mmap, и не му стига адресното пространство),и ще пробвам... Моите наблюдения м/у другото показват, че при 3000 паралелни заявки, и при около 600-700 заявки в секунда, машината стои с load 1 , ако е с thttpd (около 40mbps),и ще ми е интересно да направя такъв тест, само че с големи файлове, и много паралелни заявки. Проблемът при thttpd и boa е че не поддържат http-ranges (резюме), което за download на големи файлове ги прави абсолютно неподходящи. За много на брой малки файлчета (картинки, етц) са убийци :) -- Georgi Chorbadzhiyski http://georgi.unixsol.org/ 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
Re: ftp vs. http servers [was Re: lug-bg: Slackware 9.1]
Здрасти, Смятам така, понеже съм сравнявал системното натоварване, което оказва един 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 да издържи толкова, и да не убие машината, на която работи. Нямам и намерение обаче да правя изпитания, за да се опровергавам. :) Разбира се, не изключвам това прекалено натоварване да се е дължало на нещо друго, но съм останал с впечатлението, че ftp сървърите, и по-специално vsftpd се отнасят доста по-милостиво към системните ресурси, отколкото apache. В никакъв случай не изключвам възможността да греша. On Sun, 28 Sep 2003 19:48:44 +0300 Васил Колев <[EMAIL PROTECTED]> wrote: : Zashto smqtash taka? Az pone sum ostanal s dosta po-razlichni : vpechatleniq, a i kato cqlo HTTP protokola e po-lek ot FTP, i tvoeto : izqvlenie mi se vizhda stranno :) : : (izvinqvam se, che ne pisha na kirilica, imam nqkakuv dreben problem na : notebook-a, i oshte ne sum nameril vreme da go opravq) : : На нд, 2003-09-28 в 15:50, Nickola Kolev записа: : > Здрасти, : > Не е задължително да е по-бързо. По-важното е, че като цяло ftp сървърите : > товарят значително по-малко, отколкото http при трансфер на сериозни количества : > данни, каквито са ISO-файловете. -- Със здраве, Никола _ "Engineering does not require science. Science helps a lot but people built perfectly good brick walls long before they knew why cement works." -Alan Cox pgp0.pgp Description: PGP signature
Re: ftp vs. http servers [was Re: lug-bg: Slackware 9.1]
Zashto smqtash taka? Az pone sum ostanal s dosta po-razlichni vpechatleniq, a i kato cqlo HTTP protokola e po-lek ot FTP, i tvoeto izqvlenie mi se vizhda stranno :) (izvinqvam se, che ne pisha na kirilica, imam nqkakuv dreben problem na notebook-a, i oshte ne sum nameril vreme da go opravq) На нд, 2003-09-28 в 15:50, Nickola Kolev записа: > Здрасти, > Не е задължително да е по-бързо. По-важното е, че като цяло ftp сървърите > товарят значително по-малко, отколкото http при трансфер на сериозни количества > данни, каквито са ISO-файловете. signature.asc Description: This is a digitally signed message part
