Elettracompany.com

Компьютерный справочник
4 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Сызнова index php threads

Введение в PHP Потоки

В программировании постоянно приходиться работать с различными ресурсами: файлами, сокетами, http-соединениями. И у них у всех есть некий интерфейс доступа, часто несовместимый друг с другом. Поэтому, чтобы устранить данные несоответствия и унифицировать работу с различными источниками данных, начиная с PHP 4.3 были придуманы PHP Streams — потоки.

Несмотря на то, что PHP 4.3 вышел давным-давно, многие PHP-программисты имеют весьма отдаленное представление о потоках в PHP, и продолжают использовать CURL везде, хотя в PHP для этого существует более удобная альтернатива в виде контекста потоков (Stream Context).

Следующие виды потоков существуют в PHP:

  • Файл на жестком диске;
  • HTTP-соединение с веб-сайтом;
  • Соединение UDP с сервером;
  • ZIP-файл;
  • Файл *.mp3.

Что общего есть во всех этих ресурсах? Все они могут быть прочитаны и записаны, т.е. к ним ко всем могут быть применены операции чтения и записи. Сила потоков PHP как раз и заключается в том, что вы можете получить доступ ко всем этим ресурсам, используя один и тот же набор функций. Это очень удобно. Также, если вдруг возникнет такая необходимость, Вы можете написать свою собственную реализацию обработчика потоков «stream wrapper». Помимо чтения и записи, потоки в PHP также позволяет выполнять другие операции, такие как переименование и удаление.

Программируя на PHP, Вы уже встречались с потоками, хотя возможно не догадывались об этом. Так, функции, работающие с потоками — это fopen(), file_get_contents(), file() и т.д. Поэтому, фактически, Вы уже используете файловые потоки все это время, полностью прозрачно.

Для работы с другим типом потока, необходимо указать его протокол (wrapper) следующим образом: wrapper://some_stream_resource, где wrapper:// — это, например http://, file://, ftp://, zip:// и т.д., а some_stream_resourceURI-адрес, идентифицирует то, что вы хотите открыть. URI-адрес не накладывает каких-либо ограничений на формат. Примеры:

Однако, учтите, что не все протоколы и обработчики могут работать у Вас, так как поддержка некоторых оболочек зависит от Ваших настроек. Поэтому, чтобы узнать какие протоколы поддерживаются необходимо выполнить следующий скрипт:

Контексты потоков PHP

Часто возникает необходимость указания дополнительных параметров при http-запросе. Контексты потоков решают эту проблему, позволяя указать дополнительные параметры. У многих функций, поддерживающих работу с потоками, есть необязательный параметр контекста потока. Давайте посмотрим на функцию file_get_contents():

string file_get_contents(string $filename [, int $flags = 0 [, resource $context [, int $offset = -1 [, int $maxlen = -1]]]])

Как видно, третьим параметром передается контекст потока. Контексты создаются с помощью функции stream_context_create(), которая принимает массив и возвращает ресурс контекста.

array(
‘method’ => «GET»,
‘header’ => «Accept-language: enrn».
«Cookie: foo = barrn»
)
);

