Twitter → Twidiko — публикуем видео в твиттере
Короткие видеосообщения
Еще одно применение вашим микрофону и камере. Наш сервис позволяет публиковать короткие аудио- и видеосообщения в твиттере. Все происходит прямо в браузере и дополнительные плагины не нужны.
Так это выглядит в браузере
Серверная оптимизация → Обслуживание тысяч запросов в секунду на примере XBT Tracker
Недавно проводили тест, результаты которого показали, что одно приложение обрабатывает 2000 запросов в секунду на скромном сервере, где это было не единственной нагрузкой. При этом результат каждого запроса записывается в 3-5 таблиц в MySQL. Честно говоря, меня такой результат удивил, поэтому решил поделиться с хабрасообществом описанием архитектуры этого приложения. Подобный подход применим от баннерных показов до чатов и микроблогов, надеюсь кому-нибудь покажется интересным.
Во-первых, это приложение однопоточное. Всё делается одним процессом, работа с сокетами — неблокирующими epoll/select, никаких ожидающих ввода/вывода потоков (threads). С развитием HTTP, сначала появлением Keep-Alive, затем AJAX и набирающим популярность COMET, количество постоянных соединений с веб-сервером растёт, на нагруженных проектах измеряется тысячами и даже десятками тысяч, и если для каждого создавать свой поток (thread) со своим стеком и постоянно переключаться между ними — ресурсов сервера очень быстро не хватит.
Второй ключевой момент — что один SELECT… WHERE pk in (k1, k2, ..., kN) выполняется быстрее, чем несколько SELECT… WHERE pk=… Выполняя работу с базой данных большими пачками можно уменьшить не только число запросов в секунду, но и общую нагрузку.
Во-первых, это приложение однопоточное. Всё делается одним процессом, работа с сокетами — неблокирующими epoll/select, никаких ожидающих ввода/вывода потоков (threads). С развитием HTTP, сначала появлением Keep-Alive, затем AJAX и набирающим популярность COMET, количество постоянных соединений с веб-сервером растёт, на нагруженных проектах измеряется тысячами и даже десятками тысяч, и если для каждого создавать свой поток (thread) со своим стеком и постоянно переключаться между ними — ресурсов сервера очень быстро не хватит.
Второй ключевой момент — что один SELECT… WHERE pk in (k1, k2, ..., kN) выполняется быстрее, чем несколько SELECT… WHERE pk=… Выполняя работу с базой данных большими пачками можно уменьшить не только число запросов в секунду, но и общую нагрузку.
Персональные блоги → Что внутри высоконагруженных сервисов?
По роду деятельности интересуюсь различными аспектами реализации высоконагруженных сервисов, тут возник вопрос, на чем же лучше всего делать сервис расчитанный на многомиллионный сайт. Правильный ответ конечно зависит от того кто его будет разрабатывать, то есть кто какой язык хорошо знает.
Но интересно было наткнуться на вот такую табличку, которая собственно показывает тенденции разработки highload структур.
Чуть попозже я сделаю такую же табличку для российских стартапов, думаю многим будет интересно на чем они работают.
Также кому интересна эта тема как и мне,
рекоммендую периодически заглядывать на сайт
http://highscalability.com/
п.с.спасибо что добрые люди подняли карму до 1, что позволило этот первый пост написать;)
п.с.2 какие то проблемы версткой.
Но интересно было наткнуться на вот такую табличку, которая собственно показывает тенденции разработки highload структур.
Чуть попозже я сделаю такую же табличку для российских стартапов, думаю многим будет интересно на чем они работают.
Также кому интересна эта тема как и мне,
рекоммендую периодически заглядывать на сайт
http://highscalability.com/
п.с.спасибо что добрые люди подняли карму до 1, что позволило этот первый пост написать;)
п.с.2 какие то проблемы версткой.
Переводы → What's all this fuss about Erlang?
by Joe Armstrong
Никто не в состоянии предсказывать будущее — но я сделаю несколько обоснованных предположений.
Предположим, что Intel правы, что их проект Keifer выстрелит. Если это случится, то 32-х ядерные процессоры появятся на рынке не позже 2009-2010.
Ничего удивительного здесь нет. Sun уже продает восьмиядерные Niagara с 4-мя «hyperthreads» на каждом ядре, что эквивалентно 32-ум ядрам.
Это разработка, которая осчастливит программистов на Erlang. Они 20 лет ждали этого события, и теперь настало время расплаты.
Хорошие новости для Erlang-программистов:
На N-ядерном процессоре ваша программа будет работать в N раз быстрее.
Никто не в состоянии предсказывать будущее — но я сделаю несколько обоснованных предположений.
Предположим, что Intel правы, что их проект Keifer выстрелит. Если это случится, то 32-х ядерные процессоры появятся на рынке не позже 2009-2010.
Ничего удивительного здесь нет. Sun уже продает восьмиядерные Niagara с 4-мя «hyperthreads» на каждом ядре, что эквивалентно 32-ум ядрам.
Это разработка, которая осчастливит программистов на Erlang. Они 20 лет ждали этого события, и теперь настало время расплаты.
Хорошие новости для Erlang-программистов:
На N-ядерном процессоре ваша программа будет работать в N раз быстрее.