- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году Google заблокировал более 170 млн фальшивых отзывов на Картах
Это на 45% больше, чем в 2022 году
Оксана Мамчуева
Тренды маркетинга в 2024 году: мобильные продажи, углубленная аналитика и ИИ
Экспертная оценка Адмитад
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
По крону неудобно. Там админ должен просмотреть картинки, определить к чему они относятся, распределить их, утвердить, и тогда уже обрабатывать.
Я не понимаю, чем мешает это делать по крону?
Я не понимаю, чем мешает это делать по крону?
Ну, тем, что оно неудобно. И админу, и программисту. В случае, если не по крону, то програмист делает очень типовой скриптик, который получает параметры формы (от админа, просмотревшего картинки), сразу делает с ними что надо, включая накладку ватермарков, и показывает админу результат.
А если по крону, то админ должен посмотреть, задать параметры, и дожидаться очередного крона. А программист должен написать отдельный скрипт, принимающий параметры, как-то где-то их сохранить, отдельный скрипт для крона, чтобы прочесть параметры и обработать картинки, и третий скрипт, чтобы потом показать результат админу.
П.С. По поводу flush() (отмены буферизации) вопрос всё ещё актуален, если кто что подскажет - буду признателен.
pupseg
почему debian недолинукс?
в debian есть sysvinit-utils,
просто привык за десяток лет к rpm-based и *BSD....по работе solaris и aix....
до сих пор не адаптируюсь к куче способов установки пакетов у дебианов ... apt-get, dpkg ,aptitude и т д.... а еще после установки пакета - пакет сам запускается и работает))) а если я не хочу что бы он стартовал))) так то против дистрибутива ничего не имею))
Ну так админ выставляет опции а скрипт крона их считывает и выполняет
до сих пор не адаптируюсь к куче способов установки пакетов у дебианов ... apt-get, dpkg ,aptitude и т д....
yum, apt-get, rpm, и т.д. Вы бы хоть сперва разобрались о чем речь, не мешая в одну кучу ужа с ежом, прежде чем "адаптироваться".
а еще после установки пакета - пакет сам запускается и работает)))
Интересно, а зачем вы его иначе ставили?
pupseg, огромное спасибо! Поставил оба параметра (IPCConnectTimeout и IPCCommTimeout) в 3600, прогнал пару раз, полёт нормальный! Не падает!
Не переживайте. Упадет однажды, коли вы такие безумные таймауты ставите. Если данный виртуальный хост (или сервер в целом, смотря для чего вы эти лимиты выставили) занимается чем-то еще, кроме накладывания ватермарков.
Смысл ставить fastcgi и завышать лимиты. Используйте уж тогда модуль апача.
Упадет однажды, коли вы такие безумные таймауты ставите
Смысл ставить fastcgi и завышать лимиты
Я повторюсь, что это мой первый опыт администрирования. Я не знаю, какие лимиты умные, а какие - безумные. Если подскажете, буду признателен.
Пока что, сервер планируется использовать только для этого. Посещаемых сайтов на нём не будет.
Мы получили этот сервер уже с FastCGI. Насколько сложно/опасно переделать его на mod_php? Если основной сценарий использования сервера - запуск тяжёлых скриптов обработки графики, насколько лучше будет с mod_php?
KostaShah, чтобы ответить на ваш вопрос хорошо бы изучить более подробно что и как у вас там создается. Но исходя из того что вы написали поддержу пост #2. Не вижу аргументов для надобности пхп
ПХП - для создания удобного интерфейса для админа, который должен картинки проверить, распределить, утвердить. Первый вопрос, вроде, тьфу-тьфу, решён. По второму вопросу, всё создаётся очень просто, примерно так:
while(есть что обрабатывать){
обработать картинку;
echo "$i-ый файл готов<br>\n";
flush();
}
На паре других (шаред) хостингах, на страничке постепенно появляются надписи: "1-ый файл готов"... А на этом, пока все не обработаются, ничего не появляется.
Почитал об особенностях mod_php и FastCGI, и понял/вспомнил одну вещь. Бывало мне приходилось иметь дело с хостингами, на которых была абсолютно геморойная ситуация с правами доступа к файлам и папкам. Файл, который я загрузил на сервер через FTP, я не мог редактировать PHP-сприптом. И наоборот, файлы, созданные скриптом, я не мог удалить или переименовать через FTP. Помню, меня тогда сильно доставала эта ситуация. Теперь я понял: это были сервера с mod_php. Нет уж, спасибо, не надо такого.
Я повторюсь, что это мой первый опыт администрирования. Я не знаю, какие лимиты умные, а какие - безумные. Если подскажете, буду признателен.
Подскажу. Таймаут в чаc на сайте - безумен. Это уместно только, если сайт полностью изолирован от внешнего мира, напр. туда "ходит" только ваш админ да программист. Или только крон...
Мы получили этот сервер уже с FastCGI. Насколько сложно/опасно переделать его на mod_php? Если основной сценарий использования сервера - запуск тяжёлых скриптов обработки графики, насколько лучше будет с mod_php?
Переделывать - незачем.