Как Вы настраиваете тестирование базы данных с помощью платформы PHP SimpleTest
Я помню, что я работал с передачей больших файлов, и я использовал режим buffered для передачи, но это было не лучшее решение, потому что через некоторое время я получил какое-то исключение из-за утечки памяти или чего-то связанного с памятью, я изменил его на [ 111] и все работало нормально, в режиме buffered это означает, что весь контент сообщения присутствует в памяти до его отправки или после его получения. Хотя это хорошая стратегия для большинства сценариев и необходима для таких функций обмена сообщениями, как цифровые подписи и надежная доставка, большие сообщения могут исчерпать ресурсы системы.
взгляните на здесь .
Чтобы не создавать новые буферы постоянно, WCF использует BufferManager для повторного использования буферов, вплоть до предела, указанного в maxBufferPoolSize, buffers, дорого создавать и уничтожать. Вы можете использовать класс BufferManager для управления буферным пулом.
Вы можете попробовать увеличить maxBufferPoolSize , чтобы посмотреть, сможете ли вы уменьшить использование памяти. Я настоятельно рекомендую не увеличивать его до максимума, потому что я думаю, что буферы из пула никогда не освобождаются до тех пор, пока домен приложения не перезапустится. Период большого трафика может привести к тому, что будет использовано много памяти и она никогда не будет освобождена.
Поэтому я рекомендую использовать режим streamed для передачи большого файла.
Чтобы разделить файлы и работать с большими потоками, вам могут помочь ссылки ниже:
Несколько файлов в одном потоке, пользовательский поток
Лучший способ возврата большой файл в виде разделенных zip-файлов, потокового или байтового массива WCF
это также может помочь вам
Несколько потоков в одном потоке не будут правильно переданы клиенту [ 1123]
6 ответов
Мне выделили локальную базу данных поблочному тестированию с известным именем и базой данных, username/password. Модульные тесты были трудно кодированы к тому местоположению, но различные разработчики могли переопределить те переменные, если бы они хотели.
Затем перед каждым тестом Вы TRUNCATE каждая таблица. Это намного быстрее, чем отбрасывание/создание таблиц или самой базы данных.
Примечание: Не усекайте после тестов! Тот путь, если тест приводит Вас к сбою, имеет текущее состояние базы данных, которая часто помогает диагностировать проблему.
Вы могли бы хотеть позволить PHP создавать и данные по запасам к временной таблице / база данных и тест на той таблице/базе данных. Затем Вы не должны сбрасывать свою базу данных вручную. Большинство платформ имеет библиотеки управления базой данных для помощи. Это могло бы занять время во фронтэнде, но позволит Вам протестировать намного быстрее позже при внесении изменений позже.
Тестирование против базы данных обычно указывает на плохие тесты, вероятно, из-за отсутствия инкапсуляции в коде под тестом. Необходимо попытаться изолировать код, который взаимодействует с базой данных от остальной части кода как можно больше, сохраняя этот слой взаимодействия столь простым, что можно сойти с рук некоторые, очень простые тесты.
Другими словами; код, который имеет дело с комментариями, не должен быть тем же кодом, который имеет дело со взаимодействием базы данных. Вы могли - например - пишут универсальный модуль таблицы, что Ваше использование модели комментария для доступа к базе данных. Необходимо было бы все еще протестировать модуль таблицы, но это должно быть сделано в изоляции от кода комментария.
При тестировании кода базы данных хорошо всегда иметь ту же базу данных как начальная точка. Особенно, если Вы делаете поблочное тестирование (который я принимаю, имеет место здесь). Один из путей состоит в том, чтобы усечь все таблицы как предложенного Jason, но я предпочитаю иметь некоторые стартовые данные в нем. Вы знаете, у Вас всегда должны быть некоторые данные 'по умолчанию', которые присутствуют в каждой базе данных.
Кроме того, некоторые тесты только имеют смысл с полной базой данных. Так, создайте специальный экземпляр базы данных для тех тестов. У меня есть приблизительно 3 или 4 различных базы данных, что я плагин (просто копируют файлы в) прежде, чем запустить некоторые тесты. При наличии той же начальной точки каждый раз гарантирует воспроизводимость.
Так, просто подготовьте несколько состояний базы данных, которые являются хорошими 'начальными точками' и создают резервную копию их. Прежде, чем выполнить каждый набор тестов, восстановите соответствующую базу данных и затем выполните его.
Если бы Вы действительно хотите протестировать против базы данных, я рекомендовал бы импортировать таблицы данных/создавать перед каждым тестом. Тем путем Ваша база данных начинает с известного состояния на каждом тесте. Так как это довольно дорого производительностью, можно запустить транзакцию (при условии, что rdms поддерживает ее) в setUp и откат в tearDown. MySql (Который вероятен RDBMS, который Вы используете), не поддерживает вложенные транзакции, поэтому если код под тестом использует транзакции, можно столкнуться с проблемой. Можно обойти это, с помощью точек сохранения. Настройте точку сохранения перед тестированием и откатом к точке сохранения после теста.
Я все еще поддержу, что при необходимости в большой части этого необходимо рассмотреть возможность, что тесты пытаются сказать Вам что-то..
Я поощрил бы Вас не пытаться протестировать использование кода доступа к базе данных SimpleTest.
Вместо этого создайте функциональное испытание для своего использования приложения, например, Селена: запишите тестовый сценарий, когда Вы запустите с известного состояния базы данных; затем добавьте комментарий, и проверка (использующий Селен утверждает), который содержание действительно там.
Таким образом, это: - легче настроить и поддержать - Вы проверяете не только уровень DB, но и уровень представления, также
Тем не менее, если у Вас есть хранимые процедуры в Вашем DB, действительно используйте SimpleTest - я сделал его сам успешно. В основном создайте SimpleTests, которые начинают с известного состояния БД, затем работают, некоторые ВСТАВЛЯЮТ/ОБНОВЛЯЮТ, затем выполняют сохраненный proc и удостоверяются, что состояние DB - то, что Вы ожидали бы.