Производительность PHP
Вам нужно назначить соединение с SqlCommand, вы можете использовать конструктор или свойство :
cmd.InsertCommand = new SqlCommand("INSERT INTO Application VALUES (@EventLog, @TimeGenerated, @EventType, @SourceName, @ComputerName, @InstanceId, @Message) ");
cmd.InsertCommand.Connection = connection1;
Я сильно рекомендуем использовать using-statement для любого типа, реализующего IDisposable, например SqlConnection, он также закроет соединение:
using(var connection1 = new SqlConnection(@"Data Source=.\sqlexpress;Initial Catalog=syslog2;Integrated Security=True"))
{
SqlDataAdapter cmd = new SqlDataAdapter();
using(var insertCommand = new SqlCommand("INSERT INTO Application VALUES (@EventLog, @TimeGenerated, @EventType, @SourceName, @ComputerName, @InstanceId, @Message) "))
{
insertCommand.Connection = connection1;
cmd.InsertCommand = insertCommand;
//.....
connection1.Open();
// .... you don't need to close the connection explicitely
}
}
Кроме того, t нужно создать новое соединение и DataAdapter для каждой записи в foreach, даже если создание, открытие и закрытие соединения не означает, что ADO.NET будет создавать, открывать и закрывать физическое соединение, но просто смотрит в пул соединений для доступного соединения. Тем не менее это лишние накладные расходы.
10 ответов
Профиль. Профиль. Профиль. Я не уверен, существует ли что-нибудь там для PHP, но должно быть просто записать немного инструмента для вставки профильной информации в код. Вы захотите представить функциональные времена и времена SQL-запроса.
Поэтому, где у Вас есть функция:
function foo($stuff) {
...
return ...;
}
я изменил бы его на:
function foo($stuff) {
trace_push_fn('foo');
...
trace_pop_fn('foo');
return ...;
}
(Это - один из тех случаев, где несколько возвратов в функции становятся помехой.)
И SQL:
function bar($stuff) {
trace_push_fn('bar');
$query = ...;
trace_push_sql($query);
mysql_query($query);
trace_pop_sql($query);
trace_pop_fn('bar');
return ...;
}
В конце, можно генерировать полную трассировку выполнения программы и использовать все виды методов для идентификации узких мест.
Нет никакого волшебного решения, и пытающийся предоставить универсальные решения могла просто быть пустая трата времени.
, Где Ваши узкие места? Например, Ваш процессор/база данных/интенсивно использующий память сценариев?
Вы выполнили какое-либо профилирование?
Последуйте части другого совета сначала как профилирование и принятие хороших решений распределения ресурсов, например, кэширование.
кроме того, примите во внимание производительность внешних ресурсов как Ваша база данных. В MySQL можно проверить журнал медленного запроса , например. Кроме того, удостоверьтесь, что Вы не разработали свою базу данных забытие об этом. Оптимизация Ваших запросов ( снова для MySQL ) против реальных данных может заплатить больших.
Одна разумная техника, которая может легко быть осуществлена полка, кэшируется. Огромное количество времени имеет тенденцию входить в генерацию ресурсов для клиентов, которые распространены между запросами (и даже через клиенты); устранение этой работы во время выполнения может привести к поразительным увеличениям скорости. Можно вывести сгенерированный ресурс (или фрагмент ресурса) в файл вне веб-дерева, и затем читать, это въезжает задним ходом при необходимости. Очевидно, некоторое профилирование будет необходимо, чтобы гарантировать, что это на самом деле быстрее, чем регенерация - сдерживание веб-сервера к диску регулярно может быть вредным, таким образом, ресурс действительно должен иметь тяжелое повторное использование.
Вы могли бы также быть удивлены, сколько времени проведено внутренние плохо записанные запросы базы данных; общие сгенерированные запросы времени и видят, могут ли они быть переписаны. Количество времени, проведенное, выполняя фактический код PHP, вообще симпатично ограниченный, если Вы не используете некоторые субоптимальные алгоритмы.
Ни один из них не ограничен PHP, хотя некоторые PHP "magicy" подходы/функции могут чрезмерно защищать один от размышления об этих проблемах. Например, я недавно обновил сценарий, который использовал array_search для использования двоичного поиска по сортированному массиву и получил ожидаемое экспоненциальное ускорение.
Те я могу думать...
-
инварианты Цикла всегда являются хорошим для наблюдения.
-
Запись E_STRICT и совместимый код E_NOTICE, особенно если Вы регистрируете ошибки.
-
Избегают оператор.
-
Полные пути для требуют и включают.
-
ремни для правки бритв Использования, str_replace и т.д. вместо регулярных выражений, когда это возможно.
Тогда существует набор других методов, которые могли бы работать, но вероятно привычка приносит Вам много пользы.
Я ответственен за большую систему отчетности, и мы отслеживаем самые медленные отчеты отчасти как этот. Я запускаю уникальный ключ в дб, когда отчет запускается и затем когда это заканчивается, я могу определить, сколько времени это взяло. Я использую базу данных, потому что тот способ, которым я могу обнаружить, когда тайм-аут страниц (который происходит намного больше, чем, я хотел бы)
Каждый раз, когда я смотрю на проблемы производительности, я думаю, что лучшая вещь сделать время, сколько времени Ваши страницы берут, чтобы работать, и затем посмотреть на самые медленные. Когда Вы получаете эти реальные метрики, можно часто улучшать производительность относительно самых медленных порядками величины, или путем фиксации медленного SQL-запроса или возможно закручивания кода немного.
Это, конечно, не требует никаких новых аппаратных средств или специального программного обеспечения, просто критический взгляд на существующем коде.
Однако это будет только работать так долго..., если Вы действительно заставите достаточно трафика поражать пределы Ваших аппаратных средств, и/или существует некоторый код, который является просто по сути медленным и действительно необходимым, необходимо будет посмотреть на другие возможности.
Действительно рассмотрите использование профилировщика XDebug: помогает с проверкой, насколько определенная функция выполняется против того, что Вы ожидали бы.
я пытаюсь уменьшить инструкции при улучшении удобочитаемости кода путем замены логики поисками массива в надлежащих случаях. Это - то, что Jeff Atwood записал в [Лучший Код не является Никаким Кодом Вообще] [1].
- кроме того, избегайте циклов в другом цикле, и вложенный если/еще операторы.
- Короткие функции. Иногда много кода не должно быть выполнено, когда значение результата уже известно.
-
Ненужное тестирование:
, если (количество ($array) === 0) возврат;
может также быть записан как:
, если (! $array) возврат;
Другой вызов функции устраняется!
[1]: http://www.codinghorror.com/blog/archives/000878.html "Лучший Код не является Никаким Кодом В Весь"
включая файлы является медленным, и требование их еще медленнее. Если Вы будете использовать __ автозагрузка для включения каждого класса тогда, то это сложит. например.
я всегда немного опасаюсь пытаться быть слишком умным с точки зрения оптимизации кода, если она жертвует ясностью кода. Если бы необходимо сделать код неясным для создания его быстро, не было бы более дешево обновить hardwear вместо того, чтобы тратить впустую время, пытаясь настроить код? Циклы процессора являются более дешевыми, чем циклы программиста, в конце концов.
Rasmus Lerdorf дал некоторые хорошие советы в своем недавнем представлении" Простой, Тверд " в FrOSCon '08. Если Вы используете кэш байт-кода (и действительно необходимо использовать один), включайте путь, который промахи повреждают много, поэтому оптимизируйте require/require_once.