У моей компании есть api веб-сервиса, который начинает широко использоваться. Недавно у нас были проблемы с нехваткой памяти. Оптимизировали неэффективный код и решили проблему.
Мы знаем, что собираемся расширяться еще больше, мы хотим иметь хороший способ справиться с интенсивным трафиком.
Возникла одна идея - иметь разные URL-адреса для некоторых из наших более активных клиентов. Это просто кажется мне неправильным. В некоторых случаях URL-адреса будут указывать на изолированные серверы, но некоторые также будут указывать на большее количество виртуальных каталогов.
В любом случае это хорошее решение проблемы? Я предвижу ужасные проблемы с ремонтопригодностью и создаю больше проблем, чем он решает. Назовите, пожалуйста, плюсы и минусы обеих сторон.
Это уже на ферме серверов с балансировкой нагрузки.
Если он уже находится на ферме со сбалансированной нагрузкой, и вы получаете слишком большую нагрузку, и вы уже оптимизировали ее настолько, насколько это возможно, естественным следующим шагом будет расширение вашей фермы для удовлетворения спроса.
Если вы достигли максимальной емкости балансировщика нагрузки и у вас есть простаивающие серверы, вы можете попытаться сбалансировать более равномерно, используя какую-то обратную связь с такими балансировщиками, как mod_cluster. Если вы все еще находитесь на пределе, вы можете попробовать Циклический DNS в качестве альтернативы раздаче нескольких URL-адресов. Таким образом, вы можете переложить балансировку нагрузки на клиента. Вы можете добавить отзыв об этом решении с помощью названный. Балансировщик нагрузки большего размера - это другой подход, который, конечно, требует дополнительных долларов.
Может ли ваш API воспользоваться кешированием?
Если определенные части API часто вызываются и возвращают те же результаты, что-то вроде memcached может вам значительно помочь.
Я не вижу преимуществ в том, чтобы иметь определенные URL-адреса для разных клиентов. Мне кажется, что либо вам нужно больше серверов, либо балансировка нагрузки работает некорректно.
Балансировщик нагрузки уровня 7 позволит вам разделить тех клиентов, которые считаются «дорогостоящими», в кластер / машину, настроенную для обработки их конкретных запросов. Я предполагаю, что это «занятый» клиент, который выполняет львиную долю запросов, и разделение их на собственный сервер - вот почему вы подумали о предоставлении им отдельного URL-адреса. С помощью балансировщика нагрузки уровня 7, linuxvirtualserver.org, вы можете фильтровать определенные URL-адреса и получить довольно простую в обслуживании систему.
Хотя вы в конечном итоге хотите решить проблему правильным способом, использование чего-то подобного может выиграть вам достаточно времени.
Я бы посмотрел на этих клиентов с более интенсивным использованием прямо сейчас. Вы можете взимать с них больше? Их использование больше, чем должно быть? Можете ли вы помочь им оптимизировать свои системы, чтобы им не приходилось так интенсивно работать? Можете ли вы добавить ограничение скорости в свои API? Достаточно ли их использования, чтобы предоставить им собственный сервер и взимать с них соответствующую плату?
Следующий шаг - взглянуть на вашу архитектуру. Есть ли кеширующие прокси перед вашими веб-серверами? У вас есть отдельные серверы баз данных? Все ли ваши серверы оптимизированы так же, как и ваш код? Кешируете ли вы абсолютно все, что только можете? У вас хорошее оборудование?
Как только вы уверены, что ваша архитектура максимально оптимизирована, вам действительно нужно просто добавлять дополнительные блоки в настройку балансировки нагрузки всякий раз, когда вы начинаете достигать пределов (будь то дополнительные кеши, дополнительные веб-серверы или дополнительные серверные серверы, будет зависеть от того, какие ограничения вы бьешь).
Вы пробовали бегать http://developer.yahoo.com/yslow/ и http://code.google.com/speed/page-speed/ это плагины для Firebug, пытающиеся проанализировать количество запросов, генерируемых при загрузке страницы?