Алексей Сундуков

Учитывая тег PHP предположу, что этот язык известен больше всего. На нем и пишите. 500кю*10-15 ~ 10М/сутки нагрузка вполне подъемная для PHP даже с одного сервера.

Крайне рекомендую сразу проработать API с мобильщиками и продумайте архитектуру (хотя бы на уровне структуры URL). Иначе можно напороться на грабли с обновлением клиента и версиями API.

Если он пришел с поисковика, то узнать требуемое можно только у самого поисковика. И HTTP_REFFERER тут не поможет, т.к. там будет редирект от поисковика с кучей служебной информации.

Если нужно узнать по каким фраза пришел пользователь с гугла, ставим аналитикс. Нужны фразы из яндекса - ставим метрику.

В каментах многие высказали мысль, что уровень будет нулевой. Но я бы развил мысль. Уровень может оказаться еще ниже. Просто по причине предыдущего опыта. Ведь зачастую, научить полного в программировании новичка проще, чем переучить специалиста, но из другой области. И дело даже в невозможности освоения, нет. Человек все может освоить. Дело в стиле. В подходе к написанию кода. Шанс писать на Java как на PHP сильно не нулевой.

mysqldump -uUSER -pPASSWORD -hlocalhost -d --default-character-set=utf8 --quote-names --allow-keywords --add-drop-table --set-charset schema_info > /path/to/file/schema.mysql

mysqldump -uUSER -pPASSWORD -hlocalhost -d --default-character-set=utf8 --quote-names --allow-keywords --add-drop-table --set-charset --ignore-table=schema_info > /path/to/file/schema.mysql

man mysqldump

100 скачиваний фигня ради которой думать о мультикурле нет смысла. Поэтому можно спокойно качать в обычном однопоточном режиме. И искать ошибку в скрипте (или механизме его запуска). Правильный вариант - запуск в минутных cron-ах.

Время работы скрипта на получение - от 8 до 15 мс.

Время которое уходит на запрос к редису ни как не связанно с временем работы всегда скрипта. На общее же время влияет много фактором. Учитывая, что редиска это PHP класс, то много времени может уходить на его загрузку (видимо акселераторы не используются). А время запрос правильнее так измерять:

$start_time = microtime(true);
$key->getValue();
$end_time = microtime(true);
echo $end_time-$start_time;

У меня на дедике через сишное PHP extension на запрос уходит порядка 0.3 мс.

Если используется Apache, то вероятнее всего дело в MaxClients.

А вообще смотрите логи, там обычно причина блокировки пишется.

@inkvizitor68sl конечно дал правильное направление. Но хочется добавить еще несколько важных моментов на случай, если окажется, что в конфиге все таймауты прописаны как у него по 180 сек, а скрипт таки отваливает все равно в районе минуты. Соль в следующем.

Если из PHP ни чего не возвращает до конца своей работы, то в действие вступает такая настройка как fastcgi_connect_timeout. proxy_read_timeout тут еще не работает (т.к. по сути соединение не считается установленным). Причем максимальная величина fastcgi_connect_timeout - 75 секунд и это величина захаркожена в самом nginx. Поэтому если скрипт должен работать дольше, то нужно из PHP echo-нуть что нибудь.

Я использую MultiCurl. Запускаю 100 загрузок, через bash запускается 20 копий скрипта (IPC реализовано через очередь в Redis). 18кссылок отрабатывает за 10 минут (около 30 в секунду). Но скрипт не просто качает, он проводит анализ страницы, перекодирует в требуемую кодировку, строит DOM страницы и через XPath вытягивает нужные данные. При этом каждая копия жрет где-то 50МБ. Схема простая и легко масштабируемая горизонтально.

Кстати, нужно понимать/разделять процесс скачки страницы и её парсинг. Первое может легко и непринужденно делать wget.

Сишные либы дадут в принципе один плюс - экономию ОЗУ (т.е. nelis заблуждается). В остальном больше времени уйдет на взаимодействие с сетью и записи данных в базу.

file_get_contents без задания контекстов использовать категорически нельзя. Ибо 1) это блокируемая функция, 2) не содержит таймаутов.

Делать класс db синглтоном не хочу, потому что иногда бывает нужно создавать несколько подключений к БД.

Синглтон не исключает возможности использование нескольких подключений.

