Tark

Александр Александров, обратите внимание, что значения всего два - ровно по количеству воркеров uwsgi.

Если никто не против, расскажу небольшую историю. Когда-то, когда я писал первое приложение на Flask, я решил, что постоянно драть сервер БД ради практически неизменных данных неразумно, и кешировал их локально. Локально, Карл! В переменных. И передавал их в шаблонизатор. А потом я выложил своё творение в сеть и тоже поставил два воркера на uwsgi. И стоило мне добавить раздел меню, как я получал странную ситуацию: на части запросов сайт отображался с созданным меню, а иногда показывалась "старая" версия. Что логично, локально (на дев-сервере) всё работало замечательно.

Roman Kitaev всенепременно прав, в коде ошибка, не в nginx и не в uwsgi.

UPD: дело в том, что воркеры uwsgi запускают изолированные процессы, каждый со своим набором данных, соединением с БД/кешами прочими няшностями. Локально в таком случае ничего нельзя хранить. Если очень хочется, стоит присмотреться к асинхронным фреймворкам с единственным процессом.

Попробуйте /create_new_question/9/

(?P<id>\d+) - https://docs.djangoproject.com/en/1.8/topics/http/...

А зачем вы делаете jsonify? Передавайте прямо так в шаблон, списком обьектов, а в шаблоне работайте как с обьектами. user.id etc...

Если нужно именно убрать избыточность и при условии, что код будет вызываться только вашим приложением, то можно его изменить таким образом.

class Vehicle(API):
    def get(self, endpoint='/tanks/stats/', lang='ru', fields='', account_id=''):
        if type(fields) is list:
            fields = self._format_fields(fields)	
        return self._api_call(endpoint=endpoint, 
                              fields=fields, 
                              language=lang, 
                              account_id=account_id)

vehicle = Vehicle(...)

stats = vehicle.get()
achievements = vehicle.get('/tanks/achievements/')

Если же этот код вызывается кем-то ещё, то сами понимаете...

Да, будет.

Можете просто проверить, .explain() или .explain('executionStats') для 3.0.х

Вариант первый, не очень хороший:

from flask import Flask
import test  # именно так

app = Flask(__name__)

@app.route('/')
def main_page():
    # постоянно актуальная информация, даже если переменная изменится в другом месте
    return test.text

if __name__ == '__main__':
    app.run()

Это плохо тем, что работать будет только с одним воркером. То есть если у вас uwsgi, скажем, с двумя процессами, то часть запросов будет попадать на "старое" значение test.text. Если принудительно работать с одним воркером, будет работать правильно.

Вариант второй, получше: использовать кеш или БД.

> непонятно откуда берется нужное количество показов баннера
Оно берётся из файла; "10" в конце первой строки, например. Дело в том, что обычно покупают показы баннеров, а не время их размещения: если показывать один и тот же баннер постоянно, то он сильно примелькается, поэтому продают тысячи показов и чередуют баннеры в случайном порядке.

> зачем даны их id
Этакий primary key. Возможно, тут - для облегчения выдачи случайного баннера. Можно просто выбрать случайное число от 0 до последнего и выдать баннер, который ему соответствует.

Вам остаётся лишь как-то сохранять данные о том, сколько раз какой из баннеров показан, и проверять это при выдаче.

К сожалению, Питон строки показывает только в строках, а списки и словари будут выдавать такую вот пакость.
Сделайте
'\n'.join(error)
Или
'<br />'.join(error)
в предыдущем вашем вопросе.

Есть три варианта решения этой проблемы, два из них одинаково плохи, а третий универсален.

location / {
    rewrite ^(\d+)/(\d+)$ /index.php?a=$1&b=$2 last;
    .... 
    try_files $uri $uri/ /index.php?a=$uri;
}

Это плохо тем, что для КАЖДОГО запроса будет проверяться, не соответствует ли строка одному из заявленных регекспов. Для каждого запроса, включая стили, скрипты и статику. Насчёт last в рейврайте не уверен.

location ~* /(\d+)/(\d+) {
    rewrite ^(\d+)/(\d+)$ /index.php?a=$1&b=$2 last;
}

location / {
    try_files $uri $uri/ /index.php?a=$uri;
}

Этот способ плох тем, что придётся повторять регексп в локейшне. Насчёт last в реврайте опять же не уверен.

location / {
    try_files $uri $uri/ /index.php?a=$uri;
}

Самый уверсальный способ. Единая точка входа, роутингом рулит PHP. Идеально.

Кешировать стоит как раз те данные, которые постоянно нужны.

Постойте, у вас пользователь ждёт полторы секунды на загрузку каждой страницы - и не за счёт огромного количества данных, а потому, что эти данные заново собираются? Но это же RoR-приложение, самописное, я правильно понимаю? То есть у вас есть доступ к коду, который всё это показывает и к коду, который вызывается, когда транзакции добавляются? Тогда при обновлении транзакций делайте кеш для этого пользователя "протухшим", а в коде, который всё это хозяйство формирует, заново добавляйте кешированный результат в memcached и показывайте его. Тогда в следующий раз актуальный кеш будет выбран из системы кеширования, но на это потребуется в полторы тысячи раз меньше времени, а данные будут всё время актуальными.

Я не работаю с Django. Мне стало интересно, и я запросил у гугла информацию по вопросу "CommandError: Unable to serialize database: no such table: easy_select2_related". Да, прям вот всю нижнюю строчку скопировал. Первая ссылка ведёт на тостер (!), а вторая - на stackoverflow.com/questions/18313703/dumpdata-with... . Обращайтесь, если нужно будет что-нибудь ещё поискать.

Pure Python не применяется в веб-разработке потому, что... придётся писать свой веб-сервер, который будет слушать 80-ый порт, принимать запросы и вертать взад ответы. Хотя постойте, зачем писать веб-сервер? Есть же nginx! А приложения на Python веб-сервер отдаёт через uwsgi. Да! Тогда надо написать что-то, что будет отдавать в uwsgi сгененированный ответ. Получится что-то типа Werkzeug (часть Flask). Или что-то типа Gevent. Или что-то типа Twisted. Или что-то типа Tornado. Или что-то типа wheezy.web. Что-то, что называется WSGI-сервером. А потом на нём придётся сделать что-то типа фреймворка Bottle, чтобы можно было быренько и красиво делать то, ради чего это всё было написано.

Но... Тут возникают странные мысли насчёт того, есть ли в этом смысл? Может, стоит переложить эту задачу на чужие плечи? Даже в этом ответе уже есть до черта WSGI-серверов, которые написаны людьми, куда более сведущими в этом вопросе. Может быть, стоит сосредоточиться на самом процессе написания приложений, используя уже готовые фреймворки? Рождение ещё одного фреймворка не сделает мир лучше.