Например, за написание статей у нас есть очень неплохой бонус.
А меня вот этот пункт интересует :)
Можете поделиться, как подбирается бонус за статью?
Есть какие-то оговоренные ставки? Это какой-то процент от ЗП или сумма зависит от размера статьи?
Кто занимается ревью статей перед публикацией и есть ли копирайтер?
Бывает ли такое, что статьи отклоняются по той или иной причине?
Спасибо!
Да, метод рабочий.
Но есть у него минус. Т.к. proxy_pass работает вне блока upstream, а «напрямую», то нет keepalive соединения, а значит на каждый запрос создается новое TCP соединение, что при высокой нагрузке может добавить лишнего времени.
Производительность приложения (кассира) выражается не в размере буффера (очереди), а в скорости обработки объектов из этой очереди. Если вы второй в очереди, то у вас есть время выложить продукты на ленту. Если же 15-й, то система явно перегружена и ни о какой производительности речи быть не может, но тогда и размер буффера вас не спасет т.к. если он будет заполняться быстрее работы кассира, то очереди придется вырасти за пределы магазина, а это out of memory.
Очень хороший вопрос, который заставил меня перечитать диаграмму TCP состояний в Linux.
В одной из статей по оптимизации я прочел об этом методе, но фактически соединение будет в состоянии SYN_RECV и после того, как ядро обработает его и отправит SYN+ACK в обратную сторону, поэтому этот метод не подходит для определения загруженности очереди netdev_max_backlog.
Я внесу в статью правки согласно вашему коментарию, благодарю.
Честно признаться, перечитал свою статью на всякий случай, но отверждения «чем больше буффер, тем лучше» я не нашел. Истина, как всегда, где-то посередине.
Что для вас является проблемой?
В моем случае увеличение нескольких буфферов повысило производительность (эффективность) сервера, решило проблемы с ростом задержек (за счет избавления от пересылки сброшеных пакетов) в момент резкого роста нагрузки.
Значит ли это, что я создал проблему за счет буферов или все-таки решил ее? В моем случае проблем стало меньше, а работа стабильнее.
Cobra (не питон это)
Go
Grafana
JS
Java (кружка у официанта)
Kotlin
Lua
PHP
Ruby
RxJava (чудо змей в воде)
Swift
Postman
Sphinx
Tornado
Linux/Debian
Haproxy (пакет полицейского)
NSQ
RabbitMQ
GraphQL (дерется с json)
JSON
GitHub
Kibana
Sentry
TeamCity
Docker
Swarm
Helm
Istio
Kubernetes
TensorFlow
AioHTTP
Babel
ESLint
React
Selenium
WebPack
CouchDB (в здании на первом этаже стоит диван)?
ClickHouse
Graphite
Hashicorp Vault
MongoDB (выглядывает из-за угла)
MySQL
PostgreSQL
Prometheus
Redis
Vertica
Да, вы правы.
Здесь больше была проблема в том, что бы устройство, к которому был подключен модем, смогло преодолеть сопротивление этого кабеля и запитать модем.
Да, тот самый рефлектор.
Так как мой бюджет изначально был ограничен, а эта антенна уже была, я решил проверить, чего можно достичь с уже имеющимися деталями.
В целом, согласен с вами: для более уверенных результатов необходимы более уверенные решения, например, антенна, которой вы воспользовались.
А меня вот этот пункт интересует :)
Можете поделиться, как подбирается бонус за статью?
Есть какие-то оговоренные ставки? Это какой-то процент от ЗП или сумма зависит от размера статьи?
Кто занимается ревью статей перед публикацией и есть ли копирайтер?
Бывает ли такое, что статьи отклоняются по той или иной причине?
Спасибо!
Но есть у него минус. Т.к. proxy_pass работает вне блока upstream, а «напрямую», то нет keepalive соединения, а значит на каждый запрос создается новое TCP соединение, что при высокой нагрузке может добавить лишнего времени.
В одной из статей по оптимизации я прочел об этом методе, но фактически соединение будет в состоянии SYN_RECV и после того, как ядро обработает его и отправит SYN+ACK в обратную сторону, поэтому этот метод не подходит для определения загруженности очереди netdev_max_backlog.
Я внесу в статью правки согласно вашему коментарию, благодарю.
Что для вас является проблемой?
В моем случае увеличение нескольких буфферов повысило производительность (эффективность) сервера, решило проблемы с ростом задержек (за счет избавления от пересылки сброшеных пакетов) в момент резкого роста нагрузки.
Значит ли это, что я создал проблему за счет буферов или все-таки решил ее? В моем случае проблем стало меньше, а работа стабильнее.
Можете привести пример?
#resolve
Go
Grafana
JS
Java (кружка у официанта)
Kotlin
Lua
PHP
Ruby
RxJava (чудо змей в воде)
Swift
Postman
Sphinx
Tornado
Linux/Debian
Haproxy (пакет полицейского)
NSQ
RabbitMQ
GraphQL (дерется с json)
JSON
GitHub
Kibana
Sentry
TeamCity
Docker
Swarm
Helm
Istio
Kubernetes
TensorFlow
AioHTTP
Babel
ESLint
React
Selenium
WebPack
CouchDB (в здании на первом этаже стоит диван)?
ClickHouse
Graphite
Hashicorp Vault
MongoDB (выглядывает из-за угла)
MySQL
PostgreSQL
Prometheus
Redis
Vertica
Android SDK
XCode
Здесь больше была проблема в том, что бы устройство, к которому был подключен модем, смогло преодолеть сопротивление этого кабеля и запитать модем.
Так как мой бюджет изначально был ограничен, а эта антенна уже была, я решил проверить, чего можно достичь с уже имеющимися деталями.
В целом, согласен с вами: для более уверенных результатов необходимы более уверенные решения, например, антенна, которой вы воспользовались.