Увеличение грузоподъемности на шлюзе
Я пытаюсь отправить 10000 XML-запросы постоянно в while() цикл от клиент к шлюз(который действует как сервер для этого клиента) более UDP коробка передач. Шлюз реализует select() вызов функции для мониторинга read_fds. В Шлюзе, struct timeval ценности, которые я передаю select() являются:
tv.tv_sec = 5;
tv.tv_usec = 0;
каждый XML-запрос имеет 1500 байты и клиент и шлюз
кодируется на C ++, а исполняемые файлы работают на Linux (RHEL 5)
Есть два случая:
Случай 1:
На стороне клиента, если я отправлю 10000 XML-запросы постоянно в while() цикл и реализовать задержку 500 микросекунды с использованием usleep() между каждым запросом шлюз принимает все 10000 запросы, анализирует его и записывает запросы в файл .log.
случай 2:
На стороне клиента, если я отправлю 10000 XML-запросы постоянно в while() шлюз без задержки, шлюз принимает только +2600 запросы, анализирует его и записывает запросы в файл .log.
Вопрос:
Как я могу увеличить нет. запросов, принятых шлюзом, без реализации задержка на стороне клиента? Также скажите, пожалуйста, что происходит с оставшимися 7400 запросы от Клиента в случай 2, они потерялись?
Решение
Если серверный приемный буфер не читается достаточно быстро, остальные сообщения действительно теряются: так работает UDP.
Если вам просто нужно обработать пакет из 10000 сообщений (и не справиться с устойчивым трафиком), вы можете просто увеличить размер буфера: sysctl -w net.core.rmem_max=nnnnnnn,
В качестве альтернативы начните профилирование, где время тратится в цикле чтения вашего сервера. Вы могли бы, например, удалите весь анализ и ведение журнала как тест и просто посчитайте количество полученных сообщений: если это поможет вам приблизиться к числу, близкому к 10000, то это будет означать, что разбор и запись слишком медленны для этого цикла.
Другая вещь, которую нужно проверить, это посмотреть, какие сообщения вы теряете: если вы получаете постоянную потерю сообщений даже в ранних сообщениях (например, в первых сотнях сообщений), то это будет означать, что что-то еще на пути не может обрабатывать сообщения с такой скоростью — приемный буфер на сервере не виноват в этом случае.
Другие решения
Других решений пока нет …