When you're working with a remote interface, such as Remote Facade (388), each call to it is expensive. As a result you need to reduce the number of calls, and that means that you need to transfer more data with each call. One way to do this is to use lots of parameters. However, this is often awkward to program — indeed, it's often impossible with languages such as Java that return only a single value.
The solution is to create a Data Transfer Object that can hold all the data for the call. It needs to be serializable to go across the connection. Usually an assembler is used on the server side to transfer data between the DTO and any domain objects.
Как же любят старички вспоминать про KISS. Но принцип то не о том, что "делай как можно проще", а о том, что использовать и обслуживать механизмы должно быть просто. Сделал пуш, нажал кнопку - раскатилось, нажал другую - откатилось, вот KISS, и вся работа девопсов как раз про это. А то, что там под капотом кнопки десятки технологий - это именно то, что обеспечивает дальнейшую эксплутационную простоту.
DTO не для хранения, а для передачи данных. Это передача данных в конкретном контексте. Ничего криминального в инкапсуляции сериализации нет. Вообще можно начать с Фаулера.
Поведение != методы. Сериализация/десериализация - это не поведение объекта. Это по сути то, для чего вообще создается DTO - передать его по каналам связи.
DTO не содержит бизнес логики, а не "логики вообще". Сериализация/десереализация - эта логика, которая очень подходит для инкапсуляции ее в DTO, ибо вообще вся суть DTO изначально - быть сериализованной.
ZIP был весьма распространен в полиграфии для переноса ps файлов, да и просто макетов. Полиграфия и фотовывод (где делают пленки, с которых уже полиграфия делает формы) как правило были оборудованы ZIP, да и студии дизайна могли себе позволить. Это было намного приятнее, чем стопки дискеток, ибо размеры файлов были десятки мегабайт.
А если серьезно, просто другой подход работы с utf8 и вопрос вкуса и привычки какой удобнее - вводить разные типы строк для utf8 и bytes, или же все строки это bytes + разный набор функций.
Вот такое не хранимое в бд значение и называется солью.
У понятия "соль" при хранении паролей есть вполне устоявшийся смысл, и это не совсем то, что вы написали. В статье как раз верно раскрыт смысл "соли" при хранении паролей. Это удлинитель паролей, цель которого - защита от брутфорса пачки хешей или использования радужных таблиц. Для этих целей важна уникальность соли для каждого хеша, а вот задачи прятать соль от хеша нет. По-этому соль хранят рядом с хешом.
По большому счету прирост вы получили не из-за асинхронности и swoole, а из-за выбрасывания тяжелого бутстрапа. Заплатив за это ровно ту стоимость, скидку на которую дает "умирающий" пхп.
Ну и совсем немного экономии на переключении контекста процессора, если бы у вас было бы 70 однопоточных воркеров (например, с тем же роадранером, или какой-то свой менеджер соединений).
Вот, кстати, сравнение сравнимого - многозадачности на базе мультиплексирования vs процессы, было бы интересно.
Но при этом не раскрыта полостью тема сокращения времени бутстрапа более крассическими методами - кеш, прелоадинг, рекомендации Symfony. 120 ms намекает, что там еще большой простор.
Ну и все же L3 балансировку используют редко когда много трафика и то обычно между L7 балансировщиками. Ибо тривиально балансировать на L7 проще, а порой и эффективнее.
В предыдущем тесте как раз был nginx + fpm vs nginx + unit, и там вполне сопоставимые цифры были на пока не задрали конкурентность.
Шина используется внутри пхп приложения. А если вы каким-то образом придумали прослойку вычитывающую шину и делающую запросы в пхп (хз зачем), то можно и fastcgi запросы делать.
Но задачу балансировки при более одной ноды решать все равно придется промежуточным сервером. Мой коммент скорее был, что тест в статье меряет не fpm vs unit, а накладные расходы реверс прокси.
Тут стоит задать вопрос - будете ли вы nginx-unit сразу публиковать наружу в продакшн окружении? Или все же поставите nginx перед ним? А если поставите - то логично тестировать nginx + fpm vs nginx + nginx-unit
И опять же, тестовое не дает ответов на вопросы обучаймости, способности концентрироваться, способности работать в коллективе, разбираться в существующем коде. Т.е. оценка по испытательному нужна все-равно. Если процесс выстроен, то потеря компании - это ЗП за 3 месяца. Не взять кандидата для крупной компании - это могут быть потери побольше.
Конечно, все это верно при большом отделе разработки с постоянной нехваткой кадров. Если компания - пяток разработчиков, и неторопливо в поисках шестого (как раз как найдут - кто-то уйдет), тут совсем другие критерии.
Самое печальное, когда руководители с опытом в небольших компаниях не могут адаптироваться к новой компании с другими приоритетами и не меняют тактику отбора. А потом у всех, включая инвесторов, удивление - а где же люди, кто работать то будет?!
Ну я про эту статью https://martinfowler.com/bliki/LocalDTO.html
Экономия — ну тут я по сути цитирую P of EAA:
А DTO изначально задумывался для других целей, а именно для экономии дорогих внешних вызовов. То, о чем вы говорите — это по Фаулеру LocalDTO.
Как же любят старички вспоминать про KISS. Но принцип то не о том, что "делай как можно проще", а о том, что использовать и обслуживать механизмы должно быть просто. Сделал пуш, нажал кнопку - раскатилось, нажал другую - откатилось, вот KISS, и вся работа девопсов как раз про это. А то, что там под капотом кнопки десятки технологий - это именно то, что обеспечивает дальнейшую эксплутационную простоту.
DTO не для хранения, а для передачи данных. Это передача данных в конкретном контексте. Ничего криминального в инкапсуляции сериализации нет. Вообще можно начать с Фаулера.
Поведение != методы. Сериализация/десериализация - это не поведение объекта. Это по сути то, для чего вообще создается DTO - передать его по каналам связи.
DTO не содержит бизнес логики, а не "логики вообще". Сериализация/десереализация - эта логика, которая очень подходит для инкапсуляции ее в DTO, ибо вообще вся суть DTO изначально - быть сериализованной.
Именно это и делают плейсхолдеры, когда prepared statements поддерживаются на уровне базы
Интересно, т.е. любой пик сообщений выше запланированного приводит к отстрелу всех консьюмеров, ибо они переполняются и начинают тормозить?
ZIP был весьма распространен в полиграфии для переноса ps файлов, да и просто макетов. Полиграфия и фотовывод (где делают пленки, с которых уже полиграфия делает формы) как правило были оборудованы ZIP, да и студии дизайна могли себе позволить. Это было намного приятнее, чем стопки дискеток, ибо размеры файлов были десятки мегабайт.
Ну правды ради у них межбанк стоит фикс 9 рублей и лимит дефолтный 500к в месяц. Можете оставить как ЗП карту и перегонять по реквизитам.
А если серьезно, просто другой подход работы с utf8 и вопрос вкуса и привычки какой удобнее - вводить разные типы строк для utf8 и bytes, или же все строки это bytes + разный набор функций.
Да, давно, еще в PHP6 =)
У понятия "соль" при хранении паролей есть вполне устоявшийся смысл, и это не совсем то, что вы написали. В статье как раз верно раскрыт смысл "соли" при хранении паролей. Это удлинитель паролей, цель которого - защита от брутфорса пачки хешей или использования радужных таблиц. Для этих целей важна уникальность соли для каждого хеша, а вот задачи прятать соль от хеша нет. По-этому соль хранят рядом с хешом.
По большому счету прирост вы получили не из-за асинхронности и swoole, а из-за выбрасывания тяжелого бутстрапа. Заплатив за это ровно ту стоимость, скидку на которую дает "умирающий" пхп.
Ну и совсем немного экономии на переключении контекста процессора, если бы у вас было бы 70 однопоточных воркеров (например, с тем же роадранером, или какой-то свой менеджер соединений).
Вот, кстати, сравнение сравнимого - многозадачности на базе мультиплексирования vs процессы, было бы интересно.
Но при этом не раскрыта полостью тема сокращения времени бутстрапа более крассическими методами - кеш, прелоадинг, рекомендации Symfony. 120 ms намекает, что там еще большой простор.
Ну и все же L3 балансировку используют редко когда много трафика и то обычно между L7 балансировщиками. Ибо тривиально балансировать на L7 проще, а порой и эффективнее.
В предыдущем тесте как раз был nginx + fpm vs nginx + unit, и там вполне сопоставимые цифры были на пока не задрали конкурентность.
Шина используется внутри пхп приложения. А если вы каким-то образом придумали прослойку вычитывающую шину и делающую запросы в пхп (хз зачем), то можно и fastcgi запросы делать.
Но задачу балансировки при более одной ноды решать все равно придется промежуточным сервером. Мой коммент скорее был, что тест в статье меряет не fpm vs unit, а накладные расходы реверс прокси.
Тут стоит задать вопрос - будете ли вы nginx-unit сразу публиковать наружу в продакшн окружении? Или все же поставите nginx перед ним? А если поставите - то логично тестировать nginx + fpm vs nginx + nginx-unit
Как альтернатива, хотя где-то и более "многоклавишная", есть Find Action
И опять же, тестовое не дает ответов на вопросы обучаймости, способности концентрироваться, способности работать в коллективе, разбираться в существующем коде. Т.е. оценка по испытательному нужна все-равно. Если процесс выстроен, то потеря компании - это ЗП за 3 месяца. Не взять кандидата для крупной компании - это могут быть потери побольше.
Конечно, все это верно при большом отделе разработки с постоянной нехваткой кадров. Если компания - пяток разработчиков, и неторопливо в поисках шестого (как раз как найдут - кто-то уйдет), тут совсем другие критерии.
Самое печальное, когда руководители с опытом в небольших компаниях не могут адаптироваться к новой компании с другими приоритетами и не меняют тактику отбора. А потом у всех, включая инвесторов, удивление - а где же люди, кто работать то будет?!