wpbloger: > А как насчет не долгих блокировок, чтение/запись в бд в основном происходят за 50-100 мл секунд, но даже вроде в этом случае это должно дать положительный эффект нет?
В общем случае нет:
1) если смотреть на конкретный запрос, то оба и синхронный и асинхронный вариант завершаться за одинаковое время (50-100 мс), т.е. зависит от БД.
2) Если смотреть под нагрузкой, много параллельных запросов, то асинхронный код будет проигрывать, если кол-во поток достаточно в много-поточной версии.
Например если рассмотреть конкретный запрос в БД на 50мс, если БД сможет потянуть в 10 потоков этот запрос, то она выдаст 200 rps и съест весь проц. в итоге на остатки ресурсов процессора веб сервер выдаст результат, итого будет не более 200 rps.
Если это не БД, а легкий запрос, или БД находится не на текущем хосте, тогда можно прикинуть так:
нужно выжать 5к rps, задержка 50мс, значит один поток 1000/50 = 20 rps, для 5k нужно 250 потоков.
Итого при 250 потоках, многопоточное приложение выиграет у асинхронного, т.к. асинхронному нужно тратить часть ресурсов на обслуживание самой асинхронщины и переключение задач, когда в многопоточном это делает ОС и проц максимально быстро.
Кстати (в питоне) 250 потоков могут съесть всего 7-20Мб памяти (зависит от приложения).
Дмитрий: В какой-то забегаловке сняли по курсу: 63.285 , на данный момент форекс курс: 65.24, масткркард: 64.95, (локальный банк) сбербанк: 63.32
итого: если локальный банк посчитал по своему курсу, то возможно оно вышло без процентов (зависит на сколько плохой курс перевода), если перевод по мастеркард то ~2.6%, хотя я склоняюсь к 1-му варианту (наши не упустят шанс наварить)
а если выводить деньгами, то будет тот же не выгодный курс, и ещё 2% комиссии снимут.
Дмитрий: это возможно просто на курсе обмена дерут местные банки, я несколько лет назад проверял, потери были по минимуму, надо ещё раз сравнить, вдруг что изменилось...
Sergey Yamskoy: проверьте что весь индекс в памяти, судя по времени, он с диска индекс читает.
Индекс может занять 2-8Гб, если у вас 2 индекса в таблице - умножайте на 2.
Так же ещё можете попробовать hash индекс с доступом О(1), в посгресе он есть.
Если повозится, можно сделать хеш таблицу на основе 5байт ключей (на паспорт хватит), 600 - 800Мб.
sasha: это и то если нужна какая-то доп. инфа, а судя по задаче вообще нужно только знать входит в список или нет, тут и таблицы не нужно, индекса достаточно.
sim3x: primary key как раз уникален по дефолту, его как раз тут и надо юзать, что-б лишние индекссы не плодить, а топик стартер похоже вообще индексы не юзает.
+ не понятно зачем ему посгрес для этой задачи.
+ индекс лучше хешмап юзать вместо дерева для этой задачи
Павел Горбунов:
al-app="main" запускает метод main
al-class="red-text: alert && !name" - добавляет класс red-text при условии alert && !name
al-value="name" - синхронизация переменной name и значения контрола
:hidden="!(alert && !name)" - скрывает элемент при условии
@submit="send()" - вызывает функцию send на сабмит
все переменные находятся в scope и доступны в ф-ии main, туда ещё можно логики добавить.
так можно отправить сам сабмит если все ок: jsfiddle.net/lega911/njfq16w7
В общем случае нет:
1) если смотреть на конкретный запрос, то оба и синхронный и асинхронный вариант завершаться за одинаковое время (50-100 мс), т.е. зависит от БД.
2) Если смотреть под нагрузкой, много параллельных запросов, то асинхронный код будет проигрывать, если кол-во поток достаточно в много-поточной версии.
Например если рассмотреть конкретный запрос в БД на 50мс, если БД сможет потянуть в 10 потоков этот запрос, то она выдаст 200 rps и съест весь проц. в итоге на остатки ресурсов процессора веб сервер выдаст результат, итого будет не более 200 rps.
Если это не БД, а легкий запрос, или БД находится не на текущем хосте, тогда можно прикинуть так:
нужно выжать 5к rps, задержка 50мс, значит один поток 1000/50 = 20 rps, для 5k нужно 250 потоков.
Итого при 250 потоках, многопоточное приложение выиграет у асинхронного, т.к. асинхронному нужно тратить часть ресурсов на обслуживание самой асинхронщины и переключение задач, когда в многопоточном это делает ОС и проц максимально быстро.
Кстати (в питоне) 250 потоков могут съесть всего 7-20Мб памяти (зависит от приложения).
Гляньте этот тред: https://habrahabr.ru/post/282972/#comment_8881620
Расход на асинхронщину составил 80-90%, итого async.io выдал 1000 rps, а блокирующее на uwsgi 7000 rps
Ещё сам авторы tornado-web (асинхронный фреймворк) использовали блокирующий вызов в БД, утверждая что особо профита от асинхоронного нет.