// Используя это с file_get_contents .
echo file_get_contents («http://www.example.com/», 0, $context);

Таким образом, сегодня мы узнали, что такое потоки и контексты потоков в PHP, рассмотрели примеры их использования, а в следующих статьях мы поговорим о метаданных потока и создадим свой собственный обработчик.

Копирование материалов разрешается только с указанием автора (Михаил Русаков) и индексируемой прямой ссылкой на сайт (http://myrusakov.ru)!

Добавляйтесь ко мне в друзья ВКонтакте: http://vk.com/myrusakov.
Если Вы хотите дать оценку мне и моей работе, то напишите её в моей группе: http://vk.com/rusakovmy.

Если Вы не хотите пропустить новые материалы на сайте,
то Вы можете подписаться на обновления: Подписаться на обновления

Если у Вас остались какие-либо вопросы, либо у Вас есть желание высказаться по поводу этой статьи, то Вы можете оставить свой комментарий внизу страницы.

Порекомендуйте эту статью друзьям:

Если Вам понравился сайт, то разместите ссылку на него (у себя на сайте, на форуме, в контакте):

Она выглядит вот так:

  • BB-код ссылки для форумов (например, можете поставить её в подписи):
  • Комментарии ( 0 ):

    Для добавления комментариев надо войти в систему.
    Если Вы ещё не зарегистрированы на сайте, то сначала зарегистрируйтесь.

    Copyright © 2010-2020 Русаков Михаил Юрьевич. Все права защищены.

    PHP Profi

    КвестКак хакнуть форму

    Многопоточное программирование в PHP с помощью Pthreads Перевод

    php extension pthreads многопоточность

    Похоже, PHP разработчики редко используют параллельность. Говорить о простоте синхронного кода не буду, однопоточное программирование, конечно, проще и понятнее, но иногда небольшое использование параллельности может принести ощутимое повышение производительности.

    В этой статье мы взглянем на то, как многопоточность может быть достигнута в PHP с помощью расширения pthreads. Для этого потребуется установленная ZTS (Zend Thread Safety) версия PHP 7.x, вместе с установленным расширением pthreads v3. (На момент написания статьи, в PHP 7.1 пользователям нужно будет установить из ветки master в репозитории pthreads – см. подробнее как установить (en) стороннее расширение.)

    Небольшое уточнение: pthreads v2 предназначена для PHP 5.x и более не поддерживается, pthreads v3 — для PHP 7.х и активно развивается.

    Большое спасибо Joe Watkins (создателю расширения pthreads) за вычитку и помощь в улучшении моей статьи!

    Когда не стоит использовать pthreads

    Прежде чем мы начнём, я хотел бы уточнить, когда вы не должны (да и не можете) использовать расширение pthreads.

    В pthreads v2, рекомендация была в том, что pthreads не должна использоваться в веб-серверной среде (т.е. в fcgi процессе). Что касается pthreads v3, эта рекомендация является программным ограничением, так что теперь вы просто не сможете использовать его в среде веб-сервера. Две известные причины:

    1. Это небезопасно использовать несколько потоков в такой среде (например, в связи с ошибками ввода-вывода, да и кучи других проблем).
    2. Это не очень хорошо масштабируется. Например, скажем, у вас есть PHP-скрипт, который создает новый поток, чтобы обработать какую-то задачу, и этот скрипт выполняется при каждом запросе. Это означает, что для каждого запроса, ваше приложение будет создавать новый поток (это модель потоков 1:1 – один поток на один запрос). Если ваше приложение обслуживает 1тыс. запросов в секунду, это означает создание 1тыс. нитей в секунду! Наличие множества потоков, запущенных на одной машине, быстро наводнит ее, и проблема будет лишь усугубляться, т. к. скорость выполнения запроса будет увеличиваться.

    Вот почему многопоточность не является хорошим решением в такой среде. Если вы рассматриваете многопоточность как решение задач, блокирующих ввод-вывод (например, выполнение http-запросов), то позвольте мне обратить ваше внимание на асинхронное программирование, которое можно реализовать с помощью фреймворков, таких как Amp.

    После такого отступления, давайте сразу перейдём к делу!

    Обработка разовых задач

    Иногда вы хотите обрабатывать разовые задачи многопоточным способом (например, выполнение некой задачи, завязанной на ввод-вывод). В таких случаях можно использовать класс Thread , чтобы создать новый поток и запустить некую обработку в отдельном потоке.

    Здесь метод run — это наша обработка, которая будет выполняться внутри нового потока. При вызове Thread::start , порождается новый поток и вызывается метод run . Затем мы присоединяем порождённый поток обратно в основной поток, вызвав Thread::join , который будет заблокирован до тех пор, пока порождённый поток не завершит своё выполнение. Это гарантирует, что задача завершит выполнение, прежде чем мы попытаемся вывести результат (который хранится в $task->response ).

    Возможно, не желательно загрязнять класс дополнительной ответственностью, связанной с логикой потока (в том числе обязанность определения метода run ). Мы можем выделить такие классы, унаследовав их от класса Threaded . Тогда они могут быть запущены внутри другого потока:

    Любой класс, который должен быть запущен в отдельном потоке, должен наследоваться от класса Threaded . Это потому что он предоставляет необходимые возможности для выполнения обработки в разных потоках, а также неявную безопасность и полезные интерфейсы (такие, как синхронизация ресурсов).

    Давайте взглянем на иерархию классов, предлагаемую расширением pthreads:

    Мы уже рассмотрели и узнали основы классов Thread и Threaded , теперь давайте взглянем на остальные три ( Worker , Volatile , и Pool ).

    Переиспользование потоков

    Запуск нового потока для каждой задачи, которую нужно распараллелить, достаточно затратно. Это потому что архитектура «ничего-общего» должна быть реализована в pthreads, чтобы добиться многопоточности внутри PHP. Что означает, что весь контекст выполнения текущего экземпляра интерпретатора PHP (в том числе и каждый класс, интерфейс, трейт и функция) должна быть скопирована для каждого созданного потока. Поскольку это влечет за собой заметное влияние на производительность, поток всегда должен быть повторно использован, когда это возможно. Потоки могут быть переиспользованы двумя способами: с помощью Worker -ов или с помощью Pool -ов.

    Класс Worker используется для выполнения ряда задач синхронно внутри другого потока. Это делается путем создания нового экземпляра Worker -а (который создает новый поток), а затем внесением задач в стек этого отдельного потока (с помощью Worker::stack ).

    Вот небольшой пример:

    В вышеприведённом примере в стек заносится 15 задач для нового объекта $worker через метод Worker::stack , а затем они обрабатываются в порядке их внесения. Метод Worker::collect , как показано выше, используется для очистки задач, как только они закончат выполнение. С его помощью внутри цикла while, мы блокируем основной поток, пока не будут завершены все задачи из стека и пока они не будут очищены — до того как мы вызовем Worker::shutdown . Завершение worker -а досрочно (т. е. пока есть еще задачи, которые должны быть выполнены) будет по-прежнему блокировать основной поток до тех пор, пока все задачи не завершат своё выполнение, просто задачи не будут почищены сборщиком мусора (что влечёт за собой утечки памяти).

    Класс Worker предоставляет несколько других методов, относящихся к его стеку задач, включая Worker::unstack для удаления последней внесённой задачи и Worker::getStacked для получения количества задач в стеке выполнения. Стек worker -а содержит только задачи, которые должны быть выполнены. Как только задача из стека была выполнена, она удаляется и размещается в отдельном (внутреннем) стеке для сборки мусора (с помощью метода Worker::collect ).

    Читать еще:  Php как fastcgi

    Еще один способ переиспользовать поток при выполнении многих задач — это использование пула потоков (через класс Pool ). Пул потоков использует группу Worker -ов, чтобы дать возможность выполнять задачи одновременно, в котором фактор параллельности (число потоков пула, с которыми он работает) задается при создании пула.

    Давайте адаптируем приведенный выше пример для использования пула worker -ов:

    Есть несколько заметных различий при использовании пула, в отличие от воркера. Во-первых, пул не требует запуска вручную, он приступает к выполнению задач, как только они становятся доступными. Во-вторых, мы отправляем задачи в пул, а не укладываем их в стек. Кроме того, класс Pool не наследуется от Threaded , и поэтому он не может быть передан в другие потоки (в отличие от Worker ).

    Как хорошая практика, для воркеров и пулов следует всегда подчищать их задачи, как только они завершились, и затем вручную завершать их самих. Потоки, созданные с помощью класса Thread также должны быть присоединены к порождающему потоку.

    pthreads и (не)изменяемость

    Последний класс, которого мы коснёмся, – Volatile , – новое дополнение к pthreads v3. Понятие неизменяемости стало важной концепцией в pthreads, так как без неё производительность существенно снижается. Поэтому по умолчанию, свойства Threaded -классов, которые сами являются Threaded -объектами, сейчас являются неизменными, и поэтому они не могут быть перезаписаны после их первоначального присвоения. Явная изменяемость для таких свойств сейчас пока предпочтительна, и все еще может быть достигнута с помощью нового класса Volatile .

    Давайте взглянем на пример, который продемонстрирует новые ограничения неизменяемости:

    Threaded -свойства у классов Volatile , с другой стороны, изменяемы:

    Мы видим, что класс Volatile переопределяет неизменяемость, навязанную родительским классом Threaded , чтобы предоставить возможность изменять Threaded -свойства (а также unset() -ить).

    Есть ещё один предмет обсуждения чтобы раскрыть тему изменяемости и класса Volatile – массивы. В pthreads массивы автоматически приводятся к Volatile -объектам при присвоении к свойству класса Threaded . Это потому что просто небезопасно манипулировать массивом из нескольких контекстов PHP.

    Давайте снова взглянем на пример, чтобы лучше понимать некоторые вещи:

    Мы видим, что Volatile -объекты могут быть обработаны так, как если бы они были массивами, т. к. они поддерживают операции с массивами, такие как (как показано выше) оператор подмножеств ( [] ). Однако, классы Volatile не поддерживают базовые функции с массивами, такие как array_pop и array_shift . Вместо этого, класс Threaded предоставляет нам подобные операции как встроенные методы.

    В качестве демонстрации:

    Другие поддерживаемые операции включают в себя Threaded::chunk и Threaded::merge .

    Синхронизация

    В последнем разделе этой статьи мы рассмотрим синхронизацию в pthreads. Синхронизация — это метод, позволяющий контролировать доступ к общим ресурсам.

    Для примера, давайте реализуем простейший счетчик:

    Без использования синхронизации, вывод не детерминирован. Несколько потоков пишут в одну переменную без контролируемого доступа, что означает что обновления будут потеряны.

    Давайте исправим это так, что мы получим правильный вывод 20 , путем добавления синхронизации:

    Синхронизированные блоки кода могут также взаимодействовать друг с другом, используя методы Threaded::wait и Threaded::notify (или Threaded::notifyAll ).

    Вот поочерёдный инкремент в двух синхронизированных циклах while:

    Вы можете заметить дополнительные условия, которые были размещены вокруг обращения к Threaded::wait . Эти условия имеют решающее значение, поскольку они позволяют синхронизированному колбэку возобновить работу, когда он получил уведомление и указанное условие равно true . Это важно, потому что уведомления могут поступать из других мест, кроме как при вызове Threaded::notify . Таким образом, если вызовы метода Threaded::wait не были заключены в условиях, мы будем выполнять ложные вызовы пробуждения, которые приведут к непредсказуемому поведению кода.

    Заключение

    Мы рассмотрели пять классов пакета pthreads ( Threaded , Thread , Worker , Volatile и Pool ), а также как каждый из классов используется. А ещё мы взглянули на новую концепцию неизменяемости в pthreads, сделали краткий обзор поддерживаемых возможностей синхронизации. С этими основами, мы можем теперь приступить к рассмотрению применения pthreads в случаях из реального мира! Это и будет темой нашего следующего поста.

    Если вам интересен перевод следующего поста, дайте знать: комментируйте в соц. сетях, плюсуйте и делитесь постом с коллегами и друзьями.

    Running PHP scripts in uWSGI¶

    You can safely run PHP scripts using uWSGI’s CGI support. The downside of this approach is the latency caused by the spawn of a new PHP interpreter at each request.

    To get far superior performance you will want to embed the PHP interpreter in the uWSGI core and use the PHP plugin.

    Building¶

    A bunch of distros (such as Fedora, Red Hat and CentOS) include a php-embedded package. Install it, along with php-devel and you should be able to build the php plugin:

    If you get linkage problems (such as libraries not found), install those missing packages ( ncurses-devel , gmp-devel , pcre-devel …) but be warned that if you add development packages modifying the uWSGI core behaviour ( pcre is one of these) you _need_ to recompile the uWSGI server too, or strange problems will arise.

    For distros that do not supply a libphp package (all Debian-based distros, for instance), you have to rebuild PHP with the —enable-embed flag to ./configure :

    Ubuntu 10.04 (newer versions include official libphp-embed sapi)¶

    Multiple PHP versions¶

    Sometimes (always, if you are an ISP) you might have multiple versions of PHP installed in the system. In such a case, you will need one uWSGI plugin for each version of PHP:

    ‘default’ is the build profile of your server core. If you build uWSGI without a specific profile, it will be ‘default’.

    You can then load a specific plugin with plugins php51 , etc. You cannot load multiple PHP versions in the same uWSGI process.

    Running PHP apps with nginx¶

    If you have simple apps (based on file extensions) you can use something like this:

    You might want to check for all of URIs containing the string .php :

    Now simply run the uWSGI server with a bunch of processes:

    This will allow up to 40 concurrent php requests but will try to spawn (or destroy) workers only when needed, maintaining a minimal pool of 4 processes.

    Advanced configuration¶

    By default, the PHP plugin will happily execute whatever script you pass to it. You may want to limit it to only a subset of extensions with the php-allowed-ext option.

    Run PHP apps without a frontend server¶

    This is an example configuration with a “public” uWSGI instance running a PHP app and serving static files. It is somewhat complex for an example, but should be a good starting point for trickier configurations.

    A more extreme example that mixes CGI with PHP using internal routing and a dash of configuration logic .

    uWSGI API support¶

    Preliminary support for some of the uWSGI API has been added in 1.1. This is the list of supported functions:

    • uwsgi_version()
    • uwsgi_setprocname($name)
    • uwsgi_worker_id()
    • uwsgi_masterpid()
    • uwsgi_signal($signum)
    • uwsgi_rpc($node, $func, …)
    • uwsgi_cache_get($key)
    • uwsgi_cache_set($key, $value)
    • uwsgi_cache_update($key, $value)
    • uwsgi_cache_del($key)

    Yes, this means you can call Python functions from PHP using RPC.

    Setting the first argument of uwsgi_rpc to empty, will trigger local rpc.

    Or you can share the uWSGI cache …

    Sessions over uWSGI caches (uWSGI >=2.0.4)¶

    Starting from uWSGI 2.0.4, you can store PHP sessions in uWSGI caches.

    Zend Opcode Cache (uWSGI >= 2.0.6)¶

    For some mysterious reason, the opcode cache is disabled in the embed SAPI.

    You can bypass the problem by telling the PHP engine that is running under the apache SAPI (using the php-sapi-name option):

    ForkServer (uWSGI >= 2.1)¶

    The Fork Server (sponsored by Intellisurvey) is one of the main features of the 2.1 branch. It allows you to inherit your vassals from specific parents instead of the Emperor.

    The PHP plugin has been extended to support a fork-server so you can have a pool of php base instances from which vassals can fork() . This means you can share the opcode cache and do other tricks.

    Thanks to the vassal attributes in uWSGI 2.1 we can choose from which parent a vassal will call fork().

    You need Linux kernel >= 3.4 (the feature requires PR_SET_CHILD_SUBREAPER ) for “solid” use. Otherwise your Emperor will not be able to correctly wait() on children (and this will slow-down your vassal’s respawns, and could lead to various form of race conditions).

    In the following example we will spawn 3 vassals, one (called base.ini) will initialize a PHP engine, while the others two will fork() from it.

    then the 2 vassals

    The two vassals are completely unrelated (even if they fork from the same parent), so you can drop privileges, have different process policies and so on.

    Now spawn the Emperor:

    The —emperor-collect-attr forces the Emperor to search for the ‘fork-server’ attribute in the [emperor] section of the vassal file, while —emperor-fork-server-attr tells it to use this parameter as the address of the fork server.

    Obviously if a vassal does not expose such an attribute, it will normally fork() from the Emperor.

    © Copyright 2012-2016, uWSGI Revision b1f83a5d .

    php thread safe vs non

    Подскажите в чём прелесть и недостаток каждого из вариантов?

    Thread Safety means that binary can work in a multithreaded webserver context, such as Apache 2 on Windows. Thread Safety works by creating a local storage copy in each thread, so that the data won’t collide with another thread.

    Читать еще:  Ziparchive php как подключить

    So what do I choose? If you choose to run PHP as a CGI binary, then you won’t need thread safety, because the binary is invoked at each request. For multithreaded webservers, such as IIS5 and IIS6, you should use the threaded version of PHP.

    Вот как бы в чём вопрос. Везде упоминают Windows для Thread Safety.

    А что под линуксом например всё равно, что использовать с ПХП?

    Или во фразе: Thread Safety means that binary can work in a multithreaded webserver context, such as Apache 2 on Windows. Вместо «Windows» можно подставить другую операционку?

    под линуксом, на сколько я могу судить, всё равно.

    Я ещё забыл упомянуть, что есть некоторые расширения, которые требуют Thread-safe сборку (например, pthreads), но их немного и я не слышал, чтобы их кто-то реально использовал.

    Вместо «Windows» можно подставить другую операционку?

    Да и нет. Дело в том, что апач под linux обычно работает в виде отдельных процессов, а не многопоточно, и это общая практика в unix-системах, классика, а «such as Apache 2 on Windows» это именно особый случай, когда апач работает только многопоточно, такова специфика оффтопика, поэтому они его в пример и приводят. Но в принципе, можно и в linux запускать апач в многопоточном режиме.

    Я может чего-то подзабыл. чем отличаются потоки от процессов на программном уровне? И как каждый из них переводится на английский? 🙂

    Наверное имеется ввиду что мултипоточность — это когда каждый работает в своей виртуальной памяти и не имеет никакого доступа к другому (даже не знает о нем) за счет аппаратного i386 режима.

    Тогда не понятно какое имеет отношение к этому сам аппач. Хотя наверное я переставил местами потоки и процессы.

    Тоесть если использовать thread safe, то в любом случае будет ок? Или как?

    чем отличаются потоки от процессов на программном уровне

    Тем что потоки работают в одном и том же адресном пространстве, а процессы — каждый в своём

    Тогда не понятно какое имеет отношение к этому сам аппач

    Тем что при множестве процессов, в рамках одного процесса программа однопоточна, пых запускается однопоточно и о других процессах ничего не знает, а threadsafe не нужен.

    Я выше писал тоже самое и даже упоминал i386 protected mode (аппаратный режим разраничения адресных простарнств).

    И да. как и Вы ошибся, потоки (threads), какраз таки в одном постранстве копошатся, а процессы (processes) — это вроде и есть уже разделённые аппаратно процессы.

    В виндовсе вроде как сервисы называются, а в линуксе — демоны.

    интресено что для проца вобщем всё равно, они адресуются одними и теми же дескрипторами и обрабатываются теми же аппаратными прерываниями, просто есть основной процесс который делает теже потоки и контролирует их, а если делаешь просто сервисы (демоны) — то ими рулит как основной процесс ядро операционки.

    вопрос вобщем остался таковым. Универсалный ли вариант, если использовать thread safe вариант ПХП?

    как и Вы ошибся

    Что значит как и я? Я тебе как раз правильно рассказал.

    есть основной процесс который делает теже потоки и контролирует их

    Не основной, а единственный. Все потоки работают в рамках одного процесса. Ими никто не рулит, они сами между собой договариваются, в этом и заключается смысл threadsafe.

    Универсалный ли вариант, если использовать thread safe вариант ПХП?

    threadsafe не бесплатно. Это медленнее чем простой однопоток, т.к. требует дополнительных телодвижений по синхронизации потоков. С другой стороны, сама организация работы сервера в виде отдельных процессов может оказаться медленнее, чем один многопоточный процесс. А может и не оказаться, но если таки говорить о пыхе, то я так понимаю, что threadsafe там запилен конкретно под специфику работы http-серверов в винде.

    Я не совем тогда понимаю, если на сайт зашло 100 человек, они работают в однопотоке? Это вообще реально, удобно и быстро?

    threadsafe там запилен конкретно под специфику работы http-серверов в винде

    А в линуксе как-то по другому работают потоку? Не понимаю?

    нет, просто вместо того чтобы заморачивать себе этим голову, сейчас популярное решение переключиться на связку nginx php fastcgi

    Я просто думаю сделать простой сайт визитку.

    Мне например вполне хватит Жумлы на ПХП и Апач.

    Для ресурсоёмких проектов использую энтерпрайз решения на Жабе.

    Глупо поднимать завод по производству урана, если нужна всего лишь распилисть пару досок.

    Вот ещё из документации комментарий, не рекомендующий thread safe на продакшн

    Моё мнение такое, что если ты не можешь обосновать, зачем тебе включать thread safe, то и делать этого не нужно. В тех же репозиториях убунты лежит non thread safe, которую все поголовно используют и с Apache2 и с nginx. А кейс, когда нужна thread safe версия, надо ещё сперва придумать, сам по себе он внезапно не возникнет.

    Мне например вполне хватит Жумлы на ПХП и Апач.

    Ну тем более. На тех же шаред хостингах с апачем везде thread safe выключен. И thread safe ты как собрался ставить? Вручную php собирать с экзотическими настройками ради джумлы?

    жирновато как то хочешь визитку, а спрашиваешь про трэды

    Я про треды не спрашиваю, я про них знаю.

    Я не понимаю почему в ПХП так их вынесли как нечто магическое.

    Именно и спрашивал в чём плюшки и глюки каждого из вариантов ПХП.

    Никто ничего дельного не ответил, зачем именно 2 версии с примерами применения (ну про ЦГИ я почти понял).

    Меня интересует именно под апачем как веб применение.

    А что жирноватого для визитки из небольшого блога со статьями?

    И thread safe ты как собрался ставить? Вручную php собирать с экзотическими настройками ради джумлы?

    Вот и расскажите мне нюансы что там не так или тут не эдак.

    Я для этого и затеял вопрос?

    И причём тут руками сборка для жумлы?

    На сайте ПХП есть и та и та версия (уже собранные)

    объясните на пальцах чем та или так хороша (плоха) в ве применении на апач.

    Апач устаревает, хочешь простоты: почему бы тогда не задействовать встроенный сервер?

    Программирование по простому в пыхе выливается в такой быдлокод, что с этим сможет справиться не тривиальные технологии и подходы .

    Может тебе нужно немножко продолжительного рантайма?

    Я не собираюсь кодить в ПЫХе

    Я собираюсь использовать Joomla

    Там есть всё что мне нужно для сайта-визитки и даже больше.

    Что за встроенный сервер?

    проблема с многопоточностью в php в том, что она есть, но лучше ей не пользоваться. Проблема в исходниках и зависимостях php/расширений PHP. PHP изначально не предназначен для работы в многопоточном режиме. Сам PHP ещё может и потокобезопасен, но вот как быть с сотней расширений, которые используют сторонние C библиотеки, которые хрен знает, как работают в многопоточном режиме, непонятно.

    Хотя сейчас,может всё несколько лучше. Но раз разработчики PHP не рекомендуют использовать php в многопоточном режиме, то я предпочитаю им поверить и не использовать.

    Что за встроенный сервер?

    Не слушай анонимуса, он неадекватен. Это сервер для разработки, а не продакшена (также как simpleHttp в python).

    Ставь просто nginx/php5/php-fpm из стандартных репозиториев. Не прогадаешь.

    Я не вижу смысла ставить nginx. Если честно, то и опыта работы с ним нет. Не понимаю зачем он нужен для сайта-визитки.

    Апач не рекомендуете?

    если на сайт зашло 100 человек, они работают в однопотоке

    Что значит «зашло»? Для http начхать сколько там зашло, важно сколько они генерируют одновременных запросов. Грубо говоря 100 запросов обрабатываются в 100 однопоточных процессах, если ты про апач. В nginx они просто мултиплексируются в одном процессе.

    Это вообще реально, удобно и быстро?

    А в линуксе как-то по другому работают потоку?

    Да что ж ты такой упоротый, я тебе уже 2 раза сказал, что в винде апач и другие http-серверы работают в многопотоке, потому что там нет другого варианта, т.к. спаун другого процесса там дорогая и медленная операция. А в линуксе fork дочернего процесса относительно простой и быстрый и кроме того, до того как запилили потоки, это был единственный вариант. Поэтому в линуксе обычно не используется многопоток.

    Я не понимаю почему в ПХП так их вынесли как нечто магическое

    Да потому и вынесли, что это пляска с бубном, но необходимая, чтобы заводить пых в апаче на винде, а в реальности это нахрен никому не надо.

    объясните на пальцах чем та или так хороша

    threadsafe ничем не хороша, она просто нужна в апаче на винде и других вариантах, когда пых запускается в многопоточном сервере (т.е. опять же в основном на винде). Причём именно внутри, как с mod_php. Если запускать через fcgi, то threadsafe и на винде не нужен.

    я тебе уже 2 раза сказал

    Повторение — мать (перемать ) учения 🙂

    Изучу глубже отличие организации процессов в линуксе и винде, может пригодится для других случаев в программировании кроме ПХП.

    Если честно, раньше был уверен что многопоточность это аппаратная фишка процессоров (i386 protected mode). но наверное перед настройкой дескрипторов и отдачей процу на «жевание» процесса, какие-то есть нюансы например при выделении памяти.

    Я уже сталкивался, что в виндовсе и линуксе, как-то по разному организована работа с кучей (heap), например при настройке того же postgresql.

    php thread safe vs non

    Подскажите в чём прелесть и недостаток каждого из вариантов?

    Thread Safety means that binary can work in a multithreaded webserver context, such as Apache 2 on Windows. Thread Safety works by creating a local storage copy in each thread, so that the data won’t collide with another thread.

    Читать еще:  Веб приложение на php

    So what do I choose? If you choose to run PHP as a CGI binary, then you won’t need thread safety, because the binary is invoked at each request. For multithreaded webservers, such as IIS5 and IIS6, you should use the threaded version of PHP.

    Вот как бы в чём вопрос. Везде упоминают Windows для Thread Safety.

    А что под линуксом например всё равно, что использовать с ПХП?

    Или во фразе: Thread Safety means that binary can work in a multithreaded webserver context, such as Apache 2 on Windows. Вместо «Windows» можно подставить другую операционку?

    под линуксом, на сколько я могу судить, всё равно.

    Я ещё забыл упомянуть, что есть некоторые расширения, которые требуют Thread-safe сборку (например, pthreads), но их немного и я не слышал, чтобы их кто-то реально использовал.

    Вместо «Windows» можно подставить другую операционку?

    Да и нет. Дело в том, что апач под linux обычно работает в виде отдельных процессов, а не многопоточно, и это общая практика в unix-системах, классика, а «such as Apache 2 on Windows» это именно особый случай, когда апач работает только многопоточно, такова специфика оффтопика, поэтому они его в пример и приводят. Но в принципе, можно и в linux запускать апач в многопоточном режиме.

    Я может чего-то подзабыл. чем отличаются потоки от процессов на программном уровне? И как каждый из них переводится на английский? 🙂

    Наверное имеется ввиду что мултипоточность — это когда каждый работает в своей виртуальной памяти и не имеет никакого доступа к другому (даже не знает о нем) за счет аппаратного i386 режима.

    Тогда не понятно какое имеет отношение к этому сам аппач. Хотя наверное я переставил местами потоки и процессы.

    Тоесть если использовать thread safe, то в любом случае будет ок? Или как?

    чем отличаются потоки от процессов на программном уровне

    Тем что потоки работают в одном и том же адресном пространстве, а процессы — каждый в своём

    Тогда не понятно какое имеет отношение к этому сам аппач

    Тем что при множестве процессов, в рамках одного процесса программа однопоточна, пых запускается однопоточно и о других процессах ничего не знает, а threadsafe не нужен.

    Я выше писал тоже самое и даже упоминал i386 protected mode (аппаратный режим разраничения адресных простарнств).

    И да. как и Вы ошибся, потоки (threads), какраз таки в одном постранстве копошатся, а процессы (processes) — это вроде и есть уже разделённые аппаратно процессы.

    В виндовсе вроде как сервисы называются, а в линуксе — демоны.

    интресено что для проца вобщем всё равно, они адресуются одними и теми же дескрипторами и обрабатываются теми же аппаратными прерываниями, просто есть основной процесс который делает теже потоки и контролирует их, а если делаешь просто сервисы (демоны) — то ими рулит как основной процесс ядро операционки.

    вопрос вобщем остался таковым. Универсалный ли вариант, если использовать thread safe вариант ПХП?

    как и Вы ошибся

    Что значит как и я? Я тебе как раз правильно рассказал.

    есть основной процесс который делает теже потоки и контролирует их

    Не основной, а единственный. Все потоки работают в рамках одного процесса. Ими никто не рулит, они сами между собой договариваются, в этом и заключается смысл threadsafe.

    Универсалный ли вариант, если использовать thread safe вариант ПХП?

    threadsafe не бесплатно. Это медленнее чем простой однопоток, т.к. требует дополнительных телодвижений по синхронизации потоков. С другой стороны, сама организация работы сервера в виде отдельных процессов может оказаться медленнее, чем один многопоточный процесс. А может и не оказаться, но если таки говорить о пыхе, то я так понимаю, что threadsafe там запилен конкретно под специфику работы http-серверов в винде.

    Я не совем тогда понимаю, если на сайт зашло 100 человек, они работают в однопотоке? Это вообще реально, удобно и быстро?

    threadsafe там запилен конкретно под специфику работы http-серверов в винде

    А в линуксе как-то по другому работают потоку? Не понимаю?

    нет, просто вместо того чтобы заморачивать себе этим голову, сейчас популярное решение переключиться на связку nginx php fastcgi

    Я просто думаю сделать простой сайт визитку.

    Мне например вполне хватит Жумлы на ПХП и Апач.

    Для ресурсоёмких проектов использую энтерпрайз решения на Жабе.

    Глупо поднимать завод по производству урана, если нужна всего лишь распилисть пару досок.

    Вот ещё из документации комментарий, не рекомендующий thread safe на продакшн

    Моё мнение такое, что если ты не можешь обосновать, зачем тебе включать thread safe, то и делать этого не нужно. В тех же репозиториях убунты лежит non thread safe, которую все поголовно используют и с Apache2 и с nginx. А кейс, когда нужна thread safe версия, надо ещё сперва придумать, сам по себе он внезапно не возникнет.

    Мне например вполне хватит Жумлы на ПХП и Апач.

    Ну тем более. На тех же шаред хостингах с апачем везде thread safe выключен. И thread safe ты как собрался ставить? Вручную php собирать с экзотическими настройками ради джумлы?

    жирновато как то хочешь визитку, а спрашиваешь про трэды

    Я про треды не спрашиваю, я про них знаю.

    Я не понимаю почему в ПХП так их вынесли как нечто магическое.

    Именно и спрашивал в чём плюшки и глюки каждого из вариантов ПХП.

    Никто ничего дельного не ответил, зачем именно 2 версии с примерами применения (ну про ЦГИ я почти понял).

    Меня интересует именно под апачем как веб применение.

    А что жирноватого для визитки из небольшого блога со статьями?

    И thread safe ты как собрался ставить? Вручную php собирать с экзотическими настройками ради джумлы?

    Вот и расскажите мне нюансы что там не так или тут не эдак.

    Я для этого и затеял вопрос?

    И причём тут руками сборка для жумлы?

    На сайте ПХП есть и та и та версия (уже собранные)

    объясните на пальцах чем та или так хороша (плоха) в ве применении на апач.

    Апач устаревает, хочешь простоты: почему бы тогда не задействовать встроенный сервер?

    Программирование по простому в пыхе выливается в такой быдлокод, что с этим сможет справиться не тривиальные технологии и подходы .

    Может тебе нужно немножко продолжительного рантайма?

    Я не собираюсь кодить в ПЫХе

    Я собираюсь использовать Joomla

    Там есть всё что мне нужно для сайта-визитки и даже больше.

    Что за встроенный сервер?

    проблема с многопоточностью в php в том, что она есть, но лучше ей не пользоваться. Проблема в исходниках и зависимостях php/расширений PHP. PHP изначально не предназначен для работы в многопоточном режиме. Сам PHP ещё может и потокобезопасен, но вот как быть с сотней расширений, которые используют сторонние C библиотеки, которые хрен знает, как работают в многопоточном режиме, непонятно.

    Хотя сейчас,может всё несколько лучше. Но раз разработчики PHP не рекомендуют использовать php в многопоточном режиме, то я предпочитаю им поверить и не использовать.

    Что за встроенный сервер?

    Не слушай анонимуса, он неадекватен. Это сервер для разработки, а не продакшена (также как simpleHttp в python).

    Ставь просто nginx/php5/php-fpm из стандартных репозиториев. Не прогадаешь.

    Я не вижу смысла ставить nginx. Если честно, то и опыта работы с ним нет. Не понимаю зачем он нужен для сайта-визитки.

    Апач не рекомендуете?

    если на сайт зашло 100 человек, они работают в однопотоке

    Что значит «зашло»? Для http начхать сколько там зашло, важно сколько они генерируют одновременных запросов. Грубо говоря 100 запросов обрабатываются в 100 однопоточных процессах, если ты про апач. В nginx они просто мултиплексируются в одном процессе.

    Это вообще реально, удобно и быстро?

    А в линуксе как-то по другому работают потоку?

    Да что ж ты такой упоротый, я тебе уже 2 раза сказал, что в винде апач и другие http-серверы работают в многопотоке, потому что там нет другого варианта, т.к. спаун другого процесса там дорогая и медленная операция. А в линуксе fork дочернего процесса относительно простой и быстрый и кроме того, до того как запилили потоки, это был единственный вариант. Поэтому в линуксе обычно не используется многопоток.

    Я не понимаю почему в ПХП так их вынесли как нечто магическое

    Да потому и вынесли, что это пляска с бубном, но необходимая, чтобы заводить пых в апаче на винде, а в реальности это нахрен никому не надо.

    объясните на пальцах чем та или так хороша

    threadsafe ничем не хороша, она просто нужна в апаче на винде и других вариантах, когда пых запускается в многопоточном сервере (т.е. опять же в основном на винде). Причём именно внутри, как с mod_php. Если запускать через fcgi, то threadsafe и на винде не нужен.

    я тебе уже 2 раза сказал

    Повторение — мать (перемать ) учения 🙂

    Изучу глубже отличие организации процессов в линуксе и винде, может пригодится для других случаев в программировании кроме ПХП.

    Если честно, раньше был уверен что многопоточность это аппаратная фишка процессоров (i386 protected mode). но наверное перед настройкой дескрипторов и отдачей процу на «жевание» процесса, какие-то есть нюансы например при выделении памяти.

    Я уже сталкивался, что в виндовсе и линуксе, как-то по разному организована работа с кучей (heap), например при настройке того же postgresql.

    Ссылка на основную публикацию
    Adblock
    detector