> Было такое, что я задавал вопрос — почему патч не принят, мэйнтейнер пересматривал
> его и говорил: «да вроде всё в порядке, пришил его ещё раз». Получается, нужно
> переспрашивать про каждый патч, даже откровенно «проходной»? Некоторые патчи стоят
> людям личного времени, порой ночного времени (как у автора), долгого копания в чужом
> коде, длительного тестирования, и прочая и прочая, а его порой отшивают вообще на
> ровном месте, порой даже не заглядывая внутрь.
Я думаю, у такого положения дел есть и плюс. Это естественный отбор. Выживают только самые приспособленные и необходимые патчи, а также — самые настойчивые и увлеченные авторы. Иногда лучше 10 «звезд», чем 1000 «середнячков», потому что 10 энтузиастов могут изобрести что-то принципиально новое, а 1000 «середнячков» — вряд ли. Зато «трудяги» забьют собой эфир и заставят потратить на себя ресурсы. ИМХО.
Конечно, есть огромный минус — то, что действительно талантливые люди (как автор статьи, например) могут в некоторых случаях не пробиться и разочароваться. Судебные ошибки, так сказать. Но что тут поделать…
> Результаты собеседований меня неизменно расстраивают. Подавляющее большинство кандидатов ужасны.
Можно перед приглашением на собеседование запросить примеры кода у человека, а возможно, и попросить решить заочно небольшую практическую задачку. На среднемировое качество кандидатов это, конечно, не повлияет, но снизит их количество раз в 5-10, а следовательно — будет и расстраивать меньше.
Ух! Спасибо за ссылку. Если оно не слишком сырое, то, конечно, вариант с nginx близок к идеальному.
P.S.
Вот ради таких комментариев и стоит публиковать велосипеды и выкладывать для них подробную документацию.
Средствами AJAX этого не добиться: когда ответ уходит клиенту, клиент уже не имеет возможности сказать серверу, принял он его или нет. Но вообще, конечно, никто не мешает сделать отдельный AJAX-запрос на сервер, в котором сообщить, что данные приняты, и снова их пересылать не нужно.
TCP-соединение характеризуется парой (ip1:port1) < — (ip2:port2). В нашем случае (ip1:port1) = (1.2.3.4:8088). Соответственно, если ip2 зафиксирован, то port2 может меняться только в диапазоне 0..65535 (на самом деле меньше, ну да не важно). Поэтому на 1 слушающий сокет не может быть больше 65536 коннектов (на самом деле немного меньше). Это так?
Если да, то увеличить число коннектов можно, добавив вариабельности либо в ip1, либо в port1.
Он ищет самое первое упоминание строчки identifier=*. Поэтому, если в IN-линию вы будете посылать ответы с заголовком, включающим identifier (а именно так и приходится делать), то никаких проблем нет, и данные могут быть любыми.
Что касается статистики, то ее можно смотреть в лог-файле сейчас. Если сделать tail -n1 /var/log/multiplexor, то вы как раз и получите такую статистику.
Сервер может выдержать почти неограниченное число соединений (я проверял на 300 тыс. год назад). На каждой паре слушающий_IP: слушающий_порт может быть не более 65536 соединений (по числу портов; на самом деле, меньше, т.к. часть портов уже используется), но никто же не запрещает добавить 10 ip-адресов или 10 слушающих портов (кстати, насчет увеличения числа слушающий_порт не уверен; поправьте меня, если я ошибся). Кроме того, есть еще ulimit -n (лимит на число открытых файлов в системе), у меня не получилось выставить его больше 1 млн для одного процесса. Ну и есть еще разные лимиты внутри системы, которые можно подкручивать (обычно лимиты OpenVZ: TCPSNDBUF какой-нибудь и т.д.) Нужно заметить, что, если какой-то из лимитов оказываются превышенными, мультиплексор не всегда адекватно об этом сообщает, так что, если у вас это произошло (проводите нагрузочное тестирование вначале!), проверьте первым делом лимиты.
На самом деле, там не только разрыв соединения нужно обрабатывать, но и ошибки в передаче данных (мало ли, дисконнект приключится внезапный в середине ответа), а также «лежание» сервера, чтобы он не долбился бесконечно при смерти сервера.
Ну, это некоторый компромисс между красотой и независимостью от протокола.
Зато протокол может быть совершенно любым: при желании можно прикрутить мультиплексор к SMTP или POP, к примеру. :-)
Ну я бы не сказал, что совет прямо «плохой». Он ИМХО просто неправильный. Ну как число процессов связано с загруженностью дисков? По-первых, есть sendfile, который специально сделан, чтобы по минимуму грузить процессор и память. Во-вторых, даже с sendfile=off (и при условии, что nginx читает данные с диска синхронно, в чем я не уверен) получается очень странная картина. Вот представьте: пришло 2 запроса в 2 разных процесса, и оба процесса пошли читать данные с диска (долго — диск перегружен). При этом приходят еще 10 запросов, но они не могут начать обрабатываться, т.к. оба процесса уже «заняты». Среди этих 10 запросов, может, 9 попадают в кэш и мгновенно отдадут контент. Ан нет, их заблокировали.
> Если ожидается высокая нагрузка на жёсткий диск, можно сделать по процессу на
> каждый физический жёсткий диск, поскольку вся работа будет всё-равно ограничена
> его производительностью
Эм… кхм…
воздержусь все же, пожалуй. :-)
> ну что это за $client->__call('method', array('var1', 'var2')); вместо $client->method('var1', 'var2')
Действительно, что это за ужас?
В PHP-версии SoapClient (и, следовательно, в Dklab_SoapClient) всегда пишется вторая версия, а первая не нужна. WSDL тут ни при чем.
Смысл — дать возможность профессионального общения со своим 1-м кругом. Общение — это не только статус «кручу гайку», это еще и возможность задать вопрос или запросить рекомендацию.
> его и говорил: «да вроде всё в порядке, пришил его ещё раз». Получается, нужно
> переспрашивать про каждый патч, даже откровенно «проходной»? Некоторые патчи стоят
> людям личного времени, порой ночного времени (как у автора), долгого копания в чужом
> коде, длительного тестирования, и прочая и прочая, а его порой отшивают вообще на
> ровном месте, порой даже не заглядывая внутрь.
Я думаю, у такого положения дел есть и плюс. Это естественный отбор. Выживают только самые приспособленные и необходимые патчи, а также — самые настойчивые и увлеченные авторы. Иногда лучше 10 «звезд», чем 1000 «середнячков», потому что 10 энтузиастов могут изобрести что-то принципиально новое, а 1000 «середнячков» — вряд ли. Зато «трудяги» забьют собой эфир и заставят потратить на себя ресурсы. ИМХО.
Конечно, есть огромный минус — то, что действительно талантливые люди (как автор статьи, например) могут в некоторых случаях не пробиться и разочароваться. Судебные ошибки, так сказать. Но что тут поделать…
Можно перед приглашением на собеседование запросить примеры кода у человека, а возможно, и попросить решить заочно небольшую практическую задачку. На среднемировое качество кандидатов это, конечно, не повлияет, но снизит их количество раз в 5-10, а следовательно — будет и расстраивать меньше.
P.S.
Вот ради таких комментариев и стоит публиковать велосипеды и выкладывать для них подробную документацию.
опечатка, я имел в виду
> если ip1:port1 зафиксирован, то port2 может меняться
Но вообще, кажется, я написал бред. :-)
Если да, то увеличить число коннектов можно, добавив вариабельности либо в ip1, либо в port1.
Что касается статистики, то ее можно смотреть в лог-файле сейчас. Если сделать tail -n1 /var/log/multiplexor, то вы как раз и получите такую статистику.
На самом деле, там не только разрыв соединения нужно обрабатывать, но и ошибки в передаче данных (мало ли, дисконнект приключится внезапный в середине ответа), а также «лежание» сервера, чтобы он не долбился бесконечно при смерти сервера.
Зато протокол может быть совершенно любым: при желании можно прикрутить мультиплексор к SMTP или POP, к примеру. :-)
> каждый физический жёсткий диск, поскольку вся работа будет всё-равно ограничена
> его производительностью
Эм… кхм…
воздержусь все же, пожалуй. :-)
Действительно, что это за ужас?
В PHP-версии SoapClient (и, следовательно, в Dklab_SoapClient) всегда пишется вторая версия, а первая не нужна. WSDL тут ни при чем.