DevMan: вы серьёзно? То что на нём можно написать что угодно ещё не значит что это не боль и страдания по сравнению с более подходящими решениями:) Вот несколько причин почему PHP это боль:
1. у PHP бездарное отношение к документации, в действительности почти никто не полагается на реальный код скрывающийся за функцией и "гуглит" решения в интернете и только в крайних случаях заглядывает в Си и смотрит что же там за входные/выходные данные могут быть
2. не возможность по нормальному обрабатывать ошибки, точнее возможность-то всегда была, кроме случаев обработки фаталов (с ними как было всё плохо так и остаётся), но тонны кода написаны абы как в этом понимании
3. не возможность нормального использования ресурсов, вы никогда не сможете гарантировать что ваше приложение медленно, но отработает, а не умрёт из-за нехватки памяти, переполнения стека, фантомных ошибок, сегментации и прочих особенностей которые могут всплывать в любом месте. Доступные функции для управления GB не сильно-то помогают, даже если вы будете сбрасывать GB после почти каждой операции - это вас особо не спасёт, разве что сделает код медленнее
4. медленная производительность при практически аналогичной сложности разработки например на Golang
5. всё совсем плохо если вы хотите написать многопоточный сервер на PHP, для этого не даром было написанно несколько дополнительных расширений на Си, что бы хоть как-то сгладить проблемы. Но в сухом остатке, если где-то хотя бы одна ваша функция упадёт в паник - весь сервер умрёт и вам нужно позаботиться об этом как-то дополнительно, а значит задействовать крон либо специальный софт который будет следить за сервером и перезапускать его. В любом случае - перезапуск по таким пустякам это плохая идея
6. множество накладных расходов буквально везде, когда у вас небольшой сайт - это нормально, когда у вас ферма серверов с разнообразными задачами то это не смешно и не интересно
7. если вам захочется модифицировать стандартную библиотеку, то использовать вы сможете её далеко не всегда и не везде, не всякому клиенту это подходит, да и не удобно
8. компетенция тех кто вам скорее всего будет пробовать помочь если у вас какая-то техническая проблема.
FireGM: если программист специально этого не сделает. Попробуйте добавить мёртвый цикл в хандлер и посмотреть что будет. Первый коннект пройдёт, второй нет, пока не закончится первый.
Какую библиотеку вы используете для доступа к базе?
В стандартной (https://golang.org/pkg/database/sql/):
func (db *DB) Query(query string, args ...interface{}) (*Rows, error)
func (rs *Rows) Close() error
Напоминает историю десятилетней давности когда nginx предлагали добавлять к apache не исключая apache... вопрос о том как делать более безопасные и предсказуемые приложения на Golang сам по себ е интересен и nginx в этом вопросе никак не поможет.
Например если вы залочите один из хандлеров то ни nginx ни что либо другое вам уже не поможет, конкретная страница открываться не будет, как поведёт себя nginx обнаружив такую страницу - вопрос интересный.
21 век... регулярки не то что бы совсем плохи, но поддерживать их и раньше было сложно, а сейчас данных и задач так много что просто не вариант. Проблема топикпастера в том что PHP плохо под такие задачи рассчитан, что бы использовать именно его надо много всего дописать, додумать, дорешать, дофантазировать и так далее... но классически задача решается так:
1. научитесь максимально быстро и просто получать данные с одной страницы
2. научитесь максимально прозрачно для себя и для приложения скачивать те страницы что вам нужны
3. научитесь организовывать предыдущие два пункта так что бы и нагрузка была распределённой и проблема парсинга одной страницы не убивала весь движок целиком
Парсеры штука интересная:)
Что бы использовать именно этот крон нужно хорошо разбираться в том что в действительности там внутри происходит, иначе можно пропустить ошибку или получить не прогнозируемый результат.