Ограничения и ограничения heroku

Question

Я многое видел о ограничениях, которые Google накладывает на App Engine, но я не смог найти много ограничений и ограничений для Heroku для сравнения. Есть ли какие-либо, и если да, то конкретно, каковы они?

Связанный с этим вопрос заключается в том, что я вижу, что у Heroku есть база для сторонних дополнений. Но если я хочу функцию, охватываемую одним из этих дополнений, ограничусь ли я этим использованием или могу ли я приобрести ее у любого поставщика, которого я выбираю, или даже сам код? Было бы разумно, что я мог бы сам его закодировать, вот в чем все эти платформы, но это не значит, что нет ограничений, которые возвращают меня к исходному вопросу.

FYI, я использую Python 2.7 и Django 1.6.1, если это имеет значение для вашего ответа. И я знаю о полемике с rapgenius, но я не ожидаю, что любое обслуживание будет совершенным все время, поэтому я не уверен, что это важно.

Answer 1

Дополнительную информацию о границах Heroku вы найдете в Acceptable Use Policy. Там также есть статья "Limits" о Dev Center.

Вы можете использовать любой сервис, который вам нравится в ваших приложениях Heroku, будь то в дополнительном каталоге, вне его или независимо от того, используете ли вы его самостоятельно.

Answer 2

• Heroku имеет 30 second request timeout, который не может быть сконфигурирован. Это означает, что через 30 секунд запрос будет прерван, но ваш код будет продолжать работать, делая этот конкретный dyno недоступным. Если пользователь затем обновляет страницу и запускает ту же самую длительную операцию с другим динамо, этот другой динамо может также стать недоступным ...

• Heroku имеет эфемерную файловую систему. Это означает, что вы не можете загружать файлы непосредственно в файловую систему: они будут удалены при перезагрузке. Вам нужно будет настроить внешнее хранилище, например. Храните файлы в облаке S3. Обратите внимание, однако, что это потенциально может сделать ваши личные файлы общедоступными, поэтому я предполагаю, что вам может понадобиться еще один уровень сложности, например. создать одноразовую ссылку для использования пользователем для загрузки частного файла с очень коротким сроком действия. Если, т. Е. Вы не реализуете какое-то настраиваемое решение, которое может передать вашу аутентификацию пользователя из Heroku в AWS, но тогда вы, возможно, просто разместите на AWS в первую очередь.

• По той же причине вы не можете использовать SQLite как базу данных, поскольку она основана на файлах. Если вы это сделаете, вы получите непоследовательные результаты. То же самое касается кэширования на основе файловой системы, которое по умолчанию используется для некоторых библиотек django. Прежде чем я это понял, я иногда получал другой аватар для пользователя (новый или старый), предположительно в зависимости от того, какой процесс обслуживал мой запрос.

• Непросто отлаживать непосредственно на Heroku. Вы не можете просто вставить import pdb; pdb.set_trace() в разные места и удаленно запустить python manage.py runserver, потому что это не позволит вам сделать это по соображениям безопасности.