Сжатие содержания с PHP ob_start () по сравнению с Apache Deflate/Gzip?
Peter Cooper имеет хороший список из приемов Ruby. Возможно, мой фаворит его позволяет и единственным объектам и наборам быть перечисленными. (Таким образом, рассматривайте необъект коллекции как набор, содержащий просто тот объект.) Это похоже на это:
[*items].each do |item|
# ...
end
1 ответ
We're running... a lot of webservers, handling 60M/uniques/day. Normally this isn't worth mentioning but your question seems based on experience.
We run with doing it in apache. What comes out the other end is the same (or near enough so as to not to matter) regardless of the method you choose.
We choose apache for few reasons:
- Zero maintenance, we just turned it on. No one needs to maintain some case structure
- Performance, in our tests servers where Apache did the work faired marginally better.
- Apache will apply the output filter to everything, as opposed to just PHP. On some occasions there are other types of content being served on the same server, we'd like to compress our .css and .js
One word of warning, some browsers or other applications purposefully mangle the client headers indicating that compression is supported. Some do this to ease their job in terms of client side security (think applications like norton internet security and such). You can either ignore this, or try to add in extra cases to re-write requests to look normal (the browsers do support it, the application or proxy just futzed it to make its own life easier).
Alternatively, if you're using the flush() command to send output to the browser earlier, and you're applying compression you may need to pad the end of your string with whitespace to convince the server to send data early.