Про массу ресурсов — нет ли у Вас цифр? Я, например, так и не смог выделить это поедание на фоне издержек от TCP-соединений и загрузки PHP-кода (в случае использования SOAP в PHP, естественно)… у меня есть подозрение, что экономия на парсинге XML здесь — это экономия на спичках. А уж если сравнивать SOAP с Apache Thrift (опять же, нативную реализацию SoapClient в PHP с реализацией Thrift на том же самом PHP), то SOAP оказывается почему-то удобнее и быстрее с первого взгляда.
Немного информации по SOAP в PHP, которая может пригодиться.
1. В PHP встроенный SoapClient и SoapServer (стандартные нативные расширения).
2. SoapClient (да и SoapServer тоже) совершенно не обязательно использовать в связке с WSDL. Можно просто объявить класс, объявить в нем методы с нужными параметрами (и возвращаемым значением произвольной структуры — хоть массива массивов массивов) и передать его в SoapServer. Точно так же, достаточно передать в SoapClient URL сервера без всякого WSDL и успешно вызвать все эти методы. Проще не придумаешь.
3. В Zend Studio for Eclipse 6.1 существует генератор WSDL-файла на основе PHP-файлов с кодом и phpdoc-комментариев (в 7.x этого средства почему-то уже нет). Работает просто великолепно! Просто пишем код, объявляем параметры функции через @param type $name и получаем готовый WSDL public-свойств класса. Причем в качестве type можно указывать как простые string, boolean и т.д., так и сложные MyClass и даже массивы объектв — MyClass[], где MyClass — это мой собственный класс (в этом случае определение этого класса попадет в WSDL-файл тоже). Я, например, никогда не рискую писать WSDL руками (именно потому, что он сложен, а утилиты — типа XMLSpy — очень кривые и сложные), но сгенерировать-то актуальную версию по классам не проблема… files.zend.com/help/Zend-Studio/generate_wsdl_files.htm и forums.zend.com/viewtopic.php?f=50&t=385 и www.zend.com/en/forums/index.php?t=msg&goto=19350&S=0c850207a026dd45faff3713958e15bf
4. SOAP в PHP — это единственный производительный (!) способ сериализовать и передать на удаленную сторону некоторую сложную структуру, состоящую из объектов, массивов, списков и т.д. так, чтобы гарантировать: там она распакуется в неизменном виде. XMLRPC-модуль в PHP на это не способен. А serialize() сериализует все подряд, включая приватные свойства, что может быть крайне неудобным. Из-за этой причины я, кстати, и выбрал протокол SOAP для своей RPC-библиотеки параллельных вызовов dklab.ru/lib/Dklab_SoapClient/ (правда, кажется, там с параллельностью что-то иногда подглючивает в самой последней версии PHP — в libcurl что-то изменили).
5. SOAP прозрачно работает с куками и сессиями. Можно, например, сделать пару вызовов $soapClient->login('user', 'pass'); $soapClient->getFriends(), и при этом на стороне сервера getFriends() будет знать о том, что до этого выполнился login() (за счет сессий или кук).
В общем, не знаю, как в других языках, а в PHP с SOAP очень комфортно работать. Даже Zend-овский генератор WSDL мне понравился больше, чем генераторы WSDL в Java (я попробовал несколько штук).
Ну почему сразу «некрасивейшим»… MySQL потребляет в основном диск, а Apache — CPU. Так что они не так уж и часто прересекаются по ресурсам… разве что по памяти, это да (но это лечится наращиванием памяти).
Погуглил немного по разным reverse-proxy. Похоже, ни один из них не умеет ставить запросы в очередь по превышению числа использования backend-ов. (Включая nginx, lighttpd, perlbal, даже squid, pound, LiteSpeed; и потом я смотрел, нет ли чего-то готового на twisted.)
Хабросообщество! Если ты знаешь инструмент, который позволяет ставить запросы браузеров в очередь, когда достигнут лимит на определенное число коннектов к backend-ам для одного виртуального хоста, напиши пожалуйста, сюда, что это за инструмент.
И отдельный вопрос, который хотелось бы обсудить. Если я правильно понял, то главный смысл в том, чтобы ограничить число процессов-воркеров для одного клиента. Иными словами, ограничить число одновременных коннектов к каждому сайту, чтобы запросы, для которых «не хватило воркера», вставали в очередь.
1. Не могли бы Вы чуть подробнее расписать, почему решение этой проблемы на уровне reverse proxy Вас не устраивает в теоретическом смысле? (Про то, что в nginx нет требуемой функциональности, и про то, что limit_conn не годится, я понимаю.)
2. Пробовали ли Вы на каждом из dedicated-апачей запускать peruser-, itk- или dklab-патчи, дабы сравнить, делает ли погоду нагрузка от лишнего fork() или нет? У меня есть некоторые подозрение, что fork() здесь как раз погоды не должен делать. (Вывод «Мы выиграли процессорное время за счёт отказа от постоянных vfork()» меня не совсем убедил, т.к. процессор мог выиграться не из-за отказа от fork(), а из-за того, что Вы ограничили число воркеров на особо «жрущего» клиента; раньше процессор «жрался» 20 воркерами такого клиента, а теперь их у него только 3, вот и выигрыш.)
А вообще, я бы с удовольствием с Вами как-нибудь выпил кофе, было бы интересно пообщаться.
Филипп, не могли бы Вы ответить на вопросы:
1. Сколько в среднем клиентов (т.е. dedicated-апачей) у Вас на одной машине?
2. Каковы примерно характеристики машины (память, проц)?
Если я не ошибаюсь, для PHP пока нет полноценного (= безглючного и удобного в использовании) дебаггера с поддержкой трассировки. Примерно раз в полгода я проверяю dbg и xdebug (в связке с Eclipse) и в очередной раз убеждаюсь, что с ними все по-прежнему достаточно плохо.
Думаю, именно поэтому люди в основной массе и предпочитают вместо отладчика применять print_r. Барьер входа в последний намного ниже и, действительно, чаще всего удается отловить ошибки минимальной кровью. (А если использовать концепции Test Driven Development или хотя бы просто писать тесты через несколько минут, а не дней, после написания кода, необходимость в отладке резко уменьшается.)
Если кто-то таки поставил на поток использование полноценного отладчика в PHP (пусть даже платного), напишите, пожалуйста. Будет очень интересно.
И я надеюсь, что в Python дела обстоят менее плачевно в этом отношении (но почему-то подозреваю, что там примерно то же самое происходит, или нет?).
Настораживает, что в Джанге вот уже больше года нет поддержки репликации и шардинга, а в документации и туториалах эти вещи старательно обходятся стороной. Впрочем, в PHP-мире ситуация не лучше: все сидят на своих собственных велосипедах с квадратными колесами и не спешат делиться наработками (хотя в некоторых ORM для PHP и есть поддержка репликации, но она там «номинальная»; видно, что авторы никогда не задумывались, например, о запаздывании реплик и других эффектах).
P.P.S.
На самом деле деление на междусобойчики можно продолжать даже в «php-python-ruby-linux». Например, PHP почти не пересекается с Ruby по приверженцам. Специалисты чаще всего бывают узкие, охватывающие в основном только один язык (или семейство). Для меня, например, такое семейство — старая школа, PHP+Perl. Я совершенно не представляю, чем живут Python-программисты, к примеру.
Знаете, а ведь как это ни странно, я по некоторым пунктам поддержу Андрея. Несмотря на то, что я заядлый PHP-шник и перлист, и программирую в основном для Unix.
Действительно ведь, «php-python-ruby-linux» — отдельный междусобойчик, а продукты MS — отдельный. И они почти не пересекаются, так что тем, кто слева, трудно понять тех, кто справа (и наоборот). Какой из этих междусобойчиков лучше, сказать сложно, т.к. специалистов и в том, и в другом почти нет (я не видел). Мне лично хочется верить, что лучше первый, однако я в последние годы (как представитель первого междусобойчика) все больше ощущаю незримое присутствие второго… причем ощущение такое, что это «второе» ничуть не меньше и даже иногда не хуже «первого».
Возможно, это все из-за того, что я принципиально работаю с Windows на ноутбуке и иногда пишу для Windows довольно низкоуровневые вещи, а не ставлю Linux и не перехожу на Мак. ИМХО это единственный способ быть в курсе того, что происходит в мире MS (глупо было бы на него сейчас глаза закрывать).
P.S.
Кстати, есть еще Java-мир, это вообще третий «междусобойчик». Но только ИМХО (судя по документации к разным Java-продуктам) для Java несколько более приоритетна Windows, чем Linux, так что лично для себя я воспринимаю Java как «недоДотНет» (возможно, ошибочно).
> главный программист оценил задачу в 3 часа работы. Разработчик справился за 5, но
> написал подробно, на что он потратил еще 2 часа. Главный программист прочитал и
> сказал: «Да, я это не учел, сорри». Проблемы нет. Если же аргументация у разработчика
> неубедительная — какое-то время к результатам его работы более пристальное внимание.
М-да… эта методика на корню убивает творческое начало и мотивацию. Задачу должен оценивать тот, кто ее будет делать, а не дядька свыше.
Можно проще сделать. Для каждого юзера завести флаг: тролль он или нет. А в скриптах при выборке постов и топиков добавить дополнительный фильтр:
1) если текущий юзер — тролль, показывать все записи и ничего не фильтровать;
2) если юзер — не тролль, то выводить только топики и посты от не-троллей.
Модератор может незаметно взвести этот флаг любому пользователю. Таким образом, в 99% случаев тролль и не поймет, что его посты не видны, и в скором времени сам отвалится, т.к. решит, что его все игнорируют. Также тролли смогут общаться с другими троллями.
Если здесь есть железячники, объясните, пожалуйста, каким образом в первом ролике PC Speaker умудряется играть 2 ноты одновременно? Ведь программируемый контроллер таймера (3-й канал которого — dklab.ru/doc/timer.html#cont1 — по умолчанию подсоединен к PC Speaker) — довольно простая штука, он может выдавать только прямоугольные импульсы, а чтобы выдать комбинацию из 2 нот, нужны более сложные (два наложенных друг на друга прямоугольника). Или он что, играет самостоятельно ноты, без таймера?
По поводу домена rutwit.ru с буквой «w». Предыдущие комментарии прекрасно иллюстрируют полезность Хабра. Мы действительно недооценили важность приобретения домена rutwit.ru, хотя и вели вялые переговоры о его покупке. К счастью, после данных комментариев на Хабре мы и предыдущие владельцы домена быстро пришли к разумному соглашению.
В дополнение к благодарности хабрапользователям я хотел бы публично поблагодарить Гранта Меграбяна и Георгия Калашникова за то, что они решили помочь нашему проекту и передали домен за приемлемую для всех цену. Грант и Георгий — талантливые разработчики, очень позитивные и увлеченные делом ребята. Я получил истинное удовольствие от общения с ними, пока мы вместе проходили все «круги ада», связанные с передачей домена от одного регистратора к другому. Спасибо вам!
1. В PHP встроенный SoapClient и SoapServer (стандартные нативные расширения).
2. SoapClient (да и SoapServer тоже) совершенно не обязательно использовать в связке с WSDL. Можно просто объявить класс, объявить в нем методы с нужными параметрами (и возвращаемым значением произвольной структуры — хоть массива массивов массивов) и передать его в SoapServer. Точно так же, достаточно передать в SoapClient URL сервера без всякого WSDL и успешно вызвать все эти методы. Проще не придумаешь.
3. В Zend Studio for Eclipse 6.1 существует генератор WSDL-файла на основе PHP-файлов с кодом и phpdoc-комментариев (в 7.x этого средства почему-то уже нет). Работает просто великолепно! Просто пишем код, объявляем параметры функции через @param type $name и получаем готовый WSDL public-свойств класса. Причем в качестве type можно указывать как простые string, boolean и т.д., так и сложные MyClass и даже массивы объектв — MyClass[], где MyClass — это мой собственный класс (в этом случае определение этого класса попадет в WSDL-файл тоже). Я, например, никогда не рискую писать WSDL руками (именно потому, что он сложен, а утилиты — типа XMLSpy — очень кривые и сложные), но сгенерировать-то актуальную версию по классам не проблема… files.zend.com/help/Zend-Studio/generate_wsdl_files.htm и forums.zend.com/viewtopic.php?f=50&t=385 и www.zend.com/en/forums/index.php?t=msg&goto=19350&S=0c850207a026dd45faff3713958e15bf
4. SOAP в PHP — это единственный производительный (!) способ сериализовать и передать на удаленную сторону некоторую сложную структуру, состоящую из объектов, массивов, списков и т.д. так, чтобы гарантировать: там она распакуется в неизменном виде. XMLRPC-модуль в PHP на это не способен. А serialize() сериализует все подряд, включая приватные свойства, что может быть крайне неудобным. Из-за этой причины я, кстати, и выбрал протокол SOAP для своей RPC-библиотеки параллельных вызовов dklab.ru/lib/Dklab_SoapClient/ (правда, кажется, там с параллельностью что-то иногда подглючивает в самой последней версии PHP — в libcurl что-то изменили).
5. SOAP прозрачно работает с куками и сессиями. Можно, например, сделать пару вызовов $soapClient->login('user', 'pass'); $soapClient->getFriends(), и при этом на стороне сервера getFriends() будет знать о том, что до этого выполнился login() (за счет сессий или кук).
В общем, не знаю, как в других языках, а в PHP с SOAP очень комфортно работать. Даже Zend-овский генератор WSDL мне понравился больше, чем генераторы WSDL в Java (я попробовал несколько штук).
Хабросообщество! Если ты знаешь инструмент, который позволяет ставить запросы браузеров в очередь, когда достигнут лимит на определенное число коннектов к backend-ам для одного виртуального хоста, напиши пожалуйста, сюда, что это за инструмент.
1. Не могли бы Вы чуть подробнее расписать, почему решение этой проблемы на уровне reverse proxy Вас не устраивает в теоретическом смысле? (Про то, что в nginx нет требуемой функциональности, и про то, что limit_conn не годится, я понимаю.)
2. Пробовали ли Вы на каждом из dedicated-апачей запускать peruser-, itk- или dklab-патчи, дабы сравнить, делает ли погоду нагрузка от лишнего fork() или нет? У меня есть некоторые подозрение, что fork() здесь как раз погоды не должен делать. (Вывод «Мы выиграли процессорное время за счёт отказа от постоянных vfork()» меня не совсем убедил, т.к. процессор мог выиграться не из-за отказа от fork(), а из-за того, что Вы ограничили число воркеров на особо «жрущего» клиента; раньше процессор «жрался» 20 воркерами такого клиента, а теперь их у него только 3, вот и выигрыш.)
А вообще, я бы с удовольствием с Вами как-нибудь выпил кофе, было бы интересно пообщаться.
1. Сколько в среднем клиентов (т.е. dedicated-апачей) у Вас на одной машине?
2. Каковы примерно характеристики машины (память, проц)?
Думаю, именно поэтому люди в основной массе и предпочитают вместо отладчика применять print_r. Барьер входа в последний намного ниже и, действительно, чаще всего удается отловить ошибки минимальной кровью. (А если использовать концепции Test Driven Development или хотя бы просто писать тесты через несколько минут, а не дней, после написания кода, необходимость в отладке резко уменьшается.)
Если кто-то таки поставил на поток использование полноценного отладчика в PHP (пусть даже платного), напишите, пожалуйста. Будет очень интересно.
И я надеюсь, что в Python дела обстоят менее плачевно в этом отношении (но почему-то подозреваю, что там примерно то же самое происходит, или нет?).
имелось в виду «т.к. специалистов ОДНОВРЕМЕННО и в том, и в другом почти нет»
На самом деле деление на междусобойчики можно продолжать даже в «php-python-ruby-linux». Например, PHP почти не пересекается с Ruby по приверженцам. Специалисты чаще всего бывают узкие, охватывающие в основном только один язык (или семейство). Для меня, например, такое семейство — старая школа, PHP+Perl. Я совершенно не представляю, чем живут Python-программисты, к примеру.
Действительно ведь, «php-python-ruby-linux» — отдельный междусобойчик, а продукты MS — отдельный. И они почти не пересекаются, так что тем, кто слева, трудно понять тех, кто справа (и наоборот). Какой из этих междусобойчиков лучше, сказать сложно, т.к. специалистов и в том, и в другом почти нет (я не видел). Мне лично хочется верить, что лучше первый, однако я в последние годы (как представитель первого междусобойчика) все больше ощущаю незримое присутствие второго… причем ощущение такое, что это «второе» ничуть не меньше и даже иногда не хуже «первого».
Возможно, это все из-за того, что я принципиально работаю с Windows на ноутбуке и иногда пишу для Windows довольно низкоуровневые вещи, а не ставлю Linux и не перехожу на Мак. ИМХО это единственный способ быть в курсе того, что происходит в мире MS (глупо было бы на него сейчас глаза закрывать).
P.S.
Кстати, есть еще Java-мир, это вообще третий «междусобойчик». Но только ИМХО (судя по документации к разным Java-продуктам) для Java несколько более приоритетна Windows, чем Linux, так что лично для себя я воспринимаю Java как «недоДотНет» (возможно, ошибочно).
> написал подробно, на что он потратил еще 2 часа. Главный программист прочитал и
> сказал: «Да, я это не учел, сорри». Проблемы нет. Если же аргументация у разработчика
> неубедительная — какое-то время к результатам его работы более пристальное внимание.
М-да… эта методика на корню убивает творческое начало и мотивацию. Задачу должен оценивать тот, кто ее будет делать, а не дядька свыше.
1) если текущий юзер — тролль, показывать все записи и ничего не фильтровать;
2) если юзер — не тролль, то выводить только топики и посты от не-троллей.
Модератор может незаметно взвести этот флаг любому пользователю. Таким образом, в 99% случаев тролль и не поймет, что его посты не видны, и в скором времени сам отвалится, т.к. решит, что его все игнорируют. Также тролли смогут общаться с другими троллями.
В дополнение к благодарности хабрапользователям я хотел бы публично поблагодарить Гранта Меграбяна и Георгия Калашникова за то, что они решили помочь нашему проекту и передали домен за приемлемую для всех цену. Грант и Георгий — талантливые разработчики, очень позитивные и увлеченные делом ребята. Я получил истинное удовольствие от общения с ними, пока мы вместе проходили все «круги ада», связанные с передачей домена от одного регистратора к другому. Спасибо вам!