Я готовлюсь настроить сервер, который будет отвечать за отслеживание статистических данных из источника трафика с большим объемом. Он будет обрабатывать запросы со средней скоростью около 6-7мил/час, все из которых являются небольшими GET. Все, что мне нужно, это простая настройка сервера, который может обрабатывать параметры запроса get и записывать их в CSV-файл.
Первой моей мыслью было использовать lighttpd+fastcgi+php, поскольку это конфигурация, с которой я уже знаком. Но, учитывая, что мне не приходится принимать такие решения по производительности каждый день, я хотел бы изучить другие варианты и посмотреть, нет ли чего-то еще лучшего для этой цели.
решение1
Вы хотите выполнить 6-7 миллионов операций записи в CSV-файл в деньчас?
Серьезно, база данных — это лучшая идея. База данных предназначена для обработки параллельных записей и может масштабироваться вертикально (большая машина, более быстрые диски) или горизонтально (распределение нагрузки на несколько серверов). Запись в один CSV-файл (илилюбойfile) требует некоторой формы блокировки для решения проблем параллелизма и плохо масштабируется по мере увеличения нагрузки ввода-вывода и параллелизма.
Чтобы обойти это, вам, вероятно, придется реализовать собственные уровни кэширования и буферизации, а затем начать распределять нагрузку между несколькими файлами и т. д. и т. п. Используйте какой-либо тип базы данных с самого начала и избавьте себя от множества проблем.
решение2
Учитывая, что вы собираетесь делать около 2000 запросов/сек или 500 мкс/запрос наСРЕДНИЙ(то есть пики гораздо выше), CSV, вероятно, не подойдут из-за затирания записей при параллельных записях, поскольку ничто не гарантирует атомарную запись в ваших файлах.
Одна идея — файлы per-process/per-writer, которые собираются позже, другая идея — использовать базу данных, сильно настроенную на большие объемы записей. Вы также можете взглянуть на очереди сообщений или протоколы групповой связи (например,Распространение), но я не знаю, готовы ли они к такому объему.
Что бы вы ни делали, набросайте несколько быстрых идей и протестируйте их. Текущее оборудование может творить чудеса с производительностью, оптимизируйте только при необходимости. Что касается PHP — убедитесь, что у вас установлен Opcode Cache (например,БТР), в противном случае вы потратите много циклов на ненужную перекомпиляцию скриптов.
Также имейте в виду, как выглядит рост сервиса: вряд ли имеет смысл стремиться к решению, которое будет перегружено через несколько месяцев.
решение3
Какие параметры передаются через запрос GET? Должен ли он быть в CSV/базе данных в реальном времени? Или вы думаете, что можно создать фиктивный файл HTML (или PHP) и просто использовать веб-логи для анализа и выгрузки в CSV позже в качестве пакетного задания? (ладно... это звучит запутанно... но легко в обработке)...
решение4
Я бы посмотрел на server 2008 web edition и использовал ADO.net для записи в CSV-файл. У вас не должно быть проблем с пропускной способностью, так как ado.net будет буферизировать записи.