Re: [PHP] Need a tool to minimize HTML before storing in memecache
http://php.net/manual/en/book.tidy.php - Joseph Moniz (510) 509-0775 | @josephmoniz <https://twitter.com/josephmoniz> | GitHub<https://github.com/JosephMoniz> | LinkedIn <http://www.linkedin.com/pub/joseph-moniz/13/949/b54/> | Blog<http://josephmoniz.github.io/> | CoderWall <https://coderwall.com/josephmoniz> "Wake up early, Stay up late, Change the world" On Wed, Apr 17, 2013 at 2:52 PM, Daevid Vincent wrote: > We do a lot with caching and storing in memecached as well as local copies > so as to not hit the cache pool over the network and we have found some > great tools to minimize our javascript and our css, and now we'd like to > compress our HTML in these cache slabs. > > > > Anyone know of a good tool or even regex magic that I can call from PHP to > compress/minimize the giant string web page before I store it in the cache? > > > > It's not quite as simple as stripping white space b/c obviously there are > spaces between attributes in tags that need to be preserved, but also in > the > words/text on the page. I could strip out newlines I suppose, but then do I > run into any issues in other ways? In any event, it seems like someone > would > have solved this by now before I go re-inventing the wheel. > > > > d. > >
Re: [PHP] cyberweaponry
There was the Never Ever No Sanity worm ( http://news.cnet.com/Net-worm-using-Google-to-spread/2100-7349_3-5499725.html ). One variant of it was written in php the other in perl. - Joseph Moniz On Thu, May 31, 2012 at 10:21 AM, Tedd Sperling wrote: > Hi gang: > > This is a little early for Friday's "Open Comment" day, but my memory is > increasingly more short term and by tomorrow I might forget -- so, here goes. > > I watched a interview today where an security expert claimed that the Flame > Virus was written in a scripted language named lua (http://www.lua.org/). > > He said that this was unusual because typically such viruses are written in > languages like Ruby-on-Rails and such. > > So, my question to the group -- has PHP produced any viruses? If not, could > it? If so, can anyone elaborate on the details? > > Cheers, > > tedd > > > _ > tedd.sperl...@gmail.com > http://sperling.com > > > > > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Node.PHP
*bad link in last post http://luvit.io/ -Joseph Moniz On Tue, Apr 3, 2012 at 12:16 PM, Joseph Moniz wrote: > On Fri, Mar 30, 2012 at 5:56 PM, German Geek wrote: >> Maybe stupid question, but is node.php really necessary? If you can program >> PHP and it performs better than node.js, why would you need to have another >> wrapper around things. Why not just program "normal" PHP? > > This is normal PHP in the same sense that node.js is normal > javascript, python-tornado is normal python and ruby-event-machine is > normal ruby. The only difference as stated by micheal was the async > IO. > > On Fri, Mar 30, 2012 at 6:33 PM, Michael Save > wrote: >> Also, I kind of doubt you can outperform node.js with standard PHP. > > On Sat, Mar 31, 2012 at 9:37 AM, Daniel Brown wrote: >> On Fri, Mar 30, 2012 at 21:33, Michael Save >> wrote: >>> Because "normal" PHP is not asynchronous. >>> >>> Also, I kind of doubt you can outperform node.js with standard PHP. >> >> Your doubts are indeed well-grounded. Using node.js (indeed, >> V8-based apps in general) are compiled as native machine code, which >> don't require the added overhead of a parser, such as PHP. > > This has been an on the side just for fun project for me mostly and as > such i originally had the same performance assumptions as stated in > this thread. Basically i was writing this "to get familar with php > internals and to understand what goes into designing such a system". > > You can imagine my surprise when i ran bench marks against the example > server against an equivelant node.js http server and the node.php > implementation was able to respond to twice as many requests per > second (14k req/s) then node.js could (7k req/s). Though i would take > this with a grain of salt as the benchmark is largely unfair seeing > how node.js is much more feature complete and hardend from production > use. Never the less, i was absolutely shocked that this completely > unoptomized and memory leaky node.php implementation i hacked together > in one night was able to run circles around node.js in naive > benchmarks. > > So i was absolutely confused to the performance boost with php so i > started poking around asking people in various freenode channels if > they had any hypothesis on why node.php was able to perform against > node.js. > > I stumbled across a similar project to create a node.lua > implemantation called luvit ( http://www.luvit.io ) and it also > boasted the same exact performance boost vs node.js, thats is luvit > was able to do 2x the requests as node.js in the same amount of time. > > From my exploration on nodes 1/2x performance vs node.php and luvit > (node.lua) it turns out that V8 is fast only when it has to stay in JS > mode. The problem with node like systems is the JS to native code > boundary must be crossed several times to perform IO. So nodejs-core > get's some of it's best performance boosts from reducing the amount of > times JS has to call out to C++. The unfortunate detail is that > node.js like systems get their "power" from doing lots of IO and every > IO operation has to call out to C/C++ so node.js performance really > drags around this gotcha in V8. > > I hold out some hope for native PHP performance tough. If some one > were to invest the time into making a solid JIT based interpreter for > PHP i'm fairly confident based on language characteristics and the > performance characteristics associated with them that a PHP-JIT > implementation would be able to leave V8 in the dust. Mostly due to > explicit lexical scoping in PHP that would offset the Hidden-Class > overhead of V8. > > In terms of PHP-JITs Facebook has already done some initial work on > such a VM, they call it, not surprisingly, hip-hop-virtual-machine ( > http://www.facebook.com/note.php?note_id=10150415177928920 ) and it > already doing almost no optimizations is closer to performance of > compiled PHP via hiphop then it is to interpreted PHP via the de facto > interpreter. > > - Joseph Moniz > > > > With that >> said, compiling PHP (such as with HopHop) would give at least >> comparable performance results. >> >> Still, all in all, I would never discourage someone doing a >> 'node.php' application. While its performance may not be quite as >> good speed-wise, that doesn't mean it can't become more robust, more >> generally-applicable, or even just find niche uses. I've written >> numerous socket servers in PHP for a variety of clients and uses, >> where they made sense (speed of deployment, ease of code-management by >> a number of developers who don't know C, et cetera). I can easily see >> where this could add value. >> >> -- >> >> Network Infrastructure Manager >> http://www.php.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Node.PHP
On Fri, Mar 30, 2012 at 5:56 PM, German Geek wrote: > Maybe stupid question, but is node.php really necessary? If you can program > PHP and it performs better than node.js, why would you need to have another > wrapper around things. Why not just program "normal" PHP? This is normal PHP in the same sense that node.js is normal javascript, python-tornado is normal python and ruby-event-machine is normal ruby. The only difference as stated by micheal was the async IO. On Fri, Mar 30, 2012 at 6:33 PM, Michael Save wrote: > Also, I kind of doubt you can outperform node.js with standard PHP. On Sat, Mar 31, 2012 at 9:37 AM, Daniel Brown wrote: > On Fri, Mar 30, 2012 at 21:33, Michael Save > wrote: >> Because "normal" PHP is not asynchronous. >> >> Also, I kind of doubt you can outperform node.js with standard PHP. > > Your doubts are indeed well-grounded. Using node.js (indeed, > V8-based apps in general) are compiled as native machine code, which > don't require the added overhead of a parser, such as PHP. This has been an on the side just for fun project for me mostly and as such i originally had the same performance assumptions as stated in this thread. Basically i was writing this "to get familar with php internals and to understand what goes into designing such a system". You can imagine my surprise when i ran bench marks against the example server against an equivelant node.js http server and the node.php implementation was able to respond to twice as many requests per second (14k req/s) then node.js could (7k req/s). Though i would take this with a grain of salt as the benchmark is largely unfair seeing how node.js is much more feature complete and hardend from production use. Never the less, i was absolutely shocked that this completely unoptomized and memory leaky node.php implementation i hacked together in one night was able to run circles around node.js in naive benchmarks. So i was absolutely confused to the performance boost with php so i started poking around asking people in various freenode channels if they had any hypothesis on why node.php was able to perform against node.js. I stumbled across a similar project to create a node.lua implemantation called luvit ( http://www.luvit.io ) and it also boasted the same exact performance boost vs node.js, thats is luvit was able to do 2x the requests as node.js in the same amount of time. >From my exploration on nodes 1/2x performance vs node.php and luvit (node.lua) it turns out that V8 is fast only when it has to stay in JS mode. The problem with node like systems is the JS to native code boundary must be crossed several times to perform IO. So nodejs-core get's some of it's best performance boosts from reducing the amount of times JS has to call out to C++. The unfortunate detail is that node.js like systems get their "power" from doing lots of IO and every IO operation has to call out to C/C++ so node.js performance really drags around this gotcha in V8. I hold out some hope for native PHP performance tough. If some one were to invest the time into making a solid JIT based interpreter for PHP i'm fairly confident based on language characteristics and the performance characteristics associated with them that a PHP-JIT implementation would be able to leave V8 in the dust. Mostly due to explicit lexical scoping in PHP that would offset the Hidden-Class overhead of V8. In terms of PHP-JITs Facebook has already done some initial work on such a VM, they call it, not surprisingly, hip-hop-virtual-machine ( http://www.facebook.com/note.php?note_id=10150415177928920 ) and it already doing almost no optimizations is closer to performance of compiled PHP via hiphop then it is to interpreted PHP via the de facto interpreter. - Joseph Moniz With that > said, compiling PHP (such as with HopHop) would give at least > comparable performance results. > > Still, all in all, I would never discourage someone doing a > 'node.php' application. While its performance may not be quite as > good speed-wise, that doesn't mean it can't become more robust, more > generally-applicable, or even just find niche uses. I've written > numerous socket servers in PHP for a variety of clients and uses, > where they made sense (speed of deployment, ease of code-management by > a number of developers who don't know C, et cetera). I can easily see > where this could add value. > > -- > > Network Infrastructure Manager > http://www.php.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Node.PHP
Hey,
So i had my first Hackathon at work last week and my project was to
prototype making a node.js clone using PHP instead of V8. So i
snatched up libuv and joyent's HTTP parser and set off on a 24 hour
coding spree to get something workable. By the time the sun was coming
out the next morning the following code was working.
listen(8080, function($request, $response) {
$response->end("yay, super awesome response");
});
nodephp_run();
?>
The C code that powers it was whipped together really fast and is kind
of hackish as a result. The code has some memory leaks that i haven't
had time to fully track down yet. Some small portions of the code were
borrowed from the phode project.
In a naive benchmark on this simple server VS an equally simple server
in node.js this implementation already out performs node.js in
throughput by being able to serve just under 200% the amount of
requests per second that node.js could. Take that with a grain of salt
though because node.js has much more feature and is much more hardend
from production use. I do believe the PHP binary will have some major
performance gains over V8 as crossing the PHP <--> C barrier seems to
be a much lighter operation then crossing the V8 <--> C++ barrier.
Any help or feedback will be greatly appreciated. The projects source
code can be found here: https://github.com/JosephMoniz/node.php
- Joseph Moniz
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
