У меня одного сомнения в нужности подобных клиентов? Сижу через браузер с телефона и все нормально, не надо что бы кто-то дописал функционал, видео показывается, комменты пишутся.
Полезна ли вам статья или технология? Я до этой статьи не знал об этой технологии и из этой статьи так же не узнал. Пришлось лезть в интернет и гуглить.
Хмм, странная статья. Ожидаешь что тут будет описание технологии доступа к предположительно рухнувшему серверу, а видишь:
Для настройки netconsole нужен другой (постоянно включенный) компьютер который примет сообщение по сети.
и дальше ничего, сразу идут какие-то инструкции. Что будет после того, как другой компьютер примет сообщение по сети? Как связан рухнувший сервер и этот компьютер? Это какая-то магия? Я конечно сейчас пойду, погуглю про netconsole, но всё же…
Он не пишет паттерны снова и снова. Он просто «создает» язык, в котором может наиболее естественно, наглядно и кратко сформулировать решение поставленной перед ним задачи. Профессия становится не ремеслом, а искусством.
Наверное пару раз написав, хочется перейти к готовым решениям? Поделитесь опытом.
По теме, зачем ставить такой выбор, исключения против кодов, ведь можно совместить. На пример в эрланге стандартная практика возвращать что типа {ok, Value} или {error, Reason}: тут тебе и коды возвратов (атомы как енумы), и полезная нагрузка. Паттерн матчинг таких возвратов в случае успеха выполнит нужную логику, в случае неудачи автоматом пробросит ошибку дальше(let it crash)
Извините за то что пишу в этот пост, хотя он уже не очень свежий, но хотелось бы перенять лучшие практики:
выигрыш будет примерно на 5-10 пакетов то есть на 5-10 мс в лучшем случае
это немного не верно.
Основыне затраты соединения не в кол-ве переданных байт, собственно во времени его установления и закрытия. Например в линуксах время ожидания можно посмотреть в "/proc/sys/net/ipv4/tcp_fin_timeout", на федоре это 60с.
Т.к. количество соединений с сервером c одного ip ограничено 65k, оно всё же может исчерпаться: 65535 соединений / 60 с ~ 1093 соед/секунду. Если у вас есть поля с автодополнением, которые дёргают данные из базы, то это не так уж и нереально.
На каждое соединение тратятся соединения как сервера, так и клиента. А если клиент и сервер на одном физическом узле, то *2. Наверное тут нужен коммент от квалифицированного dba, который может сказать что-нибудь про пулы соединений со стороны бд.
про недостатки pconnect вполне ясно: это всякого рода пересечения разных запросов (данные одного, пришли в ответ другом, кстате как на счет того, что при продолжительном запросе, все последущие ждут его выполнения?)
Хотелось бы понять, как взрослые дядьки с большой нагрузкой решают эту проблему.
Круть, только почему вы начали создавать свой гитхаб? Могли бы форкнуть gitorious, запилить приватные репы (там особо пилить не нужно, есть код «почти» рабочий), ну или дописать отсутствующий функционал. А на счёт простоты установки, это как сказать. У меня основные проблемы были не с настройкой бд, сфинкса или mq, а с зоопарком в руби-гемах, который вполне возможно появится и у вас со временем.
Немного не понятно на счет 100% совместимости, может быть хотя бы несколько реальных примеров?
Как будет выглядить в этом формате такое: {
"fruits":["apple", "orange"],
"sport":[{"football" : {"players" : 11, "goalkeeper" : true}, "hockey" : {"players" : 6, "goalkeeper" : true} }]
"note" : null
}
За счет чего прирост производительности по сравнению с gzip+json, тут разве не нужно преобразовывать обратно для работы как на сервере, так и на клиенте?
У нас написана сложная система управления ресурсами, большая часть логики лежит на СУБД, в качестве транспорта между СУБД и клиентом служит php. Так же он отдает представление всех веб-страничек, а-ля шаблонизатор.
Время, потраченное на портирование этого приложения (исключая логику работы с БД) на webmachine затратило полдня. Webmachine удивительно хорошо вписался туда. Так что наверняка есть ниша, кроме REST-API, которую может занять Webmachine. Естественно это не серебрянная пуля.
и дальше ничего, сразу идут какие-то инструкции. Что будет после того, как другой компьютер примет сообщение по сети? Как связан рухнувший сервер и этот компьютер? Это какая-то магия? Я конечно сейчас пойду, погуглю про netconsole, но всё же…
Наверное пару раз написав, хочется перейти к готовым решениям? Поделитесь опытом.
По теме, зачем ставить такой выбор, исключения против кодов, ведь можно совместить. На пример в эрланге стандартная практика возвращать что типа {ok, Value} или {error, Reason}: тут тебе и коды возвратов (атомы как енумы), и полезная нагрузка. Паттерн матчинг таких возвратов в случае успеха выполнит нужную логику, в случае неудачи автоматом пробросит ошибку дальше(let it crash)
это немного не верно.
про недостатки pconnect вполне ясно: это всякого рода пересечения разных запросов (данные одного, пришли в ответ другом, кстате как на счет того, что при продолжительном запросе, все последущие ждут его выполнения?)
Хотелось бы понять, как взрослые дядьки с большой нагрузкой решают эту проблему.
Как будет выглядить в этом формате такое:
{
"fruits":["apple", "orange"],
"sport":[{"football" : {"players" : 11, "goalkeeper" : true}, "hockey" : {"players" : 6, "goalkeeper" : true} }]
"note" : null
}
За счет чего прирост производительности по сравнению с gzip+json, тут разве не нужно преобразовывать обратно для работы как на сервере, так и на клиенте?
Время, потраченное на портирование этого приложения (исключая логику работы с БД) на webmachine затратило полдня. Webmachine удивительно хорошо вписался туда. Так что наверняка есть ниша, кроме REST-API, которую может занять Webmachine. Естественно это не серебрянная пуля.