Это очень интересно. Не могли бы вы показать эти графики? А если в составе какой-то статьи, где эти графики объясняются — так вообще прекрасно. Мне вот удалось быстро найти http://www.1manteam.com/index.php/2011/01/facebooks-developer-love-initiative-3-months-later/ — что больше похоже на выводы обычной теории надёжности, чем на ваши утверждения.
ПО подвержено износу, только в качестве износа выступает усложнение и изменения этого ПО с течением времени. Кроме того, количество ошибок определяется не только износом, иначе бы в нулевой момент времени оно было бы нулём.
Модификатор e приводит к ошибке уровня E_DEPRECATED начиная с PHP 5.5.0. Во-первых, не сказать, что это очень давно. Во-вторых, по-умолчанию E_DEPRECATED отключены, так что я бы не сказал, что прям подавляли, но да, какое-то время просто не уделяли этому внимания.
Что касается конструкторов — вы ничего не путаете? Они не приводят к ошибкам. Единственная особенность — начиная с 5.3.3 у классов внутри неймспейса конструктор должен называться __construct, иначе он просто не будет вызван при создании объекта.
И да, и нет. На самом деле, в разных кластерах разные схемы балансировки нагрузки, и в одной из схем есть небольшое количество nginx на одних машинах, и большое количетво php-fpm на других. Собственно, это ответ на вопрос, почему AF_INET.
Вам не понравилось, что там не указано Error? На мой взгляд нет смысла заниматься копированием документации и migration guide, статья немного о другом.
При чём здесь исключения? При чём здесь C++? Ни при каких обстоятельствах ошибка сегментирования в PHP не может являться фичей, как бы там ни было в плюсах.
Почитайте чейнджлог пятой версии http://php.net/ChangeLog-5.php. Релиз состоялся 13 июля 2004 года, а в версиях от 3 марта 2016 года до сих пор фиксят баги. Я вам гарантирую, обнаруженный вами баг — не последний. Подождите хотя бы PHP 28.0, а лучше 29.0.
1 — Это вопрос архитектуры. Да, есть сервера очередей. Да, с их помощью тоже можно решать описанную проблему. Но это уже просто другой подход. Кроме того, сам сервер очередей так же может упасть, его так же может потребоваться перезапустить.
2 — Если сервер очередей один на все экземпляры демона — то это, во-первых, SPoF, а, во-вторых, это означает, что он находится на каком-то отдельном сервере, что увеличивает сетевые издержки. Если серверов очередей несколько — это ставит вопрос о балансировке нагрузки между ними и обеспечении отказоустойчивости при падении нескольких из них. То есть это ещё один слой архитектуры, который нужно настраивать и поддерживать.
3 — Касательно готовых решений для перезапуска упавших демонов — да, они есть. Но в данной статье не рассматривается проблема автоматизации перезапуска демона. Рассматривается проблема сохранения открытых соединений. Кроме того, перезапускать демон нужно не обязательно тогда, когда он падает. Например, его надо перезапускать при обновлении его версии(кода), что может случаться несколько раз в день.
RabbitMQ — это новая сущность, которую нужно устанавливать, настраивать и поддерживать. MySQL у нас уже есть, мы умеем его готовить. Как мы писали, миграция фотографий — это одна из частей всей миграции пользователей. То есть в базе хранится много других данных, которые хочется обрабатывать транзакционно. Вынеся часть данных в RabbitMQ мы такую возможность потеряем. Что касается скорости — нас вполне устроили полученные результаты, и если говорить именно о задаче миграции фотографий, то здесь MySQL не являлся узким местом.
В таблице, отвечающей за генерацию sequence_id, первичным ключём является (`sequence_id`,`class_id`,`user_id`), причём sequence_id — это автоинкремент. Соответственно, для генерации нового sequence_id нужно просто сделать INSERT INTO… (user_id,class_id) VALUES (123, 256). class_id — это, можно сказать, тип сиквенса.
Рабочий день — это 8 часов плюс перерыв на обед. В статье исходя из этого была приведена примерная скорость — 170 000 пользователей в час. Где вы видите несоответствие?
Не совсем понимаю вас. Мы переносили по примерно одному миллиону пользователей в день (в это время у этих пользователей была ночь). Каждый из переносимых пользователей в течении 2-3 минут при попытке логина наблюдал надпись «Сервис недоступен».
ПО подвержено износу, только в качестве износа выступает усложнение и изменения этого ПО с течением времени. Кроме того, количество ошибок определяется не только износом, иначе бы в нулевой момент времени оно было бы нулём.
Что касается конструкторов — вы ничего не путаете? Они не приводят к ошибкам. Единственная особенность — начиная с 5.3.3 у классов внутри неймспейса конструктор должен называться __construct, иначе он просто не будет вызван при создании объекта.
Что касается утверждения "Вероятность появления бага в продукте, только недавно вышедшем на рынок гораздо больше, чем в продукте, которые работает уже несколько лет" — оно неверно, начать получать ответ на вопрос "почему" можно с чтения https://ru.wikipedia.org/wiki/%D0%98%D0%BD%D1%82%D0%B5%D0%BD%D1%81%D0%B8%D0%B2%D0%BD%D0%BE%D1%81%D1%82%D1%8C_%D0%BE%D1%82%D0%BA%D0%B0%D0%B7%D0%BE%D0%B2.
Вам не понравилось, что там не указано Error? На мой взгляд нет смысла заниматься копированием документации и migration guide, статья немного о другом.
2 — Если сервер очередей один на все экземпляры демона — то это, во-первых, SPoF, а, во-вторых, это означает, что он находится на каком-то отдельном сервере, что увеличивает сетевые издержки. Если серверов очередей несколько — это ставит вопрос о балансировке нагрузки между ними и обеспечении отказоустойчивости при падении нескольких из них. То есть это ещё один слой архитектуры, который нужно настраивать и поддерживать.
3 — Касательно готовых решений для перезапуска упавших демонов — да, они есть. Но в данной статье не рассматривается проблема автоматизации перезапуска демона. Рассматривается проблема сохранения открытых соединений. Кроме того, перезапускать демон нужно не обязательно тогда, когда он падает. Например, его надо перезапускать при обновлении его версии(кода), что может случаться несколько раз в день.