Ты не вполне угадал. Очередь - да. Но с обработкой fulltime и с обратной связью в рабочее время в течение нескольких минут, так что никакого раз в сутки и обработки при logrotate. Там workflow тот еще. Даже с точки зрения владельца объявления. Ой, мне поправить, ой нет, я платно не готов, давайте я изменю так, чтобы бесплатно проходило, и т.п.
В итоге у владельца в личном кабинете ссылки на штук пять-восемь (лень считать, сколько именно) списков вида "объявления, готовые к публикации", "объявления, которые требуется оплатить", "объявления, по которым требуется уточнение".
Что веселее, у оператора таких больше десятка.
В выпуске раз в неделю порядка 10 тысяч объявлений. Ну, допустим, процентов 20 подаются через сайт, но перспектива - ближе к 100, народ постепенно сдвигается в интернет. В основном в последние два дня перед закрытием приема в выпуск. На обработку одного объявления уходит в среднем штук семь запросов (4, кажется, минимум). Из них чуть больше половины - операторские, т.е. с подсчетом актуального состояния подготовительной информации по всем пользователям.
Немножко не то, что ты описал, по требованиям к ресурсам, ты не находишь?
Не, в принципе можно сделать конструкцию, где процесс, работающий от имени юзера, вообще не будет ходить к базе, и будет написан на C, чтобы минимизировать время на инициализацию. А синхронизацию между основной базой, серьезной, и индивидуальными базами юзеров (эти хоть plain text) делать отдельным демоном. Тогда можно будет уложиться примерно в те же ресурсы по железу. Зато потребности в разработчиках на порядок выше.
То есть я за такое вообще не возьмусь ни за какие деньги, мне нервы дороже.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
Date: 2016-Feb-22, Monday 08:36 (UTC)В итоге у владельца в личном кабинете ссылки на штук пять-восемь (лень считать, сколько именно) списков вида "объявления, готовые к публикации", "объявления, которые требуется оплатить", "объявления, по которым требуется уточнение".
Что веселее, у оператора таких больше десятка.
В выпуске раз в неделю порядка 10 тысяч объявлений. Ну, допустим, процентов 20 подаются через сайт, но перспектива - ближе к 100, народ постепенно сдвигается в интернет. В основном в последние два дня перед закрытием приема в выпуск. На обработку одного объявления уходит в среднем штук семь запросов (4, кажется, минимум). Из них чуть больше половины - операторские, т.е. с подсчетом актуального состояния подготовительной информации по всем пользователям.
Немножко не то, что ты описал, по требованиям к ресурсам, ты не находишь?
Не, в принципе можно сделать конструкцию, где процесс, работающий от имени юзера, вообще не будет ходить к базе, и будет написан на C, чтобы минимизировать время на инициализацию. А синхронизацию между основной базой, серьезной, и индивидуальными базами юзеров (эти хоть plain text) делать отдельным демоном. Тогда можно будет уложиться примерно в те же ресурсы по железу. Зато потребности в разработчиках на порядок выше.
То есть я за такое вообще не возьмусь ни за какие деньги, мне нервы дороже.