SocFishing: При заходе на объявление создавать пустую запись с ID, IP, Date.
При добавлении апдейтить запись с выборкой по IP и сортировкой по Date.
По крону каждый день вычищать пустые записи.
много ненужных движений, слишком "дорого" получается....и нет гарантий отсутствия коллизий в случае NAT
обрабатываете загрузку фото, держите их имена в переменной, создаете запись в бд, попутно узнаете заветынй ID, привязываете фотки из переменной к этому ID
создать объявление (ну или просто создайте пустую запись, потом обновляйте её), потом привязать фото к его ID, если фото загружаются до создания записи - держать их во временном буфере, откуда потом подвязать к записи.
я уже писал недавно о том, как на одном из серверов у нас была беда с винтами - для них это нормальное поведение (учитывая их ценник на железо, во всяком случае)
если хостите коммерческий проект и данные вам важны - не пожалейте тех 49 евро разово, дабы не тратить время на недельное бодание с саппортом и будет вам счастье.
WapGraf: astraliens, почему это нет? Есть же в robot кнопка Monitoring. Для бесплатного варианта вполне сносно работает.
ну, если Вас устроит узнать о том, что ваш винт "уже умер и ушел в страну вечнохолодных накопителей", а сервер более не будет доступен в текущей реинкарнации, тогда да, сойдет...гвозди тоже можно забивать микроскопом...
только переходом, менять адрес в адресной строке напрямую браузер не позволит
пользуйуте window.location.href
ну или hash, но это не совсем в рамках задачи уже
можно триггерами оформить...
При заходе на объявление создавать пустую запись с ID, IP, Date.
При добавлении апдейтить запись с выборкой по IP и сортировкой по Date.
По крону каждый день вычищать пустые записи.
много ненужных движений, слишком "дорого" получается....и нет гарантий отсутствия коллизий в случае NAT
можно отсюда подробнее?
обрабатываете загрузку фото, держите их имена в переменной, создаете запись в бд, попутно узнаете заветынй ID, привязываете фотки из переменной к этому ID
создать объявление (ну или просто создайте пустую запись, потом обновляйте её), потом привязать фото к его ID, если фото загружаются до создания записи - держать их во временном буфере, откуда потом подвязать к записи.
попробуйте
будет видно, какая база/таблица растет.
останется периодически оптимизировать таблички.
очень верное решение...
оптимайз какраз и будет делать "удаление и заливку по новой". правда диску придется немного несладко, т.к. будет полная перезапись всей таблицы..
посмотрите в сторону хедера Reply-To
я уже писал недавно о том, как на одном из серверов у нас была беда с винтами - для них это нормальное поведение (учитывая их ценник на железо, во всяком случае)
если хостите коммерческий проект и данные вам важны - не пожалейте тех 49 евро разово, дабы не тратить время на недельное бодание с саппортом и будет вам счастье.
Такие мониторинги нужно делать на сервере, а не из-вне! Про то как верно настроить smartctl написано множество статей. Все элементарно!
ну так а речь-то о чем...какой вам smartctl в роботе-то...выше и писалось о том, что мониторинг нужно на сервере настраивать
astraliens, почему это нет? Есть же в robot кнопка Monitoring.
Для бесплатного варианта вполне сносно работает.
ну, если Вас устроит узнать о том, что ваш винт "уже умер и ушел в страну вечнохолодных накопителей", а сервер более не будет доступен в текущей реинкарнации, тогда да, сойдет...гвозди тоже можно забивать микроскопом...