Если все законно, и инициатор сам пользователь — поставьте ему веб-камеру, и записывайте поток куда-то на сервера свои. Таким образом он сможет прикрыть ладошкой свои личные пароли при необходимости.
Операции в клиент-банках приходят с малопонятным описанием и одной суммой. Куда выгоднее в этом плане «изобрести» сканер чеков+распознавалку. Сбер, кстати, и без отправки на почту рисует «нормальные» таблички, которые можно копипастить и не набивать суммы. Но вот какая цифра к чему относится — это придется вспоминать.=(
Я пользуюсь мозгом и логами http-сервера, в котором написано какой файл и с какими параметрами был вызван при запросе.
Другое дело, как вы не зная в каком месте надо что-то делать, пишите кусок кода эти тридцать минут? Может там двумя строчками ниже есть для этого готовый метод?
Странно, что вопрос о HDD сопровождается чем угодно, но не куском SMART. Может он действительно в PIO выпал из-за ошибок в сетевом контроллере и вам надо шнурок вынуть-вставить/поменять.
:) Думаете, если 4гб фильм затискать в мускуль, его потом будет быстрее/поще скачать? С чего бы это? В базе он будет занимать больше места. Соответственно, объем бекапа также будет больше. И скачать его будет сложнее.
В целом, поиск измененных файлов и инкрементный бекап на файлах реализуется проще, чем выборка из Mysql, архивация дампа и скачивание.
— Странно, весь интернет хранит файлы на дисках и ничего. Если есть вариант, что MySQL будет хранить их не_на_диске, а где-то в другом месте, то, возможно, будет некий бонус. В остальном это лишние накладные расходы при каждом запросе.
— Никогда небыло проблемы с бекапом файлов. Есть туева хуча готовых утилит. И, кроме того, если вы планируете бекапить базу не методом бекапа её файлов, а поднимая слейв, то это еще больший гемор.
Погуглите phpdeamon. Думаю, однопоточного демона тут вполне достаточно. Есть задача — работаем. Нету — слип на 10/60/600 сек. Запуск демона можно будет прикрутить на крон.
Грамотно — не использовать паттерн «костыль», а пользовать готовое решение, разбираясь в нем по ходу дела :)
50% факапов случаются в первые 30 дней работы. Остальные 50% в течении 30 дней по истечении гарантийного срока. Перед вами устройство, которое проработало весьма долго и все еще работает! Я бы брал не раздумывая если есть возможность сменить аккум, и нет внешних дефектов, как тут уже сказали.
Я, конечн, жопорукий извращенец, но почему нельзя сделать таблицу subscribers, заполнить ее один раз всеми значениями при добавлении подписчика, а при рассылке тупо из нее дергать?
И еще, в порядке бреда, проблема может быть в пыхе, на этапе выделения оперативки. Попробуйте для теста 5.4 не меняя остального. Не помню на какой версии у меня была такая проблема.
Если решение нишевое, то имеет смысл делать самописное, чтобы потом его продвигать в этой нише и отбить часть средств.
Если сильно кастомное, то вполне можно сделать доработку чего-то готового. Но не забывайте о поддержке. Когда Вам понадобится что-то поменять, найти программиста, способного найти косяки в получившейся штуке будет сложновасто.
Оценить время может только разработчик, поскольку то что один сможет сделать за 6 часов, второй будет клепать три дня. =/
Мне кажется достаточно temp & tmp натравить на RAMDisc и поставить побольше оперативы, чтобы свопа небыло. Остальное — копейки, главное бекапить не забывать хотя бы раз в месяц.
09, Power-On Hours Count, 8426, 100, 0, Ready for use.,
0C, Power Cycle Count, 450, 100, 0, Ready for use.,
F1, Host Writes, 3.27 TB, 100, 0, Ready for use.,
F2, Host Reads, 9.20 TB, 100, 0, Ready for use.,
Потискайте поиск, это весьма частый случай.
Как правило, Обработчик оставляют работать в фоне, и заставляют где-то хранить «текущую строку». Например, в мемкеше.
А ваш скрипт с прогрессбаром смотрит в мемкеш и отдает клиенту циферку.
Как-то так.
Ну и не забыть запустить обработчик после импорта файла. =) кто-то пользуется fork, кто-то очередями задач. Кому как удобнее.
А я бы добавил в таблицу поле "продолжительность", (или вместо "дата завершения") И имел запрос
((время начала + продолжительность)по модулю 24) >= нужная точка
Хотел набить длинный ответ, но забил. Все-таки идеального решения не бывает. Для двух разрабов я бы делал так:
dev.site.ru ->test.site.ru->www.site.ru
кажому разрабу локально ставить гит-репозитарий, и сначала работать в локале, потом коммититься в dev и там смотреть как работает на норм. данных. Ну и дальше миграцию по стрелкам.
Я делал выборку квадрата со стороной в 2 радиуса запросом, а более точно для каждой точки считал расстояния в серверной части приложения. Так проще масштабировать и будут индексы задействованы.