Комментарии 12
НЛО прилетело и опубликовало эту надпись здесь
«Как мониторите производительность страниц/запросов/API?»
Старые добрые Pinba + Munin.
«Как деплоите?»
Magallanes + самописные скрипты.
Старые добрые Pinba + Munin.
«Как деплоите?»
Magallanes + самописные скрипты.
НЛО прилетело и опубликовало эту надпись здесь
Как пример:
Deploying to XXX:YYYY
Running Deploy via Rsync (with Releases) [built-in] ... OK
Running Symfony v2 - Cache Clear [built-in] ... OK
Deployment to XXX:YYYY completed: 2/2 tasks done.
Starting the Releasing
Releasing on host XXX:YYYY ... OK
Finished the Releasing
Starting Post-Release tasks for XXX:YYYY:
Running Reload nginx ... OK
Running Reload hhvm ... OK
Finished Post-Release tasks for XXX:YYYY: 2/2 tasks done.
>> скрипт-автоподниматель, который проверяет по крону,
это у вас че такой production? ни тебе zabbix agent, ни monit ни на худой конец systemd?
это у вас че такой production? ни тебе zabbix agent, ни monit ни на худой конец systemd?
Новый ext-mongodb драйвер из коробки должен работать с HHVM, так что можно отказаться от полифила
Неужели этот набор костылей — повод для гордости?
Это не хитрость, это здравый смысл.
Иными словами, базу данных мы выбрали случайным образом. Потом оказалось что она под наши требования не подходит, нафигачили костылей, чтоб меньше тормозило.
Чем же вам монга не угодила? Вы разве не слышали, «MongoDB is Web Scale» (сарказм)
Чуть за чушь? B-Tree индексы, которым сто лет в обед, прекрасно работают с range запросами. Меньше читайте «руководства», больше думайте головой.
Если б вы параметр подобрали не опытным путем, а исходя из каких-то метрик, это было бы интересно почитать. А у вас вот так: «методом тыка подставляли разные значения пока не попустило». Что вы через месяц будете делать, когда добавите новые фичи и характер нагрузки поменяется? Опять методом тыка конфиги править?
В общем, судя по описанию, то, что это убожество обслуживает миллион уников, заслуга не ваша, а производителей современного железа, которое позволяет даже набору костылей работать с приемлемой скоростью.
Поэтому для каждого компонента системы подгружаем только необходимый набор бандов (например, на фронтенде не нужны бандлы админки, а в API не нужны бандлы админки и фронтенда и т.д.).
Хитрость в том…
Это не хитрость, это здравый смысл.
Ранее с данной БД не работали, подкупила фраза «CouchDB предназначен именно для веба».
Иными словами, базу данных мы выбрали случайным образом. Потом оказалось что она под наши требования не подходит, нафигачили костылей, чтоб меньше тормозило.
Чем же вам монга не угодила? Вы разве не слышали, «MongoDB is Web Scale» (сарказм)
Практически все руководства о создании индексов для MongoDB утверждают, что, если в запросе используются операции выбора диапазона ($in, $gt или $lt), то для такого запроса индекс не будет использоваться ни при каких обстоятельствах
Чуть за чушь? B-Tree индексы, которым сто лет в обед, прекрасно работают с range запросами. Меньше читайте «руководства», больше думайте головой.
Опытным путём для нашей системы был подобран параметр...
Если б вы параметр подобрали не опытным путем, а исходя из каких-то метрик, это было бы интересно почитать. А у вас вот так: «методом тыка подставляли разные значения пока не попустило». Что вы через месяц будете делать, когда добавите новые фичи и характер нагрузки поменяется? Опять методом тыка конфиги править?
В общем, судя по описанию, то, что это убожество обслуживает миллион уников, заслуга не ваша, а производителей современного железа, которое позволяет даже набору костылей работать с приемлемой скоростью.
>> и отдавать напрямую клиентам с помощью JavaScript без авторизации
Разве MongoDB позволяет такое из коробки? Если да, будем рады почитать/посмотреть.
Разве MongoDB позволяет такое из коробки? Если да, будем рады почитать/посмотреть.
А у вас прям такая острая потребность отдавать данные напрямую из базы без посредников? Судя по описанию, кауч доставил проблем больше, чем решил. Похоже, если вы выбросите кауч нафиг, и напишете отдельный бекенд, который будет отдавать данные из той же монги или редиса, у вас и архитектура упростится, и работать будет быстрее.
facepalm.jpg
Нет, это на самом деле классно что вы построили систему, которая, пусть и состоит из костылей, но все же работает (многие и на это не способны).
Но, после первого абзаца, кажется что сейчас будешь читать статью от гуру хайлоада, а на самом деле оказывается что статья о банальных архитектурных ошибках и их решении с помощью костылей и бубнов.
скрипт-автоподниматель, который проверяет по крону
facepalm.jpg
Нет, это на самом деле классно что вы построили систему, которая, пусть и состоит из костылей, но все же работает (многие и на это не способны).
Но, после первого абзаца, кажется что сейчас будешь читать статью от гуру хайлоада, а на самом деле оказывается что статья о банальных архитектурных ошибках и их решении с помощью костылей и бубнов.
Единственный способ запретить всем желающим смотреть базу, который смогли найти — просто удалить следующие записи конфигурации CouchDB в секции [httpd_db_handlers] (админ при этом тоже теряет возможность просматривать списки документов):
Тем не менее, получив документ по его _id методом GET любой желающий может его поменять через PUT? В том числе, и удалить методом DELETE? Или вы как-то это перекрыли? Я бы всё-таки прослойку какую-то сделал, чтобы наружу отдавать только то, что нужно, а не полный доступ к БД
У анонимных пользователей доступ только на чтение. На запись имеет доступ только специальный пользователь и админ.
_users:
В БД:
_users:
{
"_id": "org.couchdb.user:writer",
"name": "writer",
"password": "password",
"roles": [
"read",
"write"
],
"type": "user"
}
В БД:
{
"_id": "_design/_auth",
"language": "javascript",
"validate_doc_update": "function(newDoc, oldDoc, userCtx) { if (userCtx.roles.indexOf('write') !== -1 || userCtx.name == 'admin') { return; } else { throw({forbidden: 'No permission'}); } }"
}
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Форсаж под нагрузкой на Symfony + HHVM + MongoDB + CouchDB + Varnish