Я готовлюсь к установке сервера, который будет отвечать за отслеживание статистических данных от источника большого объема трафика. В среднем он будет обрабатывать запросы со скоростью около 6-7 мил / час, и все это небольшие GET. Все, что мне нужно, это простая настройка сервера, который может обрабатывать параметры запроса на получение и записывать их в файл CSV.
Моей первой мыслью было использовать lighttpd + fastcgi + php, так как это конфигурация, с которой я уже знаком. Но, учитывая, что я не могу каждый день принимать подобные решения о производительности, я хотел бы изучить некоторые другие варианты и посмотреть, может ли быть что-то еще лучше для этой цели.
Вы хотите сделать 6-7 миллионов операций записи в файл CSV за час?
Серьезно, база данных - лучшая идея. База данных предназначена для обработки одновременных операций записи и может масштабироваться по вертикали (большая машина, более быстрые диски) или по горизонтали (нагрузка распределяется по нескольким серверам). Запись в один файл CSV (или любой file) требует некоторой формы блокировки для решения проблем параллелизма и плохо масштабируется по мере увеличения нагрузки ввода-вывода и параллелизма.
Чтобы обойти это, вы, вероятно, в конечном итоге реализуете свои собственные слои кеширования и буферизации, а затем начнете разделять нагрузку между несколькими файлами и т. Д. И т. Д. Используйте какой-либо тип базы данных с самого начала и избавьтесь от множества головных болей.
Учитывая, что вы собираетесь выполнять около 2000 запросов / сек или 500 мкс / запрос на СРЕДНИЙ (что означает гораздо более высокие пики), CSV, вероятно, не подходят из-за затертых записей при одновременной записи, поскольку ничто не гарантирует атомарной записи в ваши файлы.
Одна идея - это файлы для каждого процесса / записи, которые собираются позже, другая идея - использовать базу данных, сильно настроенную для большого количества записей. Вы также можете ознакомиться с очередями сообщений или протоколами групповой связи (например, Распространение), но я не знаю, подходят ли они для такого объема.
Что бы вы ни делали, предложите несколько быстрых идей и сравните их. Современное оборудование может творить чудеса с производительностью, но оптимизируйте его только при необходимости. Что касается PHP - убедитесь, что у вас установлен Opcode Cache (например, APC), иначе вы будете прожигать много циклов ненужной перекомпиляции скриптов.
Также имейте в виду, как выглядит рост сервиса, вряд ли есть смысл стремиться к решению, которое будет подавлено через несколько месяцев.
Какие параметры передаются через GET-запрос? Должен ли он быть в режиме реального времени в CSV / базе данных? или как вы думаете, можно ли создать фиктивный HTML-файл (или PHP) и просто использовать веб-журналы для анализа и загрузки в CSV позже в виде пакетного задания? (ладно ... это звучит запутанно ... но с этим легко справиться) ..
Возможно, это вне вашего контроля, но действительно ли веб-сервер подходит для этого?
Я бы посмотрел на веб-версию server 2008 и использовал ADO.net для записи в файл CSV. У вас не должно возникнуть проблем с пропускной способностью, поскольку ado.net будет буферизовать записи.
Я не понимаю, как (даже частично) надежно это сделать с одним (более или менее недорогим) сервером. Если все, что вы когда-либо делаете, это анализирует параметры получения, лучшим вариантом может быть высокопроизводительный легкий HTTP-сервер с открытым исходным кодом, например Гатлинг и взломайте его, чтобы записать запрос в быструю очередь, например кролик.
Затем у вас может быть писатель, который читает из этой очереди и последовательно записывает в файл в жестком цикле.
Таким образом, вы можете быть уверены, что записи являются атомарными, и при этом сможете масштабировать предположительно дорогие части (синтаксический анализ и постановка в очередь) по горизонтали.
Это, безусловно, будет медленнее в «циклах ЦП на запрос», чем когда один сервер просто записывает в файл, но он останется надежным, когда трафик перегрузит одну машину, и вы даже не потеряете данные, если ваш последний последовательный писатель будет завален какое-то время.
Nota bene: (а) то, что интуитивно дорого, не должно быть таковым, используйте исследовательский код и профиль. (б) вы уверены, что не хотите спрашивать хороших специалистов по программированию в переполнение стека? В основном мы делаем здесь системы.
Для веб-части я бы использовал Nginx (lighttpd стареет;)
Для данных:
Лучший способ для такой работы - поискать что-то вроде MapReduce. Hadoop - это бесплатная реализация MapReduce.
Просто сохраните статистику в простой файл и объедините ее в систему «ключ-значение», такую как HBase (часть Hadoop).
Тогда у вас есть полностью избыточное (благодаря HDFS) и масштабируемое решение, которое может обрабатывать петабайты данных.