Приложение клиент / сервер - у нас возникла проблема с невозможностью загрузки записей. Похоже, что метод, который я использую в своем подключаемом модуле связи, заключается в том, что он пытается открыть слишком много подключений (по одному для каждого загружаемого действия), и шлюз отказывается от них после примерно 300 попыток подключения. Во время моего тестирования проблема возникла только после 300 попыток подключения. Однако я считаю, что верхний предел основан на общем количестве подключений, используемых Apache. Я думаю, что Apache разрешает всего 500 подключений. Когда нужно загрузить больше действий, чем доступно соединений от Apache, тогда появляется наша проблема.
Нужен совет / предложения / решения и т.д ..... Linux Server с 8 ГБ
Одно из предложений, которое мы рассмотрели для реализации wa, включает кэширование записей, которые должны быть загружены в специальную папку на каждом клиентском компьютере ([APP_DATA] / SCI / CACHED_UPLOADS). После кэширования записи будут оставаться в папке до тех пор, пока они не будут успешно загружены на сервер. Затем он будет удален из папки. Также будет счетчик попыток. Если после определенного количества попыток записи все еще не могут быть загружены, они будут перемещены в папку «Неудачные». Позже мы сможем изменить наше приложение, чтобы просматривать эту папку в целях отчетности. Этот метод будет использовать одно соединение для загрузки всех кэшированных файлов.
Мне не нравится это решение, потому что нам нужно отправить скрипт на тысячи клиентских компьютеров. Я бы предпочел иметь решение на сервере Linux.
К сожалению, вы не предоставили достаточно подробностей, чтобы дать хороший ответ. Вы просто отправляете данные POST в веб-приложение / службу? Есть ли у тебя причина необходимость запустить apache? Что это за «плагин» на стороне клиента? Какие данные он отправляет? Что такое «запись» и т. Д.
Во всяком случае, я могу сказать вам прямо сейчас, что ваше приложение, вероятно, потребует рефакторинга. Вам понадобится какая-то постоянная очередь перед вашим приложением, чтобы вы могли поглощать запросы от ваших клиентских машин и передавать их в ваше приложение со скоростью, которую оно может обработать. В Интернете есть много материалов для чтения по этому поводу, но документы zeromq довольно доступны, если вы не знакомы и вам нужно с чего начать ( http://www.zeromq.org/intro:read-the-manual )
Если рефакторинг невозможен, вам, вероятно, потребуется отсортировать проблему, установив несколько серверов за балансировщиком нагрузки.
Однако в ближайшей перспективе ... взгляните на след вашего среднего процесса apache и получите столько дочерних процессов, сколько уместится в памяти. Затем выясните, сколько времени занимает ваше среднее количество запросов, и уменьшите время KeepAlive. Если вы работаете со значениями по умолчанию, тогда каждое соединение с клиентской машины будет занимать дочерний процесс в течение 120 секунд или около того. Также можно переключиться на что-то вроде nginx; он работает лучше, чем Apache, но у меня есть опыт его использования только для ускорения доставки статического контента; Я не пробовал это в этом случае использования. У кого-то здесь может быть дополнительная информация.