Page 1 of 2 12 Last
  • Jump to page:
    #1
  1. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jul 2013
    Posts
    9
    Rep Power
    0

    Multithreading in PHP


    Since the beginning of civilization: what people do not know, they make up. It's likely that soon enough, PHP programmers will start to come across the pthreads extension and wonder just how it works and if it is suitable for them.

    In an effort to squish rumors before they are allowed to start, I have dotted around the internet a few short (unique) blurbs about pthreads and how it works, and what you might use it for, this is one such blurb ... enjoy ...

    Since the very first release of PHP4 ( May 2000 ), the PHP interpreter has been equipped to execute isolated instances of it's interpreter in multiple threads. This forms the basis of multithreaded SAPI support in PHP. Over the last 13 years this ability has been maintained and developed, and is deployed on some of the worlds largest websites, and no doubt, a squillion intranets we'll never know about. Dispite rumor, PHP at the core, is very thread safe. Additionally, the vast majority of extensions are also thread safe. PHP is perfectly usable in a multi-threaded environment. There's a good chance that during your time as a PHP developer you have read that multithreaded SAPI's are evil and PHP cannot handle it: this is simply wrong, nuff said.

    In the year 2000, multi-core single processor systems were science fiction, if they had been thought of at all. If you had said to me then that in 10 years I would be writing this message, in my pants (at home), using 8 cores on a single chip, I would have told you to shut up, and pass the joint ... PHP already had a defined method of scaling, "add hardware", it worked well for the people using it on the level where scale was an issue. Multi-threading in user land was never a concern for the PHP team, and it is still not today ( for many reasons ). We now live in the future, where people sit around in their pants using 8 cores and 16gb of ram to listen to music and go on facebook and spy on their friends and family, it's a pretty crazy place ... I digress ...

    We live in a world where almost every CPU being sold in massive numbers (even in the embedded market) have multiple cores, multi-threading of their operations is the only way to get by and helps us to run entire operating systems in our pockets. PHP was missing out, in a big way ... sometime last year, I had some holiday from work. This was the first break I had in three years, so I decided that I would write something very geeky. I had just spent the former three years working in Java on a system that utilized concurrency like there was no tomorrow, I excel at this, more over, I thoroughly enjoy squeezing all I can from whatever hardware I am given. I also LOVE writing in PHP, despite everything that is apparently wrong with it, the word is addicted. After 5 days, pthreads was born, an object orientated multithreading implementation for the PHP interpreter that you could load as an extension ... clearly, it sucked, I've since spent many many months and a million nights on it, pthreads is as I imagined in the beginning, more or less...

    So, future beings, PHP can multi-thread in user land ... but what does that actually mean, how is it done, where can you use it ...

    pthreads only utilizes bundled functionality to provide user land threads. The threads it creates, like those created by a multi-threaded SAPI, are completely isolated from one another. The job of pthreads is to allow safe synchronization and communication between the threads, breaking the isolation in a controlled manner to provide functionality. Pretty simple really, right ?

    Like a multi-threaded SAPI, PHP must be compiled with Zend Thread Safety enabled, and if you intend to use pthreads at the frontend, you must have a worker mpm httpd. There are no other restrictions, again, nice and simple.

    pthreads is not voodoo, nor is it unsafe, it doesn't make PHP do anything that it was not intended to do, it has as much compatibility as any other extension (that is, you can use it with nearly any other extension).

    That's all I have to say about that ...

    If you have any questions, ask
  2. #2
  3. No Profile Picture
    Dazed&Confused
    Devshed Novice (500 - 999 posts)

    Join Date
    Jun 2002
    Location
    Tempe, AZ
    Posts
    506
    Rep Power
    128
    Mr. Watkins, I presume?

    I was hoping to tinker with it at work today but it doesn't look like that'll be happening. I'm limited to WAMPServer here and it doesn't look like I'm able to add "threads" to Apache or PHP, nor ZTS to PHP.

    As I *think* those are the prerequisite configs, I'm stuck for now.
  4. #3
  5. No Profile Picture
    Dazed&Confused
    Devshed Novice (500 - 999 posts)

    Join Date
    Jun 2002
    Location
    Tempe, AZ
    Posts
    506
    Rep Power
    128
    Some progress, though it took a little while to get into the groove. Maybe I was looking wrong but I didn't see a simple example showcasing parallel processing, so wasn't sure for a while if my config was right.

    Something like the below might be beneficial to newcomers:

    PHP Code:
    <?php
        
    class Foo extends Stackable {
            public 
    $counter;
            public function 
    __construct(){
                
    $this->counter 0;
            }
            public function 
    run(){}
        }

        class 
    Process extends Worker {
            private 
    $text "";
            public function 
    __construct($text,$object){
                
    $this->text $text;
                
    $this->object $object;
            }
            public function 
    run(){
                while (
    $this->object->counter 10){
                    print 
    $this->object->counter++." - {$this->text}\n";
                    
    sleep(1);
                }
            }
        }

        
    $foo = new Foo();

        
    $a = new Process("A",$foo);
        
    $a->start();

        
    $b = new Process("B",$foo);
        
    $b->start();
    It demonstrates both parallelism as well as sharing an object between threads (assuming what I have is the right way of doing it...)

    A couple oddities I've found so far:

    With the sleep() after the print it only prints up to 9. If you move the sleep() before the print it prints 10 also. It seems like this should make sense but I can't quite put my finger on the reasoning...

    This doesn't work:
    PHP Code:
    (new Process("A",$foo))->start();
    (new 
    Process("B",$foo))->start(); 
    It's like the B thread just isn't created. The constructor doesn't even seem to execute.

    Otherwise it's pretty neat so far...
  6. #4
  7. No Profile Picture
    Dazed&Confused
    Devshed Novice (500 - 999 posts)

    Join Date
    Jun 2002
    Location
    Tempe, AZ
    Posts
    506
    Rep Power
    128
    Another issue I'm having is with static property scope.

    I can pass an instantiated object into multiple threads and each thread's changes transcend them nicely. But I can't figure out how to give static properties the same cross-thread scope. Instead each thread is getting its own scope of the respective static properties.

    For giggles I also tried old school globals (ew) and super-globals, and the behavior is the same--they become limited to the scope of the thread.

    I could probably code around this given enough time. It'd just take a decent amount of effort to move all my multiton logic from its respective classes into a central factory class. But that's about the only time I rely on global-scope static properties.
  8. #5
  9. No Profile Picture
    Dazed&Confused
    Devshed Novice (500 - 999 posts)

    Join Date
    Jun 2002
    Location
    Tempe, AZ
    Posts
    506
    Rep Power
    128
    Working on a proof of concept now, for my multithreaded socket server. Got the server/client working with an object holding state between multiple connections (and threads), so... so far so good.

    I'll be upping the diagnostics tonight with memory monitoring, thread monitoring, stress testing, etc.
  10. #6
  11. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jul 2013
    Posts
    9
    Rep Power
    0
    Originally Posted by dmittner
    Another issue I'm having is with static property scope.

    I can pass an instantiated object into multiple threads and each thread's changes transcend them nicely. But I can't figure out how to give static properties the same cross-thread scope. Instead each thread is getting its own scope of the respective static properties.

    For giggles I also tried old school globals (ew) and super-globals, and the behavior is the same--they become limited to the scope of the thread.

    I could probably code around this given enough time. It'd just take a decent amount of effort to move all my multiton logic from its respective classes into a central factory class. But that's about the only time I rely on global-scope static properties.
    Static members are a kind of thread local storage; Zend does not execute object handlers for changes to static members (they have an entry scope, not object), and so when a new thread is created complex statics are stripped leaving basic data intact, so objects/resources are thread local, but simple data, is made available in the static scope. This means that the static scope can be used to store connection information, for example, and the connection resource/object, but pthreads doesn't touch the object/resources (so it will work completely as expected from the static scope).

    Hopefully that clears that up for you ... look forward to hearing what happened next
  12. #7
  13. No Profile Picture
    Dazed&Confused
    Devshed Novice (500 - 999 posts)

    Join Date
    Jun 2002
    Location
    Tempe, AZ
    Posts
    506
    Rep Power
    128
    Originally Posted by krakjoe
    Static members are a kind of thread local storage; Zend does not execute object handlers for changes to static members (they have an entry scope, not object), and so when a new thread is created complex statics are stripped leaving basic data intact, so objects/resources are thread local, but simple data, is made available in the static scope. This means that the static scope can be used to store connection information, for example, and the connection resource/object, but pthreads doesn't touch the object/resources (so it will work completely as expected from the static scope).

    Hopefully that clears that up for you ... look forward to hearing what happened next
    So by "simple data" you just mean stuff that wouldn't be changed within a thread context?

    Take the following:
    PHP Code:
    <?php
        
    class Foo {
            public static 
    $counter 0;
        }

        class 
    Process extends Worker {
            private 
    $text "";
            public function 
    __construct($text){
                
    $this->text $text;
                
    $this->start();
            }
            public function 
    run(){
                while (
    Foo::$counter 4){
                    print 
    Foo::$counter++." - {$this->text}\n";
                    
    sleep(2);
                }
            }
        }

        
    $a = new Process("A");
        
    sleep(1);
        
    $b = new Process("B");
    Foo::$counter is entered into the thread scope but changes to it within the thread remain only in that thread. So the output of the above is:

    Code:
    0 - A
    0 - B
    1 - A
    1 - B
    2 - A
    2 - B
    3 - A
    3 - B
    Where if it had full global static scope it'd be:

    Code:
    0 - A
    1 - B
    2 - A
    3 - B
    But I think I'm just verifying what you said.

    This'll unfortunately rule out using all this for my existing app. It'd just take too much work to convert everything that'd need it.
  14. #8
  15. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jul 2013
    Posts
    9
    Rep Power
    0
    Originally Posted by dmittner
    So by "simple data" you just mean stuff that wouldn't be changed within a thread context?

    Take the following:
    PHP Code:
    <?php
        
    class Foo {
            public static 
    $counter 0;
        }

        class 
    Process extends Worker {
            private 
    $text "";
            public function 
    __construct($text){
                
    $this->text $text;
                
    $this->start();
            }
            public function 
    run(){
                while (
    Foo::$counter 4){
                    print 
    Foo::$counter++." - {$this->text}\n";
                    
    sleep(2);
                }
            }
        }

        
    $a = new Process("A");
        
    sleep(1);
        
    $b = new Process("B");
    Foo::$counter is entered into the thread scope but changes to it within the thread remain only in that thread. So the output of the above is:

    Code:
    0 - A
    0 - B
    1 - A
    1 - B
    2 - A
    2 - B
    3 - A
    3 - B
    Where if it had full global static scope it'd be:

    Code:
    0 - A
    1 - B
    2 - A
    3 - B
    But I think I'm just verifying what you said.

    This'll unfortunately rule out using all this for my existing app. It'd just take too much work to convert everything that'd need it.
    That is expected behaviour. As I said, Zend does not have handlers available to manage static class members, so pthreads is not able to make provisions for safe sharing of static variables and make operations safe. The only option therefore is either remove all statics, or leave simple data and keep static scope for thread locals.

    It's a shame you cannot test your app, but, would you really want to make chocolate from cheese !? I think now that multi-threading is available, and you have some knowledge of what to do and how to do it, writing your apps in the future to take advantage of multi-threading should be no bother at all...
  16. #9
  17. No Profile Picture
    Dazed&Confused
    Devshed Novice (500 - 999 posts)

    Join Date
    Jun 2002
    Location
    Tempe, AZ
    Posts
    506
    Rep Power
    128
    Originally Posted by krakjoe
    It's a shame you cannot test your app, but, would you really want to make chocolate from cheese !?
    Well, one of the key benefits of PHP over other languages, IMO, is the freedom it gives in how to program. It looks like the level of DI this needs would effectively require ZF2-like practices which, ironically, I've recently been questioning just recently in a couple other topics.

    I think now that multi-threading is available, and you have some knowledge of what to do and how to do it, writing your apps in the future to take advantage of multi-threading should be no bother at all...
    True, but the key use case for threading I could see was in making a persistent system behind sockets (or another persistent communication method) and this was going to evolve into a giant proof of concept to see if the response time of the web application would improve under this model.

    In theory I think it still should. It would effectively eliminate the overhead of loading class files, loading the config, etc., for every page load. But I'd be looking at a lot of work just for a proof of concept.

    That said, this is also a huge roadblock for me now. This system is intended to be my test bed for unorthodox PHP conventions and given much of it was designed with persistence in mind, I feel like I've failed if I don't convert for this.

    Just so much work...
  18. #10
  19. No Profile Picture
    Lost in code
    Devshed Supreme Being (6500+ posts)

    Join Date
    Dec 2004
    Posts
    8,316
    Rep Power
    7170
    The pthreads extension itself doesn't force you to program using any particular design patterns, however there are some fundamental differences between building a single-threaded application and a multi-threaded application when it comes to shared memory. In a single-threaded application, every part of the code can freely manipulate any piece of memory available to the process. In a multi-threaded application, each thread has to tread carefully when manipulating any piece of memory that is shared with another thread.

    As a consequence, not all single-threaded design patterns are easy to implement in a multi-threaded environment. Conversely, there are multi-threaded design patterns that cannot be implemented well in a single-threaded environment.

    The way you handle shared memory can also have a significant impact on the performance characteristics of a multi-threaded application. In a simplified sense, your application needs to be programmed to tell the computer how to handle shared memory efficiently, because the computer isn't able to determine that itself.

    As far as performance improvements go, for most web applications I expect that APC or another op-code cache would provide more of a performance improvement for most applications than multi-threading at the PHP level would. The complete purpose of an op-code cache is to substantially reduce the overhead of loading files for every page.
    PHP FAQ

    Originally Posted by Spad
    Ah USB, the only rectangular connector where you have to make 3 attempts before you get it the right way around
  20. #11
  21. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jul 2013
    Posts
    9
    Rep Power
    0
    Actually, pthreads does determine for itself what to do when multiple threads access the same data, the user is not required to think about it, at all. The reason is, what to do is set in stone, PHP is a shared nothing architecture and the Zend MM prohibits cross context manipulation of the interpreters environment.

    You are over complicating something simple. In other languages much thought has to be given to things that require almost no thought when writing in PHP with pthreads.

    I fail to see how APC can help you to, for example, request and process hundreds of web responses, concurrently, in a few seconds ... I'm not really sure where the comparison between APC and pthreads comes from ...

    It's worth mentioning, I think, that an opcode cache cannot execute in place, the cached opcodes are copied to every context that requires them before executing them in that context, that goes for any opcode cache in any build configuration. pthreads does much the same thing, in much the same way ... in other words, multiple threads do not incur the overhead of the compilation stage of execution, even when an opcode cache is not present, compilation only occurs in one context ... it might even be worth mentioning, that the modern (5.4+[ZO]) compiler is pretty damn fast, while researching for APCu, Rasmus said that he had a large config array that used to be loaded from the cache; it turns out that actually it is faster to allow the compiler to construct the massive array (by executed caches opcodes) than it is to cache it in the normal apc way (bitwise memcpy), the eval serializer was born ...

    Writing multi-threaded PHP should not be difficult, I'd go so far as to say, with a little bit of working knowledge of pthreads (the php extension, not Posix Threads) it couldn't actually be simpler ...

    I guess, it's partly my own fault for calling the extension pthreads ... Posix Threads and pthreads are not in the slightest connected from the PHP programmers perspective. Writing Posix Threads and pthreads are two very very very different things, and as I said, things you have to think about in other languages require no thought at all in PHP.

    It may not all be glorious, you can easily see the limits of pthreads; PHP's architecture forces it to work like no other implementation of multi-threading that I know of, which, on the one hand, means writing is simpler, and execution is less error prone, on the other hand, it consumes considerable resources in order to achieve this. Thankfully, modern CPU's are incredible, literally incredible bits of kit and are usually coupled with a shed load of RAM. Looking into the future, more cores is the only way to go and RAM is only set to get cheaper, so the limits should move with the times and hopefully not approach the impossible or impractical - in other words, we have enough now to support pthreads, and nothing is going to change ... its a matter of opinion, personally I'll gladly pay out a few quid for more cores and bytes of ram in order to provide me the ability to write using pthreads, making the most of my hardware.
  22. #12
  23. Mad Scientist
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Oct 2007
    Location
    North Yorkshire, UK
    Posts
    3,661
    Rep Power
    4124
    It's all a bit over my head at the moment, so please excuse the simplicity here.

    In my dev environment I have 4 cores. I am running the nginx webserver and have told nginx that I have 4 cores, this allows nginx to multithread across the cores, yet each request only exists in one core.

    Lets say i'm under some load and nginx is using all 4 cores, what happens to the workload of each core if I then start telling php to use other cores?

    Next question: if the ability to multithread is based on having multiple cores, and I have 4 cores - does this mean I can only have 4 concurrent threads? If so, does that limit how many threads I can spawn at a code level? (or do they get queued and executing whenever a core is free?)

    Given the framework I use (which I think would be difficult to make multithreaded as its built up of dependent layers) I would be looking at multithreading to process template chunks for a webpage request

    My goal is to reduce page load times and memory use. I'm currently using APC, which has given me about a 200% - 500% speed increase using the opcode cache (I haven't turned on the data caching layer in my app yet).
    Last edited by Northie; July 16th, 2013 at 03:51 AM.
    I said I didn't like ORM!!! <?php $this->model->update($this->request->resources[0])->set($this->request->getData())->getData('count'); ?>

    PDO vs mysql_* functions: Find a Migration Guide Here

    [ Xeneco - T'interweb Development ] - [ Are you a Help Vampire? ] - [ Read The manual! ] - [ W3 methods - GET, POST, etc ] - [ Web Design Hell ]
  24. #13
  25. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jul 2013
    Posts
    9
    Rep Power
    0
    Originally Posted by Northie
    It's all a bit over my head at the moment, so please excuse the simplicity here.

    In my dev environment I have 4 cores. I am running the nginx webserver and have told nginx that I have 4 cores, this allows nginx to multithread across the cores, yet each request only exists in one core.

    Lets say i'm under some load and nginx is using all 4 cores, what happens to the workload of each core if I then start telling php to use other cores?

    Next question: if the ability to multithread is based on having multiple cores, and I have 4 cores - does this mean I can only have 4 concurrent threads? If so, does that limit how many threads I can spawn at a code level? (or do they get queued and executing whenever a core is free?)

    Given the framework I use (which I think would be difficult to make multithreaded as its built up of dependent layers) I would be looking at multithreading to process template chunks for a webpage request

    My goal is to reduce page load times and memory use. I'm currently using APC, which has given me about a 200% - 500% speed increase using the opcode cache (I haven't turned on the data caching layer in my app yet).
    nginx may be using all 4 cores in the sense that on each core exists an instance of nginx accepting/processing connections, but it is not at any time using the entire capacity of any one core (under normal circumstances), while nginx may be non-blocking, it is only non-blocking where there is an option: Some things take time, for example, passing off an fcgi request to the php interpreter, loading a file from disk to serve as binary data or whatever, this leaves cycles up for grabs for other processes to utilize that same core, even though nginx is busy executing on all four cores, there is plenty to go around ...

    Well, before the web stack, it's safe to assume that all 4 cores are being utilized to some extent, it's pointless to worry about how the operating system will schedule the work, within reason it's simpler to say and safe to assume the work will be done by whatever means necessary (or available, hardware/software, HT, clever schedulers and the like).

    The ability to multithread existed before there were multiple cores, it's too simplistic to say that multiple threads need multiple cores, sure they help, but it is the nature of execution to require a result, and results take time, not everything can be done at the speed of light. Multithreading is useful even where there is only one core, and can provide some gains (though it's pretty pointless to try, or even talk about single core machines).

    Regarding your specific goals ... if my templates were so heavy to load I considered multi-threading, I would seriously consider if there wasn't something up with the templates in the first instance. It is not something I would chase, unless I misunderstand somehow and your templates do more than display html. It very much depends on the application, but multi-threading at the frontend is rarely a good idea, though it's possible, I leave it to you for testing

    I'm not sure how the average PHP programmer thinks; when I set out to write a system, I automatically divide the work between the front and backend, and until now, always chose another language for the backend. The backend would be resposible for aggregation, logging, in short whatever isn't serving templates I see pthreads as permission to consider PHP as a language to use for the backend.

    pthreads will execute at the frontend, inside apache even, indeed, it was a design goal. But before doing that, consider seriously if it is necessary and best.

    You mentioned that you have a data caching layer, I will take a stab in the dark and say whatever it is that generates whatever it is you want to cache, would be what I consider the backend, and if that is written in PHP it is a prime candidate to consider multi-threading.

    The best advice I can give you is: KISS, do not complicate the work of apache, nginx, fpm or smarty, think about what will happen if a single request results in more than one PHP context executing directly, consider what happens if one request turns into ten threads, then consider getting ten requests concurrently (and safely assume they will all be dispatched at once) ... see where I'm going !? Separate your work, and mind; backends are by nature complex, they have lots to do in as little time as possible, threading can help with that, frontends are simple by nature, they pull from a database/cache/service/socket (incidentally all of the aforementioned things have async/non-blocking/concurrent in some way API's that you should of course research and deploy where necessary/appropriate) information for display and spit out templates, you should not try to use threading to improve that, rely on the standard means, opcode caching and data caching (which you should immediately enable most likely before you look at optimization by any other means).

    So that's the general advice, and you should stick to it ... but to be honest, the projects that I will love the most are those that completely ignore what I say and smash my preconceptions about what is correct to bits, because who doesn't love that
  26. #14
  27. Mad Scientist
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Oct 2007
    Location
    North Yorkshire, UK
    Posts
    3,661
    Rep Power
    4124
    I only look at the templates as an example, as the way I want it to work would take up a lot more processing, and I can see where to chunk it up if I took that approach.

    Looking at the rest of my app, the request is filtered, and each filter could cut the request short. For example if the access control list says "No" then the process goes back up the filter chain and does not continue down to fetch the data or perform the action. Because I've been working in single threaded mode for so long, the whole framework process I've built myself is geared up for that and any unnecessary code just isn't executed.

    It's all moot for me at the moment as I haven't got ZTS installed
    I said I didn't like ORM!!! <?php $this->model->update($this->request->resources[0])->set($this->request->getData())->getData('count'); ?>

    PDO vs mysql_* functions: Find a Migration Guide Here

    [ Xeneco - T'interweb Development ] - [ Are you a Help Vampire? ] - [ Read The manual! ] - [ W3 methods - GET, POST, etc ] - [ Web Design Hell ]
  28. #15
  29. No Profile Picture
    Dazed&Confused
    Devshed Novice (500 - 999 posts)

    Join Date
    Jun 2002
    Location
    Tempe, AZ
    Posts
    506
    Rep Power
    128
    Originally Posted by E-Oreo
    The pthreads extension itself doesn't force you to program using any particular design patterns
    It does insofar that there's no global/static scope that's shared and changeable by threads. This breaks the conventional Singleton/Multiton patterns that traditionally store the instantiated object(s) in a static property.

    To get around this you need to inject any objects you want changeable into each thread, which effectively means following ZF2-like practices of defining an "application" object scope, putting everything into that as "services", and injecting that everywhere you need it: arguably everywhere.

    Even though you can mimic the behavior of Singletons/Multitons within that application scope, in theory you could have multiple application scopes, each with its own set of Singletons/Multitons--kind of breaking the concept of them.

    Originally Posted by Northie
    Next question: if the ability to multithread is based on having multiple cores, and I have 4 cores - does this mean I can only have 4 concurrent threads? If so, does that limit how many threads I can spawn at a code level? (or do they get queued and executing whenever a core is free?)
    I'm curious about this precise relationship as well. Namely, SHOULD we limit the number of threads our application creates?

    I'm guessing not; that threads are just a way to break work down into a smaller, pseudo-independent pieces that PHP/OS can delegate as needed. I just want to make absolutely sure.

    Keeping in mind my interface is going to be funneled through sockets and be a persistent backend application, it sounds like I simply need threads wherever asynchronous behavior is needed.

    So, standard convention would be:
    1. Loop listening to port, each new client gets its own thread
    2. Loop listening to client socket, each new command gets its own thread

    So this should allow the server to handle multiple clients concurrently, and each client can be running multiple processes concurrently.

    It'll also be possible (though rare) that a command can kick off subcommands in their own threads. The only use case in my system for this would be avatar resizing to multiple scales; each resizing operation can happen concurrently, saving notable time.

    For the morbidly curious, how I plan to do the front-end:

    I expect my preliminary front-end to simply be a small PHP script that takes a web request, converts it to a server request, sends it, and waits for the single reply. That single reply will contain the headers and content to output.

    A derivative of that, other scripts will accept web requests designed for different output formats; JSON, XML, etc. They'll interact the same with the backend except they'll be requesting a specific response format.

    Lastly, down the road, I expect I'll create a WebSocket endpoint that'll serve as a middleman between the client and my socket server. But I have a lot of research yet to do on that front.

    Edit:
    And hrm. I previously said:
    In theory I think it still should. It would effectively eliminate the overhead of loading class files, loading the config, etc., for every page load. But I'd be looking at a lot of work just for a proof of concept.
    I'm an idiot. I don't need multithreading to proof the biggest concept: the persistent server. It won't be capable of serving multiple requests at once, but I don't need it to. Not yet, anyway. I just need to see if cutting out class loading, etc. reduces browser-side load times.

    The multithreading is just needed to offset what's lost by funneling all requests through one process vs. the typical process per request.

    Sweet. And I'm an idiot.
    Last edited by dmittner; July 16th, 2013 at 06:57 PM.
Page 1 of 2 12 Last
  • Jump to page:

IMN logo majestic logo threadwatch logo seochat tools logo