Задержка и низкая скорость при загрузке содержимого iframe при огромном посещении

Ответ 1

С запросом в 3k в минуту и ​​с надеждой на рост вам нужно начать использовать архитектуру big data и инструменты.

Вот некоторые основные моменты освещения, которые следует учитывать:

• Используйте отдельный CDN для хранения и обслуживания изображений.
• Используйте mapReduce программное обеспечение для хранения данных, таких как hadoop.
• Получить серверы, которые distributed, в отличие от одного огромного сервера.
• Добавьте сервер load balancing.
• Отключите все функции и расширения php, которые вам не нужны.

Ответ 2

В этом конкретном месте в размере вашего приложения я бы сосредоточился на двух конкретных улучшениях в вашей инфраструктуре и логике кода.

• Отменить процессы, необходимые для обслуживания активов баннера конечным пользователям из процессов, необходимых для хранения показов объявлений.
• Реализовать горизонтально масштабируемую инфраструктуру для получения запросов.

1. Развязка обслуживающих баннеров с сохранением показов

Отделив эти две проблемы, вы сможете обеспечить более стабильную производительность для клиентов вашей службы ppc. Если вы еще не используете CDN или иным образом выгружаете запрос на обслуживание самих изображений из ваших селекторов, это может значительно улучшить время отклика.

Другая область, которая даст вам большой выигрыш, заключается в разделении обслуживания баннерного кода от процессов, которые хранят данные о показах на диске. Существует несколько способов сделать это, но для успешного решения, с которым у меня был опыт, используется ActiveMQ (http://activemq.apache.org/) или аналогичная очередь система. Система очередей поможет сэкономить нагрузку на хранилище показа с течением времени, сохраняя данные о показах в памяти и отправляя эти точки данных с постоянной скоростью на потребительские (так называемые рабочие) процессы, которые могут хранить эти данные в БД или на другом носителе данных. Это позволяет отделить загрузку фактического хранения показов на диске от процесса показа рекламы. Вы также можете настроить несколько процессов для использования заданий в очереди, что приводит ко второй области улучшения.

2. Горизонтально масштабируемая инфраструктура

Построение горизонтально масштабируемого решения в основном означает, что вместо необходимости увеличения размера и мощности одного сервера вы можете просто добавить дополнительные серверы меньшего размера, которые равномерно распределяют нагрузку на системные требования. Это имеет несколько преимуществ, один из которых заключается в том, что проще (и, как правило, дешевле) добавить несколько небольших серверов в пул, а не обновлять один большой сервер, чтобы быть более крупным и мощным. Это также имело то преимущество, что было более надежным в случае сбоя сервера.

В этом случае я считаю, что хорошим решением будет иметь один сервер или процесс, действующий как маршрутизатор, который будет просто загружать запросы баланса, отправляя их на разные серверы, которые выполняют фактическую обработку запроса. В PHP есть много хороших ресурсов для создания маршрутизации или сценариев балансировки нагрузки в PHP, но в основном вы будете получать запросы на одной конечной точке, а затем отправить этот запрос на другой сервер, чтобы он действительно выполнялся. Если вы создадите динамический список серверов, готовых для получения запросов, вы можете легко увеличить количество серверов, выполняющих запросы, когда начнете видеть неприемлемую производительность. Это также даст вам возможность легко удалить сервер из списка, если он опустится, а затем любой трафик просто будет перенаправлен на другой сервер, который все еще был.

Если вы еще этого не сделали, было бы неплохо заглянуть в lighttpd (http://www.lighttpd.net/) или nginx (https://www.nginx.com/) в качестве альтернативы Apache, которые созданы для обработки больших объемов запросов с меньшими накладными расходами. Они были бы особенно хорошо подходят для обработки запросов на вашем сервере маршрутизатора.

Как только вы настроите горизонтальное масштабирование для запросов, было бы достаточно просто настроить горизонтальное масштабирование для серверов хранения. Вы можете легко сделать это, изменив идентификатор по количеству серверов в пуле, чтобы определить, куда отправить запрос.

$serverNumber = $adID % $availableServers;

Резюме

Несмотря на то, что вы можете определенно увидеть хорошие улучшения производительности, оптимизируя методы хранения и настройку сервера, в какой-то момент в большом приложении вы захотите добавить дополнительные серверы для выполнения этой работы. Я думаю, что с вышеуказанными шагами вы будете в очень хорошем месте, чтобы масштабировать свое приложение плавно, поскольку оно растет в размерах.

Ответ 3

Возможно, вы сможете экономить на производительности и наработких за счет использования существующего журнала доступа к Apache, чтобы действовать как ваш трекер отслеживания, и полностью отключить свой код чтения/записи с помощью базы данных/плоского файла.

Настройте новый виртуальный хост Apache и укажите его в каталог webroot системы, в котором вы будете нести исключительную ответственность за показ своего PHP-поколения объявлений script. В рамках этой конфигурации одного виртуального хоста вы можете настроить журнал доступа к системе, который на 100% является эксклюзивным для показа ваших объявлений; Apache позаботится о добавлении к этому журналу при каждом посещении (показе) и вращении/архивировании журнала по мере необходимости. Вы можете указать, где бы вы хотели сохранить журнал, а также какие данные сервера/среды/реферера/пользовательского агента будут храниться в нем.

Затем, через cron или демон, вы можете запускать любой фоновый анализатор журналов, который вы хотите, собирать статистику в базу данных, хруст числа и т.д., не связывая ни один из этих более тяжелых действий по переходу на прямые веб-запросы.

Я также нашел в Qaru предложение использовать этот метод с помощью lighttpd вместо Apache для дальнейшего расширения ресурсов вашего сервера.

Дальнейшее чтение:

• Умный метод отслеживания отпечатков

• Apache: файлы журналов

• lighttpd