Согласен, что для более критичных задач специализированная очередь не помешает. Но пока этого достаточно. И масштабирование на данном этапе нет требуется, хотя при необходимости можно будет поднять еще процесс на другом сервере, архитектура пока простая и это позволяет. Сервис позиционируется как облегчение работы с биржами в том числе, но не как их замена.
Да, писал раньше на Django. Спасибо за фидбек, учту пожелания. Пароль специально с типом text, для снижения шанса ввода опечатки в пароль. Для упрощения не стал делать классическую схему с вводом и повтором пароля. Не учел что многие используют программы вроде lastpass, и сохранение пароля браузером. Буду переделывать на обычный.
Тут уже нужен ответ, который тянет на целую статью. Мы соберемся с силами и попробуем описать подробную историю проекта.
Что касается репликации, то от неё мы отказались еще на первый порах — она постоянно слетала и не всегда вовремя срабатывала из-за данные в двух БД разнились. Постоянно приходилось, что-то докручивать. Наверное можно было продолжить настройку и рано или поздно довести её до ума, но мы решили пойти более простым путем. Это было два года назад — возможно сейчас с репликацией у MySQL стало получше.
Движок таблицы MyISAM, поэтому блокирующие запросы вполне объяснимы. На innodb перейти не получилось, при бэкапе вешался сервер.
Статистика подсчитывается и хранится в отдельных таблицах, из которых удобно потом делать выборки.
Очень странно. Единственный возможный вариант — вам звонил кто-то из наших партнеров, которые продвигали наш проект в рамках партнерской программы, тут, сами понимаете, контролировать невозможно.
Однако непосредственно наши сотрудники этого сделать не могли.
Скорее всего вы перепутали нас с какой-то другой компанией, предоставляющей аналогичные услуги. Мы подобными средствами продвижения не занимаемся совершенно точно.
При правильном подходе большинство советов не вызовет значительных задержек. Мы не предлагаем сразу же переводить все на другие языки, сразу же делать шардинг БД и при запуске выставлять API для общественности. Важно держать мысль об этих вещах в голове, тогда можно избежать кучи логических ошибок при написании приложения.
Мы написали в конце статьи, что планируем переход на веб-сокеты в ближайшее время.
Консультант не домохозяйка, а вот обычные посетители, которые заходят на сайты и пишут в консультант не всегда имеют «нормальный» браузер. Но это конечно же можно определять, поэтому не проблема.
У Openfire своя mysql БД, в которую заливаются данные о пользователях из основной базы проекта.
По поводу падений, возможно у Вас заполнился какой-нибудь кэш в Openfire, посмотрите в админке. Давно как-то у нас была проблема, из-за того, что переполнился кэш ростера и openfire начал грузить сервер на 100% CPU.
300 постоянных подключений для openfire это, впринципе, не нагрузка, должно быть причина в другом. Наблюдайте за логами.
Да из MySQL, БД openfire синхронизируется с основной базой пользователей.
Нагрузка Jabber сервер не столь существенна, запас большой, здесь как раз трудностей не возникает :)
Версия последняя — 3.7.1
Да можно сжать визуально до размера экрана девайса, но такой четкости даже близко не будет.
Ибо тут 96dpi у монитора против 240dpi у hdpi-android-телефона.
Что касается репликации, то от неё мы отказались еще на первый порах — она постоянно слетала и не всегда вовремя срабатывала из-за данные в двух БД разнились. Постоянно приходилось, что-то докручивать. Наверное можно было продолжить настройку и рано или поздно довести её до ума, но мы решили пойти более простым путем. Это было два года назад — возможно сейчас с репликацией у MySQL стало получше.
Движок таблицы MyISAM, поэтому блокирующие запросы вполне объяснимы. На innodb перейти не получилось, при бэкапе вешался сервер.
Статистика подсчитывается и хранится в отдельных таблицах, из которых удобно потом делать выборки.
Однако непосредственно наши сотрудники этого сделать не могли.
Консультант не домохозяйка, а вот обычные посетители, которые заходят на сайты и пишут в консультант не всегда имеют «нормальный» браузер. Но это конечно же можно определять, поэтому не проблема.
По поводу падений, возможно у Вас заполнился какой-нибудь кэш в Openfire, посмотрите в админке. Давно как-то у нас была проблема, из-за того, что переполнился кэш ростера и openfire начал грузить сервер на 100% CPU.
300 постоянных подключений для openfire это, впринципе, не нагрузка, должно быть причина в другом. Наблюдайте за логами.
Нагрузка Jabber сервер не столь существенна, запас большой, здесь как раз трудностей не возникает :)
Версия последняя — 3.7.1
Самое то для вдохновения.
serzhb@gmail.com
www.droiddraw.org/
Ибо тут 96dpi у монитора против 240dpi у hdpi-android-телефона.