Качать картинки тем же скриптом совершенно не обязательно. Я обычно просто сохраняю url в файл который потом отдается wget-у (флаг -i). Бывает и так, что внешняя обвязка (CMS) сохраняет файлы в какой-то своей структуре. Поэтому для такого случая можно wget-ом картинки предварительно накачать в локальную ФС. Что бы в ФС адрес картинки был такой же, как у URL следует использовать -x опицию Вот типичный пример загрузки:

wget -x -b --user-agent="Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6" --referer="http://examplke.com/" -i img_url_list.txt

Качает очень быстро + легко параллелиться если разделить файл на куски и запускать с разных серверов. У меня с двух серверов 200 000 картинок общим объемом ~8ГБ грузиться около часа.

>python, ruby, php, node, nginx, mongo, redis, percona, mariadb, mysql, exim, dovecot, proftpd,
>memcache и прочее ПО которое может потребоваться разработчику в наше время.

Тогда не стоит. Как уже было упомянуто выше, проблема с панелью не в том, чтобы её написать, а в в том, чтобы её поддерживать. Адекватно это делать не на фултайме командной разработчиков нереально (вы же не будете отслеживать все релизы поддерживаемого ПО и тут же бросаться доделывать панель). Можно бить себя в грудь, утверждая, что у меня конечно же получится создать правильную архитектуру, но тогда получается, что все остальные команды, пишущие панели, настолько некомпетентны, что не смогли прийти к этой правильной архитектуре.

Рекомендую начать с малого, написав панель управления связкой nginx+php-fpm (версий 5.2-5.5)+mysql+какой-то_ftp+какой-то_dns через которую можно управлять vhost-ми, в идеале с возможностью трансформаций htaccess-ов в готовые конфигурации nginx. В крайнем случае хотя бы apache за nginx.

P.S. А чем та же OpenPanel не угодила?
P..P.S. Работая и разработчиком, и у хостера сам не раз думал и даже делал простой прототип панели. Но трезвая оценка говорит, что написать нормальную панель поддерживающую целую группу ПО да еще и разных версий не на фултайме обречено на провал. А фултайм ни кто оплачивать не хочет в условиях, когда готовые панели уже есть.

Делать нужно не ПОСТобработку, а ПРЕДобработку. Т.е. бежим по массиву и там где нам нужны цифры делаем явное приведение к нужным типам.

То ли лыжи не едут, то ли я

Регулярка вернула ровно то, что от неё просили.

1) Позиция 0: выражение '/ \d+ \d+ /' для строки ' 1 2 3 4 5 6 ' матчится в ' 1 2 ' и текущей позицией становится 5.
2) Позиция 5: выражение '/ \d+ \d+ /' для строки '3 4 5 6 ' не матчится, текущей позицией становится 6 (относительно исходной строки конечно).
3) Позиция 6: выражение '/ \d+ \d+ /' для строки ' 4 5 6 ' матчится в ' 4 5 ' и текущей позицией становится 11.
4) Позиция 11: выражение '/ \d+ \d+ /' для строки '6 ' не матчится как и все последующие до конца строки.

Результат: ' 1 2 ' и ' 4 5 '.

А второе:

«GET / HTTP/1.0» 499 0 "

явно указывает на причину проблемы. Стартовый nginx закрыл соединение не дождавшийсь ответа от конечного. Нужно просто поднимать таймауты соединений (таких как proxy_send_timeout, proxy_read_timeout и прочие).

Кстати, для дебага очень полезно использовать htop и strace (в htop-е выбрать рабочий процесс nginx-а и нажать S).

Если проксировать на этот же хост — работает. Если на указанный в конфиге — 502.

server_name 127.0.0.1;

Не нужно использовать IP адрес как имя сервера. Следует использовать имена, причем не обязательно существующие. Главное что бы они были в hosts файлах на обоих машинах.

В такой ситуации проще использовать серверные браузерные движки в духе PhantomJS. На выходе получаем сгенерированный html и не важно, что так и как кодируется. Все, что доступно в браузере, доступно и такого парсеру.

Если соединение локальное, то юниксовый сокет предпочтительнее в общем случае. Работать может до 30% быстрее. Можно управлять правами доступа на уровне ФС.

В общем поддержу opium в тезисе если бэкэнд локальный, то юниксовый сокет.