что значит https самостоятельно? в go в стандартной библиотеке есть реализация tls.
вот slowloris написанный на go для nginx github.com/valyala/goloris
веб сервер на go дает ~ 20000-25000 rps на ядро, это примерно на 20-30% медленее nginx на тойже машине в задаче отдачи статических файлов
подводя итог ваши аргументы достаточно странные как и рекомендации.
если не нужен reverse-proxy то смысла его использовать нет — получится двойной парсинг запроса, ещё больше занятых сокетов и т.п, что в итоге даст меньшую производительность.
читается и правда тяжело, что-то такое «Как мы делали лучший трекер замечаний к релизам программных продуктов» или написать release-notes проще читалось бы
> Использование базы данных как очереди задач.
а что в этом плохого? в конечном итоге standalone решение тоже должно использовать БД для хранения задач иначе они могут потеряться
> Переизобретение дискового буфера вместо использования возможностей операционки.
посмотреть в памяти процесса или shared-memory группы процессов много быстрее, чем запрашивать теже данные у операционки даже если они лежат в буферах
про Go
~30% времени тратится на аллокации строк в цикле
также используйте sha1.Sum([]byte(text)) это будет быстрее:
mas := sha1.Sum([]byte(text))
return int64(mas[len(mas)-1]) % 8
также если вы не используете в коде горутины то GOMAXPROCS на вашем коде никак не скажется
ну и тесты производительности в Go принято делать через bench (http://dave.cheney.net/2013/06/30/how-to-write-benchmarks-in-go)
про реализацию на Go — github.com/golang/go/tree/master/src/crypto/sha1, файлики *.s это ассемблеры
в Go в этом тесте тоже процентов 30 времени как раз на аллокацию и конкатенацию строк тратится
чтобы говорить, что код быстрее нужно сравнивать одинаковые вещи,
об первой вещи собственно по вашей ссылке и написано go работает с unicode
а вторая, что время для go включает ещё и компиляцию: github.com/dimroc/etl-language-comparison/blob/master/run_go
> Потому что EM — это типичный God Object
за счет чего? что он используется везде? драйвер подключения к бд это тоже God Object?
> собой спагетти из анотаций
пишите в конфиге, какие проблемы? аннотации удобны на самом деле
> ограниченные IM и UoW
IM кстати часть UoW (просто массив), uow содержит тот срез данных с которыми вы работаете, там лежат оригинальные данные выбранные из базы, на основе которых doctrine делает частичные обновления только изменений. IM используется в том числе для того чтобы правильно делать связи, не вы создаете объекты из SQL ответов, а ORM иначе она бы потеряла смысл.
и чем они ограничены?
> не гарантируют атомарность и целостность данных
если у вас есть параллельный запрос который удаляет данные дело тут не в ORM, вам нужно самому обеспокоится тем как разруливать это. а атомарность и целостность в конечном итоге гарантирует только субд
Зачем пытаться всунуть id в orm когда вы можете просто сделать sql запрос?
Что это за пример ухода от оверхеда за счет экономии на создании объекта, когда вы всеравно продолжаете вызывать весь код, который генерирует события (persist, update remove и т.п.), считает changeSet и прочее? да можно 100 объектов инстанцировать и вы всеравно не заметите разницы по сравнению с ним.
getReference как раз про это, чтобы все сделать в терминах ORM не подгружая саму сущность из базы.
и дело не в best practies, это просто логика. и это справедливо для всей симфони и доктрины.
Доктрина к слову не частность симфони
ну об этом в доке написано сразу: php.net/manual/en/language.operators.increment.php это можно объяснить, даже некую логику под это подвести (но я согласен, что это не ожидаемо)
но почему 2 строки сравниваются как числа нет
а откуда у вас при использовании ORM взялся id?
если из вне то все равно идти в базу и проверять есть он там или нет.
+ мой вариант не ломает пользователя для других частей кода, то есть куда бы я его не передал это будет пользователь с объектом группы, с которым можно работать, а не так что у него группа админы, а вы ему ставите пользователя, но пока не сохраните в БД, все равно будет админ.
В общем если используете ORM то используйте, нет, пишите
$conn->executeQuery(«UPDATE users SET group_id = 5 where id = ?», [$user->getId()])
так хоть будет видно в какой момент у вас пошел рассихрон объекта и базы и поведение будет более предсказуемо
вот slowloris написанный на go для nginx github.com/valyala/goloris
веб сервер на go дает ~ 20000-25000 rps на ядро, это примерно на 20-30% медленее nginx на тойже машине в задаче отдачи статических файлов
подводя итог ваши аргументы достаточно странные как и рекомендации.
если не нужен reverse-proxy то смысла его использовать нет — получится двойной парсинг запроса, ещё больше занятых сокетов и т.п, что в итоге даст меньшую производительность.
а что в этом плохого? в конечном итоге standalone решение тоже должно использовать БД для хранения задач иначе они могут потеряться
> Переизобретение дискового буфера вместо использования возможностей операционки.
посмотреть в памяти процесса или shared-memory группы процессов много быстрее, чем запрашивать теже данные у операционки даже если они лежат в буферах
0.73778009414673
node1: 1118402612
node2: 772230494
использование sha1.Sum (без пре аллокации)
node1: 837969082
node2: 485179839
пре-аллоцированные данные
node1: 738665390
node2: 478114103
пре-аллокация и sha1.Sum:
node1: 545527947
node2: 286142563
~30% времени тратится на аллокации строк в цикле
также используйте sha1.Sum([]byte(text)) это будет быстрее:
mas := sha1.Sum([]byte(text))
return int64(mas[len(mas)-1]) % 8
также если вы не используете в коде горутины то GOMAXPROCS на вашем коде никак не скажется
ну и тесты производительности в Go принято делать через bench (http://dave.cheney.net/2013/06/30/how-to-write-benchmarks-in-go)
в Go в этом тесте тоже процентов 30 времени как раз на аллокацию и конкатенацию строк тратится
об первой вещи собственно по вашей ссылке и написано go работает с unicode
а вторая, что время для go включает ещё и компиляцию: github.com/dimroc/etl-language-comparison/blob/master/run_go
за счет чего? что он используется везде? драйвер подключения к бд это тоже God Object?
> собой спагетти из анотаций
пишите в конфиге, какие проблемы? аннотации удобны на самом деле
> ограниченные IM и UoW
IM кстати часть UoW (просто массив), uow содержит тот срез данных с которыми вы работаете, там лежат оригинальные данные выбранные из базы, на основе которых doctrine делает частичные обновления только изменений. IM используется в том числе для того чтобы правильно делать связи, не вы создаете объекты из SQL ответов, а ORM иначе она бы потеряла смысл.
и чем они ограничены?
> не гарантируют атомарность и целостность данных
если у вас есть параллельный запрос который удаляет данные дело тут не в ORM, вам нужно самому обеспокоится тем как разруливать это. а атомарность и целостность в конечном итоге гарантирует только субд
Что это за пример ухода от оверхеда за счет экономии на создании объекта, когда вы всеравно продолжаете вызывать весь код, который генерирует события (persist, update remove и т.п.), считает changeSet и прочее? да можно 100 объектов инстанцировать и вы всеравно не заметите разницы по сравнению с ним.
getReference как раз про это, чтобы все сделать в терминах ORM не подгружая саму сущность из базы.
и дело не в best practies, это просто логика. и это справедливо для всей симфони и доктрины.
Доктрина к слову не частность симфони
но почему 2 строки сравниваются как числа нет
если из вне то все равно идти в базу и проверять есть он там или нет.
+ мой вариант не ломает пользователя для других частей кода, то есть куда бы я его не передал это будет пользователь с объектом группы, с которым можно работать, а не так что у него группа админы, а вы ему ставите пользователя, но пока не сохраните в БД, все равно будет админ.
В общем если используете ORM то используйте, нет, пишите
$conn->executeQuery(«UPDATE users SET group_id = 5 where id = ?», [$user->getId()])
так хоть будет видно в какой момент у вас пошел рассихрон объекта и базы и поведение будет более предсказуемо