The Cache: Technology Expert's Forum
 
*
Welcome, Guest. Please login or register. September 16, 2019, 09:48:31 PM

Login with username, password and session length


Pages: [1]
  Print  
Author Topic: PHP in a shell - at what memory cost?  (Read 2502 times)
perkiset
Olde World Hacker
Administrator
Lifer
*****
Offline Offline

Posts: 10096



View Profile
« on: February 13, 2008, 10:54:24 AM »

I am considering an app that needs to emulate multithreading from an ajax call.

My first preference would be to have the app fire off a bunch of Apache calls, which come back instantly yet continue working so that the calling PHP script is not "serially waiting" for each one of the Apache calls to be complete... but I am having a bit of trouble with flushing the buffer out consistently (more work and research to do here). If I can work it out, this is an important part of a scalability plan, so I'd really like to make this work.

But another way is to exec() it with a > /dev/null & suffix and let them run as daemons to get the jobs done... but I am concerned with the load I will place on my system to do this, because I'm firing up a new shell to run a new instance of the PHP interpreter to run my script... they're not long, perhaps 2-3 seconds each and low processor because the majority of the wait is on the client that I am hitting.

I'm just wondering if I get hit with 100 surfers in a single moment and each one fires off 16 tasks what the real cost in terms of memory might look like. Linuxheads seem to be of the opinion that it's quite a hit to fire off another shell for each processing, but what is "quite a hit?" Isn't this exactly how Apache fires things off in a CGI arrangement?

Thanks in advance,
-p


Logged

It is now believed, that after having lived in one compound with 3 wives and never leaving the house for 5 years, Bin Laden called the U.S. Navy Seals himself.
emonk
Rookie
**
Offline Offline

Posts: 44


View Profile
« Reply #1 on: February 14, 2008, 08:43:52 AM »

Quote
Isn't this exactly how Apache fires things off in a CGI arrangement?

 Yeah, and that's part of the reason that you shouldn't run PHP as a CGI, but instead use the apache module. It reduces overhead significantly.

 As for the rest, I don't really know. I'm trying to figure out something very similar myself right now, and I'm pretty stumped. I think I'm just gonna override the maximum execution time, and do a bunch of forking with the whole thing output buffered.

Logged
jammaster82
Lifer
*****
Offline Offline

Posts: 666


Thats craigs list for ya


View Profile
« Reply #2 on: February 14, 2008, 09:50:31 AM »


I'm just wondering if I get hit with 100 surfers in a single moment and each one fires off 16 tasks what the real cost in terms of memory might look like.


Exactly what 16 tasks, can we make an example
task/benchmark app to show it for discussion sake
i am curious as well and would love to do some
experiments here...

« Last Edit: February 14, 2008, 09:52:44 AM by jammaster82 » Logged

The watched pot, never boils... But if you walk away from it , the soup burns.  What gives?
perkiset
Olde World Hacker
Administrator
Lifer
*****
Offline Offline

Posts: 10096



View Profile
« Reply #3 on: February 14, 2008, 11:17:59 AM »

Answered my own question by making this unnecessary.

I polished off my Apache pseudo multithreading notion and posted about it here: http://www.perkiset.org/forum/php/using_php_the_webrequest2_class_and_apache_for_multitasking-t773.0.html;msg5337

WAY WAY WAY Better solution and it is as fast as poop through a goose.
Logged

It is now believed, that after having lived in one compound with 3 wives and never leaving the house for 5 years, Bin Laden called the U.S. Navy Seals himself.
Pages: [1]
  Print  
 
Jump to:  

Perkiset's Place Home   Best of The Cache   phpMyIDE: MySQL Stored Procedures, Functions & Triggers
Politics @ Perkiset's   Pinkhat's Perspective   
cache
mart
coder
programmers
ajax
php
javascript
Powered by MySQL Powered by PHP Powered by SMF 1.1.2 | SMF © 2006-2007, Simple Machines LLC
Seo4Smf v0.2 © Webmaster's Talks


Valid XHTML 1.0! Valid CSS!