Зато в nginx их куда проще писать, имхо. Если, конечно научиться их готовить ;)
На нагруженных проектах включать AllowOverride лично я не рекомендую, иначе при каждом обращении к файлу, апач на пути к нему будет проверять наличие .htaccess, его синтаксис, что делать из этих правил — пускать ли дальше или нет, юзать ли реврайты и какие и т.п. Не знаю, как оно работает, скорее всего кэшируется, но поскольку изменения в .htaccess вступают всилу без перезагрузки, то банальный stat на время модфикации все же делается, а это не есть хорошо.
Могу наваять пост о разработке многопроцессного демона рассылки после обкатки его в боевых условиях. Причем, на PHP — для настоящих извращенцев))
Надо?
Совершенно верно, но по-хорошему тот процесс, который запустил дите, должен отвечать за их уничтожение. По сигналу TERM, которое по умолчанию шлется закрываемой пользователем программе, так обычно и происходит.
Про потоки не расскажу, а fork предельно прост: тупо запускает копию родительского процесса, при этом родительский процесс получает PID дитя.
r = fork();
if (-1 == r) {
printf(«Случилось что-то страшное\n»);
} else if (0 == r) {
printf(«Я дитя!»);
} else {
printf(«Я не дитя, но дитя у меня есть: %d», r);
}
Раньше дитя получало копию всех родительских ресурсов, сейчас используются облегченные форки с copy-on-write — дитю подсовываются указатели (грубо говоря) на память предка, но как только он пытается в нее что-то записать, ему выделяется под это дело своя память, чтобы не разрушить работу предка.
Поскольку в юниксе исторически стартует всего один процесс (init pid = 1, если не считать ядро pid = 0), то если ему надо запустить какую-нибудь программу, то он должен по идее сделать exec("/path/to/some/program"), но в этом случае вместо инита выполнится some_program и по завершении вся система, кроме ядра уйдет в даун (инит конечно же ядром перезапустится, сколько я помню, но это не вариант все равно), поэтому инит сначала делает форк, а уже его дите делает exec, ибо дите нам не жалко.
Т.о. по сути все запущенные программы работают внутри программы init в том месте, где дергается exec у дитя. Идем дальше. Пользователь работает в оболочке (ну или командная строка, хотя это название мне не очень нравится); когда он набирает какую-то команду (точнее, имя файла с программой, досягаемое в пределах путей, перечисленных в $PATH), она выполняется в пределах оболочки. Если мы написали классный демон, запустили его в фоновом режиме в оболочке, а затем ее закрыли, демон так же сдохнет, поскольку принадлежит ее дереву процессов. Чтобы этого избежать, мы должны сделать примерно следующее:
if (fork()) {
// посылаем систему на фиг — мы теперь сами себе хозяева
setsid();
// делаем свое грязное дело даже после закрытия оболочки
while (1)
;
} else {
// родитель, привязанный к оболочке больше не нужен
exit();
}
Что делает setsid точно не скажу — вроде как выставляет вызывающий процесс лидером сессии (группы процессов о_О). Лучше ман на эту тему почитать))
Что касается библиотек для работы с http/ftp — вроде бы все известные сервера юзают свои реализации и работают напрямую с сокетами.
А регулярные выражения — libpcre однозначно))
Стоит она почти везде, если не везде; писать на ней достаточно просто.
На сайте zend.com весьма подробное изложение о том, как писать модули к PHP (http://devzone.zend.com/node/view/id/1021).
Пишется преимущественно на чистом Си, поскольку в этом случае можно воспользоваться скриптом phpize, который на основе шаблона сгенерит configure и еще какие-нибудь рюшечки, после которых для сборки и установки модуля достаточно будет выполнить ./configure && make install.
Модуль в самом простом случае состоит из сишных макросов, предоставляемых зендовской либой, которые создают новые функции на php, описывают их параметры и вешают обработчики (функции на Си, которые эти сами параметры принимают). Соответственно, сначала надо придумать API, затем на его основе написать сишную библиотеку, которая реализует все эти функции, оттестить ее в консоли (если возможно), затем описать все макросы и создать шаблон для phpize.
Си в отличие от C++ особо-то и не изменялся вроде, там все вполне просто)
РБК размещает свои серваки в Курчатовском институте на Октябрьском поле. Видел там две такие комнатищи шумные — как я заметил из своих наблюдений, эти комнатищи шарят между собой РБК (видел их офис с надписью «РБК хостинг»), Релком и вроде еще какие-то перцы.
В начале месяца воткнули в Релком наш сервак на 100-мегабитный канал — поразила неслыханная духота для дата-центра вместо ожидаемого холодильника, когда через несколько минут пальцы коченеют. В стойках живет все, что можно и нельзя, вплоть до обычных юзерских tower'ов. Салазок в стойке мы не обнаружили — наш сервак просто положили на другой.
Проблемы начались в первый же день — с сервера вдруг перестали резолвится домены. Проверил — упал их DNS. Ни о какой круглосуточной поддержке и речи не было, отписал письмо, ответ получил только утром часов в 9-10. Всю ночь при этом DNS то падал, то поднимался. Ответили ip-адресом альтернативного DNS-сервера — прописал и с удивлением обнаружил, что он тоже падает с завидной регулярностью… Более того, падают они попеременно…
Затем неоднократно наблюдал потерю пакетов… Вплоть до 90% — это никуда не годится.
Последние несколько дней, вроде нормально живет, но все равно будем снимать — их якобы копеечные тарифы при условии платного входящего трафика обернутся алмазно-платиновыми. Поставлю сервер скорее всего в РосТелеком — у нас на работе там 7 юнитов занято на гигабите, за 4 месяца заметил только один сбой и то, вероятнее всего в электричестве (на нашем новом серваке сдох один из 8 винтов на рэйд-массиве).
А вот еще камень в огород релкома — мне на интерфейс сваливается какое-то бешеное количество трафика, хотя сервер в тестовом режиме и весь траф по большому счету отжирает ssh. Проверил: мне валится весь траф подсети и я могу спокойно ее снифить, а это уже никуда не годится.
Не понял, за что мне карму попортили %)
Если кто не понял моего сообщения, то меня как раз все устраивает в случае с линуксом, хоть иногда рефлекторно (!) не хватает каких-то вещей, к которым уже привык за несколько лет использования win32-платформ ;)
Ага… Я вот несколько лет уже так мытарился — то фотошопа мне не хватает, то кипа, то еще какой-нибудь фигни. А теперь купил себе ноутбук из принципа под фридосом и натянул на него Gentoo затюненную до безобразия с изрядно обрезанной KDE4, которая просто летает (с отключенными эффектами — они мне не нужны).
Все круто, но на шрифты уже забил — поставил себе тахому и не парюсь.
Она зашита в том или ином виде в сам PHP — под fastcgi они подразумевают, что в памяти висит интерпретатор и форкается на каждый следующий запрос. В случае того же fpm в php в одном из заголовков передается script_FILENAME с путем к скрипту, который требуется интерпретировать.
Можно реализовать на Си расширение к PHP, реализующее собственно протокол FastCGI (http://fastcgi.com/devkit/doc/fcgi-spec.html) и тогда можно будет демонизировать любой php-скрипт, повесить его на какой-нибудь порт и передавать на вход любые данные, но если для перла хватит просто поддержки FastCGI для работы, то php еще нужен парсинг POST-данных на наличие файлов и, думаю, ряд других приблуд, которые доставят немало головной боли. Оно нам надо?)
О, да… Когда себе купил M-Audio Delta/66 и получил в NI Guitar Rig задержку 2ms против 8ms, которые обещали при использовании родного контроллера, был приятно удивлен))
Впрочем, ламповый Fender Blues Junior с каскадом из всяко-разных аналоговых примочек выдавали такой звук, который цифре и не снился — меня на концертах часто спрашивали, как я такого звука добиваюсь в таких варварских условиях — очень просто;) Ручками и аналогом))
А клавиши M-Audio Oxygen особенно хороши благодаря своим фейдерам при работе с органом NI B4, хотя на хаммонде играть поприятнее, имхо)
c10k никто не отменял — с течением времени проект либо дохнет, либо развивается, а вместе с развитием растет и нагрузка — нельзя вечно железом отстреливаться, не помогает ;)
Чем раньше решишь проблему с оптимизацией, тем меньше потратишь времени в будущем. Время программиста конечно подороже, чем железо (хотя наш новый сервер с двумя 4-х-ядерными ксеонами и 16-ю гигами мозгов стоит больше, чем я получаю денег… причем, в несколько раз), но время пользователей еще дороже — чем меньше время отклика, тем меньше вероятность, что пользователь уйдет с сайта и не узнает, что можно отправить волшебную смс, получить за это виртуальную ерунду, к примеру и озолотить тем самым на копеечку компанию-владельца ресурса, а вместе с ней и ее программистов. Упущенная выгода — смертный грех любого бизнеса, имхо +)
Да и потом, неужели неинтересно решать задачи по оптимизации? Можно вывить кучу багов, начиная с какого-нибудь алгоритма, заканчивая архитектурой самого проекта — это куда интереснее, чем железки крутить, имхо))
Впрочем, лично я и от закручивания винтиков кайф ловлю, а наблюдение за компиляцией системы меня просто в транс вводит — особенно, когда gcc ни одного писка не выдает при -Wall, как в случае с nginx'ом ;))
Меня торренты подбешивают тем, что нельзя взять тупо и скачать — я не жадный ни на контент (слава Богу, в России живу), ни на трафик (он бесплатный, ибо), но то, что выкладываю я, народ не особо качает (битлы с пинк флойдом — видимо уже не модно), посему рейтинг у меня моментально падает и приходится идти на другой трекер. А в остальном, вполне себе крутая вещь!
O(1) говорит о постоянном времени работы алгоритма, независимо от входных данных. Любые две программы будут работать с большей вероятностью с разным O(1), чем с одинаковым. В случае FastCGI + APC, как я понимаю, при каждом коннекте доступ к shared memory APC уже имеется, поэтому коннектится не надо, в отличие от мемкеша. Это первый момент, не столь критичен (loopback, socket, etc.). Мне видится, разность скорости в самой идее добычи информации — что memcached, что APC в любом случае используют всяко-разные O(1) хэш-функции для поиска данных, поэтому принцип поиска один и тот же, но в случае с APC мы имеем доступ к разделяемой памяти между процессами — они ее видят, как свою собственную память и лочат только при записи, а в случае мемкеша мы гоняем данные по транспорту, дергаем определенное количество раз mem_cpy, что занимает время. Поэтому shared memory намного быстрее, но ее не поюзаешь в распределенной системе, если это не shared memory в каком-нибудь специально спроектированном супер-кластере со своим аппаратным чудо-супер-пупер-контроллером. ИМХО.
Для XSLT-преобразований я хочу использовать nginx + xslt, у которого уже подгружены все необходимые шаблоны. Собственно, в каком виде иначе как в XML мне передавать ему данные от php? Промелькнула мысль «зачем в php упаковывать данные в xml, чтобы xslt-шаблонизатор его парсил, когда можно передать dom-дерево». Вот мне и интересно, как передать это самое dom-дерево)
бр-бр-бр… осмелюсь спросить, что такое dom-дерево, если не объектная структура и как ее передавать между независимыми компонентами? вот создал я на своем php dom-дерево и надо мне его послать другой программе, которая на это дерево натравит xslt-шаблон… мои действия могут быть следующими:
* упаковать в xml
* упаковать в иную сериализованную строку
* упаковать в какой-нибудь бинарный формат, желательно понятный как php, так и libxslt
Кстати, о производительности — есть у nginx модуль для работы с xslt. Шаблоны парсятся при чтении конфигурации и затем натравливаются на выход с бакэндов или xml-файлов. Кто-нибудь пользовался?
На нагруженных проектах включать AllowOverride лично я не рекомендую, иначе при каждом обращении к файлу, апач на пути к нему будет проверять наличие .htaccess, его синтаксис, что делать из этих правил — пускать ли дальше или нет, юзать ли реврайты и какие и т.п. Не знаю, как оно работает, скорее всего кэшируется, но поскольку изменения в .htaccess вступают всилу без перезагрузки, то банальный stat на время модфикации все же делается, а это не есть хорошо.
Надо?
r = fork();
if (-1 == r) {
printf(«Случилось что-то страшное\n»);
} else if (0 == r) {
printf(«Я дитя!»);
} else {
printf(«Я не дитя, но дитя у меня есть: %d», r);
}
Раньше дитя получало копию всех родительских ресурсов, сейчас используются облегченные форки с copy-on-write — дитю подсовываются указатели (грубо говоря) на память предка, но как только он пытается в нее что-то записать, ему выделяется под это дело своя память, чтобы не разрушить работу предка.
Поскольку в юниксе исторически стартует всего один процесс (init pid = 1, если не считать ядро pid = 0), то если ему надо запустить какую-нибудь программу, то он должен по идее сделать exec("/path/to/some/program"), но в этом случае вместо инита выполнится some_program и по завершении вся система, кроме ядра уйдет в даун (инит конечно же ядром перезапустится, сколько я помню, но это не вариант все равно), поэтому инит сначала делает форк, а уже его дите делает exec, ибо дите нам не жалко.
Т.о. по сути все запущенные программы работают внутри программы init в том месте, где дергается exec у дитя. Идем дальше. Пользователь работает в оболочке (ну или командная строка, хотя это название мне не очень нравится); когда он набирает какую-то команду (точнее, имя файла с программой, досягаемое в пределах путей, перечисленных в $PATH), она выполняется в пределах оболочки. Если мы написали классный демон, запустили его в фоновом режиме в оболочке, а затем ее закрыли, демон так же сдохнет, поскольку принадлежит ее дереву процессов. Чтобы этого избежать, мы должны сделать примерно следующее:
if (fork()) {
// посылаем систему на фиг — мы теперь сами себе хозяева
setsid();
// делаем свое грязное дело даже после закрытия оболочки
while (1)
;
} else {
// родитель, привязанный к оболочке больше не нужен
exit();
}
Что делает setsid точно не скажу — вроде как выставляет вызывающий процесс лидером сессии (группы процессов о_О). Лучше ман на эту тему почитать))
Что касается библиотек для работы с http/ftp — вроде бы все известные сервера юзают свои реализации и работают напрямую с сокетами.
А регулярные выражения — libpcre однозначно))
Стоит она почти везде, если не везде; писать на ней достаточно просто.
Там есть ооочень много всего интересного))
Пишется преимущественно на чистом Си, поскольку в этом случае можно воспользоваться скриптом phpize, который на основе шаблона сгенерит configure и еще какие-нибудь рюшечки, после которых для сборки и установки модуля достаточно будет выполнить ./configure && make install.
Модуль в самом простом случае состоит из сишных макросов, предоставляемых зендовской либой, которые создают новые функции на php, описывают их параметры и вешают обработчики (функции на Си, которые эти сами параметры принимают). Соответственно, сначала надо придумать API, затем на его основе написать сишную библиотеку, которая реализует все эти функции, оттестить ее в консоли (если возможно), затем описать все макросы и создать шаблон для phpize.
Си в отличие от C++ особо-то и не изменялся вроде, там все вполне просто)
В начале месяца воткнули в Релком наш сервак на 100-мегабитный канал — поразила неслыханная духота для дата-центра вместо ожидаемого холодильника, когда через несколько минут пальцы коченеют. В стойках живет все, что можно и нельзя, вплоть до обычных юзерских tower'ов. Салазок в стойке мы не обнаружили — наш сервак просто положили на другой.
Проблемы начались в первый же день — с сервера вдруг перестали резолвится домены. Проверил — упал их DNS. Ни о какой круглосуточной поддержке и речи не было, отписал письмо, ответ получил только утром часов в 9-10. Всю ночь при этом DNS то падал, то поднимался. Ответили ip-адресом альтернативного DNS-сервера — прописал и с удивлением обнаружил, что он тоже падает с завидной регулярностью… Более того, падают они попеременно…
Затем неоднократно наблюдал потерю пакетов… Вплоть до 90% — это никуда не годится.
Последние несколько дней, вроде нормально живет, но все равно будем снимать — их якобы копеечные тарифы при условии платного входящего трафика обернутся алмазно-платиновыми. Поставлю сервер скорее всего в РосТелеком — у нас на работе там 7 юнитов занято на гигабите, за 4 месяца заметил только один сбой и то, вероятнее всего в электричестве (на нашем новом серваке сдох один из 8 винтов на рэйд-массиве).
А вот еще камень в огород релкома — мне на интерфейс сваливается какое-то бешеное количество трафика, хотя сервер в тестовом режиме и весь траф по большому счету отжирает ssh. Проверил: мне валится весь траф подсети и я могу спокойно ее снифить, а это уже никуда не годится.
Если кто не понял моего сообщения, то меня как раз все устраивает в случае с линуксом, хоть иногда рефлекторно (!) не хватает каких-то вещей, к которым уже привык за несколько лет использования win32-платформ ;)
Все круто, но на шрифты уже забил — поставил себе тахому и не парюсь.
Можно реализовать на Си расширение к PHP, реализующее собственно протокол FastCGI (http://fastcgi.com/devkit/doc/fcgi-spec.html) и тогда можно будет демонизировать любой php-скрипт, повесить его на какой-нибудь порт и передавать на вход любые данные, но если для перла хватит просто поддержки FastCGI для работы, то php еще нужен парсинг POST-данных на наличие файлов и, думаю, ряд других приблуд, которые доставят немало головной боли. Оно нам надо?)
Впрочем, ламповый Fender Blues Junior с каскадом из всяко-разных аналоговых примочек выдавали такой звук, который цифре и не снился — меня на концертах часто спрашивали, как я такого звука добиваюсь в таких варварских условиях — очень просто;) Ручками и аналогом))
А клавиши M-Audio Oxygen особенно хороши благодаря своим фейдерам при работе с органом NI B4, хотя на хаммонде играть поприятнее, имхо)
Чем раньше решишь проблему с оптимизацией, тем меньше потратишь времени в будущем. Время программиста конечно подороже, чем железо (хотя наш новый сервер с двумя 4-х-ядерными ксеонами и 16-ю гигами мозгов стоит больше, чем я получаю денег… причем, в несколько раз), но время пользователей еще дороже — чем меньше время отклика, тем меньше вероятность, что пользователь уйдет с сайта и не узнает, что можно отправить волшебную смс, получить за это виртуальную ерунду, к примеру и озолотить тем самым на копеечку компанию-владельца ресурса, а вместе с ней и ее программистов. Упущенная выгода — смертный грех любого бизнеса, имхо +)
Да и потом, неужели неинтересно решать задачи по оптимизации? Можно вывить кучу багов, начиная с какого-нибудь алгоритма, заканчивая архитектурой самого проекта — это куда интереснее, чем железки крутить, имхо))
Впрочем, лично я и от закручивания винтиков кайф ловлю, а наблюдение за компиляцией системы меня просто в транс вводит — особенно, когда gcc ни одного писка не выдает при -Wall, как в случае с nginx'ом ;))
* упаковать в xml
* упаковать в иную сериализованную строку
* упаковать в какой-нибудь бинарный формат, желательно понятный как php, так и libxslt
что делать?)