Какой язык программирования я должен выбрать для своего высокопроизводительного веб-сервиса? [закрытый]
это произошло со мной, потому что я попытался выполнить access UI компонент в another thread insted of UI thread
, как этот
private void button_Click(object sender, RoutedEventArgs e)
{
new Thread(SyncProcces).Start();
}
private void SyncProcces()
{
string val1 = null, val2 = null;
//here is the problem
val1 = textBox1.Text;//access UI in another thread
val2 = textBox2.Text;//access UI in another thread
localStore = new LocalStore(val1);
remoteStore = new RemoteStore(val2);
}
, чтобы решить эту проблему, обернуть любой вызов ui внутри , о чем упоминал Кандид в своем ответе
private void SyncProcces()
{
string val1 = null, val2 = null;
this.Dispatcher.Invoke((Action)(() =>
{//this refer to form in WPF application
val1 = textBox.Text;
val2 = textBox_Copy.Text;
}));
localStore = new LocalStore(val1);
remoteStore = new RemoteStore(val2 );
}
10 ответов
10 000 запросов в секунду являются 25 миллиардами хитов в месяц. Это означает одну из двух вещей:
- Ваше приложение более популярно, чем MySpace; или
- Вы пытаетесь использовать это для передачи между два очень болтливые компоненты, которыми Вы управляете, и это <забастовка>, плохая ужасное проектное решение.
одно только коммутирующее оборудование для распределения так большой загрузки через ферму веб-фронтендов стоило бы много тысяч долларов.
Запускаются путем записи веб-сервиса, который может обработать 50 запросов в секунду (выбор языка не чрезвычайно релевантен). Если Ваше приложение так занято, что Вы регулярно пересекаете тот порог, можно позволить себе нанять кого-то, чтобы работать над масштабирующимся проблемным полным рабочим днем и не иметь для обращений за помощью на свободном Q& сайт.
На основе моего предыдущего опыта я могу дать Вам следующий совет.
- Выбор язык Вы (и возможно другие члены команды) как большинство . Я предпочел бы высокоуровневые языки, потому что аппаратные средства являются быстрыми и дешевыми, но программисты являются медленными и дорогими.
- Дизайн Ваши сервисы к [1 125] быть абсолютно без состояний (никакие сессии!) . Это помогает добавить новые аппаратные средства, поскольку различные экземпляры Вашего сервиса не должны знать друг о друге.
- Дескриптор Ваша обработка асинхронно , поскольку Вы, к счастью, не должны давать клиенту ответ (кроме OK). Если Вы сделаете это синхронно, то Ваш процесс заблокируется, и Ваш уровень запроса отбросит. Хорошее чтение эта статья Wikipedia, и особенно (классик!) проблема C10K .
- Помещенный сервис на многие машины. (в зависимости от скорости Ваших сервисов)
- Помещенный Ваш сервер (серверы) базы данных на другие машины, чем веб-сервисы . Используйте быстрые диски!
- Дескриптор загрузка путем балансировки это с чем-то как:
- Виртуальный сервер Linux, самое производительное решение, потому что это работает в Ядре. Масштабы как безумный. Я использовал его 2003 с ~500req/sec на P3/1GHz с загрузкой ЦП на 0,1%. Может быть соединен для достижения HA. Должен обработать 10000req/sec вполне приятно на единственной машине. Сделайте это после попытки чего-то более простого. Это может быть довольно сложно. Обновление 2018: В наше время это интегрируется в ядро магистрали, таким образом все дистрибутивы должны иметь это как пакет.
- Nginx, легкая конфигурация, очень производительная. Может сделать SSL. Может также действовать как Сервер HTTP и может быть производительное решение для хостинга для Ваших сервисов.
- Лак , кэш HTTP, который может обработать несколько бэкендов. Очень настраивающийся, но не может сделать SSL, таким образом, Вам был бы нужен Nginx перед ним, если Вы хотите зашифровать свой трафик.
- фунт
, очень легкий настроить, но высоко наверху. Хорошая начальная точка. Может сделать SSL.мертвые Проекта с 2011. -
Perlbal, не использовали его, но услышали хорошие вещи.мертвые Проекта с 2013. - или другой обратные прокси .
В 10 000 сообщений в секунду, язык является наименьшим количеством Ваших забот. Намного большей проблемой был бы дизайн Вашей фермы сервера и сети. Я предполагаю, что Вы не планируете выполнение этого на единственном поле?
Хорошо масштабируемые приложения, надежные, распределенные, и использование многоядерных / многопроцессорных систем? Здесь я сразу думаю о Erlang/OTP вместе с Отклонениями от курса как сервер веб-приложения. Отклонения от курса выполняют экстремальную конюшню, и быстрый под экстремальным значением высоко загружаются. И Erlang/OTP как платформа разработан для параллелизма и распределения, вместе с некоторой помощью механизмов к develope стабильному программному обеспечению. Затраты: ориентацией параллелизма с языком функционального программирования не является никакое ООП с Java или C#, синтаксис кажется странным (но является очень прямым и мощным, после того как Вы приняли его), и число сторонних библиотек не так огромно что касается основных языков. Но это стоит того.
Hope это помогает
mue
На том уровне, и так как Вы повреждаете HTTP так или иначе (никакой ответ) Вы могли бы также разработать свой собственный сервер или изменить сервер с открытым исходным кодом.
Запись все это в C или C++ и Вы будете сверкать о максимально быстро.
Масштабируемость затронута больше, чем выбором языка все же.
-Adam
Я видел получение миллиарда сообщений в месяц из единственной машины. Мне записали веб-сервис в c#, это в настоящее время обрабатывает приблизительно 3,5 миллиона сообщений в день. Веб-сервер работает вперед при 3%-й загрузке ЦП. Что означает, что я мог продвинуть его по крайней мере в 20 раз более твердый...
Принятие каждой из Ваших машин имело 4 ядра Xeon Six, 32 ГБ RAM, быстрого дискового массива и высоко оптимизированной базы данных для записей, Вы могли сделать это. Хотя, стоимость каждого сервера находится, вероятно, в $35 тысячах к диапазону за $40 тысяч.
Невнимательный, Ваше узкое место не было бы с C# или Java. Это было бы с сервером базы данных в зависимости от того, как большой это растет. В моем случае это - приблизительно 300 ГБ с удаляемыми 10 ГБ и 10 ГБ, добавляемыми в день.
Можно действительно использовать любой язык через CGI (Общий шлюзовой интерфейс), таким образом, он сводится к производительности. Среди языков Вы перечисляете, я ожидаю, что C# будет самым быстрым. Хорошее сравнение для скорости среди языков Перестрелка Языка
, Если Вы действительно производительность потребности, Вы могли бы хотеть посмотреть в направлении большего количества производительности, ориентировали язык как C или D для обрабатывания запросов.
Все это зависит от того, какое вычисление каждый запрос должен выполнить действительно.
Обновление: Его предназначенный, чтобы быть огнем и забыть веб-сервис. Я предполагаю, что передам простой HTTP обратно 200/OK ответов
No, это не предназначается для работы единственного поля. Его намеченное для работы нескольких полей (говорят 3-4).
, Когда запросы получены, они продвинуты очереди на других машинах, затем они взяты и вставляют Хранилище HBase/Voldemort.
, Поскольку я сказал, его предназначенный, чтобы быть "огнем и забыть" веб-сервис
Вам нужен C llike язык и постараться не писать полный сервер, я предложил бы CGI (который является тем, какой php и т.п. все пробегают так или иначе), серверы Windows предлагают разъем ISAPI ins, но они работают в контексте сервера так утечки памяти, и GPFs удалит сервер. Добавьте к этому неудобство остановки/запуска сервера каждый раз, когда Вы изменяете что-то, CGI/FastCGI смотрит лучше.
Давайте посмотрим на проблемы:
Ввод-вывод: это легко будет самым узким местом в вашей системе. Выберите язык, который обеспечивает лучшую интеграцию с операционной системой хоста и предоставляет расширенную семантику для неблокирования и, при необходимости, поддержку параллелизма.
Данные: SOAP? XML? Вы захотите минимизировать любые ненужные циклы процессора. Что плохого в простом использовании JSon? (И нет никакого божественного предписания, которое гласило бы, что сервер на основе архитектуры REST не может использовать двоичные данные в протоколе ...)
Содержание: Если задействовано какое-либо преобразование данных (например, из текста в число), вам также нужно будет подумать, какой язык предоставляет наиболее эффективные механизмы. Например, в Java (который, кстати, очень сильный кандидат для вас) класс String серьезно загружает процессор.
Java и Erlang - очень хорошие кандидаты. C всегда возможен, но параллельное программирование намного сложнее.