Re: [apache-talk] Sending poor GIF from buffer :0)

["Khimenko Victor" <khim@xxxxxxxxxxxx>]

In <Pine.LNX.4.10L0.9909221955150.315-100000@xxxxxxxxxxxxxx> Victor Wagner (vitus@xxxxxx) wrote:
VW> On Wed, 22 Sep 1999, Eugene B. Berdnikov wrote:

>>  Чем плохи threads, что при их появлении надо "двигаться прочь" от Апача?

VW> Тем же, чем объектно-ориентированное программирование на C++. Чайники
VW> думают, что
VW> это круто, а на самом деле написать хорошую программу с их использованием
VW> много сложнее (в смысле надо быть куда менее чайником) чем без них.
VW> В случае thread сюда накладывается еще и неодинаковость их реализации на
VW> разных системах.

Что должно обрабатываться соответсвующей compatibility libraries. И вовсе они
не так сильно отличаются (хотя в FreeBSD и нет MT-safe poll'а, из-за чего
возникает куча проблем)...

VW> В общем, threads под unix - признак воинствующего чайника, почему и надо
VW> от них бежать,

Не вижу логики. Это достаточно острый инструмент и пользоваться ими нужно с
осторожностью, но все зависит от решаемых задач. Есть много заблуждений такого
рода (например: "работа по прерываниям быстрее, чем polling" -- хотя временами
бывает и не так; тот же CISCO только за счет polling'а справляется со своим
довольно хилым процессором обслуживанием T3)...

VW> Кстати вот в Oracle, программистов которого чайниками ну никак не
VW> назовешь,

У них местами очень соебразное представление о жизни :-/

VW> включение  multithreaded режима под Solaris x86 посадило
VW> производительность связки apache+mod_perl+Oracle чуть ли не на два порядка
VW> (во всяком случае на малом числе конкурентных запросов. Что было бы на
VW> большом, мы бы просто не дождались, поскольку вместо десятых долей
VW> секунды страницы стали генериться десятки секунд)

Ну мало ли что вы там изменили. Очень может быть, что теперь все это засело в
каком-нибудь блокировке...

VW> Вот уверен, что попытка замены fork на thread в апаче приведет к
VW> аналогичным результатам.

Посмотрим. Пока что это на всех тестах показывает ускорение (как и должно).

>>  Зачем "бежать" от khttpd, если его просто нет в конфиге стабильного ядра?

VW> Затем, что тоже кажется проявлением воинствующего чайника. Хотя я
VW> тут  совершенно не уверен. Я, пожалуй, когда этот khttpd в конфиг
VW> стабильного ядра попадет (и если попадет) его включу и пусть гифы отдает
VW> избавляя от этой тупой работы мой не в меру умный apache с mod_perl.

Он достаточно маленький и простой, но так как это же можно сделать в userspace
без потери эффективности, то я не очень понимаю -- зачем он там нужен.

>>  И зачем нужен этот "сброс буфера контроллера" для web-сервера?

VW> Для web-сервера - не знаю. Но знаю, что у меня на рабочей станции
VW> сканнер в состоянии подвесить Linux нафиг. Именно из-за глюка в
VW> scsi-подсистеме, причем, возможно, именно этого.

Какое ядро ? 2.3.18ac8 ? Там Кокс как раз в районе SCSI недавно шашкой махал...
Хотя полное переписывание отложено до 2.5 :-/

>>  Ну никак не пойму, зачем нужны FreeBSD, сказьки и nothreads-серверы. :)

VW> FreeBSD нужна потому что у нее IP-стэк круче.

Это вы Alexey Kuznetsov <kuznet@xxxxxxxxxxxxx> скажите :-) А если серъезно, то
на сегодняшний день Linux является ЕДИНСТВЕННОЙ OS, которая корректно реализует
TCP/IP. Подробности -- у Кокса и Кузнецова... Я за их руганью следил со
стороны...

VW> скази нужна потому, что при обмене с диском процессор грузится
VW> много меньше, и можно жить в условиях активного свопинга. А еще потому,
VW> что на нее можно от 7 до 15 устройств повесить, а не 2 как на IDE.
VW> А еще потому, что на ней можно устройства на ходу включать/выключать.


VW> nothreads серверы (в смысле форкающиеся) нужны потому, что они получаются
VW> куда проще (читай быстрее) и безопаснее чем threaded.

Это не совсем так. Простота отнюдь не означает большей скорости и вообще для
Apache скорость отдачи static content'а никогда не была целью (зачем??? любой
мало-мальски приличный сервер засирает любой самый толстый канал и без лишних
ухищрений!)... BTW в Apache 2.0 планирется гибридная модель (если ее до ума
доведут)...